My 2070 SUPER VR settings and suggestions (Index - SteamVR) šŸŸ¢

you can override the IPD easily in SteamVR though!

You can do this with fpsVr with the GUI, or, you can edit the config file:

C:\Program Files (x86)\Steam\config\steamvr.vrconfig

 "steamvr" : {
      "ipdOffset" : 0.002,

This tells SteamVR to add 2mm to the actual IPD value! (the equivalent of the ā€˜Biasā€™ value in my request here: [FEATURE REQUEST] Cockpit Size and World Scale in VR )

1 Like

Oh wow I wasnā€™t aware the ipd is what was causing that Iā€™ll give that a shot thanks so much!

1 Like

It might be useful to start with reviewing what the ideal situation looks like (i.e. a an making framerate). Here is a capture taken from the SteamVR Frame Timing wiki:

This starts out at half rate (e.g. 45 fps on a 90Hz headset, Present count = 2) on the left side, and then transitions to making framerate (90 fps on a 90Hz headset, Present count = 1). Also note the red line goes from 1 where Present count = 2, down to 0 where Present count = 1. This indicates in the half-rate portion, that one of the rendered frames was presented ā€œproperlyā€ and then the second time it was presented using reprojection. Once the app starts making framerate, that red line drops to zero. This is the ideal situation.

The reason that the app wasnā€™t making framerate to begin with can be explained by the cyan (Ready For Use) line. This started out at 2 which means it was taking more than a single frame for the images to finish rendering. This might be because it was simply rendering too much, or it might be because the app started rendering too late. In either case, the result is the same. This then starts to jump between 1 and 2 and finally settles on consistently finishing on time (value = 1).

You will notice, however, that it is still several frames before things drop to ideal (Present = 1, Reprojected = 0). This is explained by looking to the top ā€œCPUā€ section of the graph. The cyan ā€œThrottle (frames)ā€ line there was at 1. That means the SteamVR runtime had detected the app wasnā€™t making framerate and started throttling it (i.e. dropped it to half rate). This only resolves itself once the SteamVR runtime sees that the app is consistently delivering frames and relaxes the throttling (value drops to zero).

Now letā€™s take a look at your first image (v1.14.16 on Runway):

Here we see the sim presenting each new frame three times (white = 3). This corresponds to an effective framerate of 30 fps (since your headset is running at 90Hzā€¦ 90 / 3 = 30). However, the red line is also at three, when weā€™d expect it to be two. This is because every single frame that was presented (i.e. displayed in the headset) had be predicted to the wrong future time and required reprojection to compensate.

If you look back to the ā€œCPUā€ section, youā€™ll see that most frames have only been predicted 1 additional frame out even though we know the app is running at 1/3rd rate. Prediction in this version of SteamVR is totally bugged for OpenXR apps it appears. This is corroborated by the v1.15.11 patch notes:

image

Whatā€™s even more concerning is the cyan ā€œReady For Useā€ line which is hovering around 5 (+/-1). The app is rendering at 1/3rd rate, but itā€™s taking on average about 5 frames for each one to finish? How is that possible? I find it useful to draw a timeline here.

Because the app is pipelined (i.e. the next frame is being simulated while the current frame is being rendered), it can deliver new images in this case every three display intervals, while the latency on how long it takes to render (cpu + gpu) is closer to five display intervals.

If we look at the in-game stats, we see the Main Thread reporting ~22ms while the Render Thread is a little over 30ms, and the gpu is about 32ms.

image

Perhaps more concerning is that even though the images are finished rendering, they arenā€™t actually displayed (the green line ā€œFirst Viewedā€) for an additional frame. That makes me think something is particularly broken with v1.14.16ā€™s implementation of OpenXR.

Normally, the only reason the green line would be higher than the cyan line is if the frame was over-predicted. OpenXR does not allow displaying images early. If an image is finished rendering earlier than it was predicted to, then the runtime is required to hold off displaying that image (and continue to use the previous image). However, weā€™ve already established that these frames are getting under predicted (the yellow line on the cpu graph). Digging in a bit further (Iā€™ll spare you the details) this appears to be a bug in SteamVR related to the prediction being off. In any case, itā€™s not a situation you want to be in.

Interestingly, we also see this in your 1.15.16 capture:

My suggestion would be to try to get that cyan line down to 3. SteamVR doesnā€™t really handle running slower than that well. Step one would be to reduce your gpu usage. During take off, youā€™re already over the 33ms limit for running at 1/3rd rate, and that presumes your cpu is able to deliver frames within the ā€œrunning startā€ time the runtime provides.

image

The red bars you see in the CPU portion of the SteamVR Frame Timing graph are labeled Late Start. This is a clue that your cpu isnā€™t able to deliver frames in time, and that red bar is showing how much time is eating into your gpu rendering time.

Hopefully that helps some.

3 Likes

I tried the new Nvidia driver. In SteamVR 1.15 there were noticeably more stutters than the 457.30 driver, however I was getting an ever so slightly higher framerate (avg. 32 vs. 30) and I think there was an improvement in visual fidelity. It seemed slightly sharper and less washed out in my Vive, but to be honest I am not 100% sure this wasnā€™t just a placebo affect.

I then tried the new driver with SteamVR 1.14, and there were close to zero stutters. Framerate seemed about the same, however the new annoyance in 1.14 is that reprojection rendering sometimes seems delayed. This is causing a very subtle but weird distortion in the cockpit, like a lensing effect, when I turn my head and look out then back in. Iā€™m also briefly noticing black bars at the periphery of the image while turning. I should note that Motion Smoothing is off.

The awesome thing Iā€™m finding with the new driver and SteamVR 1.14 is that in the C172 world scale is now perfect! It is slightly too small in 1.15. The interesting thing is that this also fixed a similar world scale issue in Elite Dangerous that Iā€™ve lived with for years. I have to say the slight change in scale makes a huge difference in immersion.

Overall I would say that the jury is still out as to whether Iā€™ll stay with this driver on 1.14 or go back to 457.30 on 1.15. Iā€™ll have to live with it for a couple of days to see if the positives outweigh the negatives. Also, thanks for the post on the IPD setting in steamvr.vrconfig. I had no idea that it existed, and if I do revert to 1.15 Iā€™m going to see if this fixes my world scale issues in that version.

1 Like

Thank you for all these details, it is indeed showing weā€™re all surfing on a moving target, not only FS2020 but also the SteamVR and NVidia drivers. It is sometimes like trying fitting a square shape in a disk holeā€¦

On my end I continue using 1.14 with 457.30 for now, but Iā€™ve been much more using the G2 than the Index lately, because I can at least with the same settings (even raising Terrain LOD back to 100%) use the G2+Reproj at 90fps/30hz in most areas and aircraft (with TAA 60 and OXRSS 65, about 1.55K x 1.55K rendering and 2.5K x 2.5K displaying), and sure enough it is making a difference.

But I do miss the immersion and robustness of the lighthouse tracking when I use the G2 and the difference is really dramatic, despite most claiming inside-out tracking has made huge progress (sure, when there is CPU and GPU left to handle it Iā€™m sure it is fine, but in practice when all your resources are already sucked up by NVidia driver bugs and FS2020ā€¦ Why canā€™t they just release the Index v2 with the G2 panelsā€¦ arghā€¦)

3 Likes

The night is busy!

Good news:
PSA: NVidia has found the root cause of stuttering and VR performance in their drivers!

And a new SteamVR release candidate:
SteamVR Beta Updated - 1.15.17

  • Reduced GPU memory usage.
  • Added workaround for very low framerates for some combinations of graphics cards and drivers.
2 Likes

Update on SteamVR 1.15.17:

Iā€™ve tried it out with the Index only (not with the G2) and I find it is still much worst than linux_1.14, causing more stutters and not necessarily better fps either.

When reverting to 1.14 and while at it, Iā€™ve tried also raising clouds, building, trees, vector data to ULTRA because some are reporting they get smoother VR experience on the Oculus at 18Hz in raising all to ULTRA. Iā€™ve been doing this over an Hawaii island to try out with a lightweight scenery and I honestly canā€™t repro the
ā€œsmoothā€ experience with the Index on my test system in these conditionsā€¦

However I was quite astonished looking at the fps counter and seeing how fps were dropping asymptotically to 30fps while raising this or that setting to ULTRA one after the other until reaching the point of a violent drop below. This is expected because the rule in VR API implementation is most likely to lock the frame rate to an integer divisor of the headset refresh rate. However this also tells me my base settings which I tuned for 30fps in a dense photogrammetry region are delivering as expected too.

Nevertheless, Iā€™m also running linux_1.14 at 120Hz with the Index now and this seems giving me a much better experience, like Iā€™ve explained in another post above, because SteamVR is trying to re-reproject the rendered frame over an higher number of displayed frames in the headset and I find this reducing considerably the juddering (still there of course, but less annoying when moving the head in the cockpit).

1 Like

Hi, I finally got around to trying tab key in vr and nothing happened. Any ideas.

You might want to start the official ā€œreadmeā€ publications?

Starting with:
[Read First] VR FAQ - Virtual Reality (VR) - Microsoft Flight Simulator Forums
How to activate VR in MSFS ā€“ Microsoft Flight Simulator Support (zendesk.com)

Are you sure you didnā€™t bind TAB instead of CTRL+TAB to switch to VR for example? You might want to review all your key bindings for anything using TAB Otherwise you can file a bug report (zendesk) and/or VR > Bugs forum.

Look in: Options - General - VR Mode
The VR - Toolbar Toggle binding is displayed there.
Remember, you may need to click on the active flight sim window after initiating VR to get the window to respond to keyboard commands.

1 Like

Thanks. There was no key assigned to toggle the toolbar in settings. Once I assigned it it works fine. I thought posters were saying that tab was preassigned to toolbar and it wasnā€™t . Thanks for your help.

2 Likes

Youā€™re welcome. :slight_smile:

First of all, I want to thank you for sharing all this info and knowledge of yours. Much appreciated!

I recently got a 3090 and finally, Iā€™m able to test it out in VR mode in MSFS. Havenā€™t been able to launch the game since it was released in end Dec due to the issue described in this post.

Now when trying to find the best balance between smooth performance and good visuals, your posts on this topic is super helpful!

I have one question though straight away. You say the recommended Nvidia driver version in VR for 3090, 3080 and 20XX cards is 457.30. However, further down in your post, the minimum version required for the 3090 is listed as 457.38?

1 Like

Thank you for your kind words!

However Iā€™m listing 456.38, not 457.38:

What NVidia Drivers are recommended for VR

1 Like

Clearly I need to read more carefully before going through the rest of your good stuff.

Thanks for opening my eyes :blush:

Hi, Just sharing my experience. Had everything running great in VR with CptLucky8 suggestions, then made the mistake of trying nVidia driver 461.09 with Steam linux 1.14 and EVERYthing went to H**L. Horrible stuttering in VR and screen modeā€¦ Basically unplayable. I have been reading all the complaints on this forum about how bad things could be and was grateful I had never had such terrible experiences, but 461.09 showed how bad it could be. Also, I donā€™t know if related, after I updated Nvidiia driver, rebooted and started FS2020 it made me reinstall the last update. Thought that was the problem, but after doing a clean install of 457.30, everything back to normal.
Thanks all

1 Like

Hi @CptLucky8 i @CptLucky
Could you please provide any more info on this setting? Following your guide and using the linux driver for the index i can now average 47fps on my 3070 10thgen i7 with everything on high/ultra and the Index HMD set to 120hz. It plays so great now its amazing. Airliners a a litter stuttery but I usually only fly light aircraft anyway.
I am finding that the scale of the cockpit is well off using this driver but I cant find this exact config file in the location you mentioned. I did find one with a similar name that had a bunch of resolution settings and refresh rate but i could not see a line for the ipd offset.
Thank again for all your amazing info on this forum.

1 Like

This is because you have to add it!

Aha I wondered as much, but was too scared to just do it Incase it did something irreversible. Will try tonight. Thanks

1 Like

A quick note to all:

Iā€™m updating the OP from time to time not only when Iā€™m making new suggestions, but also in keeping a wish list of bugs and features you can vote on. If you donā€™t happen to revisit the OP from time to time, here is the current list.

If you find these important to you, please vote!

2 Likes