SteamVR 1.16.1 and -Valve INDEX observation

I installed the SteamVR 1.16.1 BETA. My first impression was WOW… what a difference. After a little tweeking to squeeze out the best, I actually flew OVER TOKYO and was able to maintain acceptable frame rates. When I say acceptable, I mean that it was smooth, very few little jitters here and there and no CTD’s. I couldn’t believe my eyes. Here are my settings for those interested. Any suggestions for improvements, please tell me.

System Specs:
Power Supply: Corsair RM850X
MB: MSI Gaming Pro Carbon
DUAL 2GB NVMe Drives. One in TURBO M.2 slot.
CPU: Intel i9-9900KF 3.60 ( I overclock MSFS2020 to 4.8 when possible.)
RAM: 32GB Corsair RGB RAM (No O/C of RAM)
Windows 10 64. VERSION 20H2 Build 19042.746
GRAPHICS: nVidia GeFORCE RTX 2080 TI
Dual Monitor Resolution: 2560X1040 (144Hx)
Dual DELL S2716DG Monitors.
Onboard Audio.
VALVE INDEX: VR BETA 1.16.1

MSFS 2020: VR Mode Settings
Render Scaling = 80
Anti-Aliasing = TAA
Terrain LOD = 80
Terrain Vector Data = Medium
Buildings = Medium
Trees = High
Grass & Bushes = OFF
Objects LOD - 100
Vol Clouds = MEDIUM
Texture Res. = MEDIUM
Anis Filtering = 2X
Texture SS = 2X2
Texture Synthesis = LOW
Water Waves = LOW
Shadow Maps = 768
Terrain Shadows = 128
Contact Shadows = OFF
Windshield Effects = MEDIUM
Ambient Occ. = OFF
Reflections = OFF
Light Shafts = OFF
Bloom = ON
Glass Cockpit Refresh Rate = LOW

Peripherals:
Thrustmaster HOTAS Warthog
Thrustmaster Pedals.

nVidia Driver: 4.51.48

nVidia Control Panel
PROGRAM SETTINGS: MSFS2020
Image Sharpening: USE GLOBAL OFF
Anisotropic Filtering: USE GLOBAL - APP CONTROLLED
Antialiasing FXAA: USE GLOBAL OFF
Antialiasing GAMMA: USE GLOBAL ON
Antialiasing Mode: USE GLOBAL App Controlled
Antialiasing Transparency: USE GLOBAL ON
CUDA - GPUs: USE GLOBAL ALL
Low Latency Mode: ON
Max Frame Rate: USE GLOBAL OFF
Monitor Tech: USE GLOBAL G-Sync
MFAA: USE GLOBAL OFF
Open GL Rendering: GeForce RTX 2080 Ti
Power Management Mode:: Use Global - Optimal Power
Preferred Refresh Rate: USE GLOBAL - Highest Refresh Rate
Shader Cache: USE GLOBAL ON
Texture Filtering: Anis… ON
Texture Filtering Neg LOD: Allow
Texture Filtering - Quality: Performance
Texture Filtering - Trilinear Opt.: ON
Threaded Opt: ON
Triple Buffering: OFF
Vertical Sync: FAST
VR Prerendered Frames: 1

1 Like

I agree and I have to say that with this update, the difference is notable. On my Index/2080Ti/i9, stuttering continues on take-off, maneuvering, and fast head rotations, but steady framerates when maintaining altitude and direction now lock-in consistently without the need to futz with refresh frequency (90 or 120hz) and seem to remain pretty steady as you report. Very cool. I will also say that motion smoothing is also surprisingly improved, though still not really usable for more than experimentation due to lesser, but continued smearing (especially in front of or behind the propeller). And, of course, though perhaps improved (but more likely just steadier) framerates are still too low overall to make transitional movements fluid with the kind of reactive buoyancy that feels genuine (and which sims like VTOL and X-Plane still manage much better). This update does, however, makes it much more fun/comfortable to fly extended VR VFR sight-seeing tours in MSFS without as much dizziness, since at altitude and in steady flight (preferably opposite the sun), it can look quite spectacular.

Agreed. I am curious as to your settings as well. Looks like out system is very similar. I want to try the new nVidia Driver versus the 4.51 I have now. I will install the latest and report back here.

I tried the 4.61 drivers and they tanked my frame rates. I went with 4.57.30 and they work great. Flew down Miami Beach up to Lauderdale with no issues.

1 Like

This is my current config and settings:
CPU: Intel 9600K (stock)
GPU: Nvidia RTX 3080 FE
RAM: 32 gigs G.Skill Ripjaws 2800
1 TB M.2 NVME

Valve Index w/ Steam VR set to 90Hz and application FPS locked to 30

Render Scaling: 100
Anti-Aliasing: TAA
Terrain Level of Detail: 100
Terrain Vector Data: High
Buildings: High
Trees: Ultra
Grass and Bushes: Ultra
Objects Level of Detail: 100
Volumetric Clouds: High
Texture Resolution: Ultra
Anisotropic Filtering: 16x
Texture Supersampling: 8x8
Texture Synthesis: High
Water Waves: High
Shadow Maps: 1024
Terrain Shadows: 1024
Contact Shadows: Off
Windshield Effects: High
Ambient Occlusion: Off
Reflections: High
Light Shafts: High
Bloom: Off
Glass Cockpit Refresh Rate: Low

I’ve been able to maintain 30FPS pretty much everywhere, but it’s close to borderline around big cities - but still playable. In the middle of nowhere I can turn the FPS up to 45.

Your settings are higher than mine as I have RS at 80, Terrain LOD 80, Objects LOD 80. I do have a higher FPS setting of 45 so I will try to lower it a bit and see if I can squeek out better graphics. The INDEX does seem a little too blurred. What do you have your Steam VR PER EYE res set to?

Both resolution settings are set to 100. If you’re trying to run 45 all the time you’ll definitely need to make sacrifices elsewhere. 30 feels smooth enough to me and with motion smoothing it’s even better. I do bump the FPS when I can though.

Me too, nice revolution with the new steamBeta, i stopped MFS waiting that :wink:

I9-9900K/RTX2080Ti/32Go Valve Index

No tweak on nvidia control panel for the moment.
SteamVR SS=100%
New option fixed to 30fps.

in game:
Render Scaling: 100
Anti-Aliasing: TAA
Terrain Level of Detail: 100
Terrain Vector Data: Ultra
Buildings: Medium
Trees: Medium
Grass and Bushes: Low
Objects Level of Detail: 100
Volumetric Clouds: High or MEDIUM (biggest impact on FPS! with render scaling of course…)
Texture Resolution: Ultra
Anisotropic Filtering: 8x
Texture Supersampling: 4x4
Texture Synthesis: High
Water Waves: High
Shadow Maps: 1536
Terrain Shadows: 512
Contact Shadows: Light
Windshield Effects: High
Ambient Occlusion: Light
Reflections: Light
Light Shafts: Light
Bloom: On
Glass Cockpit Refresh Rate: Medium

i don’t really see big bifference between medium, high or ultra setting with allmost every options, it depends really of places in the world… sometimes i have only 12fps but it’s very strange, i don’t understand why, it’s only on one direction (west for example).
it’s really difficult to know what options to choose for me, but it’s so playable at 30fps anyway, so good :metal:

What are your settings for ADDITIONAL PREDICTION (ms)? Im not sure what this does.

You might want to first read:
My 2070 SUPER VR settings and suggestions (Index - SteamVR) 🟢 - #371 by aleiby

Then:
My 2070 SUPER VR settings and suggestions (Index - SteamVR) 🟢 - #408 by CptLucky8

And then the rest of the discussion!

I didn’t talk about the second slider originally because I was concerned it would cause more confusion than help, but let me take a stab now.

The TL;DR is that is can be used to stabilize framerate similarly to the Throttling Behavior setting, except for the GPU rather than CPU work.

It is important to remember that you are trading off smoothness for added latency, so you want to adjust these values only as much as needed and no more.

Added latency shows up in the rubber-banding effect you see when changing the direction of your head movement. For instance, if you look down at the seat and move your head side to side (laterally, not rotating), when you change directions, you’ll notice that the image lags, causing a bounce until it catches back up. This is latency in VR, and it makes people sick. Fortunately, in simulators like FS2020, you’re not making these kinds of head bobs much, so we can get away with more latency than in say an action shooter where you’re ducking behind cover, etc.

So first, we need to understand how SteamVR handles prediction. Here is an example of an application making framerate:


Three consecutive frames (red, green, blue) each have ~11ms (@90Hz) to finish. In a pipelined application like FS2020, the main thread and render thread(s) operate in parallel, however, for a given snapshot in simulation time, the simulation needs to finish first (main thread) before that snapshot in time can be rendered (render thread). This means that the application is rendering frame N (e.g. red) while simulating frame N+1 (e.g. green).

There is typically some amount of time that passes between when the application’s render thread(s) start work on a given frame, and when the gpu actually starts rendering that frame. To give applications the most amount of time available to render on the gpu, SteamVR tries to align that gpu work to start at a display interval so it can scan out on the next. Scanout (the amount of time to load the finish rendered image into the display) typically takes another frame interval, and then is illuminated for a short period of time.

The time between the render thread(s) starting and the associated gpu work starting is referred to as Running Start. Alex Vlachos did a great GDC talk on this several years ago. https://youtu.be/ya8vKZRBXdw?t=874

Poses used for rendering (i.e. where your head is relative to the cockpit) are sampled at the start of the render thread, but since the image won’t be displayed in the headset until some time later, those poses need to be predicted forward to that time.

So that’s prediction. Remember, we want to minimize this to reduce rubber-banding.

Now, if you were to select “Force Always-On” from the Motion Smoothing drop-down in the per-app settings, you’ll see a note that says: “Warning: Application will run at half framerate”. Here’s what that looks like using our timeline:


Now, both rendering on the cpu and gpu have had their budget extended by one display interval, and since the main thread runs in parallel, it too gets an extra frame to finish its simulation. But since two display intervals are now passing for each newly delivered frame, the simulation is running at half rate.

Note that running start and scanout has not doubled, just the render budget itself. So when we talk about this situation, we say that one additional frame of prediction has been applied. If the headset is running at 90Hz, this translates to 1/90 seconds = 0.0111111 or 11.1111 milliseconds (ms).

Now let’s look at the new Throttling Behavior setting. I’m going to switch to running the headset at 120Hz to make the fraction easier for this discussion.

At 120 fps, we are applying 0 extra frames.
60 fps = +1 frame (half rate).
If we add two extra frames, that’s 1+2 = 3 or 1/3rd rate. 120/3 = 40 fps.
If we add three extra frames, that’s 1+3 = 4 or 1/4th rate. 120/4 = 30 fps.
If we add four extra frames, that’s 1+4 = 5 or 1/5th rate. 120/5 = 24 fps.
And then the max the slider allows is 1+5 = 6 or 1/6th rate. 120/6 = 20 fps.

So, let’s take a look at 30 fps on our timeline:


Now the simulation is delivering a new frame every four display intervals.
However, now we have a lot more wiggle room. Ideally, the gpu gets started on the work for that frame immediately after running start. But it might be that the whole reason we needed to throttle the application in the first place is because it is taking too long to render on the cpu, adding a delay to when the gpu gets started (e.g. the green frame).

When changing the Throttling Behavior, SteamVR also adjusts the additional frames to predict to match. You can see this in your steamvr.vrsettings file (in your Steam/config folder):

"steam.app.1250410" : {
   "additionalFramesToPredict" : 3,
   "framesToThrottle" : 3
},

This assumes the ideal case of the gpu getting started asap, and finishing in the extra allotted time.

Don’t forget, the headset needs to display something every display interval, not just when new frames are delivered. So our timeline looks more like this with the highlighted frames using reprojection / motion smoothing:


Now we’re getting to the heart of things. If your gpu is bouncing between how often each frame is getting reprojected, then that is another potential source of jittering. Typically, the workload from frame to frame on the gpu is pretty similar, so you mostly only run into this when you are borderline. However, the cpu tends to fluctuate more and that affects the start time of each of these gpu blocks.

SteamVR will never display an image earlier than it was predicted to, so one thing we can do to mitigate this situation is to tweak that second slider in the per-app settings. This is what the “Additional prediction (ms):” slider is for. In the above case if we add two frames of prediction (16.67ms) then we’ll get a timeline that looks like this:


I added an extra earlier purple frame to show that we will continue to see that (with reprojection / motion smoothing) even though the red frame was ready (i.e. finished rendering).

Again, we are trading off added latency to increase smoothness.

Now the tough part… how do I know what values to set?

First get your Throttling setting dialed in. The Additional Prediction is on top of that, so until you have throttling figured out, there’s no use touching the second slider.

If you bring up SteamVR’s Advanced Frame Timing graph in the bottom GPU section is a cyan line labeled Ready For Use. If this is above the white “Present (count)” line, then that means the frames are finishing late. If this line is bouncing around a bit, then you want to take the higher value. So for instance, if you’ve set your throttling to 3 (1/4th rate), then you’d expect to present each frame 4 times (white line = 4). If the cyan line is at 6 bouncing to 7, then you might want to add three (7 minus 4) additional notches of prediction (second slider = 25ms if running 120Hz). If Ready For Use is going crazier than that, then you probably need to add an extra frame of throttling. Just don’t forget to zero out your additional prediction first - remember we still want to minimize latency - then reassess. If your green “First Viewed” line is consistently above the cyan “Ready For Use” then you may have added too much Additional Prediction and might try backing it off.

12 Likes

I wish I could double click the :heart: icon for this post!

Great explanation. Even for an old dude like me.

i edited my setup, because cloud was too high depends of weather of course. it s a shame, because clouds ultra are gorgeous in VR too…

i dont really see differences about buildings quality, between low and ultra :mask:

I think building quality affects how far away the sim renders buildings, not how detailed they are.

This is not entirely true. This is affecting both details and draw distance, the later being further adjusted with the Terrain LOD value. For example, if buildings MED is equivalent to 75 and you set TLOD to 200, you’ll see medium detail buildings up close and buildings up to 2*75 = 150 LOD ring.

I’ve documented this a lot, including implementation bugs, please vote!

LOD Problems - Distances revisited

LOD Problems - Description, analysis and solutions

I think there are at least TWO things that we are focusing our eyes on. One is buildings, planes etc and there is the low resolution BING mapping. This obviously changes from area to area. Some city areas are of one quality, and the Rural areas are of another. For me, flying a 172 or CUB over Rural areas is great “IF I HAVE A SETTING” tweeked for it. Urban areas cannot survive with those settings for obvious reasons. This is all common knowledge or common sense but I think picking between Urban and Rural for your settings need to be a priority. DISCLAIMER: On beer 6 and I wont remember any of this in the morning. hehe Cheers gang!

3 Likes

Wouldn’t it be nice if the settings could scale automatically based on urban/rural, or the complexity of the terrain…

2 Likes

Absolutely

Good idea!