Intel’s Brent Insko has taken over as the Chair of the OpenXR working group after Epic’s Nick Whiting passed the torch. The pair say the OpenXR effort is still going strong, and a progress update is planned for March.

OpenXR is a work-in-progress standard that aims to unify the underlying connections between VR and AR hardware, game engines, and content, making for a more interoperable ecosystem. The standard has been in development since April 2017 and is presently supported by virtually every major hardware, platform, and engine company in the VR industry, including key AR players like Magic Leap. OpenXR’s ‘working group’, under which representatives from member companies are actively developing the standard, is facilitated by Khronos Group.

Image courtesy Khronos Group

The OpenXR working group has been chaired from the start by Nick Whiting from game & engine maker Epic Games. Citing additional responsibilities in his role at Epic, Whiting tells Road to VR that he stepped down as chair in late 2018, though the company is still fully committed to OpenXR.

“I’m honored to have had the opportunity to serve as the chair of Khronos’ OpenXR working group for just shy of two years. Upon taking on a number of new initiatives at Epic Games, I saw a clear opportunity to pass the torch, and the group elected Brent Insko of Intel as the new chair when he stepped up to answer the call,” says Whiting. “The spec is in great hands with Brent and the OpenXR working group, and Epic remains just as committed as ever to the standard. We’re continuing to actively participate in all the [OpenXR] working group online and in-person meetings, and of course, continuing work to add support for OpenXR to Unreal Engine 4.”

Taking over as Chair of the OpenXR working group is Brent Insko, Lead Software Architect at Intel’s Virtual Reality Group. Inkso has been part of the group since its inception.

“[I want to] first thank Nick for his leadership of the group and getting us this far. As the newly elected chair, I’m excited by the opportunity to help drive OpenXR to its initial release and beyond,” Insko says. “The 30+ member companies continue working feverishly to deliver a specification that removes the major complications of writing portable VR and AR applications.”

VR's Biggest Players Back New 'VirtualLink' Connector for Next-gen Headsets

In August 2018, members of the OpenXR working group presented a detailed overview of the OpenXR architecture. The group also showed the first live demo of OpenXR in action. Built with Unreal Engine using an OpenXR plugin, Epic’s ‘Showdown’ demo, was shown running on both a Windows Mixed Reality headset and a StarVR headset.

Image courtesy Khronos Group

This showed one of the core elements of OpenXR: that developers can design their applications around a single API, and have it run on multiple headsets without dealing with multiple vendor-specific APIs. Conversely, a hardware maker targeting the OpenXR standard could count on the ability to tap into a body of existing OpenXR content, lowering the barrier to entry into the market, and expanding choices for consumers.

“Our Showdown demo running on OpenXR with Windows Mixed Reality and StarVR headsets was just the beginning, and we remain fully committed to OpenXR as the defining open standard for XR,” Epic’s Nick Whiting tells Road to VR.

Indeed, Intel’s Brent Insko says that the OpenXR working group plans to provide a progress update on development of the standard at the Khronos Developer Day on March 19th at GDC 2019.

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. See here for more information.

  • mfx

    Their diagrams are not well made but this standard is essential. Can’t wait for it.

    • Jistuce

      Honestly? I think this specific standard is a bad idea. It adds two more APIs to the path, and it reminds me of the early days of Win95, when we started adding APIs to abstract away the details of sound and graphics adapters.

      DirectX seemed like a godsend, but that solution ended up with a stack of APIs that rendered low-latency operations difficult or impossible, and we introduced new APIs to get around those limitations, regain hardware access, and work at a lower level again. Right back to square one, only there’s now a couple gigs of extra code involved.

      We don’t need extra APIs wrapping around and abstracting the currently existing ones. We need a replacement API that is accepted as a standard by everyone. Basically, the two purple blocks need to be one purple block, and the pile of logos between them needs to vanish.
      That gets us to where we’ve been with keyboards and mice and displays for years and years. There’s no two-gig abstraction layer to navigate diffrences between Logitech and HP mice. You plug it in and it just works, because they all speak the same language at all levels.

      • edzieba

        “We don’t need extra APIs wrapping around and abstracting the currently
        existing ones. We need a replacement API that is accepted as a standard
        by everyone.”


        The entire purpose of OpenXR is to eliminate the current state with additional API shims between OVR/SteamVR/OpenVR/etc by switching everyone to a common API. Different applciaitons, runtimes, drivers etc can all interface by that common API.

        • Jistuce

          They need to rework that diagram, then. Because it looks like “API that the game calls, which converts to the Oculus and SteamVR and Daydream and ETC APIs, which then go to another abstraction layer so all of these APIs can talk to any given headset. “

          • Paweł Chachaj

            From this diagram it could also be interpreted as:
            1. If you are a developer u need to focus only on Application API for your program to work on any VR, no matter what Engine you use. (top of the diagram)
            2. If you are HTC, Oculus etc. developer you need to adapt your device to handle both Application and Device API (sigle standard)
            3. If you are a user, you just plug your device and it works. Like mice, keyboard etc.

            Secound point is where HTC, Oculus, Windows MR need to handle input (Application) and output (Device).
            You can’t exacly make it more condensed because each company have it’s own optimalization solution for their specific hardware, but they are expected to use universal API.

            In the end you do have different hardware, different tracking systemss, controllers.
            Unless application uses specific functionality of single headset, it is expected to work the same on all with this API.

  • Lucidfeuer

    I’d trust Epic 10X more than Intel to make the standard be optimised and go forward…

    • tu ma

      It’s just the fucking Chair position

      • Holy in the house

        You think the chair position is meaningless? This isn’t the president sweetheart.

  • wheeler

    It will be interesting to see whether or not Oculus continues down the path of hardware exclusivity and re-introduces the “entitement check” or some critical unsupported extension once this standard is widespread.

    Store exclusivity is understandable–they paid for the exclusive content and are looking for a return. But intentional lock outs via hardware exclusivity when the interface to the hardware is standardized is not good for this market and is not in line with PC culture

  • oompah

    Its like a joke
    when intel hasnt done anything for AR/VR
    Hah ha ha
    expect demise of AR/VR
    No buy buy
    rather bye bye AR/VR