Skip to main content

OpenVR Limitations & Observations

Floatiness in OpenVR​

  • The observed "floatiness" of overlays in OpenVR is not an implementation issue on our end. Overlays are correctly submitted as world-locked.
  • The behavior is dependent on SteamVR and the specific OpenVR driver used.
  • There is no further scope for improvement within the OpenVR API constraints.

Underlying API Limitations​

  • OpenVR lacks proper support for mixing head-locked and world-locked composition layers.
  • More performant OpenVR drivers tend to experience worse world-locked behavior due to how SteamVR handles composition.

Driver-Level Behavior​

  • SteamVR-native headsets (e.g., Valve Index, BigScreen Beyond) handle world-locked overlays better than other headsets.
  • High-performance OpenVR drivers often opt to let the headset manufacturer’s compositor handle final rendering, resulting in:
    • Single image per eye submission
    • SteamVR being unable to enforce world-locked overlays properly
    • A forced choice between all overlays being head-locked or all being world-locked, degrading quality.

Comparison to OpenXR​

  • Unlike OpenVR, OpenXR allows per-layer tracking space definitions via XrCompositionLayerQuad::space.
  • The legacy Oculus API (used by SteamVR for Quest/Rift headsets) enforces a single tracking origin for all layers.
    • This forces SteamVR to either convert world-locked overlays to head-locked or vice versa, leading to precision issues.

Key Takeaways​

  • useWorldLockedPositions has no effect on OpenVR.
  • OpenVR's limitations make OpenXR the preferred API for world-locked overlays.
  • Users experiencing overlay jitter or floatiness should consider switching to OpenXR where possible.

Appendix: World-Locked vs. Head-Locked Overlays​

World-Locked Overlays​

  • These overlays remain fixed in the virtual environment, independent of head movement.
  • Example: A dashboard display in a racing game that stays in place relative to the car.
  • Provides a stable and immersive experience, but may exhibit jitter or drift if not well-supported by the VR runtime.

Head-Locked Overlays​

  • These overlays move with the user's head, staying in a fixed position relative to the user's viewpoint.
  • Example: A HUD element that always appears in the same spot in the player's field of vision.
  • Ensures that overlays are always visible but can feel unnatural for elements that should be anchored in the virtual world.

Why This Matters​

  • Many modern VR applications rely on a mix of world-locked and head-locked overlays for the best user experience.
  • OpenXR supports defining different tracking spaces for each overlay, allowing precise control.
  • OpenVR’s limitations force developers to choose between all overlays being world-locked or all being head-locked, reducing flexibility and visual consistency.