mbucchia

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

See FAQ: https://mbucchia.github.io/OpenXR-Toolkit/FAQ.html#q-theres-already-a-nisfsr-option-in-my-gpu-driver-do-i-need-this

There's typically two reasons for this: - you might have accidentally turned on "Foveated Rendering killswitch" while in safe mode. Use the "Restore defaults" option in the Menu tab and restart the game. - some Nvidia users experienced that issue after updating Nvidia drivers. The driver stopped advertising the capability. They had to do a full driver reinstall to get it back

I thought this was always an issue with Varjo, even without OpenXR. This was the reason you had to use --force_steam_VR so that the game wouldn't use the Varjo mode instead (which also had this double cursor bug). Am I misremembering?

No it's exactly the same thing.

I suspect you might not have hit "Confirm?" when doing this. Because it would have deleted the registry key like you ended up doing later. The issue you had was most likely conflicting settings somewhere between either the game and OpenXR Toolkit or Varjo and OpenXR Toolkit. This is an unfortunate consequence of multiple components contributing to a complex state. The Safe mode + Restore Defaults is meant to address exactly that.

Wrapper writes a log here: %LocalAppData%\InstanceExtensionsWrapper.log Worth checking this file out. Delete your current log file and try running DCS again to see if a new file is created. However, if like you said, you reinstalled Varjo Base, well that part deleted the wrapper, so I'm doubtful that was the issue.

I don't think the replies where "critical", every reply seems like it just added some extra information to clarify what you were seeing and what how SteamVR works. The place of SteamVR in the ecosystem creates a lot of confusion (probably just because it's a very rich platform). Without the replies to clarify what you are experiencing, the takeaway of this thread, which is your opening statement "SteamVR Beta just added OpenXR support!", could only create misinformation.