mbucchia

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.

For those who were held back into OpenComposite, I just released a new version of OpenXR Toolkit 1.2.4, when used with DCS in native OpenXR mode, will let you use WMR reprojection and also Turbo Mode. Quickstart | OpenXR Toolkit (mbucchia.github.io)

Released a new version of OpenXR Toolkit 1.2.4, when used with DCS in native OpenXR mode, will let you use WMR reprojection and also Turbo Mode. Quickstart | OpenXR Toolkit (mbucchia.github.io)

I can confirm 100% that the max() logic described above solves all 3 of the issues I've been tracking: motion reprojection hang with WMR, random crashes with PimaxXR, and hang when using OpenXR Toolkit Turbo Mode. I am investigating whether there is any negative side effect to it.

@BIGNEWY more information for the dev team regarding the remaining lock-up due to the frame loop deadlock. After some more investigation, I believe the condition happens if and only if the frame predicted display times (xrFrameState.predictedDisplayTime) does not increment monotonically: As seen above, the last value for predictedDisplayTime returned before the lock-up is 3,081,690,700,100, which is smaller than the previous frame predictedDisplayTime of 3,081,701,810,000. This seems to cause the game's frame loop to entirely skip the frame, without calling xrBeginFrame() (which is illegal and causes the deadlock). Now I have to admit, this is a little bit weird, because per The OpenXR Specification (khronos.org): I am thinking that because the loading screens in the game are skipping many many frames, this is confusing the motion reprojection logic. That's not OK and I will make a report to fix this in the next release of our runtime. Meanwhile, I believe if the game engine made sure to always invoke xrBeginFrame() for each xrWaitFrame(), regardless of the predictedDisplayTime, this will make the engine more robust to these situations. Perhaps better, always use corrected_predictedDisplayTime = max(current_predictedDisplayTime, last_predictedDisplayTime + 1) to even avoid skipping a frame and ask the platform to perform the necessary frame reprojection. I believe if the dev team implements either one of these measures, the lock-up issues will be resolved. For OpenXR Toolkit users, I believe this is the same issue that they are seeing with Turbo Mode. To be clear, there are 3 bugs here, one in the game engine frame loop, one in the WMR OpenXR runtime, and one in OpenXR Toolkit. Oops!

Anamorphic is quite tangential so I'm not really sure why you bring it up. It lets you adjust the resolution using a different scale factor on vertical/horizontal. Back to Override Resolution it serves two purposes. - you can use it in place of Upscaling if you don't like NIS/FSR. I don't personally find that quite useful. - you can use it for supersampling, meaning rendering at a resolution greater than the recommended resolution ("100%"). This is similar to OpenXR Tools Custom Render scale > 100%. You can then use it in addition to Upscaling, which is perhaps the more interesting use case.

I do not know the breakdown (and I don't think anyone but the executives do, and certainly not those "bloggers" writing articles about it while their normal coverage and "expertise" is to report that the new Call of Duty was released, or they have just benchmarked the new 4090...). I have heard directly from people across the company being let go, in various disciplines, many of them having nothing to do with MR. I know directly many people working in MR that have not been impacted (including myself). You can yourself go on LinkedIn to find messages from employees themselves to corroborate. (EDIT: For clarity MR = Mixed Reality, which is the actual name of the division).

This and OpenXR Toolkit Override Resolution do the same exact thing. The OpenXR Toolkit one, if enabled, will override any other setting though (as the name said). In other words, if you have any Override Resolution in OpenXR Toolkit, it takes precedence over what you had set in OpenXR Tools for WMR.

Why did you rename those files at all... nothing in the instructions says to do that. Your VarjoOpenXR.dll is now called VaarjoOpenXR.dll (two 'a'). That ain't gonna work.

This is absolutely not true and I know that first hand... Please folks, do not blindly believe those completely incorrect articles you see online.

Thank you, though this message is a little overdramatic and could be misinterpreted Varjo loaned me an Aero eventually, and they haven't been any trouble. ED did not want to implement the render target hint at this time, and it's totally their right to make decisions on what they put/don't put in their product.

"Cull outer mask" is an option meant for iRacing, because that game does not implement proper HAM while rendering (using the traditional stenciling technique). You're not missing out by leaving it off in DCS. Use OpenXR Toolkit Safe Mode to Restore settings to default and remove the crash. https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html#start-in-safe-mode