mbucchia

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.

Wow this is huge. I had not heard of anyone getting such a notable difference.

You can use the "Target frame rate" option under Overlay to get hints. Set it to the "ideal" framerate you wish for, and it will give you either the amount of headroom you have (if you can reach that frame rate) or where you are limited and by how much you are limited (if you cannot reach the specified frame rate).

It doesn't look like you are using the OpenBeta?

Your capitalization of --force_OpenXR is incorrect. Capitalization matters

Btw did you want to edit the top post to remove this? With 1.2.4, Turbo should be fixed now. Or let me know otherwise.

You mean OpenXR Toolkit I believe. There is no solution to that, you will just have to share the settings in OpenXR Toolkit across your multiple installs.

This is likely just an optimization. You've probably heard of the need to render at 1.4x of the panel resolution in order to achieve best quality (you can search "vr barrel distortion" for more info, this 1.4x is just an example and may vary). When doing that for the entire image (whole panel), this 1.4x factor will make the pixels at the center rendered at 1:1: of the needed resolution for best quality (because those pixels are stretched). However near the edges of the panel, you are also rendering at 1.4x, which is wasteful because less distortion happens there (those pixels might be compressed). I assume the quad viewports here are meant to avoid the "over-rendering" near the edges, and Varjo has some logic to partially push different content to different parts of their panel. So it is basically a form of fixed foveated rendering. However, for those who have tested DCS native OpenXR support _without_ my "disable quad views" hack, I don't think you have experienced any noticeable difference in quality/performance? Worst case, I believe you should be able to achieve the same result through the use of fixed foveated rendering in OpenXR Toolkit.

Stable doesn't have OpenXR support, so it's likely the one under OpenComposite_DCS instead?

@BIGNEWY I still have people coming to me saying it doesnt work, simply because they update their existing shortcut which is for DCS_updater.exe, not DCS.exe. Could you edit your post to make that very clear? Like 1) create a new shortcut to DCS.exe, 2) add --force... Thanks!

You need to force OpenXR not SteamVR (unless you are using OpenComposite). You cannot do it via Skatezilla afaik. See the pinned post on the forum about OpenBeta OpenXR support.

It sounds to me that you are trying to use OpenComposite ("added the DLL") with the SteamVR OpenXR runtime, which is totally unnecessary. If you want to use OpenXR via SteamVR, don't use OpenComposite at all, just see post 1 and 2 on this thread, run the game with --force_OpenXR while you have OpenXR set in SteamVR developer settings (which you seem to have gotten right already).