Skip to main content
three.jsraw WebXRBabylon.jsMeta IWSDKGoogle XR Blocks
1

Pick your engine

three.js and raw WebXR, Babylon.js, Meta IWSDK or Google XR Blocks. The engine you already use.

2

Install one adapter per family

The adapter depends on its core, and on the shared input contracts where the family uses them, so npm installs those with it. It also re-exports them, so your app imports everything from the one package.

npm install @realitycollective/threejs-interactions
3

Run the playground

Every family ships a deployed demo. Open it on a headset, or on a desktop with the mouse fallback.

How it is built

Every family has the same shape, and the shape is the whole idea. The logic lives in an engine-free core that carries the tests. A thin adapter, one per engine, binds that core to three.js, Babylon.js, Meta IWSDK or Google XR Blocks. Your app installs one adapter per family and never touches the engine's input, UI or environment systems directly again.

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 and applies the results back. It depends on the core, so npm installs it, and re-exports it, so you import from one package.

The engine-free core

All the logic as plain TypeScript with no engine import. An architecture test fails the build the moment one lands. That is what lets a behaviour, a window or an environment 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. An adapter written once feeds both the Interactions and UI Extensions families.

Capabilities that report

What an engine cannot do is reported, never silent. A behaviour switches itself off and says why; a sensor answers unsupported, unavailable, pending or active.

Families never reference each other

Not a runtime import, not a type. What crosses a boundary is a subscription your app makes, such as playing an Environment cue when an Interactions press fires.

Your appcontent, physics, the wiring between familiesOne adapterthree.js · Babylon.js · IWSDK · XR BlocksEngine-free coreinteractions · ui extensions · environmentContracts@realitycollective/webxr-input · zero dependenciesArrows only point down.Read the layering rule →

The families

Family 01Released

Input

The contracts. Where a hand or controller points, what it touches, what the device can do. Zero dependencies, consumed by every other family.

@realitycollective/webxr-input

Implemented by each engine adapter

Family 02Released

Interactions

Interactables, interactors and behaviours: press, hinge, dial, slide, grab, toss-scoring, gaze dwell. Capability checks that switch a behaviour off and say why.

@realitycollective/webxr-interactions

three.js · Babylon.js · IWSDK · XR Blocks

Family 03Released

UI Extensions

Movable, dockable windows, layout regions, hand menus and controls for spatial UI, authored in UIKitML. Plus dev tooling for live editing on a headset.

@realitycollective/webxr-uiextensions

IWSDK · XR Blocks and three.js

Family 04Released

Environment

The world around the player as one document: sky, fog, light, image-based lighting, passthrough, occlusion, world sensing and the sound in it.

@realitycollective/webxr-environment

three.js · IWSDK · XR Blocks

Put it on a headset

These are the live hosts, deployed from each repository's main branch with every release. Open one on a headset, or on a desktop with the mouse fallback, then come back for how it is built. The preview builds of the development branches are listed on the Start here page.

The Service Framework for the web is the fifth member of the estate and keeps its own site: serviceframework.realitycollective.net.