XR Interaction Toolkit Selection and Configuration for Game Mechanics

Selection and Configuration of XR Interaction Toolkit for Game Mechanics

XR Interaction Toolkit (XRIT) — official Unity package for VR/AR interactions. Sounds like "take from Package Manager and done". Practice: has own architecture, own compromises, incorrect setup gives mechanics not working as expected or performance issues from extra update cycles.

Version matters

XRIT 2.x and 3.x — actually different systems. Version 3.x rewrote Input handling from Legacy Input Manager to new Input System, changed Interactor/Interactable architecture, added Affordance System for visual states. If project started on 2.5 but read docs for 3.0 — some APIs simply don't exist.

Before setup: fix XRIT version in manifest.json, ensure Input System Package (com.unity.inputsystem) version ≥ 1.6, XR Plugin Management configured for target platforms. Without explicit OpenXR Loader or Oculus XR Plugin in XR Plug-in Management many XRIT components simply not initialize without clear error.

XR Origin: proper scene structure

VR scene root — XR Origin. Incorrect setup — source of 80% positioning and scale problems.

Tracking Origin Mode should match game type. Floor — for room-scale, player stands on floor, Y=0 is real floor. Device — for stationary, origin where headset at start. Wrong choice — avatar under floor or in air.

Camera Floor Offset Object — intermediate between XR Origin and Camera Offset. Y-position in Device mode sets virtual eye height (usually 1.5–1.8 m). In Floor mode Y = 0.

Hierarchy: XR Origin → Camera Offset → Main Camera (headset) + LeftHand Controller + RightHand Controller. Adding game objects directly to Camera Offset — bad practice: they move with head. World objects should be in world space.

XRGrabInteractable setup for mechanics

Standard XRGrabInteractable works for simple cases. For non-standard — need understand internals.

Movement Type defines object following hand:

• Instantaneous — teleports to attach point each frame. No physics. For UI elements.
• Kinematic — Rigidbody moves through MovePosition/MoveRotation. Correct Rigidbody interaction, may pass through static colliders at high speed.
• VelocityTracking — object gets velocity pulling to target. Most "physical", best for blocked objects. Needs fine tuning TrackingSpeed and TrackingRotationSpeed.

For weapons usually VelocityTracking with TrackingSpeed = 12–15 and separate throw handling via SelectExited event + Rigidbody.AddForce calculating velocity from last 5 frames position history.

Attach Transform — critical parameter often not set. Without it object attaches to controller position — correct only for base grip. Sword attach point at hilt; pistol at handle with correct angle. Create empty child with needed position/rotation, assign to Attach Transform.

Socket Interactor for object placement

XRSocketInteractor — for "place object on shelf/slot" mechanics. Common issues: object jumps on snapping if Snap Threshold too large (recommend 0.1–0.2 m), snap doesn't happen if Interactor Layer Mask doesn't match Interactable tags. Check: Interaction Layer Mask on XRSocketInteractor should include slots of all placeable objects.

For complex mechanics (modular weapons, assembly puzzles) standard Socket often insufficient — write custom Interactor inheriting XRBaseInteractor, override CanHover and CanSelect with conditions (object type, orientation, state).

Ray Interactor for UI and remote interaction

XRRayInteractor + XRUIInputModule for World Space Canvas interaction. Typical problem: ray passes through UI or activates elements behind others. Solution: correct Canvas sorting layer and Blocked Physics Raycasts = true on GraphicRaycaster.

For game objects XRRayInteractor with XRInteractableSnapVolume gives ray "attraction" to object center on approach — improves small object interaction accuracy without collider changes.

Cost calculated after gameplay mechanics analysis and target platforms.