Immersive Web 3D

Overview

A rotating sphere parked behind the hero text is not an immersive 3D site — it's wallpaper. The same GPU budget, spent on a scene where that sphere shatters and reforms into a torus knot as the visitor scrolls past section two, is a different piece of work entirely, and it's the one worth building.

Three axes, not one.

• Truth — would a browser actually render this? A scene built on real drei/R3F primitives (ScrollControls, useScroll, useFrame) rather than invented props or APIs that don't exist.
• Merit — is it worth watching, or generic particle-soup? Served by committing to one of the four looks (references/looks.md) and giving each section a moment worth stopping to notice.
• Time — does something change across scroll, and is the change the reason the scene exists? This is what these builds get wrong on their own: asked for "an animated 3D background," a model happily ships a shape that spins forever — technically alive, actually inert. Served by the Beat block below: if you can't name what's different at the top of a section versus the bottom, it's wallpaper, not choreography.

The Iron Law

One persistent scene. One continuous camera path. Sections are moments within it — never a hard cut between canvases.

Swapping in a fresh <Canvas> per section is the single most common way this goes wrong: it resets the WebGL context, kills any transition in flight, and reads as a page reload rather than a scene. There is exactly one <Canvas>, mounted once; every section is just a range on the same 0→1 scroll offset.

Motion budget (the same rule cinematic-video uses for camera moves): three things can move — the camera, the structures, the environment/particles. Pick two per section. Move all three at once and the GPU's coherence budget goes to the wrong place — usually frame-rate, sometimes the legibility of the DOM text sitting on top of the scene.