VRHow / All sections / VR How-To Guides / How does VR work?
How does VR work?
Last checked October 11, 2026.
The four parts of a VR system
- Optics and stereo views. The lenses and display present perspective views intended for the left and right eyes. Google Cardboard's developer documentation describes stereoscopic rendering as an essential VR feature. Lens position and display design differ by headset, so this technical overview is not a fitting guide. [1]
- Tracking. Sensors estimate head orientation (which way the user is looking) and, on systems that support it, head position (where the user is). These are distinct capabilities; the word “VR” alone does not establish that an app supports room-scale movement. Controllers, hand poses, gaze or other devices can contribute separate input.
- Runtime software. A runtime connects the application to the headset's supported views, tracking and input devices. OpenXR is a standard API layer for applications and runtimes; it provides a common interface, but does not guarantee that every game, runtime or headset combination supports every feature. Khronos OpenXR.
- Application rendering. The game uses the current pose and its virtual scene to render the views, then submits them through the runtime for display. OpenXR specifies view configurations, reference spaces, frame synchronization and frame submission. [2]
What happens when you move your head?
- The headset estimates a pose. Tracking reports orientation and may report position. Cameras, inertial sensors and other tracking methods vary by headset; the runtime reports the capabilities it supports.
- The runtime locates the views. The application asks for the headset's views in a reference space and for a display time. OpenXR defines these requests so the application can render from the user's changing viewpoint rather than treating the headset as a fixed monitor. [2]
- The app renders and submits frames. It draws the scene from the requested views and submits images to the runtime. Timing matters because the view should correspond closely to the user's movement; if tracking is lost or rendering cannot keep up, the scene may feel unstable or uncomfortable. A specific symptom still needs device- and app-specific diagnosis.
Reference spaces: head, room and play area
OpenXR uses reference spaces to describe where virtual objects are relative to the user and environment. VIEW follows the viewer's head. LOCAL is a gravity-aligned, world-locked origin. STAGE represents a runtime-defined, floor-level rectangle intended for standing- or room-scale content. STAGE support is optional, and a runtime may not be able to locate it until the user defines a play area in the runtime's own settings. Khronos OpenXR 1.1, Reference Spaces [2].
This is why a VR application can request a room-scale space without being able to create a missing boundary by itself. The headset/runtime setup owns the physical play area; application support and runtime support are separate.
Why the same game can behave differently
The headset's display, supported tracking spaces, controller profile, runtime and game all participate in one session. A different headset or connection mode can expose different input, field of view, refresh-rate options, play-area support or performance. Compatibility is therefore specific to the game, device, runtime and PC—not just to the word “VR” on a store page.
This guide explains the mechanics. For a plain-language definition and platform categories, see What is virtual reality? For practical room setup, fit and first-use steps, see How to set up a VR headset.
Sources
- Google Cardboard: Create immersive VR experiences — motion tracking, stereoscopic rendering and user interaction.
- Khronos OpenXR 1.1 specification — reference spaces, view configurations, timing and frame submission.
- Khronos Group: OpenXR — overview of the cross-platform API and the runtime/application relationship.
