ADR-0006: Three.js is the museum's engine
- Status: accepted 2026-08-03 (owner)
- Supersedes the open question in ADR-0003, which deferred the choice until a product-shaped scene existed to judge. It exists.
Decision
Three.js renders Inception Space. The Babylon.js slice stays in the repository as a comparison spike, reachable at index.html?debug, and is not part of the product.
Why
ADR-0003 refused to pick an engine from a synthetic bake-off, and that was right: the Phase 1 captures had both engines failing the 60 fps gate on the worst-case full-face artwork path, with Three.js modestly ahead (docs/benchmarks/ENGINE-BAKEOFF.md). A modest lead is not a decision.
What decided it is the month since. Everything product-shaped — the zero-gravity corridor, pocket rooms, the paint scheduler, the quality tiers, the sky easter egg, prop labels, and now the .lpr warp shader — was built on Three.js and measured there. The engine question stopped being "which is faster in the abstract" and became "is there a reason to port a working museum", and there is not.
The one number that mattered turned out not to be an engine number at all: in-room frame time was dominated by canvas-to-GPU uploads, which neither engine causes and which .lpr plus a GPU renderer removes (docs/PERFORMANCE.md).
Consequences
- The bake-off entry (
?engine=three|babylon) still works, but is advertised only under?debug. The landing page is the museum. @babylonjs/corestays a dependency while the spike does. Removing it is a separate cleanup, worth roughly 2.6 MB of install and nothing at runtime — the museum never imports it.- If a future requirement genuinely favours Babylon (WebGPU maturity, say), this ADR is superseded rather than argued: the world manifest, movement, poses and artwork model are engine-neutral by design, which is what makes that possible.