mbucchia

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.

What you are calling "SteamVR mode" sounds like an umbrella of 2 things: - using OpenVR, which locks you into SteamVR (unless using OpenComposite) - using OpenXR via SteamVR (as opposed to OpenXR via native platform support) They are two very very very different paths, and therefore using "SteamVR mode" to reference both is a bad idea. OpenXR Toolkit will only work with apps using OpenXR, regardless of whether you choose to use the SteamVR OpenXR support or the native OpenXR platform support. This has been the case since the very first version. What we need is more developers like Asobo writing their apps with OpenXR, and like ED porting their apps to OpenXR.

SteamVR had OpenXR support for years, you are clearly mistaken. Even on Pimax (this was the only way to play MSFS until I created PimaxXR). Their conformance submission is officially tracked here and dates from early 2021: https://www.khronos.org/conformance/adopters/conformant-products/openxr#submission_11 SteamVR OpenXR support works with all headsets, but for platforms that also offer native OpenXR support, it will cost you a lot more memory to run via SteamVR. And the important part is about game support. It's not enough for your platform to support OpenXR, your games must be developed to use it. I'm pretty sure Squadrons isn't, so I'm highly doubtful that OpenXR Toolkit worked with Squadrons, and if it did work I'd appreciate that you send me the OpenXR Toolkit log file.

There is a 0.3.2 official version now: https://github.com/mbucchia/Pimax-OpenXR/wiki#installing It's essentially 0.3.1 plus a few more fixes (not particularly meaningful to DCS though).

Documentation has all the answers: https://mbucchia.github.io/OpenXR-Toolkit/other-features.html#motion-reprojection

I don't think anybody is arguing that the image quality of DLSS Frame Generation is superior to Motion Reprojection. The issue is whether DLSS Frame Generation is applicable as a replacement of Motion Reprojection in VR. DLSS Frame Generation uses interpolation between 2 already-rendered frames (also known as backward reprojection), which is how such great quality can be achieved. This technique of interpolation is not applicable to Motion Reprojection, because waiting for the next frame to be rendered would add significant latency (see my long post here: Will DLSS 3.0 be supported in VR msfs? - General Discussion & Interests / Virtual Reality (VR) - Microsoft Flight Simulator Forums). If you applied interpolation for Motion Reprojection, sure you will great image quality, but with up to 3-4 frames of added tracking latency (assuming you are running at half frame rate). You will not be getting a good experience with that kind of latency in VR, due to head movement (even unintentional). One can run this experiment today via a developer option in OpenXR Toolkit to add 3-4 frames of latency (the opposite of what "Shaking reduction" does) to a game running well... it is not usable with such latency. This is why Motion Reprojection techniques rely on frame extrapolation (also known as forward reprojection), which does not need the next frame and will instead perform motion propagation using the most recent frame and the most recent tracking data (see my long explanation here: Motion Reprojection explained - General Discussion & Interests / Virtual Reality (VR) - Microsoft Flight Simulator Forums). This will give you only a single frame of added tracking latency, which will keep the experience usable. However motion propagation is much less forgiving to prediction error, which results in the visual artifacts. Unless NVIDIA can provide DLSS Frame Generation as an extrapolation technique, I don't see it being usable for Motion Reprojection in VR. And my guess is if they did something of the sort, it would use the same technique of motion propagation using Optical Flow in input, which is something that vendors already do for Motion Reprojection today (Oculus does already, WMR might do soon). They will likely get similar outcome in case of prediction error, and therefore simular visual artifacts. So the benefits relative to existing Motion Reprojection are quite TBD IMO.

I'm sorry, but sentences like these _do not compute_. I cannot help you when I literally do not understand any of your messages Maybe this will help: the things I have shown on the other forum, the 1st one is me taking parts of the SteamVR algorithm to improve our native OpenXR one. The 2nd one is another improvement.

Pico only supports OpenXR via SteamVR OpenXR. They do not support a native OpenXR runtime, you will still need to use SteamVR. Their announcement is about them reaching compliance for Android apps running in standalone mode. It means nothing at all for PC applications. You can either use SteamVR via OpenVR or OpenXR, see my post (2nd post in the thread) on what these 2 modes mean.

I saw but I do not understand your messages. Motion reprojection has nothing to do with OpenXR Toolkit so your request is quite confusing.

I know nothing about that tool, though looking at their code very briefly, I don't see a reason why it wouldn't work. It's a DLL injection, so sometimes there are freaky edge cases that can make it not work (like forgetting to passthrough a symbol), but it looks pretty solid or at least fixable if needed.

Yes, and what you're describing is the usage for motion reprojection. It is possible for VR platform vendors to use NV Optical Flow to improve the quality of motion reprojection drastically. See the other post shared by @Pride37 right above explaining how I am doing this for WMR platforms. You can read my explanation of how motion reprojection works here: https://forums.flightsimulator.com/t/motion-reprojection-explained/548659?u=mbucchia. NV Optical Flow can be used to greatly improve the motion estimation phase of the algorithm. In all cases, this remains completely different from DLSS3 frame generation, which interpolates between 2 already rendered frames, as pointed out by @Rifter. Sure both use the same method for estimating motion between 2 images, but forward propagation (used in motion reprojection) is much more complex and less forgiving (hence the artifacts). The issue with DLSS frame generation (and backward reprojection in general) is latency, which I have detailed in great amounts here: https://forums.flightsimulator.com/t/will-dlss-3-0-be-supported-in-vr-msfs/543836/47?u=mbucchia Personally, I don't see any easy path today to get DLSS 3 frame generation in VR, because the added latency is just too much. I expect it would take significant rework of any game engine and/or VR platform to support it. At which point, today's motion reprojection techniques are simply more attractive, especially if they leverage the power of NV Optical Flow. This is however not accurate. NV Optical Flow doesn't come for free. It needs to be implemented by each vendor in their motion reprojection algorithm. Most implementations today either rely on Direct3D motion estimator or the NVENC SDK, both are generic motion vector engines and they are not capable of leveraging the Optical Flow capabilities (in other words: neither of them get any "free" benefit from Optical Flow). For reference, it took me quite a few weeks of on/off work to replace our usage of the D3D motion estimator with the NV Optical Flow in WMR (but unreleased at this time).

To be fair though, don't expect a significant increase in performance going from Fixed to Dynamic Foveated Rendering anyway. We've proven that with MSFS and iRacing. Going from FFR to DFR is an extremely small performance gain compared to just enabling FFR in the first place. DFR vs FFR isn't about performance, it's about getting the same gains but with less noticeable degradation in quality (perhaps even unnoticeable we could say).

No, none of the devices today can support DFR in DCS via OpenXR Toolkit. This isn't a limitation of the devices, this is a limitation of OpenXR Toolkit not being able to identify left/right eye rendering from the game.