OpenXR, the open standard that creates a standardized way for XR hardware and applications to interface, has seen its first major update. OpenXR 1.1 evolves the standard by incorporating new functionality that was important to the industry but previously not standardized.

Facilitated by the standards body Khronos Group, OpenXR is a royalty-free standard that aims to standardize the development of VR and AR applications, making for a more interoperable ecosystem. The standard has been in development since April 2017 and over time has become supported by virtually every major hardware, platform, and engine company in the VR industry, including key AR players—but notably, not Apple.

Image courtesy Khronos Group

Following the OpenXR 1.0 release in 2019, this week’s release of OpenXR 1.1 is the first major update to the standard in more than four and a half years.

The update shows the standard evolving as industry needs emerge, an outcome that’s part of the standard’s design.

Built into the framework of OpenXR is the notion of ‘extensions’, which are vendor-specific capabilities which can customize OpenXR’s functionality without needing to first go through the process of being baked into the official standard.

In some cases, such extensions include functionality that eventually becomes universal enough to warrant inclusion in the standard overall. Thus, extensions can be ‘promoted’ and baked into the OpenXR standard for all to use and support.

OpenXR 1.1 sees the inclusion of five capabilities which originally started as extensions:

Local Floor: provides a new Reference Space with a gravity-aligned world-locked origin for standing-scale content that can be recentered to the current user position at the press of a button without a calibration procedure. It also has an estimated floor height built-in. More details about Local Floor functionality and its value to developers are available in this blog post.

Stereo with Foveated Rendering: provides a Primary View Configuration to realize eye-tracked foveated rendering or fixed foveated rendering for XR headsets across multiple graphics rendering APIs. Its use is especially beneficial for efficiently rendering high-pixel-count displays, which put a heavy load on the GPU. The original vendor extension has been adopted natively in Unity, Unreal, and recently by NVIDIA Omniverse.

Grip Surface: provides a Standard Pose Identifier that reliably anchors visual content relative to the user’s physical hand, whether the hand position is tracked directly or inferred from a physical controller’s position and orientation.

XrUuid: provides a Common Data Type to hold a Universally Unique Identifier that follows the IETF RFC 4122.

xrLocateSpaces: provides a Locating Spaces function to improve performance and simplify application code by enabling an application to locate an array of spaces in a single function call populating an “array of structures” (AoS), instead of being limited to locating a single space per function call.

Building these extensions directly into OpenXR represents the industry’s consensus on the demand for these features and how they should be implemented across the ecosystem.

OpenXR 1.1 also includes various improvements to existing features and clarifies some capabilities to make the standard clearer for those that want to build implementations that conform to the standard.

SEE ALSO
Meta is Discontinuing Quest 1 Support for New Apps Starting Next Month

Going forward, the OpenXR working group (consisting of representatives from member companies which steer the standard) says it plans to make more regular updates to OpenXR going forward, ensuring that new capabilities continue to be added as industry needs evolve.

“OpenXR 1.1 marks a significant milestone in the development of this open standard that has become widely adopted throughout the XR industry. OpenXR 1.0 provided baseline capabilities and the foundation for experimentation with new functionality through extensions,” says Alfredo Muniz, Chair of the OpenXR Working Group. “Now the Working Group is pivoting to manage regular core specification updates that balance the need for flexibility to ship new functionality with consolidation of proven technology to reduce fragmentation and enable true cross-platform application portability.”

Newsletter graphic

This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. More information.


Ben is the world's most senior professional analyst solely dedicated to the XR industry, having founded Road to VR in 2011—a year before the Oculus Kickstarter sparked a resurgence that led to the modern XR landscape. He has authored more than 3,000 articles chronicling the evolution of the XR industry over more than a decade. With that unique perspective, Ben has been consistently recognized as one of the most influential voices in XR, giving keynotes and joining panel and podcast discussions at key industry events. He is a self-described "journalist and analyst, not evangelist."
  • alxslr

    Has the Aircar dev updated the app to allow foveated rendering, or it worked directly?

    • XRC

      It works through the Pimax play client and steamVR, Aircar is openVR (steamVR) application built on Unreal engine. Aircar is on hold as the developer is not allowed to work on it due to their current employment contract.

      For openXR applications you use PimaxXR runtime and openXR toolkit to set-up eye tracking. For VR Chat there is an application VRCFT (VR Chat face tracking) which enables face and eye tracking in compatible headset.

      The Crystal comes with a Gaming licence from Tobii which is used for automatic ipd and foveated rendering, whereas the Ocumen licenced enterprise headsets like Reverb G2 omnicept and Vive Pro Eye expose the full suite of eye tracking data.

      But we can then use ghostiam’s application Broken Eye to expose all eye tracking data on the Crystal for driving compatible avatars in VR Chat.

  • Adrian Meredith

    As usual apple makes life difficult for everyone by refusing to collaborate

    • xyzs

      Is visionOS compatible with openXR ?

    • Nix

      Eh, there’s more uninvolvement in OpenXR than just Apple not in the partners list. As I understand it, companies will sign on to use what they want, but getting them to contribute back to OpenXR or to actively support OpenXR standards in their own devices is still like herding proud cats. For example, “Sony” is listed as a major partner, but PlayStation VR2 doesn’t support the OpenXR API (nor did PS4 PSVR in earlier times.)

  • perVRt

    Industry Consensus is dead wrong on Stereo with Foveated Rendering. Even all those companies had retail stores to calibrate each customer!

  • Ad

    Still not incorporating overlays in the base spec is suicidal at this point.

  • Lucidfeuer

    “XrUuid” there we go…the market has not even taken off that they want to ruin it with all their tracking malwares