| name | godot-platform-vr |
| description | Expert blueprint for VR platforms (Meta Quest, PSVR, SteamVR, Pico) covering XR toolkit (OpenXR), comfort settings (vignetting, snap turning, teleport), motion controls, hand tracking, and 90+ FPS requirements. Use when targeting VR headsets or implementing immersive 3D experiences. Keywords VR, XR, OpenXR, Meta Quest, motion sickness, comfort, locomotion, XRController3D, foveated rendering. |
Platform: VR
90+ FPS, comfort-first design, and motion control accuracy define VR development.
NEVER Do (Expert VR Rules)
Rendering & Comfort
- NEVER drop below 90 FPS โ In VR, 72 FPS or less causes instant nausea. You MUST maintain at least 90 FPS (Meta Quest 2/3 typical) and minimize rendering jank.
- NEVER use smooth rotation without a vignette (comfort mask) โ Smooth rotation causes motion sickness. Always provide snap turning OR dynamic vignetting.
- NEVER force 3D MSAA if Foveated Rendering is enabled โ Foveation can conflict with MSAA natively in the OpenXR pipeline on some hardware.
Locomotion & Interaction
- NEVER skip a teleport locomotion option โ Smooth movement is intolerable for many. Always offer teleportation as an accessibility alternative.
- NEVER use billboarding for VR UI โ
BILLBOARD_ENABLED breaks stereoscopic depth cues. Use static MeshInstance3D planes with SubViewports.
- NEVER place UI too close or too far โ 0.5m causes eye strain; 10m is unreadable. Optimal distance is 1-3 meters from the player.
Safety & System
- NEVER forget to respect physical play area boundaries โ Stepping into real-world objects is a safety risk. Use
XRServer to fetch guardian bounds.
- NEVER ignore focus_lost or session_ended signals โ Gracefully handle disconnections or system menu overlays by pausing the simulation.
- NEVER hardcode XRControllerTracker names โ Use the OpenXR Action Map system to decouple gameplay from specific hardware labels.
Comfort Decision Tree (start here)
- Can the player opt out of continuous locomotion? โ If no, stop and add teleport + seated mode before any smooth locomotion code.
- Turning: snap turn default โ load vr_locomotion_handler.gd. Smooth turn only with vignette + comfort toggle.
- Play area / focus: load vr_safety_guardian_warner.gd + vr_headset_focus_guard.gd before shipping any locomotion.
- Session bootstrap / actions / FPS: then load vr_openxr_initializer.gd, vr_input_action_mapper.gd, vr_performance_config.gd.
Available Scripts
MANDATORY: After the comfort decision tree, read the matching script before implementing that pattern. Do not invent a bare use_xr = true / XRController3D.is_button_pressed demo โ start from the scripts below.
Expert OpenXR initialization with driver support and feature verification.
Pinch and Grab recognition using XRHandModifier3D for hand tracking.
Snap turn, comfort vignette, and accessibility teleport_to() with guardian/focus failure modes.
Alpha blending and underlay setup for Mixed Reality (AR/VR) transitions.
Expert Foveated Rendering and Variable Rate Shading (VRS) setup.
Complex haptic pulse sequencing using XRController3D triggers.
Non-clipping, physics-following hands that respect environmental solid.
Guardian/Chaperone boundary distance warning logic using XRServer.
Headset-aware pause logic for focus loss (System Menu / Headset Off).
OpenXR Action Map abstraction to decouple logic from hardware buttons.
Teleport Accessibility Path
Always ship teleport (or room-scale only) as an alternative to smooth locomotion.
- MANDATORY read vr_locomotion_handler.gd โ
teleport_to(target_global).
- Raycast from controller aim to floor/navmesh; pass the hit point into
teleport_to.
- Failure modes (must handle):
- Pair teleport with snap turn + vignette from the same locomotion handler.
Comfort Gates (NEVER-adjacent)
These are hard comfort gates, not soft preferences:
- 90+ FPS before any optional VFX โ nausea risk outweighs polish.
- Teleport or snap-turn path always available โ never ship smooth-only locomotion.
- Guardian + focus handlers live before first public playtest.
- UI at 1โ3 m on composition layers / static quads โ never billboarded close-range HUD.
Expert patterns (script pointers)
- Mixed-Reality passthrough (Quest 3) โ
environment_blend_mode = ALPHA_BLEND + transparent_bg exposes the camera feed through scene alpha โ mixed_reality_manager.gd / vr_passthrough_manager.gd.
- Composition-layer UI โ
OpenXRCompositionLayerQuad + SubViewport bypasses lens blur โ xr_performance_overlay.gd.
- Universal grab โ OpenXR action map + central reparent manager โ universal_grab_manager.gd + vr_input_action_mapper.gd.
Deep dives (on demand)
Reference
Progressive disclosure: open Official Documentation links only when researching a specific API; load Related Skills when routing to a peer domain โ do not preload the whole lattice.
Official Documentation
- Setting up XR โ OpenXR project enablement, XROrigin3D/XRCamera3D tree, and first headset session bootstrap.
- A better XR start script โ robust initialize โ use_xr sequencing, focus signals, and failure paths before viewport XR mode.
- The XR action map โ hardware-agnostic actions so gameplay never hardcodes controller button strings.
- Basic XR locomotion โ teleport vs continuous movement and comfort-oriented turning patterns.
- OpenXR hand tracking โ XRHandModifier3D / joint tracking and controller fallback expectations.
- OpenXR composition layers โ crisp SubViewport UI via OpenXRCompositionLayerQuad instead of billboarded 3D quads.
- AR / passthrough โ environment blend modes and transparent viewport setup for mixed reality.
- OpenXR settings โ foveation, render target multiplier, and other headset performance knobs.
- XR room-scale โ play-area / guardian bounds via XRServer for physical safety.
- Deploying XR on Android โ Quest-class Android export, permissions, and OpenXR loader packaging.
- Variable rate shading โ VRS / foveated shading tradeoffs that pair with OpenXR foveation for 90+ FPS.
- XRInterface โ initialize, focus, passthrough, haptics, and blend-mode APIs shared by OpenXR/WebXR.
Related Skills
Prerequisites
- godot-project-foundations โ project settings, scene tree, and viewport basics required before enabling OpenXR and use_xr.
- godot-input-handling โ action/event mental model that the OpenXR Action Map extends for motion controllers.
- godot-gdscript-mastery โ typed XR scripts, await timers for snap-turn comfort, and signal wiring for focus/haptics.
Complements
- godot-camera-systems โ XRCamera3D is still a Camera3D; comfort UI distance and head-relative framing reuse camera placement rules.
- godot-performance-optimization โ draw-call and GPU budgets that decide whether 90/120 Hz holds under foveation and VRS.
- godot-physics-3d โ CharacterBody3D/RigidBody3D grab-and-throw hands that must not clip through static world geometry.
- godot-audio-systems โ mute/duck buses when headset focus is lost so system menus never leave game audio blasting.
- godot-shaders-basics โ comfort vignettes and spatial overlays during locomotion without fighting the XR compositor.
- godot-ui-containers โ layout inside SubViewports projected through composition layers at 1โ3 m.
- godot-export-builds โ Android/desktop export presets and OpenXR loader packaging for Quest and PCVR.
- godot-platform-mobile โ standalone headset Android constraints (thermal, resolution scale, touchless UX) that overlap Quest shipping.
Downstream / consumers
- godot-platform-web โ WebXR session_started/ended flows that reuse the same XRServer interface patterns for browser VR.
- godot-scene-management โ pause trees and scene swaps when focus_lost or session_ended fires mid-experience.
Master
- godot-master โ library router and mirrored module entry for cross-skill discovery.