We are working on a cross-platform PCVR project built in Unreal 5.x.
My understanding is that even with the OpenXR library in Unreal - our application will be dependent upon the user running Steam (or oculus etc).
There is no such thing as a fully standalone OpenXR runtime.
And there is no OpenXR support at all for OSX.
Is this true?
Our ideal use case -
On a brand new system install (of either PC or Mac) you double click our application runtime and it has everything you need to drop into VR in our app.
There is no need to install anything else - no other eco system registrations / logins / affiliations / email confirmations / captas / configurations / downloads / hubs / Marketplaces, or other such bloat.
Does this exist and/or is anyone working on making VR Ubiquitous / away from the gatekeepers?
An OpenXR runtime is like a graphics driver: it’s how the hardware interfaces with the application. It doesn’t make sense to have a runtime not associated with hardware, just like how it doesn’t exactly make sense to ship the graphics driver with the application.
There are runtimes that run in a simulator mode, so without specialized hardware, but that’s probably not what you want. There could also be hardware/software systems that might ship an app with its own runtime for special purpose hardware. But that’s not really the purpose of OpenXR. OpenXR exists to allow you to write your application so it runs against any OpenXR conformant runtime, instead of writing it for just a single one. It means you’re not locked into any gatekeepers: if you don’t like the requirements of one runtime, pick a different runtime/hardware combination.
OpenXR is not designed to embed the hardware support into the application: that would not really work or be scalable over time, and it would actually be less compatible.
Hi Ryan,
Thank you for the clear explanation! Very helpful.
Indeed I was under the impression OpenXR was working to be that community that might ensure an open runtime approach for independent, scalable hardware support over time.
The hardware landscape is not so robust and it seems all of them smash down into either Oculus or Steam - so in the end - one of those two own your hardware support and VR access (and your usage data / relationship to you etc).
It would be great to be able to create a truly standalone VR project allowing for rapid standalone distribution and “one click” install as well as use of purchased hardware without the need to create accounts, or login, etc with a third party… If people had to jump through the hoops we need to jump through to access VR in order to turn on their TV, play music, run a game (non-steam / epic), etc… that barrier to entry would quietly eliminate a potential user base.
Imagine if Monitor makers required you to login to their platform (with a verified email account) before you can use it - and you can only run apps on their monitor that they agree to.
Just seems odd.
I am bought in the HTC ecosystem… You mention it might be possible to pick different runtime/hardware combinations.
Are there standalone runtime options outside of Meta or Steam?
Something lightweight - not pushing games at me - not requiring registration - etc?
Not a 100% sure, but I think HTC in particular provide a standalone version of the SteamVR runtime for their enterprise customers.
In general the VR hardware is only set up to work with the vendors own runtime (or SteamVR driver) though. There is an open-source runtime called Monado, but it is not ready for general distribution with PCVR headsets and no commercial vendor provides official support for it.
Seems like (as a community) we have a some way to go before we can escape the information vortexes and the people reselling machine of the big players.
OpenXR is one component but I guess for true open compatibility it will either need to be hacked in or ISO gamified.
Either way - that is many years away.
I really hope headsets become more like monitors (buy, plug, and play with anonymity ensured) than mobile phones (registered, logged, tracked so usage data can be sold - or it’s bricked).
Will we need to get burner headsets in the future?
The idea is more that as an application developer it shouldn’t be your concern what runtime or headset end users have.
OpenXR shares many similarities with Vulkan, so the graphics driver analogy from above is very apt:
Someone looking to ship a Vulkan application will rarely provide vulkan drivers for the GPUs the users might have in their installer - the understanding is that the user’s system will already be configured to have the graphics driver for their GPU installed.
In the same way someone shipping an OpenXR application can expect that the user will already have an OpenXR runtime that supports their XR hardware installed and configured. If the user has to log in to an account in order to use the runtime or if the runtime is surveilling the user’s behavior is a matter between the user and their XR hardware vendor and if they don’t like it, they can switch to another runtime and possibly another headset that is more to their liking.
At the end of the day Khronos is still a voluntary group of companies and only goes as far towards openness as the members can agree on.
