XR terms: runtime, tracking and actions
Practical distinctions between device, API, pose, tracker, action map and focus.
These terms help explain XR settings and failure causes. They do not mean every listed feature is available on every device.
Device, API and runtime
| Term | Practical meaning |
|---|---|
| XR | Umbrella term for applications using tracked space and XR devices |
| VR | A virtual environment in place of the normal real-world view |
| AR | Virtual objects alongside visible physical surroundings |
| MR | A term for mixed experiences; not itself an API or guaranteed feature |
| HMD | A head-mounted device; its presence establishes neither 6DoF nor hand tracking |
| OpenXR | API connecting an application to an XR runtime |
| OpenXR runtime | Software handling the device, session, tracking and output; not the engine’s Runtime folder |
| XRInterface | An engine XR-interface implementation; registration does not establish successful initialization |
Passthrough shows physical surroundings through the device’s available output mechanism. It is not hand tracking, room reconstruction or spatial anchors: each needs separate support. WebXR is a browser API; enabling OpenXR does not configure it.
Pose and tracking
Pose is position and orientation relative to a selected space. OpenXR positions use meters. A numeric transform alone does not establish current tracking data. XrPosef definition.
3DoF tracks orientation on three axes. 6DoF adds translation on three axes. Head rotation does not establish positional tracking; a visible hand model does not establish tracked hands.
A tracker is a named source of tracked data. In the standard setup, controller Tracker is left_hand or right_hand; Pose selects data within it, such as grip. Neither is an Entity name or a button BindingPath. Check tracking availability before treating a position as valid.
A reference space supplies the XR coordinate frame. VIEW follows the viewer, LOCAL uses a local origin and STAGE describes a runtime-defined area; check space availability and configuration separately. XROrigin3D places incoming XR data in the game world; it is not a physical sensor. OpenXR spaces.
WorldScale relates XR meters to game-world scale. Do not compensate for scale mismatch by repeatedly adding offsets to the tracked camera. Recenter changes the spatial reference representation; handling it is not character teleportation.
Actions and session state
| Term | Distinction |
|---|---|
| Action | Game intent such as select, not a physical button |
| Action set | Group of actions the runtime can activate for a game mode |
| Interaction profile | Description of suitable device components, not a controller instance |
| BindingPath | Full component path such as /user/hand/right/input/select/click |
| Initialized | Interface initialized; not yet proof of focus or every action’s availability |
| Focused | Session has XR focus for interaction |
| Visible | Image visible without XR-input focus |
| Haptic | Device-feedback request; a parameter resource is not a sent pulse |
A configured path or SDK class creates no compatible device. See the action map for resource/runtime separation and the startup controller for failure and focus handling.
Foveation reduces rendering work in less important image regions. It may be fixed; enabling VRS alone creates no eye tracking. See the VRS guide for application and quality trade-offs.
Related examples checked resources, rig configuration and failure paths without a headset. Terms and runtime capabilities were reviewed against source and primary documentation; this does not establish tracking or XR output on a particular device.