Glide

The issue there is the amount of time it takes to test. I have a mission that has a little bit of everything, so I just need the one for testing.

When it comes to performance testing and finding optimal settings, it's important to have a favorite testing mission where you are familiar with the visuals. It is also very important to change only one thing at a time when you are tuning settings. I am happy to help.

This may seem counter intuitive, but you want to be GPU bound which means you want to add more work for the GPU. It's okay if you can't stay at 60fps. I assume your monitor is 60hz. 40fps or 50fps is just fine. HAGS on, no full screen, Windows Flip Mode Enabled in Windows 11. Run the highest resolution you can. If you run MSAA, you can Enhance it to 8x and add transparency antialiasing to make the GPU work even harder. MSAA x4 in Game, NCP Enhance AA x4 (or higher), Transparency AA Multisample or Supersample if you really want load. This only works with MSAA, not DLSS or TAA. I would turn off VSYNC and GSYNC because they let the GPU rest. Make sure it's off in the monitor, the NCP, and the game. No reflex or low latency mode.

You are on steerpoint 7 in that pic. Try it again with the Drift C/O switch set.

Engine 1 out.

These settings are for my 3080Ti and Pimax Crystal. 72hz fresh rate. I believe these settings are ideal. I run the headset at Maximum resolution with Dynamic Foveated Rendering enabled in the headset. No Smart Smoothing, so no ASW. Nothing in the Nvidia control panel. No Low latency mode at all. Restore defaults and forget about them. No Quadviews. No frame locks, no refresh rate locks. HAGS on, and windows Flip Mode Enabled in Windows 11. Turbo Mode on, or Prefer Frame Rate over Latency enabled in PimaxXR companion. The goal here is to be GPU bound. You want to add work for the GPU without exceeding your VRAM limit. I get around 50fps with this setup. I never see any desyncs. It is incredibly smooth. Use the OpenXR Toolkit FPS counter on Advanced to tune your VRAM limit and get app GPU frame times around 20ms. Just so you know what I'm on about here, with an app GPU time of 20ms, the GPU is controlling the pace of the entire pipeline. Try this on Marianas with Overcast and Rain in the TF51D. I get about 30fps in that scenario, but it's a very stable 30fps. You can vary the ground details (grass, forest, etc.) as desired.

Engine 1 out.

So, who doesn't love chasing SU-25T's around in this beauty? I am loving this flight model.

The F-16 is superior to the F/A-18 because when you lose in a F-16, you lose in beautiful design. When you lose in a Hornet, you're in a Hornet.

Map it to toggle.

Wowsers! My Viper is jealous already.

This is great news! Go team!

Thanks for clarifying.

On the Kola map, every so often two cars go by stuck together. Not sure if this is a Kola issue.

If you have Birds enabled, you may notice that the birds fly under the water at times. The code that controls how the birds fly must have limitations in it with respect to altitude.

I thought it was some kind of foveated rendering trick where only the center got MSAA applied to it. Thank for clarifying.

So, it makes the mirror lighter weight by adding the mask around the edges.

DCS and Heatblur at 9:42

What do you mean by "cut out"?

Correct. Jabbers has a good video on this on Youtube. Multithreading blasts the system with I/O requests when the mission is heavy and there are a lot of textures and shaders to load. Process Lasso and CPU affinity seem to relieve the pressure.

BTW, even when you are fully synced at 72hz/72fps, if it's still not smooth, lower the resolution of the headset. On the Kola map it's still not smooth for my Crystal/3080Ti at full resolution, but running it at a lower resolution solves this. The FPS counter in OpenXR toolkit has a developer mode (show advanced settings under System). https://mbucchia.github.io/OpenXR-Toolkit/overlay.html There are other measures like how long it takes to present to the headset, etc. that may come into play with respect to smoothness.

Not quite true. When you achieve 72fps with 72hz, you are CPU bound. To be GPU bound, you can set your refresh back to 120hz, and raise the settings that impact the GPU. Be careful you don't exceed your VRAM limit. When you are GPU bound, with the system will give those judder effects because of the old frames. Easy way to test this, set the refresh rate to 120hz, and lock the frame rate to 30fps. This is the extreme case. Looking straight ahead you don't notice it much. I prefer being GPU bound and just not looking out sideways, however, in a dogfight, the aircraft that whiz across your view port will be juddering. Watch the runway lights as you take off to clearly see the juddering. I should note this is not something DCS can solve, and it does not mean there's something wrong with your system. It's built into VR. Every VR game will do this, and every headset will see this. ASW, motion reprojection, smart smoothing, etc. are supposed to solve this by creating synthetic frames that try to compensate for the timing issue, but that's a work in progress.

The only way to eliminate this issue, called Judder, is to maintain FPS equal to your refresh rate. Set your headset to 72hz, and tune your settings to maintain 72fps. Judder happens all the time when you are GPU bound because the system is sending "old" frames which are slightly out of sync with the game. This video is a bit dated, and it's mostly about Unity, but the concepts are the same for every system.

Just to drill down a bit on this, I turned off Turbo Mode to see the correct frame times. I'm set to 72hz, so the vsync time is 14.1ms. This is why you want 72hz vs 90hz or 120hz. The higher the refresh rate, the less time Directx and the GPU have to complete their tasks. Ignore the Headroom lines for now. app CPU is DCS, so DCS is taking 2.6ms to make a frame. rdr CPU is DirectX which is taking 5.6ms to package up the frame for the GPU. app GPU is the GPU processing the frame in 10.7ms. This means the GPU has plenty of time to finish the frame before it has to sync again with the headset on the next 14.1ms mark. The problem happens when the rdr CPU (directx) stage exceeds 14.1ms. When this happens, directx can't finishing in time for the next vsync with the headset. This causes a drop in FPS, and the spiky behavior you see in the FPS counter. The goal is to have app GPU frame times with enough headroom so the GPU will always be able to send a frame at each vsync mark, and the rdr CPU DirectX calls never exceed the vsync interval. This is exactly what was happening in the Apache mission on Caucasus map. On the Persian Gulf map, in the Viper, the rdr CPU stages stayed below the threshold consistently. What happens when you are GPU bound and app GPU frame times are say 20ms? The system will send "old" frames to the headset, which will be slightly out of sync with your position in the game. This causes the judder or double vision you get with the runway lights whizzing past you. When everything is synced up like in the screenshot, the GPU will always have a new frame that matches exactly to your position, and everything will be smooth.

These settings are perfection for my system. Note the rdr CPU and app GPU frame times. No de-syncs.