mbucchia

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

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.