An Overview of OpenXR and How it Promises to Simplify the VR Landscape
I’ve never bought a VR headset, let alone try VR, but when Oculus stopped being the only VR company on the block in 2016, one question entered my mind: how is VR gonna work if there’s a handful of different VR ecosystems that don’t work well with each other? Well, I wasn’t the only one it seems, because Khronos Group, the leader of making things compatible, has a solution called OpenXR.
If you’re not familiar with how Khronos Group manages to do something that seems so difficult, I recommend reading my previous article about glTF and ANARI to get an idea of their modus operandi. Basically, Khronos Group implements a software layer (supported by Khronos Group’s other technologies like Vulkan) that efficiently communicates between the hardware and the VR application. I’m not going to go into too much depth on the technical aspect because it’s not as interesting as the ecosystem OpenXR is creating and what it can do for VR users.
Pretty much every VR headset company and some adjacent companies (like processor designers, panel manufacturers, phone manufacturers, companies with feedback and input technologies, etc) is joining OpenXR. There’s alot of support because proprietary solutions threaten the potential of VR, which could suffer something like the direct opposite of the video game crash back in the late 20th century: not having enough games. VR can only really be great if every VR headset has access to a large and diverse library of games. Oculus and Microsoft are the VR companies spearheading OpenXR with the first compatible headsets.
Speaking of hardware compatibility, that’s a very strong point with OpenXR. All but perhaps the oldest VR headsets should get OpenXR support, all the headset should need is to run a modern runtime, and given that VR is still pretty new, we might only expect the very first ones from Oculus in 2014 to not get OpenXR; for example, all of Microsoft’s headsets which support Windows Mixed Reality will get OpenXR. Including new VR headsets into the open standard shouldn’t be difficult either because OpenXR is designed to be flexible, not merely be compatible with many but specific ecosystems.
On the software side of things, OpenXR will of course be on some different platforms, mainly Android and Windows but also Linux. Now, there’s no reason why OpenXR couldn’t get support on the game consoles or Apple’s platform, but those are very large and closed ecosystems that might not necessarily need (or, rather, they might not think they need) OpenXR. Sony and Microsoft do publicly support OpenXR so maybe we will see one or both of them do something with it.
Developers also aren’t forced to use Vulkan, Khronos Group’s highly compatible and flexible API; OpenXR is compatible with many other APIs like DirectX and OpenGL. But, I suspect OpenXR is best with Vulkan because Khronos Group says “OpenXR is strongly influenced by Vulkan with a shared spec toolchain and support for API layers.”
Much like how glTF promises to proliferate 3D models integrated into webpages, OpenXR also wants to do something similar with VR. Integration with Vulkan and WebGL (again one of Khronos Group’s technologies) could allow for simple injection of VR media into web browsers. Even though VR is still niche, website content made specifically for it exists today and in the future I imagine that amount of content will grow in part thanks to OpenXR.
I’ve made it no secret that I’m simply fascinated with the way Khronos Group just takes technologies, joins them together, and makes one compatible ecosystem. OpenXR, even though I don’t own a VR headset, is very interesting to me. Maybe I’ll finally get a VR headset since I won’t have to worry about what headset gets what games and features.
Oh, and if you’re wondering why it’s called OpenXR instead of OpenVR, that’s because the top half of the X (a V) stands for VR, while the bottom half (an A) stands for AR (or augmented reality). Nice touch.
Liked it? Take a second to support Matthew Connatser on Patreon!