you can use FFR but you have to either switch the game to DX12 (which I understand is unstable on some configurations)
or
you can also toggle the SteamVR OpenXR runtime (rather than the Oculus runtime, and I’m not sure of the impact here, perhaps related to ASW?).
Note that even without either of the 2 above, you can still use the newer and all the other features, it’s just that enabling FFR will have 0 effect in MSFS.
Rest assured, we are working daily to fix that issue. So far we know what is happening, just not yet how to fix it.
You can also use the OpenXR Toolkit to benefit from other features like you pointed out.
The new version also offers anamorphic upscaling for FSR/NIS, which can be used to grab a couple of FPS of improvement. NIS also upgraded to a newer version with small improvements here and there.
Since you use the screenshots, you’ll be happy to hear that they can now be saved into a sane file format, PNG (new default), BMP or JPG!
There is the brightness/contrast/saturation, which I think you can already partially control through the Oculus software?
New menu, with a better look and smoother experience. Several bug fixes.
The experimental hand tracking feature, which was confirmed to work with Oculus in beta mode!
For the OpenXR runtime to lock to a motion reprojection rate dynamically, the runtime must make a decision of “what is the best experience for the user”.
You cannot lock to 30 FPS if your game is running at 29 FPS. So it fallback to 22.5 FPS.
You can lock to 30 FPS if your game is running at 31 FPS.
But what do you do when the game performance oscillates between 29 and 31??
There are a few techniques here, for example raise the threshold for locking to 30. For example, say we can only lock to 30 if the framerate is higher than 35. If you do that, you might get rid of the stuttering, however there may be plenty of times we’re the game will be running at 30+ but motion reprojection will still give you 22.5 FPS. If your game oscillates between 31-34 FPS, wouldn’t you prefer that it locked at 30 FPS?
Another approach is to increase the length of the filter, so that you oscillate constantly between 29-31, then we won’t have a long-enough continous period of of time above 30 that will toggle the lock to 30… but if you oscillate between 31-33, then we will be able to lock to 30… the issue with this approach is that it might not get rid of stuttering, especially if the period of your oscillations is still longer than the length we choose for the filter.
The best solution from a user perspective is to adjust their settings so that the game performance is NOT oscillating around one of the locking point, eg move your observed FPS boundaries from 29-31 to 27-29 (higher settings, always lock to 22.5) or to 31-33 (lower settings, always lock to 30).
Interesting that these black lines (addressed by disabling light shafts) occur only in the inner ring (1/4x), but not on the outer ring (1/16x) anymore. Also, according to where they occur they seem connected / conflicting with the either the anti-aliasing process (TAA for most of us) or more broadly with pixels in “border zones” between terrain / sky / atmospheric effects etc. Probably a completely useless post, but I couldn’t resist…
Very much looking forward to the next release, FFR, all the other new features and more tweaking fun!
No, this is a good point. I think our intuition is the following: when you apply VRS (the tech behind FFR), the lower resolution (reduced invocation of the pixel shader) is limited to the color buffer (the image), and meanwhile, writing to the depth buffer still occurs at full resolution.
This means that any post-processing effect relying on the depth buffer will now get inaccurate info. Because when rendering at 1/4x, this means all pixels in a 2x2 block will be the same, however they might have 4 different depth values. When looking at a line in the distance like those hills above, it means that the post-processing sees perhaps the bottom two pixels at say 4km (hills), but then sees the same top two pixels at infinity (horizon). This breaks some of the maths behind the graphic effect, because it can no longer properly detect where the depth “breaks” from the hills to the horizon.
Maybe this isn’t happening as much at 1/16x because there is either 1) a resolve of the buffers, aka the post-processing is run at blocks at a lower resolution, therefore not affected by the lower resolution created by VRS or 2) some sort of averaging filter, which eliminates the discrepancies in the depth values. No way to know without seeing the game’s shaders
I also forgot to mention an inconvenient bug with FFR, but I’m hoping it’s not impactful. We will try to fix it later. The FFR effect is applied to some of the menus(!) which results in the edges of the projected menu screen to be blurry:
You can see it in the screenshot above, the plane selection (near the edge of the “virtual” menu screen) is blurry (because rendered at a lower resolution, regardless of the head pose, meaning this happens even if you look straight at it), however the elements closer to the center of the menu screen are OK.
If you don’t understand what I just described, then just wait and see, you will notice it when you try and it will make sense. It really just happens in the main menu, no impediment when you’re flying. I know some of you only enable VR once you are sitting in the plane, so you won’t even notice this issue exists!
One solution for now is if you’re going to spend some extended time in the menu, you can disable FFR temporarily (which again is instantaneous and does not require to restart VR).
This issue is the result of OpenXR Toolkit having to guess what’s being rendered, and while we’ve succeeded in guessing left eye view from right eye view (which is Very important to have the best effect and to support Pimax as well), we haven’t succeeded yet in detecting menu elements.
Thank you for all of this guidance. The further complication for a user is that every aircraft, location, time of day, etc can impact the FPS ranges …so in an ideal future world perhaps years away, the sim could have a setting to dynamically help adjust certain graphics settings to target a frame rate/experience for the user. Some of the auto racing sims have this in a rudimentary form to help keep fps close to 90 by toggling live up/down a few of the graphics settings, but it’s not a sophisticated approach from what I can tell and doesn’t touch the rendered headset resolution, but toggles other settings live in game in some way to help maintain the target frame rate.
Thanks a lot for sharing these background insights, fascinating!
Maybe this isn’t happening as much at 1/16x because there is either 1) a resolve of the buffers, aka the post-processing is run at blocks at a lower resolution, therefore not affected by the lower resolution created by VRS or 2) some sort of averaging filter, which eliminates the discrepancies in the depth values.
What about the following theory: could it have something to do with a mathematical “50/50 pixel parity situation”? What I mean is looking at your screenshot the black lines seem to mostly occur on flat / horizontal parts of the terrain. In a 2x2 scenario (following your example) it means 2x terrain at 4km, 2x sky at infinity - stalemate, e.g. the Z-buffer or any other part of the shader runs into a “parity conflict”, etc.? On a 4x4 pixel area this 50/50 situation is still possible of course, but much less probable and frequent, simply because more (16) pixels in a complex environment… Or the fact that it’s really “infinity” mathematically turning certain calculations / divisions impossible (#Div/0! ) …I don’t know, but surely it’s an interesting one…
No way to know without seeing the game’s shaders
Honestly Matthieu, wouldn’t it be generally an idea for you and team to say hello to Asobo? You guys are contributing so much to us -the VR community and inoficially to MSFS in your spare time… maybe you could establish any kind of collaboration / exchange etc., what you prefer works best for you…?
I know it’s not at all my business!
I’m just thankful. Having you in the FS/VR community is a blessing and we still owe you guys quite some free Starbuck’s coffees or whatever you wish (an Aero for extended testing maybe?), as already stated a few times… give us that donate link!
It’s clear everything is said thank you to you Matthieu enormous Taff deserves recognition from the VR community as well as Microsoft / Asobo value!! A little message from Normandy thank you!!!
Special thanks to @Devrij (from Ultraleap) for getting me a state-of-the-art Stereo IR170 hand tracking device!
(PS: Hand tracking will get a lot more love in March)
Special thanks to Frydrych Holger (author of vrperfkit) for keeping his software open source, and therefore lending us some useful code!
100% this. for those interested, after a lot of experimentation the biggest FPS improvements/reductions came for me with just two settings - resolution, and volumetric clouds
Thank you very much for the time you took to answer, it’s very appreciated. Wow… you can have a 2.3 SS! This would break my system. I see that you use 06, 06 fov, maybe that’s what help not to have a slide show, but for me anything less than 95 I start to see really bad black vertical and horizontal line whenever I move my head. How do you prevent that?
Also, is there a benefit to use the OpenXR Toolkit if not upscaling (like in your example you are staying at 100)?
Lastly, do you use any specific bitrate parameter or you go by de default 0?
If you don’t see a version number in the menu or Companion app, the you are running the very first version.
Anyway- we are releasing tomorrow (Friday), no specific time because it will depend of when we finish working our day jobs (so we don’t get too distracted!)
Wow 90% sharpening. I’ll have to try that in FSR, but I suspect it’s going to make objects look way too cartoonish. Instrument Panel might be clearer though.
Any one knows how to start this program with Vive Cosmos? I have tried everything. This program gives me CDTs and wont even start up even i press CTRL F1. There is nothing on the screen. Any one here knows what to do ? Do i need another program? Please help
) …I don’t know, but surely it’s an interesting one…
