[I was thinking of the VHS vs. Betamax videotape format “war” before I got to the quote at the end of this Ars Technica story about a new open standard for VR and AR developers to use to ensure compatibility across the rapidly expanding hardware market for these presence-evoking technologies. See the original story for two more images, and for a short primer on format wars see a story on the BT website. –Matthew]
[Image: OpenXR is like a girl reaching for a moon, or something…]
How OpenXR could glue virtual reality’s fragmenting market together
This week’s provisional release could help unify cross-platform VR development.
Kyle Orland
March 19, 2019
Consumer-grade virtual reality (and, to a lesser extent, augmented reality) is only a few years old, but it’s already an extremely fragmented market. Wikipedia lists almost 30 distinct VR headsets released by dozens of hardware makers since 2015. Creating a game that works seamlessly with all of these headsets (and their various runtime environments) can be a headache even for the biggest studios.
OpenXR is out to change all that. With Monday’s release of the OpenXR provisional specification, Khronos’ open source working group wants to create a world where developers can code their VR/AR experience for a single API, with the confidence that the resulting application will work on any OpenXR-compliant headset.
“By accessing a common set of objects and functions corresponding to application life cycle, rendering, tracking, frame timing, and input, which are frustratingly different across existing vendor-specific APIs, software developers can run their applications across multiple XR systems with minimal porting effort—significantly reducing industry fragmentation,” Khronos said in a statement announcing the provisional release.
Unity through abstraction
Releasing such an open standard has been the result of nearly two years of work from dozens of member companies, including pretty much every big name in the VR/AR space. And getting all those stakeholders to agree on what, exactly, should go into the industry’s first open development standard wasn’t easy.
“You all get together for the first time, [creating a standard] seems like an insoluble problem,” Khronos President and Nvidia VP Neil Trevett told Ars. “It took a while, but the way the working group ended up solving that is having an extensible forward-looking architecture that has abstraction layers.”
Rather than creating one pre-defined best way for everyone to do things in VR, the OpenXR group created an API that takes the focus away from specifics. “Input is a perfect example,” Trevett said. “In an OpenXR application, the application never refers to a physical device. All the actions that it needs in the app are abstracted actions like ‘grab,’ ‘jump,’ ‘point,’ whatever it is you want it to do.”
These abstracted actions can then be bound to the specific and varied inputs used by each of the various OpenXR headsets at a hardware level. “You can go from a Hololens 2 with hand gestures to a Vive with a distinct button,” Trevett said. “It future-proofs you, too. If you have foveal tracking, you can just bind that to whatever actions you want in the UI as well.” And OpenXR developers can still use whatever 3D graphics library they want, with OpenXR providing a framework to make the images look correct on any headset.
An upward spiral
As of today, only two sets of VR headsets have provisional OpenXR support: Collabora’s open-source “Monado” headset and Microsoft’s “Mixed Reality” line of products. Other member companies like Oculus and Epic have announced intentions to add OpenXR support to their products later this year. By then, Khronos should be ready with a version 1.0 release that will differ only slightly from today’s provisional version.
From that point, with hardware and engine makers on board, all that’s left is for VR and AR software makers to embrace the new open standard. On that score, Trevett seems pretty confident that developers will see the benefit in coding their upcoming projects with the new libraries.
“It’s kind of an upwards spiral,” he said. “The first step is to get the hardware vendors. Then, if all of the key platforms support OpenXR APIs, why wouldn’t developers use it? No one is losing; it’s hard to pinpoint a loser.”
“OpenXR since the beginning has had a lot of positive energy and urgency,” Trevett continued. “I think people kind of realize everyone can benefit. Obviously it’s not going to be magic, but I think it can make a difference, because everyone wins.”
The other outcome, of course, is that some VR company or other tries to stick with its own proprietary API and pushes for that to become the de facto standard for the industry. That’s what happened with 3D graphics and Microsoft’s DirectX, which leveraged Microsoft’s near-monopoly as PC gaming’s sole operating system to cripple wide uptake of the open source OpenGL alternative.
But Trevett notes that there’s no major company currently operating in the VR/AR space that has the kind of power to really take on OpenXR at this point. Even Microsoft, far from trying to extend DirectX into some sort of DirectVR standard, “has been one of the most active” supporters of OpenXR, Trevett said. “You’re definitely seeing the new Microsoft.“
“Every open standard has a nemesis, except OpenXR [so far],” he continued. “Which means [a competitor] is about to appear from somewhere. It’s bound to. It’s a law of the universe, like gravity. Actually it’s a good thing, because anything in isolation without competition, it’s not good.”
But now that OpenXR is a reality, Trevett seemed hopeful that the VR hardware market can avoid the fragmenting, damaging competition between standards that game development has faced in the past. “Of course the most important win is the end-user. Not only do they have much more confidence they’re going to get the apps that they want, without Oculus looking over the fence at Vive or vice versa… It’s a classic betamax vs VHS thing. If you can solve that, it gives more end-user confidence, which hopefully helps everyone.”