mbucchia

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).

I'm a bit confused by your observation. When I tested with 1.2.3, I confirmed that eye tracking foveated rendering did not work properly. Out of the 38 render passes observed (as delimited by "switching render target"), 3 of them were misclassified (left instead of right, or vice-versa). This completely kills the effect of foveated rendering unfortunately, because the final pass for each eye used the wrong mask, therefore narrowing the inner ring to be almost inexistent. As a result, in 1.2.4, I force-disable eye tracking in DCS, so it's no longer advertised.

There's no reason it would break MSFS. To remove, you can find the instructions on the download page (see top post).

These options only apply to Windows Mixed Reality headsets. https://mbucchia.github.io/OpenXR-Toolkit/other-features.html#motion-reprojection

Thanks all, your observations confirm that the fix I discussed earlier (in the MSFS thread) should be satisfactory for you once it is rolled out.

There's always a bit of confusion... thank you both above for commenting. OpenXR TOOLKIT was technically first to bear the name, until OpenXR Developer Tools for WMR was renamed OpenXR TOOLS for WMR, which created a lot of confusion

It was disabled entirely in 1.2.4 since it doesn't work properly. Quest Pro only supports "eye tracking for social interactions" today, think like "to render high fidelity avatars". This works on both PC and mobile, however 1) it uses a non-standard extension 2) the support for social interactions looks insufficient to do foveated rendering, due to additional filtering of the eye tracking data for smoothness and convergence corrections to make the avatars look natural.

No this was fixed in OpenXR Toolkit 1.2.4.

One test you could do and that would be interesting: try OpenXR+SteamVR (not OpenVR) and see if you get the same experience (that you like) on both. This would give me some more information on where to look specifically. See my other post on how to toggle SteamVR OpenXR and OpenXR for WMR: Thanks.

That's both true and not entirely accurate. For details on shortcomings of the motion reprojection algorithm itself today compared to the SteamVR implementation, refer to my post above. This isn't related to OpenComposite. There was however an additional obstacle with OpenComposite, which was indeed related to frame prediction time not being reported properly, due to how OpenVR works. This can be observed (if I recall properly) when running the game (or any game really) with OpenComposite and using OpenXR Tools for WMR developer option "Jiggle view rotations". When you use that, the view in the headset shall remain stable (except flickering in the corners). With OpenComposite, I recall this test failing: instead the whole view shakes really uncomfortably. This is evidence that the frame prediction times are misused by the application (here OpenComposite, but again not their fault, they are limited by OpenVR), and therefore will make motion reprojection much less accurate. Now with DCS native OpenXR mode, you can run the same "Jiggle view rotations" test and you observe that the image does remain stable in the headset (not in preview windows, but that is expected since preview windows doesn't perform reprojection). This test passing now means that frame prediction times are properly used by the application (here the DCS engine itself). So this is definitely good news, because it should help make motion reprojection more accurate. For a more detailed explanation of how motion reprojection works in general, see my other post here: Motion Reprojection explained - General Discussion & Interests / Virtual Reality (VR) - Microsoft Flight Simulator Forums.

See https://forums.flightsimulator.com/t/openxr-toolkit-upscaling-world-scale-hand-tracking-release-thread/493924/3034?u=mbucchia (And no I do not have a release date, as someone else mentioned, I am on personal time off).

Make sure you are not running in Safe mode (there's a big red message in the menu when you do that). FFR definitely works.

You are mixing up OpenXR Toolkit and OpenXR for WMR. OpenXR Toolkit doesn't implement any motion reprojection, the change you are looking for will be on OpenXR for WMR (when ready).

Can you try just OpenXR and no OpenXR Toolkit? I don't do anything to the 2D window. Maybe look into OBSMirror for capture. That solution works with OpenXR and OpenXR Toolkit.

It still does, though as explained below, the engine only makes the double call if the runtime/API layers feed it a certain pattern of data. The change in 1.2.4 adds a safeguard to make sure the game never receives such pattern.