A practical tuning session, not a benchmark. Everything below is a starting point for my machine, described honestly — including the parts I have not yet proven.
Why I Had to Rebuild the Setup
I had Microsoft Flight Simulator 2024 in a good place in VR. Not spectacular, but predictable: the cockpit was readable, the world outside held together, and I could fly for an hour without my inner ear filing a complaint.
Then the settings reset.
I am not going to pretend I know exactly why — an update, a profile reset, a config file that got rewritten, take your pick. What I found when I put the headset back on was the simulator’s idea of a safe fallback: a mixture of Low, Medium, and automatic values, with a frame rate cap and dynamic adjustment both switched on. It ran. It just did not feel like the setup I had spent evenings building.
So this is the rebuild. And rather than jumping straight back to the settings I vaguely remembered, I decided to treat it as a fresh tuning problem and actually work through it in order.
The Problem Was Most Obvious on the Rudder
The symptom that made this worth writing down: rapid rudder input.
Straight and level, the image looked fine. Gentle turns, fine. But stamp on a rudder pedal — swing the nose quickly left and right while sitting on a taxiway — and the whole scene came apart. Tearing, or something that read like tearing. Judder. Nearby geometry doubling and smearing. Runway markings that went briefly soft and then snapped back.
That is a useful symptom, because yaw is the meanest test in the whole simulator. When you pitch or roll, a lot of the frame stays roughly where it was. When you yaw, every pixel in the headset translates sideways at once. There is no static region for the renderer to coast on, no low-motion area for the video encoder to spend fewer bits on, and no easy prediction for reprojection to make. Rapid yaw simultaneously stresses frame pacing, reprojection, and — because this is Quest Link — the video compression sitting between my PC and my face.
Which is exactly why I did not want to start by turning settings up. Whatever was breaking, image quality was going to be the last thing I touched.
My Hardware and VR Stack
- CPU: AMD Ryzen 7 7800X3D
- RAM: 64 GB DDR5, reported by Windows at 5600 MT/s
- GPU: deliberately not named here — see below
- Headset: Meta Quest 3
- Connection: Quest Link (wired, to the PC)
- Simulator: Microsoft Flight Simulator 2024
- Also in the rig: force-feedback flight controls, plus SimHub driving bass shakers
On the GPU, a small confession that is relevant to the whole exercise. In an earlier round of troubleshooting I let a card model get assumed into the conversation on thin evidence, and everything downstream of that assumption inherited the error. The only number I actually have is a Windows readout of 18 GB of graphics memory — and that figure is not a clean VRAM value. Depending on which panel you read it from, Windows will happily report dedicated video memory plus a slice of shared system memory as one total. So 18 GB is an upper bound on an aggregate, not a spec sheet entry.
I mention it because “what GPU is this” turns out to matter a lot for the advice that follows — texture resolution and off-screen terrain pre-caching are VRAM-bound, DLAA versus DLSS is a raw-throughput question — and guessing would have made this article confidently wrong. If you are following along, go read your actual dedicated VRAM before you copy any of my targets.
One more observation I have not chased yet: 5600 MT/s is below what a 7800X3D typically likes. On AM5, a four-DIMM 64 GB configuration commonly clocks lower than a two-DIMM kit, and memory latency does show up in this simulator’s main thread. I am flagging it as an open item, not a fix. I have not tested it.
What the Reset Settings Looked Like
Here is the baseline I was handed, next to where I decided to aim. To be very clear about what this table is: the right-hand column is a set of tuning targets to test, not measured results.
| MSFS 2024 setting | After the reset | Target to test |
|---|---|---|
| Anti-aliasing | DLSS Super Resolution | DLSS Super Resolution |
| DLSS mode | DLAA | DLSS Quality first; revisit DLAA once stable |
| Foveated rendering | On, scale 50 | On, retune scale after pacing is fixed |
| FidelityFX sharpening | 100 | Reduce; 100 is aggressive on top of Link sharpening |
| Max frame rate | On, 30 | Off during diagnosis |
| Dynamic settings | On, target 35 | Off during diagnosis |
| Reprojection mode | Off | Test deliberately, both ways |
| NVIDIA Reflex | On | On |
| World scale | 100 | 100 |
| Terrain LOD | 100 | 130–150 |
| Object LOD | 100 | 100–120 |
| Off-screen terrain pre-caching | Low | High (VRAM permitting) |
| Buildings | Medium | High |
| Trees | Low | High |
| Plants / Rocks | Low / Low | Medium / Medium |
| Grass | Off | Low |
| Volumetric clouds | Low | High, only after pacing is stable |
| Texture resolution | Medium | Ultra, if VRAM genuinely permits |
| Anisotropic filtering | 4x | 16x |
| Water waves | Low | Low |
| Raytraced shadows | Off | Off |
| Shadow maps / terrain shadows | 768 / 512 | Leave until last |
The two entries I want to draw a box around are Max frame rate: On, 30 and Dynamic settings: On, target 35.
Think about what those two are asking for, together, on a headset with its own fixed refresh rate and its own reprojection logic. The simulator is being told to hold 30 FPS. A separate system inside the simulator is being told to change graphics settings on the fly to chase 35. And the VR runtime, underneath both of them, is trying to deliver frames on the headset’s cadence and will synthesise them if it cannot. That is three schedulers with three different opinions.
I am not claiming that combination caused the rudder tearing. I did not isolate it and prove it. What I am saying is that you cannot diagnose anything while it is running, because you can no longer tell which layer produced the frame you just saw. Both went off before I tested anything else.
Why VR Frame Pacing Matters More Than Average FPS
On a monitor, a frame that arrives late is a small stutter. In a headset strapped to your skull, a frame that arrives late is a world that moved wrong, and your vestibular system notices before your conscious brain does.
The number that matters is frame time consistency, not average FPS. A run that holds a rock-steady frame time will look and feel better than a run with a higher average punctuated by spikes — and the average will flatter the second one. This is why “but my FPS counter says it’s fine” and “it looks terrible when I yaw” are not contradictory statements.
Layered on top is reprojection — on the Meta side, ASW, Asynchronous Spacewarp. When the renderer cannot hold the headset’s refresh rate, the runtime locks rendering to a fraction of it and synthesises the in-between frames from motion. Done well, an ugly stutter becomes acceptable smoothness. Done badly — or, worse, intermittently — you get exactly the artefacts I was looking at: doubled edges, wobbling geometry, a picture that changes character with how fast you move.
That intermittent case is the one I most wanted to rule out. An ASW setting of Auto means the runtime decides, moment to moment, whether to engage. If the renderer is sitting right at the boundary, Auto can flip states repeatedly during exactly the kind of hard yaw I was testing with. Locking it — forcing a deliberate mode rather than leaving it to arbitration — is not necessarily the better setting to fly with. But it is the setting that makes a test repeatable, and repeatability came first.
And then there is the layer that has no equivalent on a monitor at all.
Cleaning Up Quest Link
Everything MSFS renders gets encoded to video, pushed down a USB cable, and decoded on the headset. That is a real pipeline stage with real latency and real compression behaviour, and it is uniquely bad at exactly one thing: large, fast, whole-frame motion. Which is what yaw is.
So a fast rudder input is not only a rendering stress test. It is a bitrate stress test. Some of what I was calling “tearing” could plausibly have been compression breakup rather than a dropped or badly-paced frame — and from inside the headset those two look far more alike than you would expect.
Here is my Oculus Debug Tool baseline against what I set out to test:
| Oculus Debug Tool | Observed | To test |
|---|---|---|
| Pixels per display pixel override | 0 (auto) | 0 while diagnosing |
| PC Asynchronous Spacewarp | Auto | A deliberately forced mode for the chosen refresh rate |
| Video codec | H.265 | Compare H.265 against H.264 |
| Encode resolution width | 3664 | Hold at 3664 |
| Encode dynamic bitrate | Disabled | Keep disabled — repeatability |
| Encode bitrate | 200 Mbps | Step upward from 200, not straight to the ceiling |
| Dynamic bitrate max / offset | 400 / 350 | Irrelevant while dynamic is off |
| Link sharpening | Quality | Quality |
| Distortion curvature | Low | Low |
| Local dimming | Enabled | Enabled |
| Sliced encoding | Off | Off initially |
| FOV tangent multiplier | 0;0 (default) | Default until pacing is solved |
A few notes on why these, specifically.
Dynamic bitrate stays off. Not because it is bad, but because a bitrate that moves on its own makes every A/B comparison worthless. You cannot tell whether the change you made helped when an invisible variable is also moving.
H.265 versus H.264 is genuinely a test, not a known answer. H.265 gives better quality per bit, which matters on a bandwidth-limited link. H.264 is cheaper to decode and, on some systems, lands slightly lower on latency — and it can be pushed to higher bitrates to compensate for its weaker compression. Which one wins depends on your GPU’s encoder, your headset’s decoder, and your cable. Anyone telling you one is universally correct is guessing.
Bitrate goes up in steps. 200 Mbps is not a low number. Cranking straight to the maximum is a good way to introduce link instability and then spend an evening blaming the wrong thing. Confirm the cable holds at a stable value before you push it.
Sharpening is now doubled. Link Sharpening on Quality is doing work, and MSFS was also running FidelityFX sharpening at 100. Two sharpening passes stacked on a compressed image tends to make compression artefacts more visible, not less. Turning down the in-sim one was one of my earlier moves.
Cleaning Up the MSFS Side
With the pipeline understood, the in-sim settings sort into two piles — and this distinction did more for me than any individual value:
| Mostly CPU / main-thread | Mostly GPU / VRAM |
|---|---|
| Terrain level of detail | Texture resolution |
| Objects level of detail | Volumetric clouds |
| Buildings, trees, plants density | Shadow maps, terrain shadows |
| Off-screen terrain pre-caching (streaming) | Raytraced shadows |
| Glass cockpit refresh rate | Anti-aliasing / DLSS mode |
| AI and live traffic | Anisotropic filtering |
| Weather complexity | Headset render resolution |
If your stutter is a main-thread problem, adding more GPU headroom will not fix it, and dropping textures to Low will make the picture worse for nothing. That is the trap. On a 7800X3D I have plenty of single-thread performance, but MSFS is entirely capable of finding a main-thread wall anyway — dense scenery, a glass cockpit refreshing hard, and a lot of traffic will do it on any CPU you can buy.
So while diagnosing motion artefacts I kept LOD conservative, left raytraced shadows off, and treated glass cockpit refresh rate as a real variable rather than a throwaway — a modern airliner panel is not free.
Two settings I want to single out as cheap wins for later, once pacing is sorted: anisotropic filtering and texture resolution. Anisotropic filtering is close to free on any modern GPU and directly improves the thing you stare at most in a flight sim — ground texture viewed at a shallow angle, which is to say the entire runway on approach. Texture resolution costs VRAM rather than frame time. Both buy visible quality without touching the CPU side. They are where I would spend headroom first.
DLAA versus DLSS Quality is the one I deliberately deferred. DLAA renders at full resolution and is the better image — but it is also the more expensive one, and I did not want to be paying for it while I still had an unexplained motion artefact. DLSS Quality first, DLAA reconsidered once I know the actual frame-time budget.
My Optimization Order
Stated plainly, because the order is the whole point:
- Stability — one deterministic configuration, no automatic systems adjusting anything behind my back.
- Latency — Link transport and reprojection behaviour, tested deliberately.
- Cockpit clarity — the instruments I need to actually read.
- Scenery quality — terrain, buildings, clouds.
- Everything else — supersampling, DLAA, the expensive shadow work.
Nothing moves up the list until the thing above it is settled. The temptation after a settings reset is to go straight to step 4 because that is the step you can see. That is how you end up with a beautiful simulator that makes you queasy.
How I Test Rudder and Head-Movement Smoothness
The test needs to be repeatable or it is not a test. Mine:
Park or slow-taxi at the same airport, in the same aircraft, in clear weather at the same time of day. Fix the cockpit view — no leaning, no head turning, so the only motion is the aircraft’s. Then make rapid alternating rudder inputs, hard left to hard right, and watch specific things rather than forming a general impression:
- Doubled or ghosted edges on nearby buildings and runway markings — the classic reprojection signature.
- Wobbling or rippling geometry during the swing.
- Blocky breakup or mush that resolves a beat after motion stops — that reads as video compression, not rendering.
- Head-movement latency, tested separately with a quick head turn while the aircraft is still.
- Instrument readability mid-motion, not just parked.
- GPU frame time and main-thread frame time as separate numbers.
- Whether ASW is holding one state or switching during the swing.
Then: one major variable at a time. It is slow and boring and it is the only method that produces knowledge instead of superstition. Change three things at once, get a better result, and all you have learned is that one bundle of three is better than another bundle of three.
I am not publishing before-and-after frame times, because I did not capture them rigorously enough to stand behind. What I can say qualitatively: removing the competing frame-rate governors made the behaviour legible — the picture became something I could reason about instead of a moving target. That was the actual unlock, and it happened before any setting made anything prettier.
Where I Would Push Quality Next
Once the frame-time budget is genuinely known, in this order:
- Texture resolution to Ultra, if the real VRAM figure supports it. Biggest visible gain, no main-thread cost.
- Anisotropic filtering to 16x. Nearly free, immediately obvious on the ground.
- Volumetric clouds up from Low. Expensive, and the single largest change to how the world feels out of the window. Worth the cost, but only when there is cost to spend.
- Buildings and trees to High, then terrain and object LOD upward in steps — watching the main thread, since this is the CPU-side pile.
- DLAA over DLSS Quality, or a headset resolution bump, whichever survives the frame-time budget. This is the last item on purpose.
Takeaway
The lesson I keep relearning is that a fast PC does not buy you a smooth VR flight simulator. It buys you headroom, which is not the same thing — headroom you can still spend badly, on settings that look impressive in a menu and produce a picture that comes apart the moment you move your feet.
MSFS graphics settings, the Meta runtime’s reprojection behaviour, the headset refresh rate, and the Link encoder are not four separate things to optimise. They are one pipeline, and the slowest or least predictable stage sets the character of the whole experience. Tuning any one of them in isolation is how you end up chasing a symptom around a settings menu for a week.
So: establish predictable frame pacing. Eliminate the obvious motion artefacts. Stabilise the Link transport so what leaves the GPU is what arrives at your eyes. Then spend what is left on textures, clouds, scenery, and supersampling.
Layers, in that order. The pretty part comes last, and it looks better when it does.
These settings are specific to my machine, and Meta runtime or MSFS updates can change how any of them behave. Treat every value here as a starting point for your own testing, not a universal best-settings list — and where I have described something as untested or unverified, I mean it literally.