Those are some good tips I’ll try next time. I can generally run a little over 40fps at GA airports with my current settings. I think that’s scaling at 85%, FSR on, sharpening 40%, shake reduction at 0, MR off. Even here, when I turn on MR, I get wobble just sitting at the parking space.
Since I’m GPU limited, I’ve actually turned TLOD up to 200, thinking my CPU is not being tasked as hard due to my GPU being maxed out. Maybe I’ll drop that to 100 as an experiment.
I’m maintaining 31fps with MR enabled and hitting 40 with it disabled, according to the toolkit fps counter.
Motion reprojection is still wobbling and shimmering on static objects and unchanging parts of the frame just like in the videos linked above.
From my past observation of MR issues, I would agree, but there was plenty of CPU and GPU headroom to achieve 30 FPS locked in MR when I made that video.
Here’s what my unlocked FPS and frame times look like with the settings I used for that wobble video, which should absolutely eat a 30 FPS lock for breakfast:
I even tried progressively reducing my render resolution even lower and MR ended up locking at 45 FPS there was so much headroom, yet at no stage did that wobble disappear.
As mentioned earlier, that particular issue was a bug with 1.1.2 of the OpenXR Toolkit and has now been fixed with 1.1.4, which I am now running. The wobble happens whether I show the OpenXR Toolkit menu or not.
I wholeheartedly agree. I wonder how we report such an issue to the Windows OpenXR team, or is @mbucchia our conduit?
Unfortunately, there’s nothing me or my team will be able to do unless we identify the difference between a working and a non-working setup. If we cannot reproduce the issue, there is nothing we can do.
For now I propose that you send me a trace file:
I was just in the process of creating this trace file and, after disabling everything including OpenXR Toolkit, the superflous wobble around stationary objects was pretty much gone and I’d say MR artifacting at the border of stationary and moving parts of the image was actually acceptable. Turning OpenXR Toolkit back on brings back the bad wobble on stationary parts of the image. Resetting OpenXR Toolkit settings and restarting MSFS has removed the bad wobble again, so I’m currently trying to quantify exactly what OpenXR Toolkit setting is causing the flubbering and will report back when I find it.
Good to hear. Perhaps try the shaking reduction? I could see how messing with the frame prediction time cause all sort of weird stuff.
See this message and its follow-up:
Indeed it seems Shaking Reduction was the culprit. I had mine set to 50% but as soon as I drop it to 0% the wobble on stationary objects goes away. If I set it to 100% it is flubber city. Oh, well at least we’ve found what it is. I like Shake Reduction in non-MR but unless it is fixable in MR I’ll be turning that feature off in future if I use MR. Thanks for your assistance and patience in finding the cause of this elusive issue @mbucchia 
Cool. Tbh I really thought you had tried without OpenXR Toolkit, I should have asked earlier.
I had uninstalled and reinstalled it, but hadn’t tried actually disabling it and it must have remembered my settings. Nonetheless, we got there in the end. 
I’ve been following along. I’ll try this out next time I get a chance. I have pretty bad wobble on my instruments while sitting at a parking spot, and I thought I had since abandoned the shake reduction setting since I saw no benefit, but perhaps I still have it enabled. I’ve messed with so many settings it’s probably time to reset them and start over.
Tuning for VR performance is a lot more involved than I expected it to be. So many different opinions and settings throughout the forum and on YouTube.
You got that right. It’s a bloody nightmare.
Do you know if the shaking reduction affect on motion reprojection is ‘fixable’ or is it out of your control from the toolkit point of view.
I dont think it is fixable, see my reply here:
I’ll try one thing really quickly to see if it improves, but thats the on idea I have.
From what you are saying, if the CPU is waiting to start the next frame - i.e. waiting on the GPU - then does that mean the App CPU and App GPU are cumalitive figures?
That is, the CPU computes the frame to be rendered, then waits as the GPU renders it before starting the next frame - which would mean that the total time to render the frame is App CPU + App GPU - which would need to be ~30ms or less to achieve 30 fps.
I ask because I get stutters when App CPU + App GPU gets to the 30ms+ mark, with App CPU being around 10ms and GPU around 20ms+
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
