Scene design
Purposeful spatial storytelling.
Realtime 3D Delivery Pipeline Lab
We design Three.js experiences as delivery systems—scene ownership, quality tiers, HTML equivalents, pause when unseen, and complete resource disposal—not as random decorative WebGL.
Three.js · Technology detail
3D Experience Delivery System
Product intent through scene graph, assets, camera/lighting, interaction, render loop, quality policy, accessible fallback, and deployment monitoring—readable without WebGL.
Product intent
Define the decision the 3D view must support before adding geometry.
Scene graph
Own nodes, transforms, and stage objects with clear hierarchy.
Assets / materials
Load only needed meshes/textures; prefer progressive and lightweight payloads.
Camera / lighting
Framing and lights that clarify stages—not decorative spectacle.
Interaction
Selection and orbit with equivalent HTML controls outside the canvas.
Render loop
Hybrid demand + continuous while visible; pause when hidden/offscreen.
Quality policy
Bounded DPR and tiered geometry/effects for constrained devices.
Accessible fallback
Static pipeline explanation when WebGL is unavailable or lost.
Deployment / monitoring
Watch client errors, context loss, and payload size in production.
Textual equivalent: Product intent leads to scene graph, assets and materials, camera and lighting, interaction, render loop, quality policy, accessible fallback, then deployment and monitoring. Meaning does not require WebGL.
Capability system
Purposeful spatial storytelling.
Draw-call and memory discipline.
Raycasting and camera controls.
Static/image paths when needed.
Compression and format strategy.
Non-canvas explanations.
Illustrative flow
Stage 1 / 4
Load assets
Models, textures, materials.
Architecture view
Example system responsibility — select a layer to inspect its boundary.
Content
Assets and LODs
Illustrative spatial delivery systems—not a guaranteed catalog or benchmark claim.
Configurators and spatial previews with DOM controls and progressive assets.
Digital-twin style schematics with status panels outside the canvas.
Lazy client islands with visibility pause, DPR caps, and disposal on unmount.
A spatial pipeline of asset → material → camera → lighting → interaction → renderer → fallback. Select stages via HTML controls; canvas selection is optional and mirrored outside WebGL.
Loading Three.js delivery pipeline lab…
The WebGL island loads only in the browser. Pipeline stages and delivery-system copy on this page remain readable without the canvas.
Illustrative delivery shapes—not fabricated client outcomes or performance guarantees.
Objective: Let users preview option combinations before purchase or quote.
Scene: Hero product node with swappable materials/parts under a stable camera.
A11y: Option lists and summaries fully usable without WebGL.
Misuse: Loading every SKU mesh at route start.
Objective: Reveal relationships in spatial or layered datasets.
Scene: Grid/volume with selectable markers and a linked data table.
A11y: Sortable/filterable table mirroring visible points.
Misuse: React state every frame for particle positions.
Objective: Mirror operational state for monitoring or planning.
Scene: Schematic plant/site graph with status-linked nodes.
A11y: Status list with the same alerts as the scene.
Misuse: Photoreal assets that hide critical status labels.
Objective: Guide attention through a narrative sequence of product moments.
Scene: Ordered beats with camera bookmarks and DOM chapter list.
A11y: Full transcript/chapter text outside the canvas.
Misuse: Story that only exists inside WebGL with no copy.
Objective: Practice procedures in a safe spatial context.
Scene: Task stations with explicit success/failure states.
A11y: Checklist and instructions fully keyboard operable.
Misuse: Mandatory drag gestures with no button alternative.
Objective: Orient users in an environment or territory overview.
Scene: Terrain/extent proxy with layered overlays and legend.
A11y: Legend + feature list with the same layer states.
Misuse: Full-page canvas capturing scroll and trapping focus.
Scene ownership, renderer lifecycle, and separating business state from per-frame visuals.
One clear owner creates and disposes the graph. Avoid leaking nodes across React trees.
Create the renderer in the island mount path; dispose on unmount. No global singleton renderer.
Camera framing and lights serve comprehension. Separate cosmetic effects from required information.
Keep Three.js imports inside the lazy client island. Business state lives in React/DOM; per-frame visual state stays in the loop.
Use HTML for controls, copy, and forms. Overlay only when it clarifies—do not recreate the entire UI in WebGL.
Budget payloads early. This demonstration uses procedural geometry only—no large external models.
Budget mesh/texture size early. Compression and LODs matter more than decorative fidelity.
Show placeholders and errors. Do not block the whole page on a single model.
Version assets; configure CORS for CDN origins; invalidate caches intentionally.
Do not load every scene at route start. This demonstration uses procedural geometry only.
Qualitative guidance. Local draw-call stats in the lab describe this scene only—not device benchmarks.
Reduce unique materials/meshes; watch overdraw from transparent stacks.
Shadows and post-processing are expensive—gate them by quality tier.
Cap devicePixelRatio. Do not push React state every animation frame.
Renderer-reported draw calls/triangles describe this local scene only—not user-device performance guarantees.
The canvas is supplementary. Stage meaning, controls, and fallbacks live in HTML.
Critical copy, stage lists, and controls live in HTML. WebGL enhances—it does not own meaning.
Stage selection, quality, motion, pause, and camera reset are available as HTML controls.
Respect prefers-reduced-motion and an explicit paused mode; remove secondary motion.
WebGL failure and context loss show a controlled fallback with the same pipeline stages.
Eight Three.js-specific steps from purpose to production maintenance.
Write the decision the scene supports and the HTML equivalent first.
Define graph, pick targets, and resettable camera poses.
Budget payloads; plan placeholders and errors.
Choose DPR caps and effect gates before polishing visuals.
Mount/dispose, visibility pause, context-loss recovery path.
Keep domain state outside per-frame renderer internals.
Profile on real devices; treat local diagnostics as local only.
Watch errors, payload size, and fallback rates after release.
Lifecycle, accessibility, and performance patterns that break production 3D delivery.
Motion that does not support a product decision.
Canvas captures scroll/focus and blocks the page.
Using raw devicePixelRatio without a cap.
Shipping desktop effects to constrained devices.
Burning GPU while the tab or island is not visible.
RAF continues after unmount.
Geometry/material/texture/renderer left alive.
Accidental remounts creating competing WebGL contexts.
Reconciliation storms from per-frame setState.
Route startup downloads the entire catalog.
Blank canvas on failure.
Meaning unavailable to keyboard and assistive tech.
No button/keyboard equivalent for selection.
Continuous motion ignoring user preference.
Leaked listeners or zero-size crashes.
Unhandled webglcontextlost leaving a broken page.
Effects that cost more than they communicate.
Non-deterministic placement harming tests and comprehension.
Domain truth trapped in mesh userData alone.
Forced spin without pause or reduced-motion path.
Three.js requires explicit lifecycle and resource management. WebGL capability and performance vary by device. Static fallback and accessibility equivalents remain required. Build success is not proof of runtime rendering quality.
Treat Three.js as a lifecycle-owned subsystem: purposeful scenes, quality tiers, HTML equivalents, pause when unseen, dispose everything created, and verify on real devices.
No. Typecheck and static export success do not prove runtime rendering quality on user devices. Profile on real hardware and keep quality tiers conservative.
The lab shows a controlled non-WebGL fallback with the same pipeline stages and explanations so content remains accessible.
Unlimited DPR can multiply fill-rate cost on high-density screens. Quality tiers use bounded DPR caps appropriate to the chosen tier.
Ship Three.js as a lifecycle-owned delivery system: purposeful scenes, bounded quality, HTML equivalents, pause when unseen, and dispose everything you create. Build success does not prove runtime rendering quality on user devices.
I would like to discuss Three.js scene architecture, quality tiers, accessibility fallbacks, and lifecycle-safe WebGL delivery for our product.
Begin stack consultation