Constant terrain stutter on MT

[fab.13]

Thanks for your complete report @Sile

I have tried playing with Shadows because micro stutter were sporadic and relative to the sun direction, and bingo !

Result test with OpenXR with Turbo Mode :

- MT Free Flight OpenXR Turbo Off : micro stutter above city when looking right left side ( the only place )
- MT Free Flight OpenXR Turbo ON : smooth everywhere ( Good ! )
- MT MultiPlayer OpenXR Turbo Off : stutter on airfield ( unplayable )

- MT MultiPlayer OpenXR Turbo ON : smooth but airplane double vision above AirField, FPS divided by 2 above AirField

- MT MultiPlayer Occulus API  : smooth and clean airplane flying ( better option for multiplayer on my side )

Edit: i setted Q2 to 120hz in order to get 60 hz in DCS : Multiplayer is now good with OpenXR Turbo ( 1080ti ) 

 

 

Edited June 10, 2023 by fab.13

[obious]

To chime in here, I was having terrible micro stuffers until I enabled turbo mode now they’re 98% gone. I wonder what Turbo Mode does to help combat micro stuttering 

[Hoirtel]

On 6/6/2023 at 6:50 PM, fab.13 said:

Thanks for your complete report @Sile

I have tried playing with Shadows because micro stutter were sporadic and relative to the sun direction, and bingo !

Result test with OpenXR with Turbo Mode :

- MT Free Flight OpenXR Turbo Off : micro stutter above city when looking right left side ( the only place )
- MT Free Flight OpenXR Turbo ON : smooth everywhere ( Good ! )
- MT MultiPlayer OpenXR Turbo Off : stutter on airfield ( unplayable )

- MT MultiPlayer OpenXR Turbo ON : smooth but airplane double vision above AirField, FPS divided by 2 above AirField

- MT MultiPlayer Occulus API  : smooth and clean airplane flying ( better option for multiplayer on my side )

Edit: i setted Q2 to 120hz in order to get 60 hz in DCS : Multiplayer is now good with OpenXR Turbo ( 1080ti ) 

 

 

 

How do you run the MT client without openxr? I would like to try the oculus runtime. 

[Qcumber]

9 hours ago, obious said:

To chime in here, I was having terrible micro stuffers until I enabled turbo mode now they’re 98% gone. I wonder what Turbo Mode does to help combat micro stuttering 

I get terrible spikes in frame time when I enable turbo mode. These are regular, about 1hz and cause a huge drop in frame rate. I can mitigate this by capping frame rate to just below the headset rate (e.g. 70 fps for 72hz). This then reduces the microstutters. However if the game latency increases and as a result fps drops (e.g. below about 40) then the spikes come back. The only solution then is to run at 90hz and use space warp to run at 45. But that then negates the use of turbo mode. I feel like I'm in catch 22. Any ideas? 

[fab.13]

Hello,

if you disable openxr runtime ( through windows registry because occulus setting is blocked on ), DCS will use occulus native api

check the runtime used in DCS log

 

i’ll redo some tests about turbo mode, it was the only way to delete stutters and get smooth experience in a simple free flight ( i don’t look at spike …)

 

such suggested setting to test : 

 

Edited August 13, 2023 by fab.13

[Gryzor]

On 6/6/2023 at 7:50 PM, fab.13 said:

Thanks for your complete report @Sile

I have tried playing with Shadows because micro stutter were sporadic and relative to the sun direction, and bingo !

Result test with OpenXR with Turbo Mode :

- MT Free Flight OpenXR Turbo Off : micro stutter above city when looking right left side ( the only place )
- MT Free Flight OpenXR Turbo ON : smooth everywhere ( Good ! )
- MT MultiPlayer OpenXR Turbo Off : stutter on airfield ( unplayable )

- MT MultiPlayer OpenXR Turbo ON : smooth but airplane double vision above AirField, FPS divided by 2 above AirField

- MT MultiPlayer Occulus API  : smooth and clean airplane flying ( better option for multiplayer on my side )

Edit: i setted Q2 to 120hz in order to get 60 hz in DCS : Multiplayer is now good with OpenXR Turbo ( 1080ti ) 

 

 

 

If I enable with OpenXR the turbomode, I have constant pauses (pico 4 HMD). Do you put any other option to get fluid movement?

[fab.13]

9 hours ago, Gryzor said:

If I enable with OpenXR the turbomode, I have constant pauses (pico 4 HMD). Do you put any other option to get fluid movement?

Yes, i have to put Shadow On !

See my previous post:

 

[Gryzor]

4 hours ago, fab.13 said:

Yes, i have to put Shadow On !

See my previous post:

 

What shadows do you refer? TERRAIN SHADOW? could you post your settings plz? (I have other shadows ON, except terrain ones).

[fab.13]

11 hours ago, Gryzor said:

What shadows do you refer? TERRAIN SHADOW? could you post your settings plz? (I have other shadows ON, except terrain ones).

 

[PinkCube]

It seems that this thread has been hi-jacked with users experiencing a different problem.

This issue is very specific to the terrain moving badly as viewed from your own cockpit. I experience this while having a constant 180FPS. The following recording is only in 60FPS, and doesn't necessarily show the full detriment of this issue, however it still highlights the issue.

Here is a video of the issue that needs to be resolved.
 

 

[MoleUK]

9 minutes ago, PinkCube said:

It seems that this thread has been hi-jacked with users experiencing a different problem.

This issue is very specific to the terrain moving badly as viewed from your own cockpit. I experience this while having a constant 180FPS. The following recording is only in 60FPS, and doesn't necessarily show the full detriment of this issue, however it still highlights the issue.

Here is a video of the issue that needs to be resolved.
 

 

^ This is a good capture of the problem. Look closely. It's been present since the rollout of MT afaik, and feels MUCH more noticeable in VR.

[TOViper]

I can clearly see in the video what you are talking about. I am currently figuring out on my rigs if it has something to do with the available performance overhead. For my (weak) rigs, it seems that if the performance overhead is high (because I use the very lowest graphic settings), the less stutter I have. It's a complex problem I think ... and the more I test and read, the more I have the impression that the terrain itself is somehow rated lower to be displayed right in time within the DCS engine.

I don't know if my perception is right, but I have the impression that the terrain moves about a certain distance (lets say 100m within e.g. 100 frames), and then at the 101th frame it suddenly "jumps" 20 meters more (where just only one meter more would be good to have it fluent). I know that the position of the aircraft should be at 120m, but why does the aircraft move just 100m within the first 100 frames when 120m would have been necessary? (if you don't understand what I want to ask, ... never mind ... hard to describe at the moment )...

 

Edited August 26, 2023 by TOViper

[MoleUK]

18 minutes ago, TOViper said:

I can clearly see in the video what you are talking about. I am currently figuring out on my rigs if it has something to do with the available performance overhead. For my (weak) rigs, it seems that if the performance overhead is high (because I use the very lowest graphic settings), the less stutter I have. It's a complex problem I think ... and the more I test and read, the more I have the impression that the terrain itself is somehow rated lower to be displayed right in time within the DCS engine.

I don't know if my perception is right, but I have the impression that the terrain moves about a certain distance (lets say 100m within e.g. 100 frames), and then at the 101th frame it suddenly "jumps" 20 meters more (where just only one meter more would be good to have it fluent). I know that the position of the aircraft should be at 120m, but why does the aircraft move just 100m within the first 100 frames when 120m would have been necessary? (if you don't understand what I want to ask, ... never mind ... hard to describe at the moment )...

 

 

I have tried to wrap my head around it since it first started occuring. It does not appear related to FPS or frametime, which is very odd.

It's very random as to when it happens and when it doesn't. I haven't yet seen a single metric that indicates when it's happening and when it's not, other than my eyeballs.

Edited August 26, 2023 by MoleUK

[PinkCube]

A quick update. It seems that I may have found a fix.

I decided I would set my max frame-rate to 165 in graphics.lua match my monitor refresh ratenull

This removed the stuttering effect but highlights a almost "STATIC" horizontal strip across my monitor that contains visual tearing and moves the terrain as it passes through.

Test #2
maxfps=164, Terrain stutter gone. The tearing horizontal strip scans my screen DOWNWARDS and pulses ~1 second

Test#3
maxfps=166, Terrain stutter gone. The tearing horizontal strip scans my screen UPWARDS and pulses ~1 second.

The "pulse" effect with lack of better word to describe it is what alters the position of objects. Edit: tearing solved with vsync turned on in nvidia control panel

Test#4
maxfps=165 in a heavy multiplayer mission with frame-rates peaking around 100-120 . Things seem slightly smoother, however any stutters could now be linked to an actual frame-time issue. And hard to pin down exactly if my fix worked and if it only works when the game is running at 165hz.

null

Edited August 27, 2023 by PinkCube

[Glide]

This is a tricky problem to solve.  Just a few notes: HAGS off and Low Latency Mode Ultra (NCP) go together.  If you use Ultra Low Latency, you MUST be GPU bound (GPU frame times higher than CPU frame times).  So, with HAGS off and Low Latency Mode Ultra, you want to turn UP the graphics settings to make the GPU work harder.  The one big exception to this rule is Visibility Range.  The higher the Visibility Range, the more the CPU has to work.  Try Medium or Low.

Also, Turbo Mode ignores latency timing and spams frames at the headset as fast as it can.  This can sometimes work if all the timings are just right, but it can misfire now and then causing a big stutter instead of those constant small stutters.

Long story short, in the time it takes to make a frame and display it, objects that are moving rapidly across the view port (looking down or out to left or right) are captured in the frame with a tiny change in position.  Looking straight ahead, you don't see this effect at all, but objects that are close to you and moving rapidly across the view port will exhibit this lag.  In VR, motion reprojection is designed to correct for this lag, but MR is not quite perfect just yet. 

I have trained myself to keep my eyes within 45 degrees of forward until I am far enough above the terrain that it is not noticeable. 

If you want to experiment, try HAGS off, Low Latency Mode Ultra, MSAA OFF, SSAA OFF, AF OFF, and Visibility Range Low.  Try difference resolutions with these settings.  However, these settings are no fun to play with daily. 

Edited August 27, 2023 by Glide

[PinkCube]

After experimentation. These two settings provided a half fix for me. Edit: update on "fix" in later post

Graphics.lua maxfps=refreshrate & Nvidia settings v-sync fast + app controlled refresh rate

 

Edited August 28, 2023 by PinkCube

[Glide]

The problem is not on the GPU side of the equation.  A flight sim, like all computer games, is a big loop.  Once per loop, the CPU has to calculate the position of all the objects in the sim, build a frame based on the view port, and send that frame off to the GPU.  When objects are close to the view port and moving rapidly across it, there is an opportunity for those position calculations to be ever so slightly off.  This has to do with the angle between the object and the center of the view port changing by a large amount.  Objects that are coming straight at the view port, or are far away and moving across, change by only a small amount.  This is why when you look straight ahead you see no stutter, but when you look to the side the issue becomes visible again.  This is a problem only the developers can solve.  It could be related to the physics library.  It could also be related to the timing of when the CPU completes each task.  It could be related to how frames are queued up for the GPU.

With DX12 and Frame Generation, HAGS must be on.  With HAGS off the CPU manages the timing.  With HAGS on the GPU manages the timing AND uses AI calculations to generate frames that that presumably don't contain these position errors.  I can't say for sure because I don't have a 40 series card.  I do know that users in MSFS with 4090 cards still complain about this issue in that sim.

[PinkCube]

On 8/27/2023 at 6:04 AM, Glide said:

The problem is not on the GPU side of the equation.  A flight sim, like all computer games, is a big loop.  Once per loop, the CPU has to calculate the position of all the objects in the sim, build a frame based on the view port, and send that frame off to the GPU.  When objects are close to the view port and moving rapidly across it, there is an opportunity for those position calculations to be ever so slightly off.  This has to do with the angle between the object and the center of the view port changing by a large amount.  Objects that are coming straight at the view port, or are far away and moving across, change by only a small amount.  This is why when you look straight ahead you see no stutter, but when you look to the side the issue becomes visible again.  This is a problem only the developers can solve.  It could be related to the physics library.  It could also be related to the timing of when the CPU completes each task.  It could be related to how frames are queued up for the GPU.

With DX12 and Frame Generation, HAGS must be on.  With HAGS off the CPU manages the timing.  With HAGS on the GPU manages the timing AND uses AI calculations to generate frames that that presumably don't contain these position errors.  I can't say for sure because I don't have a 40 series card.  I do know that users in MSFS with 4090 cards still complain about this issue in that sim.

HAGS on or off made no difference for me. I don't use DX12 or frame generation. Not technically versed in any of this stuff. I am only doing my own experimentation and finding out what "solves" the issue for me.

After further testing, I have come up with this temporary solution that works for me until ED do something about this. This seems to keep everything in "sync". 

Monitor refresh and maxfps value in graphics.lua values must match.
If you are playing heavier missions in DCS then set the refresh rate and graphics.lua to a minimum baseline which would be somewhere just under your average frame rate. There will be no stutters so long as your in-game framerate does not drop below whatever limits you set. If framerate is limited by nvidia software then I just experience stutters at a high frequency which produces a vibrating effect and therefore does not work and must be application controlled.
 

or limit it using the max framerate setting as well.

If frame-rates drop below the numbers you set often and induce stuttering then alter as desired. The refresh rate must be application controlled and vysnc=fast in Nvidia control panel. Changing other settings like low-latency mode and pre-rendered frames may help.


I'm done. because now this just makes trackIR stutter. and I probably need trackIR to be in "sync" somehow now as well.

null

Edited August 30, 2023 by PinkCube

[MoleUK]

20 minutes ago, PinkCube said:

HAGS on or off made no difference for me. I don't use DX12 or frame generation. Not technically versed in any of this stuff. I am only doing my own experimentation and finding out what "solves" the issue for me.

After further testing, I have come up with this temporary solution that works for me until ED do something about this. This seems to keep everything in "sync". 

Monitor refresh and maxfps value in graphics.lua values must match.
If you are playing heavier missions in DCS then set the refresh rate and graphics.lua to a minimum baseline which would be somewhere just under your average frame rate. There will be no stutters so long as your in-game framerate does not drop below whatever limits you set. If framerate is limited by nvidia software then I just experience stutters at a high frequency which produces a vibrating effect and therefore does not work and must be application controlled.
 

If frame-rates drop below the numbers you set often and induce stuttering then alter as desired. The refresh rate must be application controlled and vysnc=fast in Nvidia control panel. Changing other settings like low-latency mode and pre-rendered frames may help.


I'm done. because now this just makes trackIR stutter. and I probably need trackIR to be in "sync" somehow now as well.

null

 

Pretty sure something here has fixed the head movement stutter I would get when dropping below the headsets refresh rate on VD. Will have to try matching the desktop refresh rate to headsets later, I did previously had problems when they were misaligned.

[5ephir0th]

On 8/27/2023 at 1:12 AM, PinkCube said:

A quick update. It seems that I may have found a fix.

I decided I would set my max frame-rate to 165 in graphics.lua match my monitor refresh ratenull

This removed the stuttering effect but highlights a almost "STATIC" horizontal strip across my monitor that contains visual tearing and moves the terrain as it passes through.

Test #2
maxfps=164, Terrain stutter gone. The tearing horizontal strip scans my screen DOWNWARDS and pulses ~1 second

Test#3
maxfps=166, Terrain stutter gone. The tearing horizontal strip scans my screen UPWARDS and pulses ~1 second.

The "pulse" effect with lack of better word to describe it is what alters the position of objects. Edit: tearing solved with vsync turned on in nvidia control panel

Test#4
maxfps=165 in a heavy multiplayer mission with frame-rates peaking around 100-120 . Things seem slightly smoother, however any stutters could now be linked to an actual frame-time issue. And hard to pin down exactly if my fix worked and if it only works when the game is running at 165hz.

null

 

You always should limit your max fps a little below of your refresh rate, if not and you are hiting the refresh rate with your FPS you will get screen tearing and stuttering.

Limit your fps to 162-161 fps and try, it should fix it

[PinkCube]

28 minutes ago, 5ephir0th said:

You always should limit your max fps a little below of your refresh rate, if not and you are hiting the refresh rate with your FPS you will get screen tearing and stuttering.

Limit your fps to 162-161 fps and try, it should fix it

Any variance of the game frame-rate and monitor refresh rate mismatch causes the specific stuttering. The bigger the difference, the more noticeable it becomes. It has been speculated that this is because of CPU & GPU frame timings being off and it is out of our control. My final fix is to limit both the game fps and monitor refresh rate to something that can sustainably be maxed out so they always match. The tearing issue that came with that is solved with vsync=fast in nVidia control panel.

Edited August 28, 2023 by PinkCube

[Rapierarch]

Dear this is a problem with the engine, you cannot solve it with the settings. 

Lagging screen, lagging and transporting plane contacts are all the same bug. Those are different render layers having mismatched fps with the cockpit. Game reports cockpit fps and mismatched terrain, active object, and mirror fps causing stuttering experience and screen tearing on pancake.

In VR you can see the problem clearly. I have tried it in Dubai between the skyscrapers in MI-8 cockpit in VR. Cockpit is rendered at 72fp full refresh rate which is also reported to the headset. I can see perfectly fluent movement in the cockpit when I look at the engineer and copilot but in the same view the scenery out of the cockpit windows were stuttering. 

It was definitely lower fps than reported refresh rate but since Oculus see reported fps is 72fps it does not engage the motion smoothing even...

Nothing you can do with NVCP or game settings can fix this. 

There is only one thing you as a user can do: Cap your FPS at 60 and lower your graphics options / resolution. So that all render threads can render at the same fps. 

Edited August 28, 2023 by Rapierarch
spelling

[Glide]

8 hours ago, Rapierarch said:

There is only one thing you as a user can do: Cap your FPS at 60 and lower your graphics options / resolution. So that all render threads can render at the same fps. 

Working on the theory that the frames are all correct, I ran a bunch of tests this morning. I believe what we are seeing is the effect of frames being dumped from the queue.  I set my sim up to achieve over 60fps, set my G2 to 60hz, and played around with HAGS, Low Latency Mode, and VR Prerendered frames.  My CPU rdr times are around 5ms, and my GPU app times are around 10ms.  So, for the most part the CPU can make around 2 frames in the time that the GPU can process one.

I could eliminate the steady stutters, but every so often I would get one.  I am theorizing now that when a frame gets dropped, you will see that little stutter if you are looking out at 90 degrees left or right.  You can't really notice it looking straight ahead.  Rapierarch is correct, the theoretical ideal situation is for the CPU and GPU to be completely in synch such that no frames are dropped.  This is a balancing act. 

In VR I am always GPU bound.  But I will experiment with settings that get me to be CPU bound.  Theoretically, if the CPU makes a frame, the GPU should be able to grab it immediately such that no extra frames are created and none get dropped from the queue.  I'll try this with both HAGS on and off.

[Rapierarch]

Dear @Glide,

My advice is for the pancake. VR is complicated in DCS.

DCS engine builds up each frame from ground up as an independent frame in VR. 

60fps in VR for DCS means 120fp on pancake both for CPU and gpu. It is too much for DCS to handle in current state (vulkan threads contained and bottlenecked by a DX11 transcriber thread behind which is not capable to emulate full Vulkan api). Yet in my opinion 60fps is not usable put it is personal. anyway. 

If they move to single parser applying render frame or basic frustum culling and also move completely to Vulkan than we can talk about a possibility of perf uplift for VR and stable smooth frames. Currently as far as I can see ED is not capable of making this state of the engine to pump synchronized stable image at high refresh rates. 

[Glide]

11 minutes ago, Rapierarch said:

My advice is for the pancake. VR is complicated in DCS.

Very true.  I got it going pretty good.  I could not get the CPU frame times to climb up to match the GPU frame times, so I brought the graphics settings down as far as I could.  It was very smooth at 60fps.  Once I got it going smoothly, I switched over to Motion Reprojection (best frame rate).  It stayed at 60 throughout the dogfight.  It still dropped a frame now and then though.

I set the max fps setting in graphics.lua, but I am not sure exactly what that does.  Is this the same as setting max framerate in the NCP?

Anyhow, every so often the terrain would give a little hiccup with these settings, so I have to assume, no matter how synched up you get it, the GPU will miss a frame or toss a frame now and then leading to the little jump in terrain position. 

In a hot dogfight, I don't notice any graphic settings and smoothness is everything.