mbucchia

This likely means you are using SteamVR.

It was worth the try between the 2 modes. TBH what I have learned early on with Motion reprojection is that people will either love it or hate it. There is no seeking 100% satisfaction with it. If it doesn't work we'll for you, don't use it. I'm told that using OpenXR Toolkit or Nvidia options to limit frame rate to 1/2 (eg 45 FPS) without motion reprojection works well. Using a fractional rate like this produces more consistent frame latency and helps with smoothness. Perhaps this is something that can work better than Motion reprojection for you?

I suggest you try comparing with and without Nvidia Optical Flow enabled. One might be more adapted to your content than the other. You'll need to restart the game when changing that setting.

That's probably what's called a "deocclusion" artifacts. We can't predict what's behind your wing, so unless it's a fairly simple/repeatable pattern, you will still see a trail of bubbliness. Hopefully you are not running at 1/4 rate because that's too low of a rate to get a decent experience IMO.

It's not gone. You need to enable custom render scale checkbox first (same as before). We had to replace the slider with an input box due to accessibility issues. But it still works exactly the same. The Optical Flow motion reprojection is a new mode. It may or may not produce a better effect (it depends on people and games). I wrote some slightly more complete release notes on the other sim's forum: https://forums.flightsimulator.com/t/openxr-tools-for-windows-mixed-reality-update-in-the-store-4-14/586988

That update is rolling out now: Please be patient if you don't get the update from the Microsoft store quite yet... it takes a few hours, and sometimes up to 48 hours!

I'm not going to implement this on Pro. The Pro is too low resolution to benefit from the quad views. When doing some quick math earlier, it looked like the gains on Pro would be perhaps one quarter of the gains of Aero/Crystal. Doing quad views on the Pro isn't worth the development effort. Their compositor doesn't support fovMutable which makes the task even harder.

Nothing stops other vendors to implement Varjo quad views in their OpenXR runtime though. I am currently adding support for it in my OpenXR runtime for Pimax, so that hopefully it's usable with Crystal as well (and I'm making it an option to force foveated rendering even if the app doesn't ask for it, so users on Pimax won't even need the extra Varjo-Foveated software to enable it). All this stuff is relatively small development efforts, but for a fairly small number of users (whether Varjo or Pimax). I believe that's the excuse developers (both engine and platform) are hiding behind when not implementing these features. There probably isn't sufficient ROI from giving you better performance

Yes it's a Windows Store application, those get updated automatically. Unless you made some fancy policy to disable/delay updates.

This issue will be fixed in the new version of OpenXR Tools for WMR, and there won't be a need to use OpenXR Toolkit for that.

Patience folks... there should be some good news coming in the next couple of weeks.

Automatic in OpenXR Tools for WMR means "only MSFS2020". In other words, it does _absolutely nothing in DCS_. So I highly doubt your issue has anything to do with this setting... you probably should start looking elsewhere. PS: the "Automatic" is being remove in the next version of OpenXR Tools for WMR.

Well as dburne said PSVR isn't really a device made for PC. IMO you can only gain from starting to use any headset that is actually made for PC instead... you'll get broader and better platform software support.

If you are using iVRY then it's a SteamVR driver and therefore you can use OpenXR via SteamVR. You'll need to set SteamVR as your OpenXR runtime as described in this post: However, I expect you will see little-to-no gains from using OpenXR via SteamVR vs OpenVR. The performance and quality will likely not be better.

Maybe try turbo_mode=0 as well. I'm told it's been reducing framerate in some circumstances.

100% not, SteamVR doesn't have the concept of quad views nor eye tracking. Edit: OK not 100%, but let's say 99% because tremendous amount of work to reimplement quad views on top of SteamVR and inject the eye tracking from outside of SteamVR Not worth the effort for 1 game and 1 headset brand

It should be 4 and 5, depends on whether you disable eye tracking in the config file as well.

Can you check with the testers on Varjo discord? None seen that so it's a bit surprising. Of anything, I would think turbo_mode=1 would cause issues, not the multiplier tweaks...

Thanks for posting this! I don't want to take all the credit here, because the foundation (ie: implementing the Varjo quad views) is all done by Eagle Dynamics, and that is frankly THE complex part, that they have achieved without anything from me. Adding the foveated rendering on top was quite easy. @BIGNEWY I always love to share some useful feedback for the dev team, so maybe you could forward some of this to them: 1) With XR_VARJO_quad_views working, adding XR_VARJO_foveated_rendering is really super simple! The dev team should check out the OpenXR spec for details. It's very straightforward, just need to add a few things here and there to make a great feature! This is all my program does really. Let's wait for feedback, but I feel it is well worth the effort to implement inside the game for all Varjo users. My code is also open source and can be used as reference (see link). My code is more complex than if it was done in-game, and implementation in the engine is likely < 50 lines of code total. 2) I did find what looks like a bug in the engine, that made things a little more tricky: it seems that with multithreading, the engine is sometimes mixing up the FOV values that it submits with each frame. This causes the FOV values queried to render frame N+1 to be submitted for frame N instead. The trace below shows an example of it (see the "display time" values and how the submitted FOV values for view 2 and 3 do not match the correct frame display time? Red arrow shows what needs to be done instead). This bug breaks foveated rendering because it introduces a 1-frame warp of the focus area, and I put a workaround for it in my program (that literally does what the red arrow shows, by matching the FOV values with the correct frame display time).

That's only applicable to WMR devices (eg: HP Reverb G2). Toggling the OpenXR switch in Varjo Base will effectively make Varjo your OpenXR runtime, which is what you need, not the WMR one.

"toogle" literally means the string "toggle", meaning turn off if it's on, and turn on if it's off. No value other than "toggle" is accepted.

https://mbucchia.github.io/OpenXR-Toolkit/cli.html -record-stats toggle

This will be fixed in an upcoming update to OpenXR for WMR. In the meanwhile, you can use OpenXR Toolkit to mitigate the issue: Quickstart | OpenXR Toolkit (mbucchia.github.io)

My OpenXR Toolkit has an on-screen overlay that will display FPS, CPU/GPU frame times, and VRAM usage, as well as an option to record data to CSV file: https://mbucchia.github.io/OpenXR-Toolkit/

OpenXR Toolkit with Varjo and DCS native support requires the Varjo OpenXR Wrapper, as mentioned in other threads on this forum: https://github.com/mbucchia/OpenXR-InstanceExtensionsWrapper/releases There is a website with a search function and many many of the answers to these typical questions, eg: https://mbucchia.github.io/OpenXR-Toolkit/other-features.html#motion-reprojection