I’d like my app to work with users who use Steam for convenience, but MicrosoftKhronos’s loader doesn’t seem to be compatible. I was trying to use SteamVR’s runtime to test this (Do these XrFovf values look suspicious/defective to you? {-0.785, 0.707, 0.785, -0.782} {-0.785, 0.866, 0.785, -0.781} - #10 by mbucchia1) problem with a different runtime, but I realize this may be an issue since so many gamers use Steam. I’m not sure why Microsoft’s loader doesn’t route to Steam’s runtime when it’s the active runtime. I assume they just don’t play nice with each other.
FYI: Yes I have turned on SteamVR’s “current OpenXR runtime” option, and it does worry me it’s under the Developer section, as it makes no sense being there.
EDITED: When I open the OpenXR Tools for WMR mini app it shows SteamVR. I’m also very worried I can’t disable SteamVR now in Steam’s app… it turned from a button into a text label! What gives???
EDIT#2: The “Launch OpenXR demo scene” button isn’t working either… it seems to crash SteamVR. But it’s not working with WMR either… in that case it does a transition (gray instead of blue for some reason) and the “scene” shows up as a black screen… then after a while it beeps (with WMR runtime) and goes back to Cliff House. I guess all of the infrastructure around PCVR is still highly untested/experimental more so than I thought as a late comer. Note, my app and Cliff House still work, so this seems specific to the pack-in demo app. Which as I recall is very simple, purple rocks or green grass, low-poly, I can’t recall.
There is no such thing as “Microsoft’s OpenXR loader”, the openxr_loader.dll comes from Khronos. We don’t have a special Microsoft build.
Regarding switching runtime, each vendor implement their own “Switch to my runtime” button. When you open the developer settings in SteamVR, it only knows to switch to the SteamVR runtime. Same for Oculus’ software. Same for WMR Portal. Same for Varjo base software.
To change back to the WMR runtime, you have 2 easy options:
the WMR Portal will have a banner at the top with a “Fix it” button
the OpenXR Tools for WMR has a “Set as active runtime” on the 3rd tab to the right.
I believe the demo app works without issues with the SteamVR runtime, I will double-check tomorrow to be sure.
Would you mind taking a look at this (KING'S FIELD 25th PROJECT by swordofmoonlight) VR demo I just published, to see if it can be made to work with SteamVR or non-WMR devices without modification? I figure you might already know that, but I’m curious and I didn’t have any luck myself today as this topic/thread attests to. I’d really like an answer to this question and if necessary advice how to manage this from the end-user’s perspective.
The loader was downloaded not too long ago from NuGet taking guidance from Microsoft’s documentation. It’s written for OpenXR and I’ve only been able to test it with my HP Reverb G2. There’s a section in the middle that explains how to use F2 to put it into VR mode, F1 after to change super-sampling, and some other tips. It’s also a pretty cool app IMHO (knock on wood it runs and isn’t a dud, being a fresh demo.)
Your app has been working for me with the WMR runtime, but not with other runtime (“Stereo Unavailable (3)”). Tried SteamVR (with WMR), Varjo and PimaxXR.
What I get is the loader not able to find a runtime:
I think the issue is that your app is 32-bit. The WMR runtime supports 32-bit, but none of the other I have mentioned do (SteamVR and PimaxXR do not, I’m not 100% sure about Varjo but it looks like the answer is no).
It might look like an issue of the loader, but this is only because in 32-bit mode, the loader will use the ActiveRuntime from HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Khronos\OpenXR\1 (instead of HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenXR\1).
For short (believe it or not), the WMR runtime offers wider support than the other ones, and this is why your app works on WMR but not with other runtimes (yes, including SteamVR for WMR, because the SteamVR runtime (not the WMR part) does not support 32-bit).
AFAIK, your only option to support other devices is to port your app to 64-bit. I am not sure what the roadmap is for other vendors to support 32-bit with their runtimes.
One quick note: I see that you are doing xrCreateReferenceSpace() every frame, which is legal but certainly strange (and perhaps affect performance due to the inability for runtimes to cache XrSpace information).
Concerning this: I’ve been able to run the WMR OpenXR demo scene using the WMR runtime, Oculus runtime, Varjo runtime, all 3 worked successfully. I am however getting a crash with the SteamVR runtime, which seems to indicate to an issue with the SteamVR OpenXR runtime rather than the app itself. Will look into it.
Ah, that would make sense. It’s really weird that SteamVR doesn’t have 32 bit support when it does with OpenVR.
Speaking of the wide support in the WMR runtime, are there any plans to support OpenGL and Vulkan? Almost all the other runtimes support both, and it seems like a big roadblock for interoperability.
Vulkan is on the roadmap, and meanwhile you can use this API layer to make it work.
Most of the middleware today will offer you support for DirectX (eg: Unity will let you build your app with Vulkan or OpenGL but fallback to DirectX if needed).
For people not using middleware, if you are seeking performance and portability, the recommendation is to go with modern technology like Vulkan rather than 30-year old technology like OpenGL.
Awesome! I know we established that openxr_loader.dll is Khronos property, but I just think it could give better diagnostics in this scenario, if you guys are in communication.
32-bit support is definitely a problem for my app since it builds onto an older runtime. It’s good to know. There’s probably not a solution for this in my case. Even if there’s some interop solution, I reckon timing would be a problem, and there’d be an extra buffer copy penalty.
Of course: If there’s any possibility Microsoft could lean on these other guys to support 32-bit I’d be in your debt for life!!
EDITED: KING'S FIELD 25th PROJECT by swordofmoonlight is the app in question. I’m surprised it’s not in this topic/thread somewhere already! Send this to MS to make a case for why Valve and Pimax should include 32-bit builds. It’s probably not hard for them.
OpenGL can do interop with D3D11. It’s a pain in the butt. But it’s actually more stable than Direct3D 9 on my system once it’s working. I’m not sure why.
EDITED: Note, I think Microsoft (you guys) could implement OpenGL by doing the D3D interop for OpenXR behind the scenes, without much trouble. But I know MS pushed D3D hard on us. I was forced to use OpenGL because D3D9 isn’t supported.
FYI: The demo scene still isn’t working for me. Maybe switching from SteamVR and back broken something… but I don’t know if I’ve rebooted my system since I noticed this. But I’ve restarted the portal, and still it’s the same… black screen… after a while it goes back to Cliff House without a transition effect.
For the record, yes it seemed to… the glass house thing, etc. We’ve since determined the loader silently fails with 32-bit app for the non-supporting runtimes.
You can use DbgView (like my screenshot showed). It clearly says what the error is (“failed to find active runtime file in registry”), but it is up to you to know whether it means the 32-bit or 64-bit entry based on what your application needs.
There is no Pimax OpenXR support btw, this is an Open Source project I maintain. Pimax only does via SteamVR otherwise. My Pimax runtime builds on 32-bit but it’s mildly untested. Your app is starting up with up but crashes shortly after. I’ll see if I have time to debug it.
Come on. D3D9 is 20 years old. Next up we will ask support for MS-DOS too?
Set OpenXR to use the WMR runtime and send me a trace please.
Yes, that occurred to me too late last night, I hadn’t checked OutputDebugStringA type output or console either. I’m very absent minded.
Come on. D3D9 is 20 years old. Next up we will ask support for MS-DOS too?
Supporting legacy software is complicated. Not all software can just be retooled. Rectus and I think that all VR products should be working on the 32-bit path with OpenXR. Do you know how this can be lobbied for? Ideally it’s just a matter of setting up a 32-bit build target. It seems like Valve needs to get in line with the others or it’s just a hole in the ship of OpenXR. The main case for 32-bit I think is mod like projects. That’s my situation. A mod can’t easily bolt D3D11 onto code written for D3D6 or D3D7 because it’s too different. Microsoft has always been good about supporting legacy software. But I wonder if 32-bit programs will ever stop working. I hope not. Valve is dragging its feet over Microsoft’s reputation.
Edited: RE “20 years old” I think this is an annoying habit… I’d say count the age from the end of its lifetime to be realistic. In which case, yes, D3D9 is pretty old, but it’s also very good. But OpenGL is still fresh it seems.
Set OpenXR to use the WMR runtime and send me a trace please.
(lacks 32-bit support)
(I don’t have a Vive Cosmos)