The sky, the fog, the light, and the sound in it.
WebXR Environment describes the world around the player, the sky, the fog and the light, and the sound in it, as plain data, and applies that description through a thin adapter for whichever engine is hosting. Every one of those is a platform facility that each host exposes differently. Content is never here: meshes, prefabs and placement belong to the app.
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.
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
An environment as one document
Sky, fog, ambient light, key light and an environment map for image-based lighting, as plain data. Name a preset, then ease to it: every slot moves together on one curve.
One owner for the background
Passthrough is a suppression on top of the one writer, not a second writer. The sky stops being drawn while the real world shows and comes back unchanged afterwards.
Sensors that admit when they do nothing
Depth occlusion, light estimation and world sensing report unsupported, unavailable, pending or active, each with a sentence saying why. Nothing fails silently.
Pick an adapter
Install exactly one. Each re-exports the core, so you never install the core yourself. A Babylon.js adapter is pending an estate-wide review.
three.js and raw WebXR
threejs-environmentA gradient sky as an equirectangular texture regenerated in place, Fog and FogExp2, an AmbientLight and a DirectionalLight, Web Audio playback, light estimation straight from WebXR.
fullRead more →Meta IWSDK
iwsdk-environmentDrives IWSDK's own DomeGradient, IBL and light components, AudioSource entities and depth occlusion. IWSDK 0.5 has no light estimation, and the adapter says so. Setup is one call: registerEnvironment(world).
fullRead more →Google XR Blocks
xrblocks-environmentThe three.js adapter plus two sensors: XR Blocks' depth occlusion and its Lighting manager for light estimation.
experimentalRead more →Babylon.js
pendingWaits on a review across all five families rather than being started here.
pendingRoadmap →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 Environment →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.