Unity XR Interaction Toolkit Tutorial: Full Guide

Device-based system — plus a set of ready-made locomotion providers, interactors, and interactables you wire together in a scene. This guide walks through installation, rig setup, grab and teleport interactions, and the trade-offs enterprise teams hit in production.

Key Takeaways

• XRI 3.0 defaults to the Action-based interaction system, which routes input through Unity’s Input System package and supports remapping, multiple devices, and runtime rebinding; the Device-based system still exists for legacy projects.
• A working XR scene needs three layers: an XR Origin (the rig), interactors (ray, direct, poke, socket), and interactables (grab, teleport, UI).
• Locomotion is modular — teleport, snap turn, continuous move, climb, and grab-move are separate providers you enable or disable per project.
• For enterprise simulation and training, the biggest wins come from input remapping, haptics, and socket-based snap placement rather than from exotic interaction types.
• Test on target hardware early: XRI behaviour differs between standalone Android-based headsets and PC-tethered headsets, and between controller and hand-tracking input.

This summary serves as a high-level unity xr interaction toolkit tutorial.

What the XR Interaction Toolkit Actually Is

Unity’s XR Interaction Toolkit (XRI) is a package that provides a high-level, component-based framework for building VR and AR interactions without writing custom raycast and grab logic from scratch. XRI sits above Unity’s lower-level XR plug-in layer, so it works across OpenXR-compatible runtimes and vendor SDKs rather than locking you to one headset.

The package is distributed through the Unity Package Manager and documented in Unity’s official XRI manual, which is the authoritative reference for component APIs and version changes. This makes it a core part of any unity xr interaction toolkit tutorial.

The toolkit’s value is standardisation. Instead of every developer reimplementing “point at object, press trigger, object follows hand,” XRI defines reusable components — XR Ray Interactor, XR Direct Interactor, XR Grab Interactable, XR Socket Interactor — that interoperate. That matters for teams building training simulators, digital twins, and design review tools where the interaction layer should be boring and reliable, not bespoke.

Choosing Between Action-Based and Device-Based Input

In this unity xr interaction toolkit tutorial, we look at the two input systems. The Action-based system is the default for new XRI 3.0 projects and the one Unity recommends. It builds on the Input System package, so input is defined as actions (Select, Activate, UI Navigate) bound to controls on one or more devices. The payoff is device-agnostic input: the same “Select” action can be bound to a controller trigger, a hand pinch, or a keyboard key, and users can rebind at runtime.

The Device-based system predates this and reads input directly from specific controller types. It is simpler to reason about for a single known headset but brittle when you add a second device or want remapping. For enterprise deployments where you may ship the same build to a Varjo XR-4 on a workstation and a standalone headset in the field, Action-based input is the pragmatic choice.

Installing the Package and Configuring the Project

Package installation for this unity xr interaction toolkit tutorial happens through Window → Package Manager, searching for “XR Interaction Toolkit.” Unity’s XRI installation documentation covers the exact steps and any samples you can import. Import the Starter Assets sample — it gives you a preconfigured XR Origin, locomotion providers, and interaction prefabs that save hours of setup.

Project configuration matters as much as the package. Enable the XR Plug-in Management provider for your target platform (OpenXR is the common denominator for PC-tethered headsets; platform-specific providers handle standalone Android-based devices). If you use Action-based input, install the Input System package and set the project’s active input handling accordingly — mixing the old and new input systems is a frequent source of silent failures where interactors simply never fire.

Building the XR Origin and Rig

The XR Origin is the root of your player rig. It contains a camera offset and the camera itself, and it is the object that locomotion providers move. In XRI 3.0 the rig was reorganised compared to earlier versions, so tutorials written for XRI 2.x may reference component names that have moved. Always cross-check against the version of the package you actually have installed. This unity xr interaction toolkit tutorial assumes you are using the latest version.

A minimal rig for a controller-based VR app contains:

1. An XR Origin with the camera offset and main camera parented correctly.
2. Left and right controller GameObjects, each with an XR Controller component and an input action asset assigned.
3. Interactors on each controller — typically an XR Ray Interactor for distant objects and an XR Direct Interactor for close ones.
4. A locomotion system component on the rig, with providers for teleport and turn.

For hand tracking, you replace or supplement the controller objects with hand GameObjects and poke or direct interactors. Hand tracking changes the interaction design — pinch replaces trigger, and precision grabbing becomes harder — so plan the interaction model before committing to it.

Making Objects Grabbable

In this unity xr interaction toolkit tutorial, an object becomes grabbable by adding an XR Grab Interactable component and ensuring it has a collider and, usually, a Rigidbody. The interactable defines how it responds: whether it follows the interactor kinematically, whether it uses velocity tracking for throwing, and which interactors are allowed to grab it.

Practical caveats from production work:

• Collider size drives grab feel. A collider much larger than the visual mesh makes objects feel magnetic; much smaller and users miss grabs. Match colliders to the visual silhouette.
• Rigidbody settings interact with locomotion. Objects with heavy mass and no damping can behave unpredictably when the player teleports while holding them.
• Grab vs. attach. For tools that should lock to a hand pose (a wrench, a scanner), use attach transforms and socket-style snapping rather than free grab.
• Interaction layers. XRI uses interaction layer masks to control what can interact with what. Getting these wrong is the single most common reason “nothing happens” when you press the trigger.

Locomotion: Teleport, Snap Turn, and Continuous Move

Locomotion in XRI is a set of independent providers under a locomotion system. Teleport is the safest default for training and enterprise use because it reduces motion sickness; continuous movement feels more natural to some users but causes discomfort in others. Snap turn is generally preferred over smooth turn for the same reason. This unity xr interaction toolkit tutorial covers the providers you will commonly enable:

• Teleport — with a teleport interactor on the controller and teleport areas in the scene.
• Snap Turn — discrete rotation, comfortable and predictable.
• Continuous Move / Continuous Turn — smooth but potentially nauseating.
• Climb — for maintenance and inspection scenarios where users scale structures.
• Grab Move — pull yourself along geometry, useful in confined spaces.

A useful enterprise pattern is to expose locomotion style as a user setting rather than hard-coding it. Different users in the same organisation have different comfort thresholds, and accessibility guidance increasingly expects this configurability.

UI, Ray Interaction, and Menus

World-space UI in XR is handled by an XR UI Input Module on the EventSystem plus a canvas configured for world space. Ray interactors then drive UI like a laser pointer. The gotchas are consistent: the canvas needs a collider or a Tracked Device Graphic Raycaster, and the UI input module must be the XR one, not the default standalone module. This is a key part of any unity xr interaction toolkit tutorial.

For enterprise dashboards and control panels, consider whether UI should be diegetic (part of the 3D world, like a physical panel) or floating. Diegetic panels read as more realistic in simulation but are harder to keep legible at distance. Floating panels are easier to read but break immersion.

Testing, Performance, and Deployment Realities

Testing on the target headset early is non-negotiable. XRI behaviour can differ between standalone and tethered platforms, and between OpenXR runtimes. Frame rate is the other hard constraint: interaction raycasts, physics, and UI all cost frame time, and dropping below the headset’s target refresh rate causes discomfort. Profile on device, not in the editor.

For teams standardising hardware, the interaction layer should be treated as portable. OpenXR is the interoperability standard maintained by the Khronos Group, and building against it reduces the cost of supporting multiple headsets. Vendor-specific features — eye tracking, foveated rendering, passthrough — still require vendor SDKs, but the core grab-and-teleport layer should not. This approach is a key consideration for any unity xr interaction toolkit tutorial.

Where XRI Fits in an Enterprise XR Stack

XRI is the interaction layer, not the whole application. A typical enterprise stack layers XRI on top of OpenXR, adds a rendering pipeline (URP is common for standalone, HDRP for high-fidelity tethered work), and integrates domain logic — simulation state, data feeds, and multi-user networking.

Multi-user training adds a networking layer, and XRI’s interactables need authority handling so two users cannot fight over the same object. For those following a unity xr interaction toolkit tutorial, understanding this architecture is key.

For procurement and IT leads, the practical implication is that XRI reduces custom development cost and vendor lock-in, but it does not remove the need for device-specific testing and, in some cases, vendor SDK integration. Budget for both.

Frequently Asked Questions

Is the XR Interaction Toolkit free to use?

Yes. XRI is a free Unity package distributed through the Package Manager under Unity’s standard package licensing. Costs come from Unity’s editor licensing tiers and from any third-party assets or vendor SDKs you add, not from XRI itself.

Do I need the Input System package to use XRI?

For the Action-based interaction system, yes — it depends on Unity’s Input System package. The older Device-based system does not require it, but Unity recommends Action-based input for new projects, so most teams install the Input System package as part of setup.

What is the difference between XRI 2.x and XRI 3.0?

XRI 3.0 makes the Action-based interaction system the default and reorganises parts of the rig and component structure. Any Unity XR Interaction Toolkit tutorial written for 2.x may reference component names or hierarchies that have changed, so always check the documentation for the exact package version installed in your project.

Can I use XRI for hand tracking instead of controllers?

Yes. XRI supports hand tracking through hand GameObjects and poke or direct interactors, and Action-based input can bind the same Select action to a pinch gesture. Hand tracking changes interaction design — precision grabbing is harder and pinch replaces trigger — so plan the model before committing.

Does XRI work with HoloLens, Varjo, and standalone headsets?

XRI works across OpenXR-compatible runtimes, which covers a wide range of PC-tethered and standalone headsets. Vendor-specific capabilities such as eye tracking or passthrough still require the vendor’s SDK, but the core interaction layer remains portable across devices.

How long does it take to build a basic XRI scene?

A developer familiar with Unity can assemble a working grab-and-teleport scene in an afternoon using the Starter Assets sample. Production-ready interaction — remapping, haptics, sockets, multi-user authority, and device testing — typically takes considerably longer and should be scoped as real development work.