Second in a short series on VR and simulation. The first post — my complete MSFS 2024 + Quest 3 VR optimization guide — covers the full settings rebuild. This one is about the single symptom that started it, and how to work out which layer is actually producing it.
The Simulator Looked Fine Until I Touched the Rudder
Straight and level, everything was fine. Gentle turns, fine. Cockpit readable, world holding together, no complaints from my inner ear.
Then I put a boot on the rudder pedal.
Swing the nose hard left and right while sitting on a taxiway, and the whole scene came apart. Something that read like tearing. Judder. Nearby geometry doubling and smearing. Runway markings going briefly soft and snapping back a beat later.
The interesting part is that nothing about the average performance had changed. The frame counter looked the same during the swing as it did pointing down the runway. Whatever was breaking, it was not showing up in the number most people use to decide whether a setup is working.
Why Rudder Movement Is Such a Brutal VR Test
Yaw is the meanest input in the simulator, and it is worth understanding why before touching a single setting.
When you pitch or roll, a good part of the frame stays roughly where it was. Sky above, ground below, cockpit fixed in your view. There is always some region of the image that is not moving much.
When you yaw, every pixel in the headset translates sideways at once. There is no static region for the renderer to coast on. There is no low-motion area for the video encoder to spend fewer bits on. And there is nothing easy for reprojection to predict, because the entire scene is sliding in one direction and the depth relationships between near and far objects are changing fast.
So a hard rudder input stresses frame pacing, reprojection, and video compression simultaneously. That is what makes it a good diagnostic. It is also what makes it confusing: three different failures all show up at the same moment, and they look more alike than you would expect.
My MSFS 2024 + Quest 3 Setup
- CPU: AMD Ryzen 7 7800X3D
- RAM: 64 GB DDR5
- GPU: not named here — see below
- Headset: Meta Quest 3
- Connection: Quest Link, wired
- Simulator: Microsoft Flight Simulator 2024
On the GPU: the only figure I have is a Windows readout of 18 GB of graphics memory, and that is not a clean VRAM number — Windows will report dedicated video memory plus a slice of shared system memory as a single total, depending on which panel you read it from. So it is an upper bound on an aggregate, not a spec-sheet entry. I am not going to name a card on that basis, because an earlier round of this troubleshooting did exactly that and everything downstream inherited the error.
It matters more than it sounds. Whether texture resolution and off-screen pre-caching have room is a VRAM question, and whether DLAA is affordable is a raw-throughput question. Go read your actual dedicated VRAM before copying anything below.
The Settings I Found After the Reset
The full baseline and where I aimed it is in the first post. Here are only the ones that matter for this symptom.
| Setting | Observed | Troubleshooting target | Why it matters for yaw |
|---|---|---|---|
| Max frame rate | On, 30 | Off while diagnosing | An arbitrary cap fights the runtime’s own scheduling |
| Dynamic settings | On, target 35 | Off while diagnosing | Changes graphics mid-test, so no two runs compare |
| Reprojection mode | Off | Test deliberately, both ways | Without it, dropped frames show as raw stutter |
| PC Asynchronous Spacewarp | Auto | Force a mode for the test | Auto can switch state during the swing |
| DLSS mode | DLAA | DLSS Quality first | Full-res AA is the expensive option; buy headroom first |
| FidelityFX sharpening | 100 | Reduce | Stacks on top of Link Sharpening, amplifying artifacts |
| Encode dynamic bitrate | Disabled | Keep disabled | A bitrate that moves on its own invalidates every A/B |
| Encode bitrate | 200 Mbps | Step up from 200 | Fast lateral motion is the hardest case to compress |
| Encode resolution width | 3664 | Hold | Changing two encode variables at once tells you nothing |
Look at the first two rows together. 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. Underneath both, the VR runtime is trying to deliver frames on the headset’s own cadence and will synthesise them if it cannot.
That is three schedulers with three different opinions. I am not claiming that combination caused the 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 looked at.
There Is More Than One Kind of “Tearing”
This is the part I wish I had understood first. “Tearing” gets used for at least five distinct failures, and they live in different layers of the pipeline. Learning to tell them apart is most of the diagnosis.
| What you see | What it looks like | Likely layer |
|---|---|---|
| Judder | Scene advances in uneven steps rather than sliding smoothly | Frame pacing — frames arriving late or unevenly |
| Double image | Edges duplicated during rapid motion, resolving when you stop | Reprojection / ASW synthesising a frame |
| Wobble | Buildings, cockpit edges or runway markings appear to bend or flex | Synthetic-frame artifact — reprojection guessing badly |
| Compression smear | Fine detail breaks into blocks or mush, then sharpens a beat later | Quest Link encode — bitrate or codec |
| Head-turn lag | The world feels like it is following your head rather than attached to it | Cumulative pipeline latency, not any single stage |
The tell for compression smear is timing: it resolves after the motion stops, because the encoder catches up once there is less to describe. Reprojection artifacts do the opposite — they exist only during motion and vanish the instant it ends. Judder is visible in the movement itself rather than in the objects.
Once I started asking “which of these five is this?” instead of “why is it tearing?”, the problem became tractable.
The Pipeline You Are Actually Debugging
A frame in this setup passes through seven stages before it reaches your eyes:
- MSFS main thread prepares the scene
- GPU renders it
- The VR runtime schedules presentation against the headset refresh
- ASW or reprojection may synthesise or adjust frames
- Quest Link encodes the frame to video
- USB transport carries the stream
- The Quest decodes and displays it
Stages 5 through 7 do not exist when you play on a monitor. That is the single biggest conceptual difference between tuning a flat sim and tuning this one, and it is why advice copied from a desktop performance guide only gets you partway.
The practical consequence: lowering graphics settings only helps if your problem is in stages 1, 2 or 4. If it is in 5 or 6, you can drop every slider to Low and the smear will still be there.
Step 1: Stop the Settings From Fighting Each Other
Before testing anything, turn off everything that changes state on its own — the in-game frame cap and the dynamic settings system. Not because they are bad, but because a moving variable makes every comparison worthless.
This is the least satisfying step and the one that actually unlocked the problem for me. Removing the competing governors did not make anything prettier. It made the behaviour legible — a thing I could reason about instead of a moving target.
Step 2: Test ASW and Reprojection on Purpose
ASW set to Auto means the runtime decides, moment to moment, whether to engage. If your renderer is sitting near the boundary, Auto can flip states repeatedly during exactly the hard yaw you are testing with — and a transition between modes is far more visible than either mode is on its own.
So force a deliberate mode for the test. Not because forced is better to fly with — it may not be — but because it makes the test repeatable. Then watch specifically for whether artifacts are continuous or only at transitions. Those point at different fixes: continuous means your render load is genuinely over budget, transitional means you are hovering at the threshold and need headroom either side of it.
Test MSFS’s own reprojection deliberately too, in both states, rather than leaving it ambiguous.
Step 3: Get the Render Load Under Control
Settings sort into two piles, and this distinction did more for me than any individual value.
CPU / main-thread: terrain LOD, object LOD, scenery density, glass cockpit refresh rate, traffic, weather complexity. GPU / VRAM: texture resolution, clouds, shadow maps, DLSS mode, headset render resolution, anisotropic filtering.
If your stutter is a main-thread problem, adding GPU headroom will not fix it, and dropping textures to Low makes the picture worse for nothing. A 7800X3D has plenty of single-thread performance and MSFS will still find a main-thread wall given dense scenery and a busy glass panel.
While diagnosing motion: keep terrain LOD around 130–150 and object LOD around 100–120 as a starting point, drop glass cockpit refresh on panel-heavy aircraft, leave ray-traced shadows off, and hold clouds at Low until the motion is stable. Clouds are the single most expensive thing you can turn up, and the most tempting.
Step 4: Don’t Forget Quest Link Encoding
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 it is uniquely bad at exactly one thing: large, fast, whole-frame motion.
Which is what yaw is. So a rudder test is not only a rendering test — it is a bitrate test.
Keep dynamic bitrate off while diagnosing, for the same reason as the in-game frame cap: a value that moves on its own makes A/B comparison meaningless. Step the bitrate up from 200 Mbps rather than jumping to the ceiling — 200 is not a low number, and cranking to maximum is a good way to introduce link instability and then spend an evening blaming the wrong thing.
Compare H.265 and H.264 rather than assuming. H.265 gives better quality per bit, which matters on a bandwidth-limited link. H.264 is cheaper to decode, can land slightly lower on latency on some systems, and can be pushed to higher bitrates to make up for weaker compression. Which wins depends on your GPU’s encoder, your headset’s decoder and your cable. Anyone who tells you one is universally correct is guessing.
One thing worth checking that is easy to miss: if in-sim sharpening is high and Link Sharpening is on Quality, you are running two sharpening passes over a compressed image. That tends to make compression artifacts more visible, not less.
My Repeatable Rudder Test
Copy this. It takes two minutes and it is the difference between knowledge and superstition.
Park or slow-taxi at the same airport, in the same aircraft, in clear weather at the same time of day. Fix your head — no leaning, no looking around — so the only motion is the aircraft’s. Then make rapid alternating rudder inputs, hard left to hard right, and check specific things rather than forming a general impression:
- Doubled edges on nearby buildings and runway markings
- Wobbling or bending geometry during the swing
- Blocky breakup that resolves after the motion stops
- Instrument readability mid-motion, not just parked
- GPU frame time and main-thread frame time as separate numbers
- Whether ASW holds one state or switches during the swing
Then change one major variable at a time and repeat the identical motion. It is slow and boring and it is the only method that produces knowledge. Change three things, get a better result, and all you have learned is that one bundle of three beats another bundle of three.
I am not publishing before-and-after frame times, because I did not capture them rigorously enough to stand behind. Qualitatively: the artifacts became identifiable long before they became rare, and identifying them was the actual progress.
Once Motion Is Stable, Turn the Quality Back Up
In this order, and only once you know your frame-time budget:
- Texture resolution — biggest visible gain, costs VRAM rather than frame time
- Anisotropic filtering to 16x — nearly free, and it fixes ground texture at shallow angles, which is the entire runway on approach
- Volumetric clouds — expensive, and the largest change to how the world feels out the window
- Buildings, trees, then terrain and object LOD — upward in steps, watching the main thread
- DLAA over DLSS Quality, or a headset resolution bump — last, on purpose
What I Learned
The thing that actually changed my approach was realising that “tearing” is a symptom vocabulary problem before it is a settings problem. Five different failures, five different layers, one word covering all of them — and every settings guide on the internet answering a question you have not yet established you are asking.
Rapid yaw is a good diagnostic precisely because it stresses every stage at once: main thread, GPU, runtime scheduling, reprojection, and the video encoder. That makes it brutal, and it also makes it informative, as long as you can name what you are looking at.
Get frame pacing predictable. Make reprojection behaviour deliberate rather than automatic. Confirm the render load fits. Stabilise the Link transport so what leaves the GPU is what arrives at your eyes. Only then spend the remaining headroom on quality — and re-run the rudder test after each step, because the whole point is to notice the moment the artifacts come back.
Coming up in this series: Quest Link optimization for flight simulation, ASW and reprojection explained for flight simmers, and DLAA versus DLSS in MSFS 2024 VR.
VR performance depends heavily on headset refresh rate, GPU, CPU, aircraft, scenery, runtime version, and Meta/MSFS updates. Treat every value here as a tuning starting point rather than a universal setting — and where I have described something as untested, I mean it literally.