Oculus "Runtimes"
This page provides additional information for those wanting to understand more about how applications are using the Oculus software or Virtual Desktop and how to take advantage of all the options offered to you.
An Application Programming Interface (API) is a set of data structures and functions that provide a way for a developer to program the use of a functionality (here, access to a Virtual Reality device).
For example, an API may define how a programmer will retrieve the head tracking information from your VR headset, or how they will present a rendered image to the display panel in the headset.
There can be multiple distinct API providing the same functionality, or a subset/superset of the same functionality.
Typically, end users do not know and do not care about the API used by developers. However in the world of PCVR, this notion becomes important due to the large variability in functionality and performance of each API, or in fact, each runtime implementing the API (see further below).
An API is not a piece of software. It is not a program that you can install or use on your computer. Instead, the runtime is the software.
Example: the accelerator and brake pedals of your car can be considered an API. They give the driver a way to operate the car. However, they may be built in a different way under the hood, depending on the brand and type of your car.
A runtime is a component that provides a functionality during execution of a program ("at run time", when your program is "running"). Often, a runtime will expose a functionality to other applications, via an API (see above).
There can be multiple runtimes implementing the same API, and the choice of which runtime to use for a specific API may or may not be left to you.
The runtime is the piece of software installed on your machine by yourself or a vendor to provide a functionality.
Example: the set of electrical, hydraulics or pneumatics components controlled by the accelerator and brake pedals of your car can be seen as the runtime implementing your pedals' (the API) functionalities.
This is the original API and runtime developed by Meta (Oculus at that time) for the Oculus Rift headset. It was later updated for Oculus Quest.
The API is tailored specifically for Oculus devices. It only includes functionality proper to the Oculus headsets. For example, it does not have provisions for the buttons of a Valve Index motion controller, so it would be impossible for a developer to program such device using OVR.
Originally, there was only one runtime implementation of the OVR API, the one for Oculus Rift and later Quest Link. However, a few implementations were created in order to allow running original Oculus Rift content on other headsets. In particular, we care about the Virtual Desktop implementation, which is the foundation of Virtual Desktop.
There are also implementations of OVR such as legacy OpenComposite or Revive attempting to bring compatibility with OVR applications to any headset, but these are beyond the scope of this document.
It is now obsolete and not recommended for any new applications. In fact, Meta will not allow new applications using OVR to be published in their store.
In a nutshell:
- Great performance (direct access to the headset)
- No portability (only works for Oculus devices and Virtual Desktop)
- Obsolete and doomed to slowly disappear
The growing number of VR device brands created a problem of fragmentation, where each headset would expose its functionality through a new unique API (something different from OVR, but that would accomplish more or less the same thing).
Valve introduced OpenVR as a cross-device API that would primarily work with their 1st party headsets (HTC Vive and the Index) but be extensible enough to support other vendors via a driver system in their SteamVR platform. As an API, OpenVR is agnostic of the underlying device, for example it does not have the notion of a fixed set of buttons like OVR did for the motion controllers, but instead it exposes a generic system of action paths that can be customized for various configurations of buttons.
There is only one runtime officially implementing OpenVR: SteamVR. This means that all applications using OpenVR to access VR functionality will use SteamVR. SteamVR is more than just a runtime, it is in fact a full platform providing an ecosystem of features such as a storefront, a home environment, a dashboard system and overlays. One of the foundations of the platform is a driver mechanism allowing vendors to make their devices usable with SteamVR. As a result, OpenVR applications will work on Valve's own devices, as well as any other VR headset (Oculus, Windows Mixed Reality, Varjo...).
There are also implementations of OpenVR such as OpenComposite attempting to remove SteamVR's overhead, but these are beyond the scope of this document.
OpenVR is still capturing a number of new developments while OpenXR is rising. However OpenVR is not ready for next generation headsets and lacks of features such as eye tracking or mixed reality.
In a nutshell:
- Provides universal VR hardware support (nearly any headset)
- Backed by a large ecosystem of SteamVR features and 3rd party extensions (eg: fpsVR)
- High overhead due to SteamVR
- In decline and not supporting modern features
OpenXR is the newest API for AR and VR applications. It aims at solving some of the same problems as OpenVR did, however unlike OpenVR, the design of OpenXR is governed by the Khronos consortium (as opposed to a single entity like Valve). This means that many vendors such as Meta, Microsoft, Varjo and Valve are developing the OpenXR API.
While OpenVR was applicable to vendors other than Valve through the SteamVR drivers' mechanism, the core of the OpenVR API was developed uniquely by Valve and built into SteamVR. This made it very difficult for any vendor to add new features that were not applicable to Valve's 1st party devices.
Each vendor now has the option to create their own OpenXR API extensions to drive innovations in the areas they care the most about. These vendors can then implement their OpenXR runtime with the features they desire. These runtimes do not use SteamVR. Vendors are eventually encouraged to converge their API extensions into cross-vendor extensions to avoid fragmentation.
The Oculus OpenXR runtime developed by Meta provides support for Oculus Rift and Quest Link without relying on SteamVR and while providing access to the full capabilities of Oculus devices, such as face tracking or body tracking.
Valve still provides an OpenXR runtime for SteamVR, offering access to their entire ecosystem and guaranteeing support of many headsets through their driver mechanism. It is sometimes called "SteamXR", however this name is not widely accepted and shall be avoided.
Some vendors do not provide their own OpenXR runtime and instead rely on SteamVR exclusively (for example Bigscreen Beyond).
OpenXR is the API recommended by many vendors for new developments and being continuously updated with modern features.
In a nutshell:
- Great performance (direct access to the headset when using the vendor's non-SteamVR runtime)
- Deliver modern capabilities such as hand tracking, eye tracking, mixed reality, and more
- Provides access to the SteamVR ecosystem when using SteamVR as the runtime
- Still in early stages of adoption
People will sometimes talk about "the Oculus runtime", which is a very ambiguous term.
-
"Oculus runtime" has for a very long time been referring to the Oculus VR (OVR) runtime.
-
"Oculus runtime" is today often (mis)used to refer to the Oculus OpenXR runtime.
As explained in this document, there are many differences between the two runtimes, and they cannot be used interchangeably. For clarity, people should prefer using "Oculus OVR runtime" and "Oculus OpenXR runtime" when appropriate.
People will sometimes talk about "OculusXR" when they mean "Oculus OpenXR runtime", which is incorrect.
OculusXR is a term that designates the Oculus XR Plugin for Unity/Unreal. Because that plugin can either use OpenXR or OVR, implying that "OculusXR" is OpenXR is misleading and shall be avoided.
Virtual Desktop supports all 3 of the APIs previously described.
- Virtual Desktop can be used with legacy OVR applications
- Virtual Desktop can be used with OpenVR applications through SteamVR
- Virtual Desktop can be used with OpenXR applications through SteamVR
- Virtual Desktop can be used with OpenXR applications through VDXR
The way Virtual Desktop achieves this is by providing a fast and efficient implementation of the OVR runtime.
This obviously takes care of 1).
It implicitly takes care of 2) and 3) because the SteamVR driver for Oculus (driver_oculus) relies on OVR and therefore Virtual Desktop can force this driver to use its own OVR runtime.
With the addition of VDXR, a lightweight implementation of the OpenXR API on top of OVR, it is now possible to run OpenXR applications with Virtual Desktop without relying on the SteamVR platform.
The Oculus OpenXR runtime, developed by Meta for Oculus Rift and Quest Link, is an OpenXR runtime tailored specifically for Meta's needs. While this runtime internally relies on the OVR API (via a set of unpublished extensions privately used by Meta), it does not allow usage of any OVR runtime other than the one from Meta. In technical terms, the Oculus OpenXR runtime is "statically linked" to Meta's OVR runtime.
Because of this implementation detail, it is not possible for Virtual Desktop to force the Oculus OpenXR runtime to use its own OVR runtime. Even if it did, due to the large amount of unpublished extensions in the newest OVR API, it would not be practical for Virtual Desktop to be compatible with the Oculus OpenXR runtime.
Instead, VDXR was developed as an OpenXR implementation tailored for Virtual Desktop's OVR runtime.
The OVR API was designed before the rise of modern AR/VR features, such as hand tracking. Therefore, there is no provision for hand tracking in the OVR API, at least not in the publicly available definition of the OVR API. Because OVR is the building block of Virtual Desktop, it means that it is impossible for Virtual Desktop to provide hand tracking information through OVR.
In 2024, Virtual Desktop introduced several new data channels adjacent to OVR in order to transmit data for advanced features such as hand tracking, body tracking, face tracking and eye tracking. With them, it is possible to offer these features in certain applications and under certain conditions. But it is not universally done. Some examples of Virtual Desktop use cases for these features:
- Hand tracking via SteamVR skeletal input API or Index Controller emulation
- Hand tracking and eye tracking via VDXR cross-vendor API
- Body tracking via Vive tracker emulation in both SteamVR and VDXR
- Face tracking via 3rd party add-ons such as VRCFT for VRChat
- Face tracking via VDXR vendor-specific API
For all of the usage above, applications must participate, meaning that the game developers must write support explicitly for these features.