Star Citizen Settings and Low FPS: What to Change First

Official RSI Launcher interface illustration

Choose useful starting settings, identify what is limiting performance and separate graphics problems from memory pressure, loading hitches and server delays.

A low frame rate throughout a Star Citizen session, a short pause when an area loads and a door that refuses to open can all feel like poor performance, but they need different investigations. Graphics settings can reduce the work your PC does; they cannot repair a stalled server interaction.

For an initial setup, use your display’s native resolution, keep textures within the graphics menu’s video-memory budget, and try a quality-focused upscaling mode. Begin with moderate cloud detail and disable motion blur or film grain if you prefer a clearer image. Compare these choices in the places you actually play.

Graphics settings worth changing first

Photograph your existing settings before changing them. Keep the same location and camera view for comparisons, then repeat a short movement through that area. A quiet hangar and a crowded city are different workloads; changing location at the same time as a setting makes the result difficult to interpret.

Resolution and upscaling

Keep the display output at its native resolution initially. If the graphics card is struggling, try DLSS on a supported Nvidia card or CIG-TSR on other hardware. CIG recommends these options in its graphics guidance. Start with the mode that favours image quality, then compare a more aggressive mode if necessary. Inspect fine cockpit lettering, moving edges and distant objects as well as the FPS counter.

Upscaling renders from a lower internal resolution. It can relieve a GPU limit, but a softer or less stable image may be the cost. If reducing resolution barely changes performance, stop sacrificing clarity and investigate the CPU, memory and the scene instead.

Textures and video memory

Use the graphics menu’s VRAM estimate to choose texture quality. Stay below the indicated limit, allowing room for other applications. A red warning is a reason to reduce demand. Lower textures first when memory is tight; they affect surface detail, whereas reducing resolution changes the whole image.

Clouds, detail and image effects

Begin with a medium cloud setting where available, then compare a lower setting while looking at the same cloud-heavy view. Lower cloud quality can make the sky less detailed or more visibly reconstructed. The benefit will depend on the scene; an empty-space test does not tell you how Orison will behave.

Leave terrain and object-distance settings at a moderate level for the first comparison. Reduce them individually if the scene remains slow, watching for earlier detail changes or objects appearing closer to you. Avoid changing the entire preset after every test: it moves several controls and obscures which one helped.

Motion blur, film grain and chromatic aberration are largely presentation preferences. Turning them off can make text and movement easier to judge, but do not expect them to rescue a heavily limited PC. Keep field of view at a comfortable value rather than narrowing it until flying becomes awkward.

Frame caps and synchronisation

Check for an existing frame cap or VSync before treating a flat FPS reading as a fault. A cap deliberately limits output; synchronisation can reduce tearing. For diagnosis, compare briefly without an artificial cap, then restore the presentation you prefer. After testing, a cap can reduce fluctuations above your chosen target; demanding scenes can still fall below it.

A practical sequence for low-FPS troubleshooting

  1. Check compatibility and storage. Compare the machine with our Star Citizen system requirements guide. Confirm that the game itself is on an SSD and that the drive has room for updates and paging.
  2. Record the conditions. Note the build, renderer, resolution, location and whether the problem began after a patch or driver change. Close unnecessary recording, browser and overlay software for a clean comparison.
  3. Test graphics demand. Lower internal resolution or choose a stronger upscaling mode. If performance improves materially in the same view, graphics load is a useful place to concentrate.
  4. Check utilisation and memory together. Use Windows Task Manager or your GPU vendor’s monitoring overlay. Look for exhausted memory, sustained graphics load or a few busy CPU cores. A single total CPU percentage can hide a saturated thread.
  5. Repeat in a second location. Compare the troubled landing zone with a station or quiet interior. Keep a separate note for each; do not average away the location where you actually want to play.
  6. Check known issues before reinstalling. A renderer regression or game bug needs a different response from a damaged download. If installation integrity is suspect, use the launcher’s Verify option before considering a full reinstall.

GPU utilisation is a clue, not a verdict. Low utilisation can mean the GPU is waiting for other work, but a frame cap, loading, power limits and background activity can produce similar readings. On a laptop, confirm the game is using the discrete graphics card and the manufacturer’s normal plugged-in gaming mode. Do not use an overclock as a troubleshooting baseline.

When performance is limited by CPU-side work, reducing output resolution may make little difference. Busy scenes can require more simulation, object handling and rendering preparation. Turning every setting to its lowest value is therefore not a reliable cure, and neither is the old advice that every PC should use the highest preset.

Memory pressure, shaders and brief pauses

If Windows is short of system memory, close applications you do not need and keep the pagefile enabled. CIG’s memory guidance recommends automatic management as a straightforward starting point. A pagefile helps prevent allocation failures; it is slower than physical RAM and is not an FPS upgrade.

Brief hitches need a different comparison from a consistently low frame rate. Loading assets and preparing shaders can interrupt otherwise smooth movement. Star Citizen has used shader caches and asynchronous compilation for years; that does not establish a fixed warm-up time for every current build. Let any visible shader preparation finish, then repeat the same route before judging a setting.

Do not repeatedly clear caches to chase higher FPS. Removing cached work can require it to be rebuilt. If a current patch instruction specifically calls for a cache reset, follow that instruction and distinguish the first run from later comparisons. Avoid deleting the entire USER folder simply because an old performance guide says to: it can also remove personal settings and control profiles.

For persistent allocation errors, follow CIG’s memory troubleshooting. For control-profile backups, see our HOTAS and dual-stick setup guide.

DirectX or Vulkan?

Use the renderer that behaves reliably on your current hardware and driver. Vulkan is designed to reduce CPU overhead, but that does not make it the faster or more stable choice in every Star Citizen build.

CIG’s Alpha 4.10.2 known-issues page identifies Vulkan frame-rate loss and a crash associated with Nvidia driver 616.56. For those symptoms, DirectX 11 is an official fallback. This specific warning takes precedence over a blanket instruction to install the newest driver and always select Vulkan.

If the game still opens, change the renderer through its graphics options and restart when requested. If Vulkan prevents launch, our Vulkan crash guide explains CIG’s configuration-file method for returning to DirectX. Preserve existing configuration entries rather than replacing the file with an unknown downloaded preset.

Use stable drivers from the GPU manufacturer. When a problem begins immediately after a driver change, record the version and check the current CIG issue rather than assuming the hardware has become inadequate. Driver-level frame-generation overrides can also complicate diagnosis; disable your own override temporarily if it is causing black screens or confusing comparisons.

Client FPS and server performance measure different work

Client FPS describes how frequently your PC presents frames. Server performance concerns the simulation and services supporting the shared world. A server’s simulation rate is not a numerical cap that your monitor’s FPS must match.

A smooth camera with delayed doors, purchases or NPC responses points towards interaction or service trouble rather than simply expensive graphics. Both types of problem can occur together. Compare another session when practical and check RSI service status; lowering texture quality cannot make a stalled transaction complete.

If the fault is repeatable, report the location, steps, hardware, driver and renderer through the Issue Council. Describe what changed during the comparison. An FPS number without those conditions is much less useful than a reproducible example.

Crashing after a renderer change?

Follow the focused Vulkan guide to return to DirectX when the game will not open. Keep your existing control and configuration files intact.

Open the Vulkan troubleshooting guide