Buttons, levers, dials and grabbable things.
WebXR Interactions adds interactive objects to a WebXR scene. The interaction logic has no 3D engine code in it. You add one adapter for the engine you already use, and that adapter feeds the shared core. It is based wholly on the Reality Toolkit's interaction framework for Unity, revised for the web.
How it is built
Every Reality Toolkit WebXR family has the same shape. The logic lives in an engine-free core that carries the tests. A thin adapter binds that core to one engine, depends on it, and re-exports it, so your app installs one package. Where families need to agree on a shape, they share plain contracts rather than importing each other.
Your app
Owns the content: meshes, panels, placement, physics and sound files. Installs one adapter per family and wires families together with subscriptions in the one place where both halves are in scope.
One adapter per engine
The only place an engine name appears. It reads the engine each frame, feeds the core, applies the core's results back, and reports anything the engine cannot do instead of failing silently.
The engine-free core
All the logic, as plain TypeScript with no engine import. An architecture test fails the build the moment one lands, which is what lets the same behaviour run unchanged on every engine, and be tested without a headset.
Shared contracts
One description of input, poses and pointers, published from its own repository with zero dependencies, so an adapter written once feeds both the Interactions and UI Extensions families.
Where it sits in the stack
Four families, one rule: no package references a sibling family, not even a type. What crosses a boundary is a subscription your app makes, such as playing an Environment cue when an Interactions press fires.
The Service Framework for the web sits beside these four and keeps its own site: serviceframework.realitycollective.net. The layering rule explains the boundaries in full.
Why you would use it
Behaviours, ready made
Press with an optional latching mode, pulse, hinge, dial, slide, grab and toss-scoring for throw-and-catch games. Attach one to an object and subscribe to its events.
Targeting that does not flicker
For each hand or controller the core picks one target: the platform's own answer first, then a close touch, then a pointing ray, with a short hold on the boundary between two objects.
Capabilities that speak up
If the headset cannot do what a behaviour needs, the behaviour switches itself off and says so, rather than silently doing nothing.
Pick an adapter
Install exactly one. Each re-exports the core and the input contracts, so you never install those yourself.
three.js and raw WebXR
threejs-interactionsThe default, standalone adapter. Reads raw WebXR, adds three.js hit-testing and object movement, and a desktop mouse fallback. Presence is opt-in through registerVisual.
defaultRead more →Babylon.js
babylon-interactionsReads a WebXRDefaultExperience: controllers, motion controller trigger and grip, hand joints. Structurally typed, so no @babylonjs/core import.
not yet run on a real appRead more →Meta IWSDK
iwsdk-interactionsPasses IWSDK's own press and grab answers straight through, with native grab fulfilment and full presence control. Setup is one call: registerInteractions(world).
fullRead more →Google XR Blocks
xrblocks-interactionsMaps the XR Blocks input pipeline onto the three.js machinery. XR Blocks has no haptics and no way to hide its own hand visuals, so neither is offered.
experimentalRead more →Who does what
Read the ladder top to bottom. The middle column is the stage every engine goes through; the core owns the left, the adapter you install owns the right.
Five words you will meet
Where to next
Welcome to WebXR Interactions →Requirements, packages, use cases and a quickstart on one page.Basics →The concepts, one page per topic, in the same order as the Service Framework basics.Features →The additional capabilities that ship with the family, and the design decisions behind it.Host integrations →One page per package: the core and the adapter for each engine, with what it cannot do and why.Examples →The shipped demos and examples, broken down piece by piece.API reference →Generated from the TSDoc in every package of the family.Source and issues: GitHub. Questions go to the Reality Collective Discord.