The Khronos Group, alongside the myriad of other tech companies, have been working on a royalty-free, open standard for the virtual and augmented reality (VR/AR) industry called OpenXR for a number of years now. This week SteamVR has rolled out a new update to fully support the OpenXR 1.0 API standard.
While PC VR users won’t notice any change, developers most certainly will. The whole purpose of OpenXR is to remove fragmentation across the XR industry. So rather than a developer having to create a project for one specific platform and then port to more further down the line – not always an easy process – with OpenXR its a one and done approach.
Thus it’s great for creators and end-users. Studios don’t have to decide on one VR headset to support initially, they save time and money bringing their project to multiple devices, and in turn earn more from a greater customer reach. Of course, on the other end, PC VR owners don’t need to worry if the headset they own will be supported, plus true cross-platform XR experiences can be created.
The main portion of SteamVR’s v1.16 update was for OpenXR but it includes some smaller extras. Most notable is the option to: “Allow motion smoothing to apply up to six frames of extrapolation (was three). Note: This also only applies to SteamVR’s compositor.” This will allow users to run applications at a lower framerate.
The news continues to help the XR industry create a more open ecosystem, removing barriers that could hinder adoption. As further updates for SteamVR are announced, VRFocus will keep you updated.
The Khronos Group and its OpenXR platform have been rapidly pushing ahead over the past year since the v1.0 specification was established. Today, the group has announced the launch of the OpenXR 1.0 Adopters Program, Microsoft and Oculus officially supporting implementation as well as cross-vendor hand and eye tracking extensions.
With Microsoft’s and Oculus’ support developers are now able to submit their OpenXR apps to the Oculus Store, whilst Minecraft’s new rendering engine RenderDragon is using OpenXR as the basis for its desktop VR support. Plus Microsoft has released an OpenXR-conformant runtime for HoloLens 2.
A royalty-free, open standard designed to make it easier for virtual and augmented reality (VR/AR) developers to make content for a wide range of devices, and OpenXR’s open-source conformance tests help in that process. Published under the Apache 2.0 license on GitHub, the test suite enables any developer to submit conformance test results to ensure their product meets the standard, regardless of being a Khronos member, and become an OpenXR Adopter.
In addition to Microsoft’s and Oculus’ implementation the Khronos Group reveals that open source projects like 3D creation suite, Blender 2.83, Google’s Chromium81 and Varjo have incorporated OpenXR. Additionally, Valve previously released developer preview implementation of OpenXR on SteamVR.
When it comes to the cross-vendor hand and eye tracking extensions this will improve support for both technologies. Ultraleap, for example, has already released preview OpenXR integration for its hand-tracking tech.
“The Working Group has put tremendous effort into OpenXR conformance testing to create a truly reliable cross-platform API. We encourage OpenXR implementers to use the tests in their own development and consider contributing additional tests to help further reduce cross-vendor variability,” said Brent Insko, working group chair, OpenXR Working Group and lead XR architect at Intel in a statement. “With the release of the conformance tests and official launch of the Adopters Program, widening availability of OpenXR across diverse devices, and expanding use in large open-source projects, OpenXR is now ready for the next wave of adoption and deployment.”
“The time to embrace OpenXR is now,” said Don Box, technical fellow at Microsoft. “On the content side, the adoption of OpenXR in Minecraft’s desktop VR product further reinforces Microsoft’s commitment to the success of OpenXR.” This could then eventually see Minecraft VR on more devices.
As OpenXR continues to improve and gain more support, VRFocus will keep you updated on its latest advancements.
One of the problems companies working within the XR space have been trying to solve is the issue of platform fragmentation, where developers have to build for each one; taking up time and precious resources. Which is why The Khronos Group in conjunction with Valve, Facebook, HTC, NVIDIA and others created OpenXR. This week Valve announced the launch of an OpenXR Developer Preview for SteamVR.
OpenXR is one of those initiatives which sits in the background unnoticed but has massive implications for the industry. The open-standard allows developers to build their project once and it’ll work across all the various hardware and software platforms available.
In a statement, the company notes: “Valve is releasing initial support for the current 1.0.9 OpenXR release now, to enable developers to begin work implementing OpenXR applications that work with SteamVR, but it is not yet enabled for broad general use.”
It’s still going to be a while yet before OpenXR becomes widely available and implemented as the defacto standard but these are the necessary steps to get there. This announcement follows on from Oculus’ in March when the company mentioned that the Prototype OpenXR API would be madfe available to developers using Oculus PC and Mobile software development kits (SDK).
The news is also important for devs using game engines like Unity. A few months ago when Unity made its High Definition Render Pipeline (HDRP) VR compatible it noted that OpenVR compatibility would be phased out because Valve was working on its own OpenVR Unity XR Plugin for 2019.3.
SteamVR is already fairly hardware agnostic, compatible with Oculus Rift, HTC Vive/Vive Cosmos, Valve Index and Windows Mixed Reality headsets. But there are plenty more devices out there and with more on the way, especially as an influx of Qualcomm XR2 Powered 5G devices are expected to begin arriving by the end of 2020.
As further OpenXR advancements are made, VRFocus will keep you updated.
Much like the Game Developers Conference (GDC) which it’s replacing, Facebook’s Game Developers Showcase is a chance for the company to announce both consumer and industry-focused news, with the first day mainly concentrating on Oculus Quest. Facebook also unveiled plans to roll out OpenXR in prototype form for Oculus Rift and Quest developers later this month.
Having played a central role in the development of OpenXR, helmed by The Khronos Group, Facebook and Oculus first revealed plans to give developers access back in September 2019. A royalty-free open standard designed to aid the development of high-performance virtual reality (VR) applications across multiple platforms, an update offering access to OpenXR will arrive in the next few weeks.
As VRFocushas previously reported, the OpenXR 1.0 specification launched last year to solve the fragmentation of the XR industry, reducing overheads for VR/AR developers working across various platforms because they can reuse the same code. This should, in theory, provide consumers with more choice in the long run.
The Oculus Developer Blog notes: “The Oculus PC and Mobile SDKs will include the resources necessary to use the Prototype OpenXR API for native C/C++ development of Oculus Rift Platform apps and Android apps for Oculus Quest respectively. OpenXR offers an alternative development path that allows developers to create portable code that can be used on devices from multiple vendors.”
Also for developers, Oculus will be releasing an Add-ons option in the Developer Dashboard. This will combine Downloadable Content (DLCs) and In-App Purchases ( IAPs) under one management function, making the creation of add-on content easier. So hopefully you’ll see more content arrive for your favourite videogames.
Initiatives like OpenVR have allowed platforms like Steam to be hardware agnostic, allowing almost any virtual reality (VR) headset which supports the protocol to be used. The industry is striving for ever greater openness and interconnectivity, hence why The Khronos Group and its affiliates began working on OpenXR. Soon Oculus will begin to adopt OpenXR with support reportedly coming in the latest Oculus Public Test Channel release.
Appearing on the Oculus Forums, the preview release is available for testing now, just don’t expect to be running an HTC Vive or Valve Index on Oculus Home anytime soon. The whole purpose of OpenXR is to provide an open standard for cross-platform VR/AR apps, allowing them to be used on any compatible headset, without developers having to make lengthy and costly changes.
The current OpenXR 1.0 specification which launched in July helps to solve the fragmentation of the industry with companies like Epic Games, HTC, Google, HP, Unity, Valve, Sony, Samsung, Oculus and Microsoft all supporting the endeavour. At present only Microsoft’s Windows Mixed Reality headsets support OpenXR. The addition for Oculus Runtime has been expected, a Khronos press release previously mentioned: “Oculus OpenXR implementation for Rift, as well as Oculus Quest support coming upon ratification of OpenXR 1.0.”
However, there are big plans for OpenXR which could make platforms like Oculus Home hardware-agnostic just like Viveport. The Khronos Group does mention: “Optional device plugin interface will be supported post V1.0,” which could make that possibility a reality, albeit very unlikely as Facebook likes to keep a tight rein on its software.
With this appearing, only a couple of weeks before Oculus Connect 6 (OC6) further details regarding Oculus OpenXR integration plans may come during the keynote, most likely from CTO John Carmack or possibly Chief Science Officer Michael Abrash. VRFocus will be in attendance to find out further details.
In the meantime, you’ll have to use software such as Revive to play Oculus exclusives on HTC Vive via Steam with plenty of compatible titles currently available. As the implementation of OpenXR continues to expand VRFocus will bring you all the latest updates and announcements.
To help grow and support the growing virtual reality (VR), augmented reality (AR) and mixed reality (MR) industries, The Khronos Group and its affiliates have been working on the OpenXR standard since 2016. Today, the consortium has announced the launch of the 1.0 OpenXR specification.
The public release of the OpenXR specification creates a unifying, royalty-free, open standard for cross-platform access between XR platforms and devices. This makes it far easier for software developers or hardware manufacturers who support the ecosystem to build products that work across devices, allowing for less fragmentation and therefore less confusion for consumers looking to invest in XR technology.
“The working group is excited to launch the 1.0 version of the OpenXR specification, and the feedback from the community on the provisional specification released in March has been invaluable to getting us to this significant milestone,” said Brent Insko, OpenXR working group chair and lead XR architect at Intel in a statement. “Our work continues as we now finalize a comprehensive test suite, integrate key game engine support, and plan the next set of features to evolve a truly vibrant, cross-platform standard for XR platforms and devices. Now is the time for software developers to start putting OpenXR to work.”
Khronos launched the provisional OpenXR 0.90 spec during the Game Developer Conference (GDC) 2019, gathering feedback from the XR community to improve the OpenXR input subsystem, game engine editor support, and loader. Version 1.0 will continue to evolve the standard while maintaining full backwards compatibility, with Khronos member companies continuing ecosystem support via additional implementations. These include ‘Monado’ OpenXR from Collabora, the OpenXR runtime for Windows Mixed Reality headsets from Microsoft, an Oculus Rift implementation, Unreal Engine support from Epic Games and Oculus Quest support.
“OpenXR is an important milestone for VR. This API will allow games and other applications to work easily across a variety of hardware platforms without proprietary SDKs,” said Joe Ludwig, programmer at Valve. “Valve is happy to have worked closely with other VR industry leaders to create this open standard, and looks forward to supporting it in SteamVR.”
“We’re thrilled to support the OpenXR 1.0 release, along with all of the Khronos Group members who have worked tirelessly to create the standard. Unreal Engine led the way with support for the OpenXR 0.9 provisional specification, and we’re excited to move the 1.0 revision forward in collaboration with our hardware partners releasing at the same time. Epic believes that open standards are essential to driving technology and bridging the gaps between digital ecosystems,” adds Jules Blok, Epic Games.
OpenXR members Epic Games, Microsoft and Varjo will be holding demonstrations using the OpenXR API at SIGGRAPH 2019 this week. The new specification can be found on the Khronos website and via GitHub. For further updates keep reading VRFocus.
.Ever since the Khronos Group announced back in 2016 plans to have an open standard for virtual reality (VR) and augmented reality (AR) devices called OpenXR, the initiative has garnered more and more support. With the first public demos showcased at SIGGRAPH last year, for the start of the Game Developer Conference (GDC) 2019 the group has publicly launched the OpenXR 0.90 provisional specification.
The whole purpose of OpenXR is to solve the issue of fragmentation within the VR/AR ecosystems – commonly referred to as XR – allowing developers to easily port content to a range of devices without having to spend serious amounts of time dealing with each their particular software issues.
As this is version 0.90 of OpenXR it’s not the final version, merely a provisional release so that Khronos Group can correlate feedback from users. OpenXR 0.90 specifies a cross-platform Application Programming Interface (API) so that platform vendor’s expose the functionality of their runtime systems, which can frustratingly different across existing vendor-specific APIs.
“OpenXR seeks to simplify AR/VR software development, enabling applications to reach a wider array of hardware platforms without having to port or re-write their code and subsequently allowing platform vendors supporting OpenXR access to more applications,” said Brent Insko, lead VR architect at Intel and OpenXR working group chair. “The OpenXR provisional specification—together with the runtimes publicly available at launch and coming in the next few weeks—will enable hands-on, cross-platform testing by application and engine developers. The working group welcomes developer feedback to ensure an OpenXR 1.0 specification that truly meets the needs of the XR industry.”
Advocates of the OpenXR standard range across the industry, from Google and Epic Games to Magic Leap and Sony Interactive Entertainment.
“Epic believes that open standards like OpenXR are essential foundations for a vibrant, multi-platform VR and AR industry in the coming years. We’ve supported OpenXR since its inception, including powering the first public demo of OpenXR at SIGGRAPH last year, and hope to see the ecosystem continue to grow with the first public release of the spec at GDC,” said Tim Sweeney, founder and CEO of Epic Games. “Epic plans to continue supporting OpenXR in Unreal Engine 4.”
“Facebook and Oculus continue to believe in the value the OpenXR standard delivers to users and developers. We plan to provide runtime support for apps built on OpenXR 1.0 on the Rift and Quest platforms later this year,” Nate Mitchell, Oculus Co-founder and head of VR product, Facebook adds.
The new specification can be found on the Khronos website. For further updates on OpenXR, keep reading VRFocus.
As a developer moving from the web and app world into 3D and XR, I’ve had to constantly re-evaluate my platform and tool choices as the industry evolves at tweetstorm velocity. Today’s XR development pipeline is clogged by a glut of proprietary hardware and software APIs and SDKs by competing firms like Oculus, HTC Vive, Microsoft, Google, Apple, Sony and SteamVR — to say nothing of emerging third-party peripherals like Logitech’s VR-tracked keyboard, the new AR-enabling Zed Mini dual-eye camera for the Rift or Vive, or any other industry-disrupting Kickstarters that might’ve sprung up since I started typing this paragraph.
Left to right: a bunch of cool stuff I want.
Each platform’s fine — even technologically stunning, one might argue — with respective strengths, weaknesses and use cases. But the distinctions force XR developers to ask hard questions: Where is the market going? How do I invest my skill-building time? What devices should my app support? What platform can I get a job working on? Developers must be business analysts as much as creative technologists to stay relevant. It’s easy to suffer choice paralysis with such a wide array of options, and easier still to bet on the wrong technology and lose.
Personally, I also face certain technical, logistic and financial realities as an independent XR developer in the Midwest (US), where the industry hasn’t proliferated as it has in major coastal cities. Thankfully, game engines like Unity and Unreal are rapidly democratizing this space. Both engines seek to bridge the gaps between the various XR SDKs, employing thousands of engineers to ensure their software plays nicely with just about any significant third-party API. For example, as I wrote about in August, the Oculus SDK integrates beautifully with Unity and comes equipped with many of the scripts and prefabs needed to quickly prototype, develop and deploy a custom Rift app.
I miss bossing around my hand-modeled #MadeWithBlocks BB-8. Check out my deep dive on this project, The Future of VR Creation Tools.
That’s fantastic, but it’s still non-standard. To port the same Unity app to the HTC Vive or a Windows HMD is non-trivial — not impossible or even terribly difficult, but non-trivial. Maintaining your app for multiple SDKs over the long haul is similarly non-trivial. Non-trivial costs money and time and we’re all short on both.
Instead imagine if XR practitioners had to worry less about betting on the right platform or device and could instead focus on creating unique and compelling experiences, content and UX. The first step down that path was VRTK — but sadly, one of the best tools to combat the VR SDK surplus will soon be hobbled by the loss of its founder.
VRTK: The Open Source Approach
This free, open source Unity toolkit aims to knit together a single workflow for a variety of VR APIs. It comes with the same stock prefabs and scripted mechanics you might find included in any single proprietary SDK, but makes each piece of functionality identical whether deployed to Oculus, SteamVR (read: Vive and, with v3.3.0, Windows HMDs) or Daydream — covering all major VR HMD manufacturers today.
It’s a boon to anyone wanting to dip their toes in the waters of VR development. Think of it: Want to implement teleportation locomotion over a Unity NavMesh? Just drop the component onto your player prefab. Want to test out grab mechanics, or a quick bezier pointer? VRTK’s demo scenes have you covered, and they’ll work easily on a variety of devices. Since it’s open source, you’re also free to dive in and customize the code. Struggling to get a feature working in your own project? Check out this implementation on a varieties of SDKs — not a bad way to grok new XR coding concepts.
Sadly, VRTK’s creator is sunsetting the woefully underfunded project. The UK-based developer TheStoneFox — who until recently was actively seeking contributors, partnerships and support — announced recently that he would will be stepping back from the project post-version 3.3.0. Though VRTK boasts an active Slack community, a growing list of “made with” titles and a recent Kickstarter, TheStoneFox was unable to attract the support necessary to sustain it for the long term.
Now, as the opportunity to contribute to and utilize a premier open-source VR development pipeline expediter will fade going forward, what if anything will replace it?
OpenXR: One API to Rule Them All
The VRTK approach —using Unity scripting to knit together similar mechanics across a spectrum of VR SDKs — is necessary in the current fragmented development landscape, but there are downsides. Some community still has to monitor the various proprietary SDK updates and your end-user VRTK app still has to be mindful of VRTK’s changes over time. In this way, VRTK treated the symptoms of the VR SDK overload, but was not equipped to address the root cause. Enter OpenXR, The Khronos Group’s upcoming industry standard:
The standard, announced December 2016, is being written now and is quickly gaining traction among industry players (with the notable exception of Magic Leap). Instead of forcing developers to grapple with variable propriety SDKs and all the accompanying business consequences, companies will instead tailor their hardware and software to comply with OpenXR’s spec. Khronos, the non-profit responsible for shepherding the Vulkan, OpenGL, OpenGL ES and WebGL standards, is leading the charge. Cue the infographics!
On the left, the problem — on the right, the solution:
“Each VR device can only run the apps that have been ported to its SDK. The result is high development costs and confused customers — limiting market growth,” reads some fairly accurate marketing copy on their website. “The cross-platform VR standard eliminates industry fragmentation by enabling applications to be written once to run on any VR system, and to access VR devices integrated into those VR systems to be used by applications.”
A working group of industry heavyweights have agreed the standards be extensible to allow for future innovation and should support a range of experiences — anything from a 3-DoF controller all the way to a high-end, room-scale devices.
The only thing missing is a realistic timetable before this standard has an impact on the development community and its day-to-day workflow. Until the market-movers get their act together, we’ll be left scrambling (and patching up VRTK projects, in many cases).
OpenXR supporters: everyone except Magic Leap.
The Cinema of Attractions: Slow Your Reel
But should we so quickly welcome industry standardization while the technology is still so new and full of possibilities? That’s the question asked in a recent Voices of VR podcast by Kent Bye and Rebecca Rouse. The two discussed the early days of cinema — when exploration and experimentation were the status quo — and Rouse drew striking parallels between that era and the current period in XR production and development.
Pure spectacle then and now. Left: a Cinema of Attractions-era still. Right: Chocolate VR.
“[Scholars of early film] came up with this term ‘cinema of attractions’ because they saw an incredible wealth of diversity and kind of range of exuberant experimentation in those early pieces, so they were very hard to sort of clump them together — there was such diversity — but this ‘attraction’ idea was a large enough umbrella, because all of those early pieces are in some way showing off the technology’s capabilities and generate this experience of wonder or amazement for the viewer. And the context in which they were shown is that of attractions, so they were shown at world’s fairs and as a part of vaudeville shows with other kinds of performances and displays.”
— Rebecca Rouse, assistant professor of communication & media at Rensselaer Polytechnic Institute
Sounds eerily familiar, huh? The whole podcast is well worth a listen, but tldr: while there are obvious consumer and market advantages to XR standards, Rouse argues that perhaps we shouldn’t jump the gun here— not during this era of frenetic, often avant garde XRexperimentation across art, science, cinema and gaming. Looking around the industry, it’s hard to disagree.
EditorXR
One man-eating-the-camera-brilliant new application of XR technology is Unity Labs’ EditorXR. Created by Unity’s far-future R&D team (whose roles often find them working on projects and products five-to-ten years away from consumer adoption), EditorXR offers you an interface to create custom XR Unity scenes entirely within virtual reality.
Oh! And there’s flying, among other superpowers — soar through your scene like Superman or scale the whole thing down to a pinhole. They’ve literally ported the Unity inspector, hierarchy and project windows (again among others) to an increasingly user-friendly VR UI pane on your wrist. With the latest update, you’re able to:
hook into Google’s Poly asset database web API in real-time inside VR
create multiplayer EditorXR sessions for editing Unity scenes with friends and collaborators
run EditorXR with Unity’s primary version 2017.x editor
It’s still new and I’ve encountered bugs, but it’s a foregone conclusion that this tech will become a standard feature of Unity’s scene creation process as XR technology matures and proliferates. Even their alpha and beta efforts evoke the same sense of wonder and possibility that early Cinema of Attractions-era moviegoers must have felt.
Another experimental Unity project, ML-Agents, explores one of the most promising avenues for the future of XR development, design and UX: machine learning. Using so-called “reinforcement learning” techniques which expressly don’t feed the AI model any sample data or rules for analysis, ML-Agents instead applies simple rewards and punishments (in the form of tiny float values) based on the outcomes to their [usually very narrowly defined set of] behaviors.
Stretched out over hundreds of thousands if not millions of trial-and-error training sessions, the computer experiments with its abilities and forms a model for how to best achieve the desired goal. In this way, your Agents become their own teacher s— you just write the rubric.
The original GitHub commit contained some basic demo scenes and the development community quickly took up the torch from there. Unity’s Alessia Nigretti followed up the original blog with one describing how to integrate ML-Agents into a 2D game. On Twitter, @PunchesBears has been demonstrating similar concepts — and showing that often enough, Agents respond to developers’ carefully calculated reward system in ways they don’t anticipate. Similar to actual gamers, no?
In one of my favorite applications of ML-Agents, the developer Blake Schreurs actually brings a 6-DoF robo-arm Agent trained to seek a moving point in space into virtual reality — with slightly terrifying results once he assigns that moving target to his face.
Imagine someone applying this training model to actual robotics and fat-fingering the wrong key. Or don’t, whatever.
He’s down for the count! I was immediately reminded of the audiences pouring out of theaters in 1895, afraid they’d be run down by the Lumière brothers’ Arrival of Train at La Ciotat. We’re still in the salad days of both machine learning and XR development compared to where we hope to be 10 or even 50 years from now. In that time, some combination of traditional or procedural AI with these new machine learning approaches will doubtless lead to great developments in gaming and XR at large — or even in the very design process and daily workflow of computing itself.
Rift OS Core 2.0
With Rift’s new Core 2.0 OS, your entire Windows PC is accessible from your right-hand menu button. Being able to view and use your desktop apps, as well as pin windows inside other VR apps, introduces new possibilities for XR workflows (and even for traditional computing workflows) in VR.
While working on my next project, entirely within VR, I can watch Danny Bittman’s great Unity rendering and lighting tutorial on YouTube in a pinned browser while messing with those same settings on my wrist in UnityXR. I can watch @_naam craft original assets in Google Blocks at the same time I do, or I could gather assets from the Poly database and deploy them to my Unity scene in real-time VR, pulling up Visual Studio to code some game logic as I please.
That sounds pretty goddamn metaversal to me — and before long, we likely won’t even need code.
The XR Developer of the Future Is Not a Developer
If XR technology is to go mainstream, the development process must be as efficient and accessible as possible — and likely even open to non-developers through content creation and machine learning applications. Spanning sciences and disciplines, there’s so much more to talk about and speculate over that this piece hasn’t even touched on (next time I’ll examine WebVR and A-Frame as viable XR development pathways). More and more pieces of this accessible, standardized XR development pipeline will fall into place as the immersive computing revolution rolls on, though I’m thankful the XR industry isn’t ready to ditch its Cinema of Attractions ethos quite yet.
The standard, announced December 2016, is being written now and is quickly gaining traction among industry players (with the notable exception of 
