Khronos, the developmental organization behind such open standards as OpenGL and Vulkan, wants to change that. The group is working on a new application programming interface (API), called OpenXR, that will act as a middle man between VR hardware of all sorts, and existing VR interfaces. That same API will also standardize the transition between company-specific VR APIs, and the VR applications themselves.
That’s a tough job, but if achieved, it could see virtual reality standardized in a manner that makes it possible to play any VR experience on any headset – and if any organization is up to the task, it’s Khronos.
Bringing everyone together
Since the year 2000, Khronos has worked to bring together AMD, Nvidia, Intel, Sony, and others, to build standards for technology that aid the consumer and their own product lines. It recognizes that while competition drives industries forward, proprietary technologies can cause needless friction that does little but hinder progress.
“If you just have incompatibilities in the market that aren’t adding value, then everyone loses”
“Like Blu Ray vs HD DVD, if you just have incompatibilities in the market that aren’t adding value, then everyone loses,” Neil Trevett, president of Khronos, told Digital Trends. “The industry needs places where competitors can come together and cooperate to get rid of those friction points and needless barriers.”
That’s what Khronos has done in the past with the development of open graphics APIs like OpenGL and, more recently, with the Vulkan standard. It’s what it wants to do again with OpenXR.
“The point of OpenXR is to bring the runtimes together in the Khronos safe space and all agree on a single API that we can […] expose and remove that large friction point for the industry,” Trevett said. “The apps can be written once and run everywhere, so it’s a win-win. Applications can run on more hardware, and the hardware guys can access more content for their consumers.”
To make this possible, it’s secured the involvement of almost all the big players in the virtual reality market. That includes the likes of HTC, Valve, Oculus, Sony, Starbreeze, Razer, Samsung, Google, Tobii, Unity, and Qualcomm. Game developers like Epic Games are also part of the OpenXR working group.
Khronos remains hands-off with the stand-offs
While the list of OpenXR co-developers is expansive, you may have noticed a few absentees. That isn’t much of a surprise to Trevett, though. “In the ridiculous extreme, with something like Microsoft, or Apple, all the content of the world runs on their platform, and nowhere else,” he said.
Although Microsoft recently joined the OpenXR working group it, like Apple, falls into the camp that would likely benefit from less of an open VR ecosystem. Open-source efforts like OpenXR push back against that kind of thinking.
“At the moment it is impossible to write an application that can run everywhere.”
“The pendulum typically swings backwards and forwards between those extremes,” Trevett explained. “Sometimes the vendors can get more of a lock on content because their platform is so strong, but sometimes it swings back the other way. That will never stop. It’s a fundamental structure of the universe. You’re always going to have that tension between locking down on different platforms and inter-operability, and it’s up to each business about where to make their stand on that spectrum.”
“When companies go out into the industry, they should compete for the best tracking, highest frequency tracking, lowest power on mobile. That’s what pushes the industry forward,” Trevett said. “What Khronos is fixing, is don’t compete on a basic API call, because if you compete there, you’re just adding friction, you’re not adding value. At the moment it is impossible to write an application that can run everywhere, and that’s the engineering problem that Khronos is looking to fix.”
Streamlining VR to support everything
One of the biggest challenges facing OpenXR right now, is supporting all the hardware out there. There are different headsets, controllers, sensors, and numerous accessories. How can OpenXR possibly hope to support all of that with a singular API?
“You have to pick the right level of abstraction,” Trevett explained. “The right level of abstraction gives the developer all of the information they need. Six dimensional coordinates, at the right frequency for good interactivity, haptic information; there are lots of details, but it needs to be high enough that you’re not getting into ‘how’ that information is derived. You’re simply concerned with getting the developer that information in an effective, and easy to consume way. If you can pick that right level of abstraction, then people can use whatever technology they wish to deliver that information.”
That’s where the first of the two parts of the OpenXR API comes in. The “device layer,” or device facing interface, translates the input data coming from the hardware itself into something that any of the existing virtual reality APIs can read. That way, any hardware can function with any VR API, simply by supporting OpenXR.
Without OpenXR, things are far more complicated.
“If I’m a small startup company, innovating on something like eye tracking or motion controllers, if I come up with a new sort of awesome hand tracker I have a real barrier to getting that out there into the market,” Trevett explained. “I have to go to each of these headset makers and on a one to one basis integrate my device into their runtime. There are lots of different devices, so it’s hard to cover all the bases.”
If all goes to plan, OpenXR will make that process much simpler. A theoretical startup would simply need to make their product work with OpenXR, and suddenly it’s compatible with all hardware and software supporting OpenXR.
This has the potential to accelerate the development of virtual reality and the acceptance of new companion technologies. There’s a reason that Khronos opted to call this API “OpenXR” and not “OpenVR” – the eagle eyed among you may have spotted the X looks like a V and A combined. Khronos wants its API to help standardize augmented reality as well.
Khronos is crawling before it walks, though, and for the first release it’s very much focusing on virtual reality, while leaving the door open for new technologies to be supported in the future.
“It wouldn’t take much for a developer to rewrite the API calls to make something OpenXR compatible.”
“OpenXR 1.0 is going to be very VR focused, and on technologies that are well established, and we know that we can develop a controlling API that can stand the test of time,” Trevett said. There are still many facets of virtual reality that need to be worked out before the community of developers can agree on a best practice for them. For now, Khronos is keeping its sights firmly set on existing, proven VR hardware and software.
“I think eye tracking will be critical down the line, but we don’t really understand how it will work yet,” Trevett said. “FOV rendering is still very much a research topic. If Khronos were to try and lay down the law for how to do eye tracking, we’d be out of date very quickly. OpenXR is going to be focused [on] both the application and device layer, it will be disciplined and restricted to cover stuff that has been proven and is shipping in the industry today.”
Supporting games old and the new
The application layer is the software-orientated side of OpenXR. It sits between the game engine running the VR application, and the existing virtual reality APIs from the various headset manufacturers. In the same way that the hardware manufacturers of the future will (in theory) only need to make their kit function with OpenXR to have access to a variety of hardware platforms, software developers making the next-generation of VR games should only need to make them compatible with OpenXR to support all major VR platforms.
The difficulty with creating a new standard, though, is that it could leave older ones unsupported. With OpenXR games offering native universal support for hardware, what happens to games made before OpenXR’s release?
“The differences between the APIs were annoying friction, but they weren’t fundamentally different, so it wouldn’t take much for an existing Oculus or Vive developer to rewrite the API calls to make something OpenXR compatible,” Trevett said. He believes the process would be simple, claiming that a “fairly small amount of code” changes are needed to add OpenXR support to older titles.
Taking VR online
Although OpenXR is designed to work well with major game engines like Unreal and Unity, Khronos is also looking to link it up with the web-based virtual reality standard, WebVR. Still in the nascent stages of its development, the online VR platform is designed to enable immersive, 3D experiences from within the browser. While we’re still not quite convinced anyone has figured out the best way to handle a 3D web browsing experience, Khronos wants to make sure that OpenXR has a hand in shaping it.
“If people want to be cross platform, there is going to be no choice. They’re going to want to go to OpenXR.”
“One question we often get, is ‘does WebVR compete with OpenXR?’ They are definitely complementary,” Trevett said. “WebVR brings the rendering and the device handling into the webstack, where OpenXR is a native API. We’re working very closely with the WebVR [team] and at the moment they have the same problem as every other developer. They want to ship it on Oculus, Vive, Daydream, but they’re having to rewrite their low-level code. We can offload a lot of busy work for WebVR and help the team concentrate on adding value in the webstack, which they’re already doing a great job on. WebVR is using both OpenXR and WebGL.”
It will take a lot more than an open standard to take VR web browsing to its full potential, but Khronos is aware of that. Trevett said that OpenXR will “reduce just one of the friction points,” suggesting that future developments like augmented reality, wireless transmission, and many more standards, will be required to make it viable and even preferable over 2D browsing.
“There are dozens of standards bodies working on these things, and it’s going to end up with constellations of hundreds of standards, but this isn’t new. If you count the number of standards on PCs, it’s amazing,” he said.
If you build it, will they come?
Even if Khronos has received a lot of support from developers, and has a solid working group building towards a common goal, there is still no guarantee that anyone adopts it, as Trevett himself highlighted. Indeed, you could argue that Khronos’ standards have not always drawn the support expected. OpenGL was never universally supported by developers – DirectX remains far more popular to this day – and Vulkan, despite having been available for a year and a half, has only a handful of supporting games.
Despite that, Trevett isn’t worried.
“The 3D APIs [like Vulkan] are not something that’s new,” he said. “They’re a replacement for something that’s extremely effective. OpenGL, DX11, they are awesome APIs that people are familiar with. Vulkan, DX12 and Mantle, they’re not bringing anything new to the table, they’re improving on something existing. OpenGL has had 25 years of developer education. Vulkan is 18 months. The low-level APIs are going to have a big impact, but they’re going to take longer than people expect.”
OpenXR could have even more of an impact if it turns out to be as effective as Trevett hopes. Since it’s not looking to replace an existing open-source API, its path to popularity could be far swifter.
“If people want to be cross platform, there is going to be no choice,” Trevett said. “They’re going to want to go to OpenXR.”
Only time will tell if that turns out to be true. We have a little wait until we’ll find out, as version 1.0 of Khronos’ new API isn’t expected until sometime during the first half of 2018.
