← ClaudeAtlas

xr-interaction-and-locomotionlisted

Design and implement XR interaction: hand / controller / gaze input on an OpenXR action abstraction, locomotion chosen for comfort (teleport / dash / snap-turn vs smooth + vignette), reachable and readable 3D UI, and intentional grab/physics — with accessibility built in as a requirement. Input-API specifics verify-at-use.
mcorbett51090/RavenClaude · ★ 7 · Web & Frontend · score 65
Install: claude install-skill mcorbett51090/RavenClaude
# XR Interaction & Locomotion How the user reaches into the experience and moves through it. This is where XR feels natural or feels wrong, and where comfort is won or lost. > **Engineering judgment.** Input APIs, interaction profiles, and comfort research evolve; specifics carry a retrieval date + `[verify-at-use]`. Comfort and accessibility are acceptance criteria, not preferences. No PII. ## Workflow 1. **Abstract the input source.** Target OpenXR actions/interaction profiles so a single interaction binds across hands, controllers, and gaze and degrades gracefully when a modality is missing. 2. **Choose locomotion for comfort.** Match the scheme to the audience and session: teleport/dash + snap turning for broad/seated audiences; smooth locomotion only with comfort mitigations (vignette/tunneling, static reference frame, seated mode) shipped as defaults. 3. **Lay out 3D UI for reach and readability.** Comfortable depth and angular size, world/head/hand anchoring by task, hit targets sized for ray vs poke, text sized and contrasted for headset optics. 4. **Make grab/physics intentional.** Decide kinematic vs physics grab, attach transforms, two-hand manipulation, and haptics — don't inherit "floaty" and "clippy" by default. 5. **Bake in accessibility.** Seated/standing modes, one-handed and dominant-hand paths, snap-turn options, captions, adjustable text — designed in, not retrofitted. ## Metrics table | Metric | What it watches | Flag | |---|---|---| | Sim-sickness