mbucchia

I haven't looked at that in depth yet, but strongly suspect that Turbo mode doesn't work for the same reason motion reprojection doesn't work for some users. So hopefully when that game bug is fixed, we might have a shot at Turbo mode.

I honestly don't think the "Cull outer mask" option should do anything useful at all with DCS. But it'd be nice if someone could try and compare.

I can confirm that I am observing the same exact xrWaitFrame() deadlock as before. This is the same issues that certain users of Pimax (not WMR) are experiencing too (and there is no motion reprojection involved there). This is not an issue specific/related to motion reprojection: this is an issue of frame loop that gets exacerbated with specific frame times. The frame loop seems to entirely skip a frame and go back to the top of the loop (which the first call appears to be xrPollEvent()). The last "good" call before that "skip" is to xrGetActionStatePose() to check for motion controller tracking. The OpenXR API is agnostic of motion reprojection. This is a bug that could happen even without it. I would look for what can go wrong between xrGetActionStatePose() and xrBeginFrame() and that may cause the code to hit the top of the loop (xrPollEvent()).

The "Reset all settings" bit is a clickable link that takes you to a section that has screenshot showing the exact menu entry to look for: https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html#reset-all-the-settings

It's not enough to use Safe mode to "check" the settings. As explained in the troubleshooting guide on OpenXR Toolkit website, Safe mode just _does not load any settings_. So of course things like reprojection will appear off while in Safe mode. But if your previously saved settings have it on, the moment you disable Safe mode, these settings are loaded again. What you need to do instead is use Safe mode to Restore Defaults from the Menu tab. Don't forget to Confirm. Also, you want to make sure that in OpenXR Tools for WMR (if you have it installed), Motion reprojection is set to Disabled. Because by default, OpenXR Toolkit will just passthrough that setting from OpenXR Tools for WMR. I have no outstanding reports of crashes related to OpenXR Toolkit with yesterday's OpenBeta update, as long as both Motion Reprojection and Turbo are left off. All people who reported issues had them resolved after Restore Default from Safe Mode, then staying away from Motion Reprojection and Turbo. So I think the 2 recommendations above should resolve your issue.

I don't know, you seems pretty proud to "have been there in 2014" and keep repeating that like it was a privileged that none of us had? I don't get the point of it. Also, read the news too, the layoffs have been affecting all of the tech industry for many months now... it has nothing to do specifically with the XR industry. Many of the people laid off have absolutely nothing to do with XR. I am only pointing out that a lot of your so-called "facts" are ill-informed, and the way you are putting them out without backing information and all your negative langage clearly shows your bias, and ultimately your lack of credibility.

Your message has absolutely no substance. There were other people in VR in 2014, and even before, you know. Unless you are also going to claim being the inventor of VR? Sure, some of the things you wrote above are accurate, but mixed in so many twisted "facts" and inaccuracies that are very clearly biased by your uber-negative opinion of the vendors being discussed. It was a great idea for you to start a post to try to clarify the current situation after today's update, it's only too bad that it turned within a few words into anti-Microsoft, anti-Meta, anti-everything propaganda with absolutely no backing facts. This thread could have been helpful if it wasn't for that.

Dude just stop. You are incorrect on so many levels, and very clearly do not know what happens behind the curtains.

Follow the "Start in safe mode" bit, it is meant specifically for these situations where a setting prevents start up. Troubleshooting | OpenXR Toolkit (mbucchia.github.io)

No, they appear to intentionally force XR_VIEW_CONFIGURATION_TYPE_PRIMARY_QUAD_VARJO as long as they detect Varjo via instance capability (XR_VARJO_quad_views), and even if the runtime doesn't advertise it (I updated OpenXR Toolkit to force not advertising it). See my comment here about proper enumeration logic, which they do not appear to follow:

Game bug: Nothing I can do about. It does work for certain users though (PimaxXR 0.3.0 works fine for me).

@BIGNEWY this issue is also affecting certain PimaxXR users. Same exact situation, regardless of whether they have motion reprojection or not: null

I added a note in my post, this is certainly a good fallback for people who just can't get OpenXR working.

You do not need OpenComposite anymore. You can just use OpenXR via the SteamVR OpenXR runtime.

Few things that may be useful. With OpenXR supported in the game, you do not need OpenComposite anymore, regardless of what headset you use. The goal of OpenComposite is to bridge OpenVR to OpenXR. Using OpenComposite now would be redundant. With OpenXR, you may have the opportunity to either USE or NOT USE SteamVR. See the table below for headsets capable of native support (bypassing SteamVR): Headset brand Has native OpenXR support? (without SteamVR) Windows Mixed Reality (HP Reverb, Samsung Odyssey…) Yes Oculus (Rift, Quest, Quest 2, Quest Pro…) via Link Yes Oculus (...) via Virtual Desktop No Varjo (Aero, VR-3…) Yes Pimax (5K, 8K…) Yes (via PimaxXR) HTC Tier 1 (Vive original, Vive Pro, Vive Pro 2) No HTC Tier 2 (Vive Cosmos, Vive Focus) Yes (via VIVE Console) Valve Index No Pico (Neo 3, Neo 4) No NOTE for Oculus users: if you are using Virtual Desktop, you MUST USE SteamVR (as of date of writing 2023-01-26). Only Link cable and Air Link will work with Oculus native OpenXR support. NOTE: headsets in the list above without native OpenXR support can still use OpenXR, but you MUST USE SteamVR as your OpenXR runtime, as explained directly below. If you want to USE SteamVR with OpenXR Why/when to use SteamVR OpenXR? - I have a headset that does not support OpenXR natively (eg: Valve Index). - I rely on SteamVR features (like overlays or controller button bindings). - I rely on SteamVR 3rd party apps (like fpsVR or OVRMC). You must set SteamVR as your OpenXR runtime and run DCS.exe with --force_OpenXR (see BIGNEWY post above): If you wish to revert to using OpenVR instead of OpenXR Why/when to use OpenVR? - I rely on OpenVR 3rd party injections (mods) like ReShade or vrperfkit - I could not get OpenXR to work You must run the game with the extra command-line argument: DCS.exe --force_steam_VR If you want to NOT USE SteamVR at all Why/when to use OpenXR without SteamVR? - I have a headset that supports OpenXR natively (eg: HP Reverb). - I want to remove the overhead of SteamVR (lower memory usage and possibly higher image clarity). The procedure varies by headset/brand, and you must run DCS.exe with --force_OpenXR (see BIGNEWY post above): WINDOWS MIXED REALITY (use EITHER method) From Mixed Reality Portal: From OpenXR Tools for Windows Mixed Reality: OCULUS (Link cable or Air Link only) From the Oculus app: VARJO From Varjo Base: PIMAX You must download unofficial Pimax OpenXR support: Home · mbucchia/Pimax-OpenXR Wiki · GitHub Then from PimaxXR Control Center: HTC (Vive Cosmos and Focus only) You must install the HTC Vive Console For SteamVR. Once opened: To inspect the current configuration on your system (and make sure OpenXR is properly installed and configured), you can use OpenXR Explorer. It will show you the currently active OpenXR runtime (which should match your device if you want things to work!):

Thanks. Can you also check with the dev team if there is a way to disable usage of XR_VARJO_quad_views for Varjo users, via a command-line argument for example? That's an atypical mode and it is breaking some of the mods out there. Cc @zildac Also, apps should always check for view configuration availability via xrEnumerateViewConfigurations(). That doesn't seem to be the case here and DCS seems to activate XR_VIEW_CONFIGURATION_TYPE_PRIMARY_QUAD_VARJO regardless of whether it is enumerated, as long as XR_VARJO_quad_views is available from the runtime. This is not a conformant behavior when using OpenXR.

There is a safe mode option in the desktop companion app. Use that to start the game, then restore defaults from the menu. https://mbucchia.github.io/OpenXR-Toolkit/troubleshooting.html#start-in-safe-mode Sounds like your issue is that you had enabled Motion Reprojection indeed.

Working fine for me and several other reports on my Discord. Seen good reports with G2, Quest 2, and Pimax (EDIT: Add Quest 2 after report below). However the bad news is for Varjo users, where it just won't work because the new engine uses VARJO_quad_views, and this will not be supported. Unless there is an option (maybe ED can tell us) to disable quad views, there will not be support for Varjo anymore. Also if you are on WMR and using Motion reprojection enabled via OpenXR Toolkit, you want to disable Motion reprojection. There's a bug in the game engine that causes that to crash (not related to OpenXR Toolkit or OpenXR for WMR).

You always have the option to set SteamVR as your OpenXR runtime. That should work pretty universally and re-enable the use of things like fpsVR.

You may forward to dev team: the game is doing 2 back-to-back xrWaitFrame() from the same thread, which causes a deadlock. nullThis condition is probably exacerbated by the frame timing of motion reprojection. Read more about xrWaitFrame() deadlocks here: OpenXR-Guide/frame_submission.md at main · KhronosGroup/OpenXR-Guide (github.com) Happy to find a more official channel to discuss. Thanks.

OpenXR Toolkit is not related/endorsed in any way by Microsoft, OpenXR Toolkit is my week-end project. My comments associated with the development of OpenXR Toolkit shall not reflect in any way the positions/views/opinions of Microsoft. Please do not associate anything WMR here. The moment you are doing this is the moment trouble begins for me. I have deleted my previous comment from Discord and I publicly apologize for my comment that did not reflect the positions/views/opinions of my employer. (EDIT: To be clear, my comment was also taken out of context when copy/pasted on this forum... it was not specifically targeting this developer or this title.) I have no desire to pursue any developments in OpenXR Toolkit related to this title, and therefore this discussion is no longer productive. (EDIT: To be clear, this does not mean OpenXR Toolkit will stop working, I just do not have plans to write new features specifically for this title, like it had been done on several occasions in the past.) (EDIT: One more "To be clear": on a previous page of this thread, I had mentioned that my team at Microsoft (which again is a completely separate effort from OpenXR Toolkit) is always open to help developers with migrating their applications to OpenXR, and my team has a track record of helping a handful of major game studios doing so. This is a permanent offer that always stands, including for the developers of this title, regardless of any discussion that took place regarding my OpenXR Toolkit project.) Asking @moderator at this point (so @BIGNEWY I think?), can we please lock this thread? Thanks.

There is no dependency on OpenXR Toolkit needing OpenXR Tools for WMR. If you have OpenXR Toolkit, you only really need OpenXR Tools for WMR if you want to enable WMR beta ("Preview runtime"). Also @shambler6691 you should only get OpenXR Tools for WMR if you have a WMR device (eg: HP Reverb). It's not useful with other headsets.

Great to hear and thank you for the feedback! We will be promoting that beta to stable in the next few days (if not today perhaps).

Yes, to be clear this is a deficiency of OpenXR Tools for WMR, not OpenKneeboard. But it is what it is today. I've been encouraging people to use OpenXR Explorer as well.

Are you on Windows Mixed Reality? If so, definitely give the beta a try: https://steamcommunity.com/games/719950/announcements/detail/6096216107292749119 We fixed an issue with a memory leak that caused VRAM to fill out.