OpenXR 1.1 Update Shows Industry Consensus on Key Technical Features

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.

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.”

The post OpenXR 1.1 Update Shows Industry Consensus on Key Technical Features appeared first on Road to VR.

Magic Leap 2 Now Supports OpenXR, Strengthening Industry Against Potential Apple Upheaval

Though delayed from its commitment last year, Magic Leap today announced that ML2 now fully supports OpenXR. The timing might have something to do with Apple’s looming entrance into the XR space.

Magic Leap had planned to deliver OpenXR support for its ML2 headset last year, but it was seemingly delayed until now. Today the company announced that Magic Leap 2 is conformant with OpenXR.

OpenXR is an open standard that aims to standardize the development of VR and AR applications, making hardware and software more interoperable. The standard has been in development since 2017 and is backed by virtually every major hardware, platform, and engine company in the XR industry.

“The adoption of OpenXR as a common AR ecosystem standard ensures the continual growth and maturation of AR,” Magic Leap said in its announcement. “Magic Leap will continue to advance this vision as Vice Chair of the OpenXR Working Group. In this role, Magic Leap provides technical expertise and collaborates with other members to address the needs of developers and end-users, the scope of the standard, and best practices for implementation.”

Its true that Magic Leap has been part of the OpenXR Working Group—a consortium responsible for developing the standard—for a long time, but we can’t help but feel like Apple’s heavily rumored entrance into the XR space lit a bit of a fire under the feet of the company to get the work across the finish line.

In doing so, Magic Leap has strengthened itself—and the existing XR industry—against what could be a standards upheaval by Apple.

Apple is well known for ignoring certain widely adopted computing standards and choosing to use their own proprietary technologies, in some cases causing a technical divide between platforms. You very well may have experienced this yourself, have you ever found yourself in a conversation about ‘blue bubbles and green bubbles’ when it comes to texting.

With an industry as young as XR—and with Apple being so secretive about its R&D in the space—there’s a good chance the company will have its own way of doing things, especially when it comes to how developers and their applications are allowed to interact with the headset.

If Apple doesn’t want to support OpenXR, this is likely the biggest risk for the industry; if developers have to change their development processes for Apple’s headset, that would create a divide between Apple and the rest of the industry, making applications less portable between platforms.

And while OpenXR-supporting incumbents have the upper hand for the time being (because they have all the existing XR developers and content on their side), one would be foolish to forget the army of experienced iOS developers that are used to doing things the ‘Apple way’. If those developers start their XR journey with Apple’s tools, it will be less likely that their applications will come to OpenXR headsets.

On the other hand, it’s possible that Apple will embrace OpenXR because it sees the value that has already come from years of ironing out the standard—and the content that already supports it. Apple could even be secretly part of the OpenXR Working Group, as companies aren’t forced to make their involvement known.

In the end it’s very likely that Apple will have its own way of doing things in XR, but whether that manifests more in the content running on the headset or down at the technical level, remains to be seen.

Pico Now Fully Supports The OpenXR Standard

Pico headsets are now fully compliant with the OpenXR standard, the company says.

OpenXR is the open standard API for VR and AR development. It was developed by Khronos, the same non-profit industry consortium managing OpenGL. OpenXR includes all the major companies in the space such as Meta, Sony, Valve, Microsoft, HTC, NVIDIA, and AMD – but notably not Apple. It officially released in 2019.

The eventual promise of OpenXR is to let developers build apps that can run on any headset without having to specifically add support by integrating proprietary SDKs. Developers still need to compile separate builds for different operating systems, but all current standalone VR headsets use Android.

Meta deprecated the proprietary Oculus API almost two years ago in favor of OpenXR, so Pico’s change should make it easier for certain OpenXR apps to be ported over. But ‘certain’ here means native apps written using a custom engine. Most mobile VR apps and games are made in Unity, and Pico’s Unity OpenXR Plugin is marked as “an experiment version and is not available for formal development”, last updated in October.

Even if the Unity integration supported OpenXR, there are other barriers to releasing VR apps to other stores. Platform-level APIs like friend invites, parties, leaderboards, cloud saves, and avatars still differ. Porting involves a lot more work than the dream of OpenXR may suggest.

Major XR Players Join New Metaverse Forum to Cooperate on Foundational Standards

Khronos Group, the consortium behind the OpenXR standard, is helping to assemble other XR industry players in service of cooperatively building interoperability standards for what it hopes will be an “open and inclusive metaverse.”

The so-called Metaverse Standards Forum was founded by platform holders, hardware companies, engine/tool creators, and users, with participants including companies such as Adobe, Autodesk, Epic Games, Unity, Meta, Microsoft, nVidia, OTOY, Qualcomm, and Sony.

Its founders says the Forum, which will hold its first meeting in July, will focus on “practical, actionable interoperability projects that can ‘move the needle’ on aspects of the metaverse that are needed by broad consensus.”

Image courtesy Metaverse Standards Forum

“We are ‘baking the open standard bricks’ for the metaverse, not ‘building the cathedral’,” the group says.

Forum organizers say the group will “coordinate requirements and support for existing SDOs developing standards relevant to the metaverse,” with the Khronos Group acting as host.

The Khronos Group is known for backing and organizing a number of open standards including OpenXR, an open standard developed to make XR applications run across many different XR headsets without developers needing to build different versions of their applications for each headset.

Organizers say the industry-wide forum will be open to all interested parties, as it includes no participation fee, no non-disclosure agreements (NDA), and no IP framework. Check out the project’s website to learn more about how you can join.

The post Major XR Players Join New Metaverse Forum to Cooperate on Foundational Standards appeared first on Road to VR.

Magic Leap Commits to OpenXR & WebXR Support Later This Year on ML2

In an ongoing shift away from a somewhat proprietary development environment on its first headset, Magic Leap has committed to bringing OpenXR support to its Magic Leap 2 headset later this year.

Although Magic Leap 2 is clearly the successor to Magic Leap 1, the goal of the headsets are quite different. With the first headset the company attempted to court developers who would build entertainment and consumer-centric apps, and had its own ideas about how its ‘Lumin OS’ should handle apps and how they should be built.

After significant financial turmoil and then revival, the company emerged with new CEO and very different priorities for Magic Leap 2. Not only would the headset be clearly and unequivocally positioned for enterprise use-cases, the company also wants to make it much easier to build apps for the headset.

To that end Magic Leap’s VP of Product Marketing & Developer Programs, Lisa Watts, got on stage at week’s AWE 2022 to “announce and reaffirm to all of you and to the entire industry [Magic Leap’s] support for open standards, and making our platform very easy to develop for.”

In the session, which was co-hosted by Chair of the OpenXR Working Group, Brent Insko, Watts reiterated that Magic Leap 2 is built atop an “Android Open Source Project-based OS interface standard,” and showed a range of open and accessible tools that developers can currently use to build for the headset.

Toward the end of the year, Watts shared, the company expects Magic Leap 2 to also include support for OpenXR, Vulkan, and WebXR.

Image courtesy Magic Leap

OpenXR is a royalty-free standard that aims to standardize the development of VR and AR applications, making hardware and software more interoperable. The standard has been in development since 2017 and is backed by virtually every major hardware, platform, and engine company in the VR industry, and a growing number AR players.

In theory, an AR app built to be OpenXR compliant should work on any OpenXR compliant headset—whether that be HoloLens 2 or Magic Leap 2—without any changes to the application.

OpenXR has picked up considerable steam in the VR space and is starting to see similar adoption momentum in the AR space, especially with one of the sector’s most visible companies, Magic Leap, on board.

The post Magic Leap Commits to OpenXR & WebXR Support Later This Year on ML2 appeared first on Road to VR.

HTC Brings OpenXR Public Beta to Vive Focus 3

HTC announced this week it is making available an OpenXR public beta for the Vive Focus 3. OpenXR is designed to make it easier for developers to create a single app that’s cross-compatible with multiple OpenXR-supporting headsets.

OpenXR is a royalty-free standard that aims to standardize the development of XR applications, making hardware and software more interoperable. In the best case scenario, an app built to be compliant with OpenXR can run on any OpenXR-supporting headset with no changes to its underlying code.

Image courtesy Khronos Group

OpenXR has seen a slow but steady adoption since reaching version ‘1.0’ in 2019, and picked up significant steam in 2021 with official support on SteamVRMeta going “all in” on OpenXR, “production-ready” OpenXR support in Unreal Engine, and more.

And now HTC’s latest enterprise-focused standalone headset, Vive Focus 3, has moved significantly closer to the finish line. The company announced this week that it’s ready for developers to test out the headset’s OpenXR support through a public beta.

“We’re committed to enabling the developer community to build the content and applications that power experiences across the spectrum of reality,” said Dario Laverde, Director of Developer Relations at HTC Vive. “With OpenXR, more developers will be able to bring their content to Vive Focus 3, and users will benefit from an expanded app library and more flexibility in terms of how they consume content. We strongly believe it’s a win for the XR industry as a whole.”

Now that doesn’t mean that you’ll be able to buy Quest applications and run them on Vive Focus 3… but it does mean that developers should have a much easier time porting their apps to run on Vive Focus 3, if they choose to offer their apps on the headset.

Developers interested in using OpenXR on Vive Focus 3 can find instructions for joining the public beta and using the standard in Unity at HTC’s developer forum.

The post HTC Brings OpenXR Public Beta to Vive Focus 3 appeared first on Road to VR.

HTC’s Vive Focus 3 Standalone Headset Gets Beta OpenXR Support

HTC’s Vive Focus 3 standalone headset now has beta support for OpenXR content.

OpenXR is the open standard API for VR and AR development. It was developed by Khronos, the same non-profit industry consortium managing OpenGL. OpenXR includes all the major companies in the space such as Meta, Sony, Valve, Microsoft, HTC, NVIDIA, and AMD – but notably not Apple. It officially released in 2019.

The promise of OpenXR is to let developers build apps that can run on any headset without having to specifically add support by integrating proprietary SDKs. Developers still need to compile separate builds for different operating systems, but all current standalone VR headsets use Android.

Last year Meta deprecated its proprietary Oculus SDK in favor of OpenXR, so Vive Focus 3’s support for OpenXR should make it easier for Quest apps to be ported. HTC still only markets the headset to businesses though – the $1299 price includes a two year business license, extended warranty, and priority support.

There are still barriers to releasing VR apps to other stores however. Platform level APIs like friend invites, parties, leaderboards, cloud saves, and avatars still differ. Porting involves a lot more work than the ideal of OpenXR may suggest.

Running OpenXR apps on Vive Focus 3 currently requires joining the beta program. For developers, HTC has instructions for building OpenXR content in Unity on the Vive forums.

Unreal Engine Gets OpenXR Improvements Just in Time for Oculus Development Shift

The latest version of Unreal Engine 4, version 4.27, brings “production-ready” support for OpenXR. The change comes just in time for Oculus developers, as the company recently announced it’s fully moving open to the OpenXR standard for VR development going forward.

You may recall news back in May that the early access version of Unreal Engine 5 includes improved support for OpenXR. And while developers can play with that version of the engine and its XR tools, the engine’s creator (Epic Games), doesn’t recommend the early access version of Unreal Engine 5 for anything more than experiments at this point. For developers building anything they intend to ship to the public, the company is still recommends Unreal Engine 4.

Since Unreal Engine 5 itself isn’t ready for prime time, Epic Games is continuing to update the production-ready Unreal Engine 4. The latest of which, version 4.27, is the first that the company says includes production-ready OpenXR capabilities.

OpenXR is a royalty-free standard that aims to standardize the development of VR and AR applications, making hardware and software more interoperable. The standard has been in development since April 2017 and is backed by virtually every major hardware, platform, and engine company in the VR industry, including key AR players.

OpenXR has seen a slow but steady adoption since reaching version ‘1.0’ in 2019, and in the last 12 months it has significantly picked up pace with SteamVR officially supported it back in February and Oculus announcing last month that it’s going “all in” on the standard, saying that all new developer features will be built on top of OpenXR going forward.

That makes Unreal Engine 4.27 a timely release; when Oculus said it would be fully shifting to OpenXR development last month, it put XR developers in an odd spot because the two biggest game engines, Unity and Unreal Engine, didn’t yet claim to offer production-ready OpenXR support.

Unity developers will have to wait a while longer before they can confidently make the leap to OpenXR as oculus expects that the Unity OpenXR plugin won’t be “fully supported” until early 2022. That will be a bigger deal once it finally happens because Unity is far and away more used than Unreal Engine when it comes to building XR content.

But maybe developers should take another look… last we checked, Oculus still has a special deal for developers building VR apps with Unreal Engine; the company offers to cover engine royalties for a game’s first $5 million in revenue.

Epic says that the OpenXR support in Unreal Engine 4.27 supports extension plugins from the Unreal Marketplace, which means that developers can add extra OpenXR functionality through plugins rather than waiting for updates to the entire engine.

New VR and AR Development Templates

Unreal Engine 4.27 also adds an improved VR Template which Epic says is “designed to be a starting point for all your VR projects,” and comes with basic VR capabilities built-in, like teleport locomotion, snap rotation, object grabbing, a spectator camera, and a VR-capable menu system.

The VR Template offers support for Oculus Quest 1 & 2, Quest with Oculus Link, Rift S, Valve Index, HTC Vive, and Windows Mixed Reality. Thanks to OpenXR, Epic says that “the template’s logic works on multiple platforms and devices without any platform-specific checks or calls.”

For PC VR, Unreal Engine 4.27 also includes experimental support for fixed foveated rendering, a technique which reduces the quality of peripheral imagery in favor of higher quality at the center where the user can see most sharply through the lens. Fixed foveated rendering in Unreal Engine 4.27 is currently limited to Windows platforms with DX12 and a GPU supporting VRS Tier 2.

Unreal Engine 4.27 also includes a new template for handheld AR development which is designed as a starting point for developers building AR apps based on ARCore (Android) and ARKit (iOS). Similar to the VR template, the AR Template includes basics like a built-in UI, a tool for users to take snapshots of the AR content, and the ability to move, rotate, and scale models places into the world.

The new engine update further includes heaps of improvements to Unreal Engine’s virtual production tools which are designed to combine real-time CGI environments with live-action filmmaking. Check out the complete patch notes for Unreal Engine 4.27 here if you want to go in-depth.

The post Unreal Engine Gets OpenXR Improvements Just in Time for Oculus Development Shift appeared first on Road to VR.

Unreal Engine Improves OpenXR Support, Now Production-Ready

The OpenXR plugin for Unreal Engine has been updated in the latest 4.27 release and is now production-ready.

OpenXR is a new standard that provides an API for VR and AR content that allows game engines to write code that is compatible across multiple hardware platforms. Previously, companies like Facebook, Valve and Microsoft all used their own separate APIs, which therefore required more effort from developers if they wanted to support multiple headsets.

Platforms have slowly been adding support for OpenXR and transferring over to the new API. SteamVR added full OpenXR support earlier this year, while Facebook got fully on board just under two months ago.

The latest release of Unreal Engine, 4.27, improves the OpenXR plugin support and brings it to a production-ready state. This means that Epic Games considers OpenXR support is essentially ready to use and able to meet the demands and needs of VR developers using Unreal. In 4.27, Epic added support for stereo layers, splash screens, querying playspace bounds and more — you can find more detail here.

The release also includes redesigned templates for VR and AR projects, which serve as “a starting point” for developers to jump off when developing a project using OpenXR, ARCore or ARKit.

The new VRTemplate for OpenXR projects includes encapsulated logic for teleport locomotion, snap rotation, grab components, a VR spectator camera and a menu. The template supports Quest 1 and 2, Quest via Link, Rift S, Valve Index, HTC Vive and Windows Mixed Reality platforms. You can read more about the template here.

The redesigned handheld AR template, designed for developers using ARCore or ARKit platforms on iOS and Android devices, includes some basic features such as basic UI and touch interface, easy setup and model scaling and rotation features.

Previously, Epic added OpenXR support to the beta for Unreal Engine 5. You can read more about OpenXR in Unreal 4.27 here. 

 

Facebook Deprecates Proprietary Oculus APIs In Favor Of OpenXR

Facebook will deprecate its proprietary Oculus APIs in favor of industry standard OpenXR.

Facebook says new features “will be delivered via OpenXR extensions” starting with v31, echoing language release by Valve last year regarding new features on SteamVR being connected to OpenXR as well.

According to Facebook, in August of 2022 the existing Oculus Native Mobile and PC APIs will become “unsupported”, meaning that “existing applications will continue to function on Oculus devices” but new applications will be required “to use OpenXR, unless a waiver is provided.” In the interim, Facebook will “help developers build new applications with OpenXR via our Developer Site” and “perform QA testing of OpenXR to ensure features are working.”

Facebook “will be unable to provide access to Oculus Native Mobile and PC APIs but will allow existing applications to continue to use them” and “can provide recommendations for migration of existing applications to OpenXR via guides but are unable to assist with creation of new applications with Oculus Native and PC APIs.”

Broad industry support for OpenXR from Facebook and other major VR players like Valve, Microsoft and HTC — as well as game engines from companies like Unity and Epic Games — should make it easier for developers to make VR apps that run on a wide range of hardware. Microsoft’s Flight Simulator VR is one of the first OpenXR-compatible titles. At the end of 2020 Facebook started recommending game engines use OpenXR.

VR Industry Ramifications

“This is the right move at the right time,” wrote original Oculus Rift creator Palmer Luckey in a direct message. “One standard to rule them all didn’t make sense in the earlier days of VR given the fundamentally different approaches of different companies on the hardware and software side, to say nothing of the business component – there was a time when SteamVR/OpenVR (which was not actually open) had huge issues and many companies were philosophically opposed to things like reprojection, the pain developers went through supporting various APIs was critical in building industry consensus on what works best and why. HTC is probably going to benefit the most from widespread OpenXR adoption on the corporate side in the near future, but there are some upcoming entrants who also stand to gain a lot. Industry-wide standardizing to the lowest common denominator still has some downsides, but they are almost certainly outweighed by the benefits to developers and gamers.”

While the move should make it easier for developers of new apps to build for multiple hardware platforms, those building with earlier APIs or older versions of game engines may face some pressure to update to ensure their software and their players are supported should bugs arise, or to gain access to new features like the new Passthrough API.

“I will eventually switch to OpenXR but it will take months of work as Virtual Desktop was developed against Oculus’ VrApi over the last 4 years,” Virtual Desktop developer Guy Godin wrote in a tweet and direct message. “Still have months of work to port Virtual Desktop from VrApi to OpenXR. A passthrough environment will not be possible until then.”

“I’ll no longer be able to expect that — if a critical issue arises caused by Facebook’s new software — that it will be fixed. Which will affect every PCVR game built before 2020 in Unity, ie. most of them,” wrote H3VR developer Anton Hand in a direct message.

You can read more about the OpenXR transition over on the Oculus developer blog.