SteamVR 1.16.1 and -Valve INDEX observation

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

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.

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):

"" : {
   "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.


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!


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



Good idea!

If you’re taking about SteamVR settings I totally agree, that would be great!

I would certainly like the clouds to go from LOW or MEDIUM (at takeoff when I need lots of FPS ) to HIGH-ULTRA above a certain AGL when buildings and trees aren’t as important. Obviously it isn’t this simple but it still would be a nice option that would help.

Actually I find this a very good idea!

My tests are showing I can settles on a base settings configuration and the ones I’m probably adjusting the most during flight in order to balance performance, are clouds and Terrain LOD. What is neat with clouds is they probably lends well into auto-adjusting their rendering resolution because of their “fluffy” look, and so is Terrain LOD if you keep it in a “reasonable” bracket, like 100% to 150%.

I’d very much like being able to tick the settings I’d like to auto adjust with low/high bracket values.

Yes, for XP11 there are plugins that adjust settings related to scenery and LOD on the fly according to performance (I use FlyAgi for example) and this is very handy to fly in VR smoothly no matter where I choose to fly. I hope we’ll see something like that for MSFS one day


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.