Im the user who made the statement about the cpu time being lower than 9.2ms for having always perfect MR at 45 with a 4090.
I feel there is something that makes the MR to break (having more artifacts) and it has to do with de CPU timing. As the cpu timing changes while changing altitudes and Tlod… I see inmediatelly when it “breaks” just adjusting tlod during a flight
I have been trying and experimenting a lot with this, and I can give you also new findings that include that above 13ms cpu time, also make perfect MR
Flying in non photometric scenery with GA 1500feet flight level, TLOD 100 (cpu time 10-12)…wobbles
Then on the same flight, raising TLOD to about 210 or more (cpu time rise to 13…14?) and I get surprisingly PERFECT MR. If I down tlod less than 210 (just to 200) the wobbles appear again as before. And of course, lowering tlod to 30 (getting less than 9,2ms cpu) no wobbles, as stated on my other post (below 9.2ms, always perfect MR)
Flying the pmdg737 (cpu hungry) then the TLOD numbers react diferently , and normaly with a tlod of 160 my cpu time is above 13ms, so perfect MR
This numbers are not always exatly, depends on scenery, altitude etc
In conclusion, and in my case:
CPU app time higher than 13ms= perfect MR
CPU app time lower than 9.2ms= perfect MR
CPU app time between 9.2ms-13ms= Wobbles and more artifacts while paning my view, more noteceable on cockpit windows frames and vertical lines etc
So, if someone can try and test rising Tlod to 250-300 on a GA for example and then returning to tlod 100 while flying …to check if its only happening in my system would be interesting.
Probably depending on you CPU the high tlod number my be different until you get perfect MR
I was a silent reader in this thread until now: My VR experience never has been better than it is now, so please don’t even think about rolling anything back
Big thumbs up and thanks for everything that you contributed in the past for us VR guys. Not every superhero wears a cape, you know? Keep it up!
I’m the same. I quite like MR, but in my particular use of the sim, I tend to be on the ground with a complex airport/scene out the window and in the PMDG or Fenix etc sucking the sweet life out of the CPU. I get MR working ok but with dragging/artifacts as it has to fight other things for my poor sweating i9 9900K. Once up high it’s fine. Because of that I tend to run with MR off and am still super happy with how it looks still in the preview 113 and ‘Prefer frame rate over latency’ on. I’m using the RTSS locked at 30 and I think that helps some, but not 100% sure. MSFS is the only VR title I need to use that on, so like Matt mentioned, it is probably something odd MSFS does with its timings that other titles don’t.
I also have a G2 and I have been knocking my head against the wall for weeks now trying to get the best settings. I literally wake up in the night thinking about it smdh. I’d love to hear your thoughts if you could share how you set up Open XR toolkit and any other bits of wisdom (no need to detail every last setting you use ). Ryzen 7 5700x 4080 32 GB RAM
I concur: don’t let them roll it back! This is the best MR implementation so far. Prop artifacts are gone, even without the mod (I still use the mod though). Other artifacts are much lessened. Flickers and freezes are related to optional settings that can be turned off. My personal problem with the stutters I mentioned here is not connected to MR.
Fully agree, please don’t roll it back.
I deeply think we got major improvements regarding MR implementation and stability.
I can’t be much thankful for that.
New panel options are also just what we needed to get a straightforward experience in VR. Simple and effective, less tuning to perform, got much more time and pleasure to fly now. That’s awesome!
CPU app time higher than 13ms= perfect MR
CPU app time lower than 9.2ms= perfect MR
Same finding here. I run a 3080 Ti with an Intel i7 10700K.
In al my testing I can see in the MSFS developer overlay that I am always CPU limited. Looking at the CPU app time in the Toolkit overlay I noticed the same as above.
Trying to stay below the 9.2 Ms in every dense scenario means lowering resolution and Tlod too much. The other way around is also possible. Upping the settings so it will stay above 13 ms. But this can lead to filling up Vram to the max. I have not found the best middle ground yet.
This is an extremely interesting find. I too have had perfectly smooth MR with hardly any artefacts. This comes in combination with the latest OXR Tools update AND limiting framerate at 30 in RTSS instead of Nvidia CP. However, the first thing i noticed after limiting framerate in RTSS is that my frametime went up quite significantly. It’s now always somewhere between 13 and even up to 24 ms. But even so, contrary to all logic, this makes for a perfectly smooth experience. Though, my only measurement of this is via the OXR Toolkit. Now, only @mbucchia understands this deep enough to firstly even say if these measurements are even plausible as i know he stated in the past that certain things may lead to incorrectly reported measurements of CPU time. I have not tried to measure any other way.
I have another interesing observation:
As I’m mainly using the OpenXR Toolkit (OXRTK) for the configuration, I’ve found out that using MR-on without limiting the framerate only gives me max 22,5 in MR and it’s not stable in the refresh rate. Howver also limiting the max refresh to 30Hz in OXRTK I’m getting the 30Hz almost all the time (in both cases RTSS is limited to 30Hz, too). Pretty stable and rocket smooth - no wobbling (even not on the horizontal line of the FBW 320N which I’m having when MR is switched off). When I’m using MR-Default in OXRTK and configuring the MR in the OXR Tools Setting with 1/3, I’m getting similar results, but it seems to be a bit more unstable in refresh (might be subjective).
Anyhow, please keep the new version availbale, as I now found the best configuration with the smoothest experience so far!
Her is my complete configuration for getting smooth 30Hz MR with FBW 320N, fsltl-traffic injector, Flybywire Simbridge, SimShaker and some other tools running on a 5800x3d (PBO -30) with RTX4090 (950mV at 2750MHz Mclock+500) and G2 - total energy consumtion of whole PC system ~400W:
Graphics Driver: Nvidia 531.79 HAGS on, GAME Mode on
OXR Tools: newest runtime on, Rendering 100% (and it’s using NVOF10tS)
MS FlightSim Settings: Scaling 100% (done through OXRTK) DLSS Super Res / Performance, DX12, LODs 100, all other settings maxed out (ULTRA or HIGH if ULTRA not available), anisotropic filter off (see NCP)
NCP: anisotropic filter 16x, rest default except negative LOD “clamp”
RivaTunerStatisticsServer RTSS: Limit to 30Hz, calculation point “frame Start”, framerate limiter “async”, enable passive waiting
OXR Toolkit OXRTK: Resolution 4457x4362, CAS, 100% sharpen, FFR-off, Turbo-off, MR-on, Lock-30Hz, overprediction 0 (BTW: if the cameras on the side of the G2 are fully covered, you’ll get significant less shaking)
Thanks for your testing…I see Im not alone on this findings
It would be interesting if @mbuchia can give us some light on this…
One tip I would add after experimenting with image quality:
For me there is a noteceable difference in image quality and artifacts between being at 30 vs 45.
I believe the 2 ghost frames generated at 30…vs 1 ghost frame generated at 45 fps translates in a much crisper and less artifacts when being at 45.
At 30 there are ALWAYS artifacts, paning view inside cockpit just looking at lateral windows vertical frames..you can see always the “double” image on the frame while looking left or right. And I would say everything in the scenery looks a little bit blurrier.
BUT at 45 locked, it feels like 90 fps with very few artifacts, and cockpit windows frames dont have this “double” effect when paning and the scenery looks much crisper (for me).
So in my case, I lowered resolution to be always at 45, rather than having more resolution but having more artifacts and blurrier scenery image at 30
If your system can handle it, try to aim for 45 fps locked in opxrtools, using the mixed reality tools will jump to 30 fps many times (seems it likes to have too much headroom for being always at 45)
I agree, its much better to lock FPS via oxr Toolkit, with mixed reality tools it always jumps to a lower “lock level”
Eraser, I also have a 4090, perhaps you can try to lower the resolution to something like 4100x4100, use FFR…and dont use more than “medium” on clouds (Very GPU demanding)..and use medium/high settings in the rest of options (ambient oclusion, reflections, shadows etc)
Then set 45fps on the OXRTK and check how it feels while flying For me it feels more “real”, I cant describe it…but I like it more, even loosing some quality
This is how Im flying now and after a lot of testing, for me its the best experience I can get.
I’m sorry, but there’s not enough headroom to get a stable 45 MR.I tried to compromise, but with my sttings above I get a much clearer picture - expecially with the cockpit and the instruments and I can keep the 30MR which feels “real”. Have you ever tried that resolution?
Anyhow - everything we’re talking about is only possible with the newest version of the OXR Runtime - thanks to mbucchia.
this is wrong. First of all, if you lock in the toolkit and your framerate does break below 45, your reprojection will break, which is game breaking. The best result possible (and this is now confirmed by many) is setting the MR at whatever ratio you desire in the OXR Tools (so even if it breaks below, it won’t be game breaking), and then limit the framerate in RTSS (at 45 if you’re aiming for MR at 1/2). If you haven’t tried this, limiting your framerate with RTSS, i strongly encourage you to try it as this has been the game changer for many of us lately who are now having absolutely perfectly smooth sim with barely any artifacts even at 1/3 limit.
Again. Trying to lock at 45 is not possible with my desired graphic resolution. So I aim for 30. Rtss is always set to limit on the desired Hz ( in my case 30Hz). Setting 1/3 in OXR Tools rather fixes more on 23Hz. Switching it on in OXR Toolkit with Limit of 30Hz it can keep it most the time. Even if it breaks it doesn’t break the sim. Maybe you haven’t tested it kately with my settings.
I have another interesing observation:
As I’m mainly using the OpenXR Toolkit (OXRTK) for the configuration, I’ve found out that using MR-on without limiting the framerate only gives me max 22,5 in MR and it’s not stable in the refresh rate. Howver also limiting the max refresh to 30Hz in OXRTK I’m getting the 30Hz almost all the time (in both cases RTSS is limited to 30Hz, too).
This is strange but you are right… I have been testing the past weeks with MR set to ⅓ in OXR Tools and leaving OXR toolkit MR to auto (without lock but using RTTS). And indeed if I fly in a dense area it will break below 30 frames and temporarely settles at 23 frames. If this happens I see a lot of red spikes in the MSFS FPS counter and it always says CPU limited. However, when using also the Toolkit and lock MR to 30 it stays at 30 frames (and this is very interesting), the MSFS FPS counter is now all green and telling me that it is GPU limited? But perfectly smooth, no stutters…
Something strange is going on. There are now 3 locks active, OXR Tools, RTTS and OXR Toolkit ???
Yes I tried higher resolutions, even 5000x5000 at 30fps,(G2 headset) Im using a very agresive FFR and DLSS quality at 4300x4300…and many options on medium, I believe thats what makes a 45fps stable posible (in the air) but of course I loose more fancy graphics etc. Its such a compromise…
Probably Im too sensitive to artifacts and latency…and I dont know why but once I got used to 45FPS …when changing to 30, it felt a little bit worse in terms of fluidity, artifacts etc.
But the good thing is that each one can choose his preferences! one day we will be at 90FPS with a 6090
Good idea but somebody will have to take the lead on implementing that. Also the biggest challenge will be how to capture all possible settings in a non-ambiguous way. I don’t have a good solution for that.
I think I’ve experienced it at some point with certain settings in the sim but could not reproduce since. Is it particularly obvious with trees? Like runway at Sedona, looking around at the trees, tearing like crazy?
Perhaps it was the “between 9 and 13 ms” thing below. I’ll have to try that.
See [1] at the end of the message.
Let’s put the both of you to work, see [1] at the end of the message.
The option in OpenXR Toolkit for MR isn’t a limit, it’s a “force to selected rate”. Most likely your performance is in fact too borderline for the runtime to think you should do 30 Hz, and when you lock it in OpenXR Toolkit, you are forcing it to 30 in spite of that. However if you ever get too close or below 30 Hz, your experience will likely be worse than if you were locked to 22.5Hz.
For short the runtime without lock is more conservative, tries to give you a consistent experience, the OpenXR Toolkit lock is savage and will just force things even if it gives you a bad experience.
Keep reading the reply below too.
There is a difference between OpenXR Tools and OpenXR Toolkit frame rate locking for MR. They use the same technique (as opposed to RTSS), but the difference between the two is:
OpenXR Tools “Limit frame rate” will as it says, limit to a maximum, but still allow to engage at lower rate if needed
OpenXR Toolkit “Lock rate” will force the selected rate, even if it’s not achievable.
If you use both at once, I’m actually not sure what happens. I think OpenXR Toolkit settings “wins” over OpenXR Tools. I’m about 95% sure of that.
Now for the homework:
[1] would be helpful to get some short traces (like 30 seconds top) of “good MR” and “bad MR” at the same rate with/without the RTSS settings or LOD setting (to achieve desired CPU times). You can do that relatively easy with OpenXR Toolkit:
Be sure to select Yes at the “…additional WMR traces”. You don’t need to capture entering into VR. Just get the sim up and running and in a good/bad state, start the capture, let it run long enough to see goodness/badness (but not too long, big files are hard to read…), stop the capture.
I recommend doing this after a fresh reboot, there is something about capturing traces that makes them fail after long uptimes.
Your obtained file should be several 10s or 100s MB, but will ZIP to very small sizes.
I’d expect to see 2 traces: one with “good MR” and one with “bad MR”.
If you can get me those this would be helpful.
Please others, don’t send me random traces of your problems. I’m only interested in the RTSS + CPU frame time scenarios at this time.