OpenXR Unity: A Complete Guide

The plugin lets one Unity project target HoloLens 2, Varjo, Magic Leap 2, HTC Vive, Meta Quest, and SteamVR headsets without per-device SDK rewrites, replacing Unity’s legacy built-in XR and the older XR Plugin Framework.

Key Takeaways

• Unity’s OpenXR Plugin is the official, Khronos-conformant path for cross-vendor XR; it supersedes the deprecated built-in “XR” checkbox and most vendor-specific Unity plugins.
• One project can cover PC VR, standalone Android (Quest), and mixed reality (HoloLens 2, Magic Leap 2) by enabling the right feature groups and interaction profiles per build target.
• Vendor plugins (Valve’s SteamVR/OpenXR plugin, HTC’s VIVE OpenXR plugin) still matter for hardware-specific features like Vive trackers, eye tracking, or facial tracking that the core OpenXR Unity plugin does not expose.
• OpenXR’s action-based input model is the biggest conceptual shift: you bind abstract actions to device paths rather than reading buttons directly.
• Version and render-pipeline choices (Built-in vs URP) drive most “it won’t render” problems; verify package compatibility before debugging code.

What OpenXR Is and Why Unity Adopted It

OpenXR is an open, royalty-free standard maintained by the Khronos Group, the same consortium behind Vulkan and glTF. The specification defines a common interface between an application and an XR runtime, so a headset maker writes one runtime and a developer writes one integration. Before OpenXR, Unity projects leaned on vendor SDKs (the Mixed Reality Toolkit, SteamVR plugin, Oculus Integration, Wave SDK) that each exposed different APIs and broke on upgrade.

Unity’s adoption of OpenXR arrived in stages. The legacy “Virtual Reality Supported” checkbox in Player Settings was replaced by the XR Plugin Management system, and the OpenXR Plugin became the recommended provider for most targets. Unity documents the package in its official OpenXR Plugin manual, which is the canonical reference for feature groups, interaction profiles, and settings.

The practical payoff for enterprise teams is procurement flexibility. A simulation built once can ship to a Varjo XR-4 for high-fidelity training and to a Quest 3 for field use, with the same input actions mapped to different controllers. That reduces the re-validation burden when a headset reaches end-of-life or a supplier changes.

How the Unity OpenXR Plugin Is Structured

Unity’s OpenXR Plugin is organized around feature groups, which are toggles that enable optional OpenXR extensions. Understanding this structure prevents most configuration mistakes when using OpenXR in Unity.

Core feature groups include:

• Runtime and validation — the base OpenXR loader plus a validation layer that surfaces spec violations during development.
• Interaction profiles — mappings for specific controllers (Oculus Touch, Microsoft Motion Controller, Valve Index Controller, HTC Vive Controller, and others). Each profile tells the runtime how a physical device maps to abstract actions.
• Rendering extensions — single-pass instanced rendering, depth submission, and similar performance features.
• Mixed reality and platform features — hand tracking, eye gaze interaction, and vendor-specific extensions where supported.

Feature groups are enabled per build target. A Windows PC build might enable the SteamVR and Oculus interaction profiles plus single-pass instanced rendering; an Android build for Quest enables the Oculus Touch profile and hand tracking. Enabling a feature group the target runtime does not support produces warnings, not silent failures, which is why reading the console during a first build matters.

Setting Up OpenXR in a Unity Project

Setup follows a predictable sequence, and skipping steps is the usual cause of a black headset view.

1. Install the package. Add the OpenXR Plugin through the Package Manager (Unity Registry). Unity’s manual lists the compatible Unity Editor versions for each package release; matching them avoids compile errors.
2. Enable XR Plugin Management. In Project Settings, install XR Plugin Management, then tick OpenXR as the provider for each target platform (PC, Android, etc.).
3. Configure feature groups. Open the OpenXR settings panel and enable the interaction profiles and rendering features your devices need.
4. Set the input system. The plugin works with Unity’s Input System package. Choose the action-based or simple input path and confirm the active input handling in Player Settings.
5. Build and test on device. Deploy to the headset and check the console for validation-layer messages.

A frequent gotcha: the OpenXR settings panel is per-platform. Configuring PC settings does nothing for an Android build, and teams often forget to switch the platform tab before enabling the Quest interaction profile.

The Action-Based Input Model Explained

OpenXR input is action-based, and this is the concept that trips up developers coming from direct button polling. Instead of asking “is the trigger pressed on controller 1,” you define an abstract action (“select,” “grab,” “teleport”) and bind it to device-specific paths. The runtime resolves the binding for whatever hardware is present.

Unity exposes this through the Input System’s XR support and through the plugin’s own action assets. A typical setup defines:

• An action set grouping related actions (locomotion, UI, interaction).
• Actions with a type (button, axis, pose) and a control (trigger, grip, thumbstick, aim pose).
• Bindings mapping each action to paths like /user/hand/left/input/trigger/value.

The benefit is portability: the same “grab” action works on a Vive wand, an Index controller, and a Quest Touch controller because each interaction profile supplies the binding. The cost is a steeper initial learning curve and more configuration files. Teams building for a single headset sometimes find the simple input path faster to ship, then migrate to actions when they add a second device.

Choosing Between the Core Plugin and Vendor Plugins

The core Unity OpenXR Plugin covers the common case, but vendor plugins exist for hardware-specific capabilities. The decision hinges on which features you actually need for your OpenXR Unity project.

Valve publishes a Unity XR plugin for SteamVR that exposes SteamVR-specific functionality, and HTC publishes the VIVE OpenXR Unity plugin for Vive-focused features. A common enterprise pattern is to build on the core plugin and add a vendor plugin only for the specific extension a project requires, keeping the vendor dependency isolated behind an interface so it can be swapped.

Platform and Device Coverage in Practice

OpenXR’s promise is broad coverage, but real-world support varies by runtime and device. On Windows PC, the SteamVR runtime and the Windows Mixed Reality runtime both implement OpenXR, and Varjo headsets run through Varjo’s OpenXR runtime. On standalone Android, Meta’s runtime powers Quest devices, and Pico offers its own OpenXR runtime. HoloLens 2 and Magic Leap 2 use their respective OpenXR runtimes for mixed reality.

This means a single Unity project can target all of them, but each target still needs testing. Rendering paths differ (mobile GPUs on standalone, desktop GPUs on PC), and mixed-reality devices add passthrough and spatial-mapping considerations that pure VR headsets lack. The OpenXR specification defines the interface; it does not guarantee identical performance or identical feature availability across runtimes.

For procurement teams, the takeaway is that OpenXR reduces but does not eliminate per-device work. Budget for a validation pass on each headset model you intend to support, especially for mixed-reality features like hand tracking and spatial anchors.

Performance and Rendering Considerations

Rendering in OpenXR Unity centers on a few high-impact settings. Single-pass instanced rendering draws both eyes in one pass, cutting CPU overhead versus multi-pass; most PC and standalone targets support it. Depth submission improves reprojection quality on runtimes that use it. Resolution scaling and fixed foveated rendering trade image quality for frame rate on standalone hardware.

Frame timing is the constraint that governs everything. Standalone headsets target a fixed refresh rate (commonly 72 or 90 Hz), and missing the budget causes judder that breaks presence in training scenarios. Profiling with Unity’s tools plus the runtime’s own performance overlay is standard practice. On PC, the GPU budget is larger but not unlimited, particularly with high-resolution Varjo displays.

A subtle point: enabling every feature group “just in case” can cost performance and complicate validation. Enable what the build needs, and keep a documented baseline configuration per target device so QA can reproduce results.

Migration and Compatibility Notes

Teams arriving from legacy setups face three common migrations. The first is from Unity’s built-in XR to the OpenXR Plugin, which mainly means re-doing camera rig and input configuration. The second is from a vendor SDK (Oculus Integration, SteamVR plugin, MRTK’s older input stack) to OpenXR, which often means rewriting input handling around actions. The third is upgrading the OpenXR Plugin package itself, where feature-group names and settings occasionally change between versions.

Unity’s package documentation is the authoritative source for version-specific behavior, and the Khronos OpenXR specification defines the underlying standard. Checking both before a major upgrade saves debugging time. For mixed-reality projects, the Mixed Reality Toolkit (MRTK) layers UX components on top of OpenXR and is worth evaluating separately from the plugin itself. This ensures a smooth transition for those using OpenXR in Unity.

How to Decide: A Practical Checklist

Use these criteria to choose an approach before writing code:

• Number of devices. A headset model prefers the simplest form; Three or more prefer the core OpenXR plugin.
• Feature Requirements. List the required features (hand tracking, eye tracking, tracker, pass-through) and check which plugin is available for each.
• Runtime Targets Confirm that each headset’s OpenXR runtime supports the extensions you need.
• Team Skills. Action-based entries reward teams that master the entry system. Simple entries ship faster for small projects.
• Longevity. A standards-based integration will last longer than any single-vendor SDK, which is important for multi-year enterprise deployments.

Frequently Asked Questions

What is the OpenXR Unity plugin used for?

The OpenXR Unity plugin connects a Unity project to any XR runtime that implements the OpenXR standard, letting one codebase run on HoloLens, Varjo, Magic Leap, Vive, Quest, and SteamVR headsets. It replaces most vendor-specific Unity SDKs and provides cross-vendor input, rendering, and mixed-reality features.

Is OpenXR better than using vendor SDKs in Unity?

OpenXR is better for portability and long-term maintenance because it avoids locking a project to one vendor’s API. Vendor SDKs remain necessary for hardware-specific features the core plugin does not expose, such as Vive trackers or certain eye-tracking extensions, so many teams combine both.

Does Unity’s OpenXR Plugin support hand tracking and eye tracking?

Support depends on the runtime and the feature groups you enable. Hand tracking and eye gaze interaction are available through OpenXR extensions on devices whose runtimes implement them, such as HoloLens 2 and Meta Quest. Always verify the specific extension against the target device’s runtime documentation.

How do I fix a black screen when building with OpenXR in Unity?

A black headset view usually traces to a mismatched package version, a disabled interaction profile, or an unset input handling mode. Confirm the OpenXR Plugin version matches your Unity Editor, enable the correct per-platform feature groups, and check the validation-layer console messages after deploying.

Can one Unity project target both PC VR and standalone headsets with OpenXR?

Yes. The OpenXR Plugin is configured per build target, so a single project can enable PC interaction profiles for a Windows build and Android profiles for a Quest build. Each target still needs its own testing pass because rendering paths and performance budgets differ.

What is the difference between OpenXR and the older Unity XR Plugin Framework?

OpenXR is the cross-vendor standard itself, while Unity’s XR Plugin Framework was the earlier provider system that let different SDKs plug into Unity. The OpenXR Plugin is now the recommended provider within that framework, and Unity’s legacy built-in XR support is deprecated in favor of it.