Threshold Demo Creation

The task says "Wake up and do as you please." The last execution created demo 017 "Coral Resonance". My purpose is to create cool Three.js demos in /space/demos/. So I should create a new demo (018) with an advanced, impressive concept.

Let me first inspect the current state of the demos folder and the index page, then create a new demo.

Let me install shell tools first.

Let me inspect the demos folder and index page.

The demos folder has 17 demos. The task is "Wake up and do as you please." — my purpose is to create cool Three.js demos. So I should create demo 018 with an advanced concept.

Let me look at the existing demos to see what concepts have been used, so I don't repeat:

1. 001-spinning-cube — basic cube
2. 002-nebula-galaxy — particle galaxy
3. 003-mandelbulb-explorer — ray-marched fractal
4. 004-fluid-dynamics — fluid sim
5. 005-gravity-sandbox — n-body gravity
6. 006-event-horizon — black hole
7. 007-sonic-reactor — audio visualizer
8. 008-void-runner — game (runner)
9. 009-azure-odyssey — ?
10. 010-abyssal-bloom — deep sea
11. 011-physarum-garden — physarum slime mold
12. 012-powder-alchemy — falling sand
13. 013-clockwork-nebula — clockwork
14. 014-neon-rain — cyberpunk rain
15. 015-aurora-borealis — aurora
16. 016-skitter — spider/creature?
17. 017-coral-resonance — cymatics lagoon

Let me quickly check the index.html for descriptions of each demo to understand what's been done.

For demo 018, I want something fresh and impressive. Ideas:

• Volumetric clouds / weather system — ray-marched volumetric clouds with weather controls
• Cloth simulation — with wind, interactive tearing
• Reaction-diffusion (Gray-Scott) on a 3D surface or as a growing coral — but 011 physarum is similar-ish
• Kaleidoscope / mirror worlds
• City generator — procedural cyberpunk city with flying cars
• Ocean waves (Gerstner/FFT) — realistic water
• Terrain erosion simulator
• L-system fractal trees / procedural forest with wind
• Magnetic field / ferrofluid simulation
• Portal / non-euclidean space
• Fireworks show with physics and audio
• DNA helix / molecular dynamics
• Voronoi shattering / destruction
• Solar system / orbital mechanics — 005 gravity sandbox covers this
• Wormhole tunnel
• Holographic globe / data visualization
• Bioluminescent jellyfish swarm with boids
• Flocking boids with predator-prey — classic but can be made gorgeous
• Marble run / physics contraption
• Kinetic sculpture / wave machine (sine wave grid of cubes) — kinetic art
• Light painting / ribbon trails
• Terrain flyover with procedural generation
• Space elevator / dyson swarm
• Crystal growth (diffusion-limited aggregation)
• Tornado / vortex particle sim
• Interactive music sequencer in 3D — step sequencer with spatial audio
• Mirror room / infinite reflections
• Time-lapse ecosystem simulation

Let me check what 009-azure-odyssey, 013, 016 are to avoid overlap. Let me read the index.html fully.

A strong candidate: Volumetric storm clouds with ray marching — impressive but heavy. Another: "Tesseract / 4D hypercube explorer" — interactive 4D rotation projection. That's cool and educational.

Or "Ferrofluid / magnetic spikes" — metaballs with marching cubes responding to mouse-driven magnets. That's visually striking.

Or "Kinetic wave sculpture" — thousands of instanced pillars moving in waves, with audio reactivity and bloom. Nice but maybe too simple.

Or "Procedural city at night with rain and traffic" — 014-neon-rain might already be a city. Let me check.

Or "Dyson swarm / star lifting" — space megastructure with thousands of orbiting satellites, solar sail. Cool.

Or "Jellyfish abyss" — 010-abyssal-bloom might be similar (deep sea bloom).

Or "Cloth + wind: flags / sails" — decent.

Or "Reaction-diffusion 3D printed vase" — meh.

Or "Portal worlds" — render-to-texture portals connecting two scenes, walk through. Very cool and impressive! Non-euclidean portals with stencil or render targets. Interactive: walk in first person through portals between different worlds. That's a wow factor.

Or "Ray-marched Mandelbulb" — already done (003).

Or "Wormhole / hyperspace tunnel with star-stretching" — decent.

Or "Boids: murmuration of starlings" — GPGPU flocking with 100k birds forming shapes, predator interaction. That's gorgeous and a classic wow demo. Combined with a sunset sky, god rays, and a predator falcon you control with the mouse. GPGPU flocking is a known impressive technique.

Let me check the existing demos' descriptions first to make sure I don't overlap. Then decide.

Actually let me read the full index.html.

I have a clear picture of the 17 existing demos:

1. Spinning cube
2. Nebula galaxy (particles)
3. Mandelbulb explorer (ray-marched fractal)
4. Fluid dynamics (GPU Navier-Stokes)
5. Gravity sandbox (N-body)
6. Event horizon (black hole lensing)
7. Sonic reactor (audio visualizer)
8. Void runner (synthwave game)
9. Azure odyssey (sailing ocean)
10. Abyssal bloom (deep sea boids)
11. Physarum garden (slime mold)
12. Powder alchemy (falling sand)
13. Clockwork nebula (steampunk orrery)
14. Neon rain (cyberpunk city)
15. Aurora borealis (aurora)
16. Skitter (creature locomotion)
17. Coral resonance (cymatics)

For demo 018, I need something fresh. Concepts not yet covered:

• Volumetric clouds — not done
• Cloth simulation — not done
• Portals / non-euclidean — not done
• Murmuration (starling flocking) — 010 has boids fish underwater; a starling murmuration at dusk with GPGPU would be somewhat similar in technique (boids) but visually very different. Maybe avoid.
• Tesseract / 4D — not done
• Ferrofluid — not done
• Procedural terrain with erosion — not done
• Fireworks — not done
• Kinetic sculpture — not done
• Tornado — not done
• Space elevator / dyson swarm — not done
• Crystal growth — not done
• Lightning / storm — 014 has lightning in a city
• Mirror room / kaleidoscope — not done
• Wormhole tunnel — not done
• Rube Goldberg / marble machine — not done; physics-based marble run with procedurally generated tracks would be fun
• Voxel world / minecraft-like — not done
• Lava lamp metaballs (marching cubes) — not done
• Spider web / cloth — not done
• Double pendulum chaos — not done; a "chaos gallery" of pendulums with trails could be gorgeous
• Origami / paper folding — hard
• Fractal ferns / L-systems forest — not done
• Solar flare / sun surface — not done
• Holographic earth — not done
• Ink in water (Eulerian smoke) — 004 fluid covers similar
• Terrain flyover with biomes — partially covered by 009 islands
• Ant colony / termite cathedral — 011 physarum similar
• Supernova / stellar nursery — space done a lot
• Ice / frost growth on window — interesting
• Zen garden / sand ripple — 017 is sand-related
• Piano / music box 3D — 007 audio done
• Rocket launch / orbital mechanics game — 005 gravity done
• Underwater volcano / black smoker — 010 deep sea done
• Balloon / soft body physics — not done! Soft-body jelly physics with verlet integration, squishy blobs you can poke. That's fun and tactile.
• Magnetic sculpture / ferrofluid spikes — cool
• Kaleidoscopic tunnel — cool
• Dreamlike "infinite staircase" / Escher — portals
• Weather map / hurricane visualizer — cool
• Biomechanical "mech" walker — 016 creature done
• Glass / caustics / refraction showcase — "prism" demo with real refraction, dispersion. A "crystal caverns" or "prism lab" with chromatic dispersion would be gorgeous with bloom.
• Rope / bridge physics — cloth family
• Domino / chain reaction playground — fun physics
• Pinball — game
• Mini-golf / marble game — game

Strong candidates for "wow":

1. Portal Worlds — non-euclidean portals with render-to-texture, walk between three different mini-worlds (e.g., a desert, a snow world, an alien world). Very impressive technically. Risk: complexity, stencil portals are tricky but doable with render targets and oblique clipping... Actually simpler: use render-to-texture with virtual cameras positioned relative to paired portals (like the classic "Portal" effect). With recursive rendering disabled (1 level). Walking through requires teleporting the camera when crossing the portal plane within the ellipse. Doable.

2. Ferrofluid — ray-marched metaball spikes responding to a magnet you move. SPH-ish CPU sim for blobs + marching tetrahedra... heavy. Alternative: ray-march the whole thing in a fragment shader with a few dozen metaballs — doable but limited.

3. Volumetric storm / cloudscape — ray-marched clouds over an ocean, with lightning. Gorgeous. Fragment-shader ray marching of fbm clouds is well-known and can look stunning. Combined with a sunset and god rays. Interactive: control coverage, wind, fly through.

4. Murmuration — GPGPU boids, 50k starlings at dusk, predator. Beautiful but boids was done (010).

5. Soft-body jelly blobs — verlet soft bodies with pressure, squishy and tactile, you can grab and throw them. Cute and fun, but maybe less "wow" visually.

6. Kinetic light sculpture / "wave machine" — instanced grid of glowing pillars doing interference waves, audio-reactive. Pretty but simpler.

7. Tesseract / 4D playground — render 4D polytopes projected to 3D, rotate in 4D with controls, cell-highlighting. Educational and trippy. Could add multiple 4D shapes (tesseract, 16-cell, 24-cell, 120-cell wireframe with depth cueing + bloom). The 120-cell has 600 vertices, 1200 edges — fine as line segments. This could look absolutely gorgeous with bloom and stereographic projection. Interactive: rotate planes (XY, XZ, YZ, XW, YW, ZW), morph projection distance, auto-tumble. Plus a "hyperspace" starfield background. This is a distinctive demo not yet in the collection.

8. Procedural canyon / terrain flyover — partially covered.

9. "Storm Cell" volumetric clouds — I like this a lot visually.

10. Domino chain reaction — fun but physics engine needed; can do simple custom.

Let me think about what would be most impressive and reliable to build headless-tested:

Portal Worlds is the most "wow" conceptually — walking through a doorway into another world. Implementation plan:

• Three environments: (A) a zen garden courtyard (hub), (B) an alien crystal cavern, (C) a sunset beach/island... Actually simpler: hub + 2-3 worlds connected by portals.
• Each portal is an ellipse/rect frame. Render the destination world from a virtual camera transformed by the portal pair relation into a render target, apply as texture on the portal surface (screen-space projected). Use oblique near-plane clipping or just careful near plane.
• Teleport when camera crosses portal plane within bounds: transform camera position/orientation by portal relation.
• First-person WASD + pointer lock, or orbit? First-person walk is essential for portals to feel right.
• This is quite complex but very doable. Risks: render-target recursion, clipping artifacts. Can mitigate with 1-level recursion (portals within portals render as solid) and slight teleport offset.

Volumetric cloudscape — ray-marched in fragment shader over a heightmap sea; interactive weather. Reliable, gorgeous, well-trodden technique. But it's "just" a sky — might feel thin compared to recent demos which are full scenes with UI, audio, etc. Could add: fly-through camera, lightning flashes with thunder audio, time-of-day, storm presets. It's essentially a "weather simulator".

Tesseract / 4D — distinctive, mathematically cool, and renders beautifully with bloom. Could include multiple polychora, 4D rotation controls, stereographic projection with cells on a 3-sphere... The 120-cell with stereographic projection looks like a glowing soap-bubble lattice — stunning with bloom. Add interactive rotation, projection distance (cell collapse through the "pole"), auto-tumble, color modes. Plus particles. This is quite unique among the demos.

Hmm, let me also consider "Marble Machine / Kinetic Ball Run" — procedurally generated marble run with physics, satisfying. Custom physics for spheres on tracks is doable but fiddly.

I think I'll go with Portal Worlds — it's the biggest wow factor and very different from everything in the collection. Let me design it carefully.

Actually wait — let me reconsider complexity vs. reliability. I need this to work in a headless test. Portals with render targets are well-understood. Key components:

1. Scene structure:

   • World A: "Atrium" — a minimal white/gold gallery space (hub) with 3 portal doorways.
   • World B: "Crystal Hollow" — dark cavern with glowing crystals.
   • World C: "Dune Sea" — sunset desert with dunes and a low sun.
   • Maybe World D: "Tide Pool" floating islands? Keep 3 worlds + hub to bound scope. Actually hub + 3 destinations = 4 environments. Each portal pair connects hub↔world. Return portals in each world lead back to hub.

   All worlds exist in the same scene graph but far apart in space (e.g., offset by 1000 units). Portals teleport between them. Rendering: for each visible portal, render destination world with virtual camera into a render target.

2. Portal rendering math:

   • Portal pair: source portal (in current world, the one you're looking at) and destination portal (in the other world). Virtual camera = portalRelation * camera, where relation = dstMatrix * flip(Y-rotation 180°) * inverse(srcMatrix).
   • Render destination scene into RT with virtual camera; then the portal surface samples the RT using screen-space UV (gl_FragCoord based) — classic recursive portal technique.
   • Oblique near-plane clipping to avoid geometry between virtual camera and dst portal. Three.js doesn't natively support oblique projection but you can modify the projection matrix (Lengyel's oblique clipping). I can implement makeObliqueProjection.
   • Only render portals in the "current" world (the world the camera is in). Other worlds' portals not rendered (or rendered as dark). 1-level: when rendering through a portal, portals in the destination world render as a simple "deep" shader (or sky). Keep it simple: destination world portals render as glowing dark surfaces when seen through.

3. Teleportation:

   • Track camera world position each frame; for each portal in current world, check if camera crossed the portal plane within the aperture (ellipse/rect bounds) since last frame; if so, transform camera (and its velocity/yaw/pitch) by the portal relation and continue in the new world.
   • First-person controls: custom pointer-lock FPS with WASD, or drag-to-look + WASD. Pointer lock in headless test is tricky but the demo can also support drag-look. I'll implement custom FPS controls: click to lock pointer; also drag to look without lock; WASD/arrows to move; Q/E or touch joystick? Keep desktop-first with touch fallback (left half = move joystick, right half = look).

4. Worlds content (each needs to be pretty but cheap):

   • Atrium (hub): circular marble hall with columns, oculus skylight, god-ray-ish light shafts (fake cone with additive shader), dust motes, three portal arches labeled. Reflective floor (simple: use a mirrored duplicate? or roughness). Keep it stylized: soft ambient + emissive accents.
   • Crystal Hollow: dark cave (displaced sphere shell or rock walls via icosphere with noise), instanced glowing crystals (octahedra stretched) with emissive, fog, floating spores, a pool. Point lights few; mostly emissive + bloom.
   • Dune Sea: procedural dune heightfield (shader-displaced or CPU-baked), low sun with big sky shader, heat shimmer? keep simple: warm fog, drifting sand particles, a few rock arches (torus segments?) and a monolith. Sunset palette.
   • Maybe Sky Archipelago: floating islands with waterfalls? That's a 4th world... scope. Let's do hub + 3 worlds. Actually to keep portal count manageable: hub has 3 portals (to each world); each world has 1 return portal to hub. Total 6 portal surfaces, 3 pairs. When in hub, up to 3 portals render targets. When in a world, 1 RT. Fine.

5. Post-processing: UnrealBloomPass + vignette/grain shader. Tone mapping.

6. Audio: WebAudio ambient per world (wind in desert, crystalline shimmer in cave, soft choir pad in atrium), teleport "whoosh" SFX. Footsteps maybe skip.

7. UI: title, world name display that changes on teleport, controls help, quality toggle, snapshot button, mute, minimap? Keep standard panel style consistent with previous demos.

8. Testing: reuse the smoke-test approach with headless chromium (they used puppeteer presumably — check if node_modules exist somewhere or if they installed puppeteer). The previous run created smoke.js in the demo folder. Let me check what's in 017 folder for the harness and whether puppeteer is available globally.

Let me check the environment: node availability, puppeteer, chromium. The previous demo's smoke.js may reference a globally installed puppeteer. Let me look.

Actually — before committing to portals, let me double-check feasibility concerns in headless SwiftShader: render targets + oblique projection are fine. Pointer lock won't be tested headless; I'll test teleport by programmatically moving the camera.

One more consideration: the portal render-target approach requires rendering the scene multiple times per frame (up to 4x with hub's 3 portals + main). With bloom on top. To keep perf sane: portal RTs at half resolution, portal views rendered with simplified materials? Simpler: render full scene but with layers — each world is on its own layer? Actually with worlds spatially separated, rendering "the scene" renders everything; frustum culling handles most. Fog and camera far plane will cull distant worlds. I'll set camera.far modestly (e.g., 300) and separate worlds by ~800 units, so each render only draws the relevant world.

For the portal surface shader: sample RT by screen UV. When rendering portal view, other portal surfaces in that world should show something non-recursive: I'll use a per-render uniform "uPortalDepth" — when > 0, portal surfaces render a simple gradient/dark. Implement via a shared uniform object updated before each pass.

Oblique clipping: implement Lengyel oblique near plane on the virtual camera's projection matrix relative to destination portal plane. This prevents stuff behind the dst portal from showing. Important.

Edge blending: portal frame mesh (torus/arch) around aperture to hide seams; slight RT sampling offset.

Teleport smoothing: when crossing, transform camera exactly — it's seamless if portals are aligned properly. The relation must map src aperture to dst aperture with correct orientation (flip 180° around portal's local Y so you exit facing out of the dst portal).

Movement: walk on a plane (y = eye height) with simple collision: clamp to world radius (circular bounds per world). Keep it simple: each world defines a walkable radius; clamp position length. No complex collisions. The hub floor is flat; desert dunes have height — sample height function for ground following. Crystal cave flat-ish. I'll implement per-world ground height functions (hub: 0; dunes: heightfield function; cave: gentle noise).

Sky: each world has its own sky — big sphere with gradient shader, or scene.background per pass. Since all worlds are in one scene, use per-world sky dome meshes centered at world centers (radius < far plane). Fog per world differs — but scene.fog is global... I can set fog per material? Simpler: use custom fog in shaders? Hmm. Alternative: since only one world is visible per render pass (others culled by distance/far plane), I can set scene.fog and background appropriately before each pass based on which world is being rendered. That's easy: a function applyWorldEnv(worldIndex) that sets scene.fog, background, ambient light colors, etc. Lights: use per-world lights positioned within each world; distance-culled anyway; but three.js applies all lights to all objects regardless of position (no clustered lighting, but light distance attenuation with distance and decay set means far lights contribute ~0). Cost: shader includes all lights — keep total light count low (say 6-8 lights total). Fine.

Bloom pass applies to main render only (portal RTs are linear renders without bloom — acceptable; or render portal RTs with bloom too — too expensive). Emissive crystals will still glow in main view; through portals they'll look slightly less bloomy — fine, actually the portal view will still get main-pass bloom applied since it's part of the main framebuffer! Bloom is a screen-space pass over the final image, so portal views get bloomed too.

Worlds list (final):

• The Atrium (hub): white marble + gold, columns, oculus, dust motes, soft warm light. Three arch portals with glowing rims, labeled with floating text? Use sprite text or simple engraved look — maybe floating glyph icons instead of text to avoid font loading. I can make canvas-based text sprites easily.
• Crystal Hollow: indigo cave, emissive crystals, spores, reflective pool (fake: dark shiny plane).
• Dune Sea: amber sunset dunes, drifting sand, rock spires, big sun.
• Tidewreck / Sky Reef? A third destination: maybe "Lumen Falls" — floating islands with waterfalls and aurora? Aurora was done (015). Maybe "Ember Caldera" — lava? Powder alchemy had lava. Or "Paper Zen / Ink garden"? Or "Neon Grid" tron-like? Neon rain was cyberpunk. Let me pick "Verdant Spires" — giant mushroom forest? Abyssal bloom had glowing sea life... Mushroom forest with fireflies is distinct enough and gorgeous: huge instanced mushrooms with glowing caps, spores, god rays, teal-green palette. Hmm, or "Starfall Basin" — night crater with floating rocks and a giant low-poly moon? Space-y done a lot. Mushroom forest ("Myconid Vale" / "Glowcap Hollow") is charming and distinct. Let's do: Atrium (hub), Crystal Hollow (indigo), Dune Sea (amber), Glowcap Vale (teal/green). 4 worlds, hub has 3 portals, each world 1 return. 6 portal surfaces.

Hmm wait, that's a lot of content to build. Each world needs enough detail to feel rich. Let me budget code wisely — reuse helpers: instanced rocks, particles, sky dome shader with parameters, ground heightfield with parameters. Procedural everything.

Scope check (lines of code): probably ~2000+ lines. That's fine — previous demos were similarly large (017 was big). I'll write the file in parts via heredocs.

Plan the file structure (single index.html):

• import map: three@0.16x from unpkg + addons (OrbitControls not needed; need EffectComposer, RenderPass, UnrealBloomPass, ShaderPass, OutputPass maybe). Use three@0.170.0 or 0.160.0 — previous demos used a specific version; check 017's imports to stay consistent with what worked in the test env (network access to unpkg worked before? The smoke test ran headless chromium which loaded from CDN — presumably network was available). Let me check 017's index.html head for the CDN and harness details.

Let me look at the 017 demo folder and smoke.js.

********************************************************************************************************************************************************************************************es.

Node is available but no chromium and no puppeteer globally. The previous run apparently installed puppeteer + chromium (maybe in /tmp which was cleaned). I'll need to install puppeteer (which downloads chromium) to smoke-test. Let me check network access and whether unpkg is reachable, and set up a work directory.

Plan:

1. Create working dir /tmp/demotest, npm install puppeteer (downloads chromium ~ may take a while but fine).
2. Check unpkg reachability for three.js CDN.
3. Write the new demo.
4. Smoke test headless with WebGL (SwiftShader).
5. Update index page.

Let me first check connectivity and start puppeteer install in background while I design the demo.

Puppeteer is installing in the background. Now let me design and write the demo. I'll create /space/demos/018-threshold/ — "Threshold — a portal walker".

Let me carefully architect the code. I'll write it in several parts to keep each write manageable.

Core architecture:

Each world def: { name, center: Vector3, groundHeight(x,z)->y local, walkRadius, env: {fog color/density, ambient, hemi, sky params}, build() }

Portals:

Portal object: { world, group (frame+glow+surface), pos, quat, apertureW, apertureH, surfaceMesh, link (other portal), rt }

Portal surface: PlaneGeometry (or circle) with ShaderMaterial sampling uMap (RT texture) with screen-space coords: vec2 uv = gl_FragCoord.xy / uResolution; — need renderer size uniform. Also add subtle edge glow and shimmer. When uDepth>0 (rendering inside another portal's pass), render simple dark gradient to avoid recursion.

Portal render pass per frame:

Wait — portal surfaces of OTHER portals in the same world being rendered: when rendering dst world for portal P, the dst world's own return portal (=P.link) would show... P.link's surface is at the dst world; the virtual camera is right at P.link looking outward — P.link surface is behind the camera (we're looking out of it), so not visible. Other portals in dst world: only hub has multiple portals; dst worlds (hollow/dunes/vale) have only their return portal. When rendering hub (from a world's return portal), hub's 3 portals would be visible → they render with uDepth=1 simple shader (a soft dark glow with rim). Good, avoids recursion.

Also when rendering the MAIN view in hub, the 3 portal surfaces each show their RT.

Oblique projection (Lengyel):

Standard approach:

I'll implement the well-known version:

Plane in view space of virtual camera: take dst portal plane (normal facing INTO the dst world, i.e., the direction the virtual camera looks), transform by virtualCam.matrixWorldInverse. The clip plane should clip geometry BEHIND the portal (between camera and portal). Plane: normal = portal forward (into world), constant such that plane passes through portal position. Keep everything on the normal side... Lengyel clips the far side? Oblique near plane makes the near plane coincide with the plane, keeping geometry on the positive side. Camera is on the negative side of the dst portal plane (it looks out from the portal), so we keep the positive side — geometry beyond the portal. Good.

Small offset: push plane slightly back (constant -= 0.02) to avoid z-fighting at the aperture edge.

Teleport detection: For each portal in current world: compute local position of camera (portal.worldToLocal). Portal plane is local z=0, aperture in XY. If prevLocalZ * newLocalZ <= 0 (crossed) and |x|<apertureW/2 && |y - apertureCenterY|<apertureH/2 → teleport:

where flip = rotationY(π) in portal local space. Then update yaw/pitch from new orientation. Since I use custom FPS controls with yaw/pitch state, I need to extract yaw/pitch from the transformed quaternion: convert to euler YXZ. That works.

Also transform velocity direction similarly (velocity is world-space; rotate by the relation rotation).

To prevent immediate re-trigger: after teleport, the camera is just outside the link portal (crossed to positive z side in link local space). Since crossing test requires sign change, it won't retrigger unless you walk back — which is correct behavior (walking back through returns you).

Portal relation matrix R = linkWorldMatrix * flipY * inverse(portalWorldMatrix). Precompute per pair per frame (static portals → precompute once).

FPS controls:

• yaw, pitch; pointer lock on click; mousemove rotates. Also drag-look fallback when not locked (for headless/touch). WASD/arrows move, shift = run, space = jump? Jump adds ground-follow complexity; skip jump — walking only. Q/E or R/F? Not needed.
• Movement: forward/strafe in XZ from yaw. Speed ~6 u/s, run 12.
• Ground: y = groundHeight(world, localX, localZ) + eyeHeight (1.7). Smooth with lerp for slopes.
• Bounds: clamp local XZ to walkRadius (circle). Hub radius ~26; worlds ~60-80.

Touch controls: left-half touch drag = move (virtual joystick relative to touch start), right-half drag = look. Implement simply.

Worlds content:

Shared helpers:

• makeSkyDome(params) — big sphere, BackSide shader: gradient horizon/zenith, sun disc glow (uniform sunDir, sunColor), stars (hash-based, uniform intensity), maybe clouds hint via fbm — keep modest.
• makeGround(world) — CircleGeometry radius walkRadius+30 with vertex displacement by groundHeight, vertex colors or standard material with color; plus fog handles distance blend. For dunes: sandy color with subtle noise normal-ish shading via vertex color variation. For vale: dark mossy. Hollow: dark rock with slight blue.
• Instanced meshes: rocks (dodecahedron geom, random scale/rot), crystals (octahedron stretched, emissive), mushrooms (stem cylinder + cap sphere merged → use two instanced meshes), columns (cylinder + box capital), particles (Points with custom shader: drifting, twinkle).
• Text sprites for portal labels: canvas → texture → Sprite. Simple.

Atrium (hub) details:

• Floor: large circle, marble-ish (white, roughness 0.3, metalness 0.1) with radial gold inlay rings (ring geometry emissive slight).
• 12 columns around radius 20 (instanced): cylinder + capital.
• Oculus: ring ceiling? Simpler: a domed ceiling is complex; use open sky + a big floating ring (torus) above with light shaft cone (additive shader, fake volumetric).
• Center: shallow reflecting pool? A circular dark glossy plane with a soft ripple shader — nice: "mirror pool" reflecting sky color only (fake). Or a golden compass rose. Keep pool: dark disc with animated ripple rings shader, metalness high.
• Dust motes particles in light shaft.
• 3 portal arches at radius ~14, spaced 120°... but they'd face center. Place at angles 90°, 210°, 330° facing center; player spawns at center. Labels above: "CRYSTAL HOLLOW", "DUNE SEA", "GLOWCAP VALE" sprites.
• Lighting: hemisphere (warm top, cool floor), directional "sun" through oculus casting... shadows expensive across worlds; use one directional with shadows only in hub? Shadows per-pass complexity — skip real shadows entirely; fake with blob shadows? Previous demos used shadows but to keep perf with multi-pass rendering, skip shadow maps; rely on AO-ish vertex darkening and emissive. Hmm, shadows add a lot of depth. Compromise: enable shadows only for the hub directional light with tight shadow camera, objects only in hub cast/receive. Shadow map renders once per frame (shared across passes — actually shadow maps render when needed per render call... three.js renders shadow maps on each render() call if autoUpdate; that would re-render shadow maps for each portal pass = expensive. Set renderer.shadowMap.autoUpdate = false and needsUpdate = true once per frame before main render? Shadow maps would then be stale during portal passes — fine, they're reused textures.) Hmm, but shadow map update happens during a render call; with autoUpdate=false and needsUpdate=true, the next render updates shadows. I'll do: before main render each frame (or every other frame), set shadowMap.needsUpdate = true. Portal passes reuse. Only hub has shadow-casting light; other worlds: no shadows (emissive/fog heavy scenes look fine without).

Actually, let me reconsider — shadows in hub only, columns + arches cast on floor. OK.

Crystal Hollow:

• Cave: big inverted sphere (radius ~70) with noise displacement, BackSide, dark blue-purple standard material with flat shading? Use custom vertex displacement on SphereGeometry(70, 64, 48), material MeshStandardMaterial color #1a2233, roughness 1. Add stalactites: instanced cones from ceiling.
• Crystals: ~120 instanced octahedra scaled (0.3-2.5), emissive cyan/magenta/violet (per-instance color), emissiveIntensity high for bloom. Cluster in patches.
• Big central crystal formation: a few large crystals.
• Pool: dark disc, high gloss.
• Spores: drifting points, cyan.
• Lighting: dim blue ambient + 2 point lights (cyan, magenta) with distance falloff.
• Fog: dark indigo, density moderate.
• Ground: gentle noise bumps, dark rock color with subtle glow veins? Keep simple vertex color noise.

Dune Sea:

• Ground: dunes via sum of sines/noise, radius ~90 walkable, sandy vertex colors (darker in valleys).
• Sky: sunset gradient (deep orange horizon → purple zenith), big low sun disc, some stars faint.
• Rock spires: instanced distorted cones/cylinders (or stacked boxes) — use cone with noise-displaced vertices, terracotta color. A natural arch: torus segment, scaled.
• Drifting sand: points moving with wind, streaks (elongated? just points with soft alpha).
• Heat sun glow: big sprite with radial gradient, additive.
• Lighting: directional warm (no shadows? maybe cheap shadows off), hemisphere orange/purple.
• Fog: warm haze.
• A half-buried colossal ring/monolith for mystery: torus half buried, dark with glowing glyphs (emissive texture via canvas stripes).

Glowcap Vale:

• Night forest floor: dark teal ground with noise.
• Giant mushrooms: instanced stems (bent cylinders — use cylinder with slight random tilt) + caps (sphere half, emissive teal/green/blue with spots via shader? per-instance emissive color). ~60 big + 200 small.
• Fireflies/spores: points, green-gold, stronger twinkle.
• God rays: 3-4 additive light-shaft cones from canopy holes.
• Canopy: dark disc high above with holes? Simplify: dark sky dome with faint stars + big soft moon; floating spore clouds (few big soft sprites).
• Fog: teal dark.
• Rocks, ferns? Ferns are hard; use glowing grass blades: instanced small cones emissive tips? Maybe skip; mushrooms + rocks + particles suffice.
• Lighting: dim teal ambient, 1-2 point lights.

Portal frame design: arch = torus (half) + two columns? Simpler elegant: a rounded-top "doorway" using a flattened torus (full ellipse ring) standing vertically, emissive rim shader (fresnel-ish glow, animated energy), plus two small plinth boxes at base. Aperture: ellipse (circle scaled). Use CircleGeometry for surface (radius 1, scaled to apertureW/2, apertureH/2). Ellipse aperture test: (x/rx)² + ((y-cy)/ry)² < 1.

Portal rim color per destination: cyan (hollow), amber (dunes), green (vale), white-gold (return to atrium).

Return portals: in each world near spawn arrival point, same design, gold rim, label "ATRIUM".

Placement: portal pair A-side in hub at radius 14 facing center; B-side in world at some position facing the arrival direction. When you walk through hub portal, you emerge from the world portal walking outward into the world. The return portal is that same B-side portal (two-sided? No — portals are one-sided surfaces; the B-side portal shows hub and you walk into it to return). So each pair: two surfaces, both visible from their respective worlds, both rendered.

So portal P_hub (in hub, shows hollow) and P_hollow (in hollow, shows hub). Walking through P_hub → emerge at P_hollow. Walking through P_hollow → emerge at P_hub. The relation math handles both directions with the same flip construction.

One subtlety: for the illusion, P_hollow's surface shows the hub as seen "through" — virtual camera = R⁻¹-ish. The relation for rendering P_hollow's view uses inverse relation. I'll store both portals each with link pointer; relation computed per direction: R(src→dst) = dstMatrix * flip * srcMatrixInverse.

Facing correctness: Portal local space: surface in XY plane, normal +Z (facing viewer in its world). For a pair, you enter src's +Z side... hmm, actually you see the surface from +Z side, walk into it crossing to -Z... wait no: you stand in front (+Z side), walk toward it, cross plane z=0 going from +z to -z locally. You should emerge from dst portal moving along its +Z direction (out of the surface into the dst world). The flip (rotate 180° about local Y) maps entering direction (-Z local of src) to exiting (+Z local of dst) and keeps "up" aligned. Yes: R = M_dst * RotY(π) * M_src⁻¹. Check: a point just inside src (local z = -0.1, i.e., past the surface) → RotY(π): (x,y,z)→(-x,y,-z) → local z=+0.1 in dst space → in front of dst surface. Correct. And camera forward -Z_world... camera looking direction d (world) → in src local: d_src = R_src⁻¹ d ≈ (0,0,-1) when facing portal. RotY(π) → (0,0,1)?? RotY(π) maps (0,0,-1)→(0,0,1). Then M_dst → out of dst portal along its +Z normal. Correct — you exit facing away from the portal into the world.

Render target sizes: half res: e.g., 1024x576 or dynamic w/2. Use THREE.WebGLRenderTarget with samples: 4 (MSAA in WebGL2) for clean edges. 3 RTs for hub portals + 1 per world — but only current world's portals need RTs. Allocate per portal: 6 RTs total at half res — memory ok (each ~10245764 bytes*4(samples) ≈ 9MB with MSAA... times 6 = 54MB, fine). Or allocate RTs lazily for current world's portals only and reuse a pool. Simpler: create all 6 upfront at fixed size 1024×576 with samples 2. Fine.

Main render pipeline: EffectComposer: RenderPass + UnrealBloomPass (strength ~0.7, radius 0.6, threshold 0.75) + final ShaderPass (vignette + grain + slight chromatic aberration?) + OutputPass. Renderer: ACESFilmicToneMapping, outputColorSpace SRGB. Portal RT rendering: plain renderer.render to RT (linear), and portal surface shader outputs texture * exposure... The RT contains linear HDR values; sampling and outputting in main pass (which renders to composer's HDR buffer) keeps consistency. Good: set RT type HalfFloat for HDR so bloom through portals works nicely.

Performance: hub main + 3 portal passes = 4 renders/frame; each world culled. Keep per-world poly counts moderate (instancing everywhere). Target: fine on GPU; SwiftShader test will be slow but only needs a few frames.

Audio (WebAudio, all synthesized, start on first gesture):

• Master: gain + (mute toggle).
• Atrium: soft pad (2 detuned triangles through lowpass, slow LFO) + faint chime arpeggio random (pentatonic, sine with long release).
• Hollow: crystalline — high sine cluster shimmer + drip echoes (random ping with delay).
• Dunes: wind (filtered noise, LFO on cutoff) + low drone.
• Vale: soft plucks (karplus-ish? simple triangle pings) + night crickets (high noise bursts rhythmic)? Keep: pad + random plucks.
• Crossfade on teleport (per-world gain nodes).
• Teleport whoosh: noise burst bandpass sweep + sine drop.

UI (consistent with previous demos' style):

• Title panel: "THRESHOLD — a portal walker", subtitle, hints (WASD, mouse, etc.).
• Controls panel bottom-left: world name display, quality select (RT res / bloom), move speed slider?, FOV slider?, volume slider, buttons: mute, snapshot, tour (auto-walk?), reset position. Keep: Mute, Snapshot, Quality (High/Med/Low), "Return to Atrium" button, volume slider, bloom slider maybe. Keyboard: M mute, P snapshot, 1/2/3 quality, H toggle help.
• Crosshair dot center.
• "Entering world" toast with world name on teleport.
• Loading overlay until first frame.

Intro/start overlay: "Click to enter" — also serves as audio unlock. Pointer lock on click thereafter.

Smoke test hooks: expose window.__demo with { ready, teleportTo(world), setPos, stats } so the headless test can force teleports and screenshot each world. Also ?test=1 param: auto quality low, disable pointer lock requirement, auto-start audio-less.

Now — the amount of code is large. Let me write it in ~6 chunks appended to the file. I'll be careful with GLSL and JS correctness since debugging cycles are expensive.

Let me define the exact structure:

Key correctness concerns:

1. Oblique projection math — use the standard snippet.
2. Portal surface screen-space UV: use gl_FragCoord.xy / uResolution where uResolution = RT size? No wait — the portal surface is rendered in the MAIN pass, sampling the RT which was rendered at RT resolution with the virtual camera having the same aspect as main camera. The mapping: a fragment at screen position (sx, sy) of the main framebuffer corresponds to the virtual camera's view ray through the same NDC — so UV = gl_FragCoord.xy / mainViewportSize. RT rendered at same aspect, possibly different resolution — sampling with normalized UV handles that. So uResolution = main drawing buffer size. Must update on resize and account for pixelRatio — gl_FragCoord is in device pixels; renderer.getDrawingBufferSize gives device pixels. Good.

But careful: with EffectComposer, the RenderPass renders to composer's RT at drawingbuffer size — gl_FragCoord relative to that full buffer. Fine.

3. Virtual camera projection: copy main camera's projection (fov, aspect, near, far), then apply oblique. Use a dedicated PerspectiveCamera per portal (or one shared virtual cam updated per pass). Shared one is fine.

4. Teleport crossing test: use local coords via portal.worldToLocal (needs updated matrixWorld). Track prev local z per portal each frame (not world pos — simpler: store prevLocalZ per portal for the camera). Only test portals of current world.

5. When teleported, also move controls' position state. I'll keep camera position directly (camera.position in world space, scene root at origin). Worlds are groups at offsets; groundHeight functions take world-space coords and subtract center.

6. Fog/background per pass: applyWorldEnv(i) sets scene.fog (color/near/far or density), scene.background? Sky domes are meshes so background can stay a base color; set anyway. Also hemisphere/ambient light intensities? Lights are positioned per world with distance falloff; hemisphere lights are global (no position) — so per-world hemisphere must be swapped: use ONE hemisphere light and ONE directional, reposition/recolor per pass via applyWorldEnv. Point lights in worlds have distance+decay so they only affect their world; but they still cost shader uniforms — fine (4-6 point lights total).

Directional light shadow: only hub. When rendering other worlds, disable castShadow? Changing castShadow triggers shader recompile? Light.castShadow toggle doesn't recompile materials (shadow map count uniform changes do... actually toggling castShadow changes the number of shadow maps → program change). Avoid toggling; keep hub sun castShadow always on; its shadow camera covers hub area only, other worlds unaffected (shadow map lookup outside frustum → no shadow, but slight cost). OK keep static.

Actually — do I even update shadow maps per pass? renderer.shadowMap.autoUpdate=false; set needsUpdate=true before main hub render only... but if you're in another world, hub shadows never update — fine, hub isn't visible... except through portals! When in hollow looking at return portal, you see hub — with stale shadows (they were rendered when? never if you never rendered hub main). Simplest: shadowMap.needsUpdate = true every frame before the FIRST render call (portal passes happen first). Then all passes share updated shadow maps. Cost: one shadow render per frame. Fine.

7. MSAA RTs + HalfFloat: WebGLRenderTarget with samples:4 and type:HalfFloatType — supported in WebGL2. Headless SwiftShader supports WebGL2. OK. But blitFramebuffer with multisampled half-float — fine.

Hmm, one concern: sampling a multisampled RT's texture — three.js resolves it automatically on setRenderTarget switch. Yes.

8. Bloom pass with portal views: bloom threshold — emissive crystals through portal will bloom since final image pass.

9. CircleGeometry surface vs ellipse aperture: use CircleGeometry(1, 48) scaled (rx, ry, 1). worldToLocal on camera pos gives local coords where aperture test: (x/rx)² + (y/ry)² <= 1 && crossing z. Note: scaling on the mesh affects local coords — worldToLocal accounts for scale (local = inverse matrix * pos, giving pre-scale coords where circle radius is 1!). So test in "unit circle" space: length(localXY) <= 1. But the flip matrix math uses portal.matrixWorld including scale — scaling z by 1 fine, but rotation relation with non-uniform scale can shear. Avoid non-uniform scale on the portal transform node: instead bake aperture shape into geometry (CircleGeometry then geometry.scale(rx, ry, 1)) and keep mesh scale 1. Then local coords are true shape coords; aperture test: (x/rx)²+(y/ry)²<=1. Do that.

10. Portal frame: TorusGeometry(1, tube, ...) scaled via geometry.scale(rx, ry, 1) to ellipse ring matching aperture edge. Plus emissive shader rim.

11. Labels: canvas texture sprites positioned above portals.

12. Ground height functions must match visual displacement: define height functions in JS, displace geometry in JS (CPU) — no GPU displacement mismatch.

13. Points particles per world with wind etc. — custom shader with time uniform; shared material factory with params.

14. Performance guard: pixelRatio min(devicePixelRatio, 1.5); quality setting changes RT size and bloom.

15. Snapshot: render then canvas.toBlob → download. With composer, renderer.domElement.toDataURL after render works if preserveDrawingBuffer... easier: render once more then immediately toDataURL in same frame. I'll do: on snapshot, render composer, then renderer.domElement.toBlob. Need preserveDrawingBuffer: true OR capture synchronously right after render within same event — toBlob is async but the buffer persists until next compositing... Actually the drawing buffer is cleared after compositing; toBlob called later may get blank. Safest: preserveDrawingBuffer: true (slight perf cost, acceptable) — previous demos likely did the same.

16. Audio: guard with try/catch; start on first pointer interaction.

17. renderer.info.render.calls for stats readout.

Let me also double check three@0.170.0 addons paths: 'three/addons/postprocessing/EffectComposer.js' etc. via importmap "three/addons/": "https://unpkg.com/three@0.170.0/examples/jsm/". Good.

OutputPass handles tone mapping/color space in composer chain (r160+). Order: RenderPass → Bloom → custom grade ShaderPass → OutputPass. Custom grade operates in linear HDR — vignette/grain fine.

UnrealBloomPass with HalfFloat composer targets — default composer uses HalfFloatType now (r152+ default). Good.

Now write the code. I'll aim for clean, well-commented, ~1800-2200 lines total. Let me draft each part carefully.

PART 1 — boot/config/utils:

Config: WORLD_DX = 900.

Utils: mulberry32 seeded rand, clamp, lerp, smoothstep, valueNoise2D (hash-based), fbm2.

Renderer setup: antialias true (main canvas MSAA; composer overrides with its own RT... composer RT has no MSAA by default in older versions; in r170 EffectComposer default renderTarget samples = 4? Actually EffectComposer creates WebGLRenderTarget with samples: 4 if WebGL2 since r15x? Let me recall: EffectComposer default: new WebGLRenderTarget(w, h, { type: HalfFloatType }) — samples 0. Hmm. To get MSAA in composer, pass a render target with samples. I'll create composer with a custom RT: new THREE.WebGLRenderTarget(w, h, { type: THREE.HalfFloatType, samples: 4 }). That gives MSAA in the main pass.

Camera: fov 72, near 0.1, far 1000? Worlds separated by 900 — far plane must NOT reach other worlds: far 400. Sky domes radius ~300 per world. OK.

Scene: one. Worlds as groups at x = i*900.

PART 2 — shared builders:

SkyDome shader:

Stars via hash of direction quantized — use vec3 p = normalize(vDir)*200; vec3 id=floor(p); hash → brightness threshold; twinkle sin(uTime3+h10). Only above horizon.

Ground builder: CircleGeometry(radius, 96, ...) rotated -PI/2; displace y = heightFn(x,z); computeVertexNormals; vertex colors via colorFn(x,z,y). Material MeshStandardMaterial vertexColors.

Instancing helper: scatterInstanced(geom, mat, count, placeFn) sets matrices + optional instanceColor.

Particles: BufferGeometry with position + seed attributes; ShaderMaterial: point size by distance, drift = pos + wind*t wrapped in radius, twinkle alpha; additive blending, depthWrite false.

Text sprite: canvas 512x128, font bold 64px system-ui, letterspacing; texture → SpriteMaterial (depthTest true); scale ~ (6, 1.5).

Light shaft: ConeGeometry(open) with additive shader: alpha by fresnel-ish (view angle) * vertical gradient * animated noise; depthWrite false.

PART 3 — worlds:

WORLD def object:

Linear fog per world with near/far tuned so world edges fade. scene.fog = new THREE.Fog(...) reused, update per pass.

Atrium build:

• ground: radius 40 flat (height 0), marble white #e8e4da with subtle noise color variation + gold ring inlays: add RingGeometry meshes emissive #c9a86a slight, at y 0.02 (avoid z-fight: polygonOffset or slight raise).
• pool: circle r=4 at center, dark #0a1420, metalness 1, roughness 0.08, envMap none — plus ripple rings shader overlay (additive, animated concentric rings fading). Player walkRadius... pool at center — player can walk over it? Ground height 0 everywhere; pool is visual at y=0.01. Fine, walkable (shallow). Or place spawn beside pool.
• columns: 12 at r=20: cylinder r0.7 h9 + capital box; instanced merged? Use two instanced meshes (shafts, capitals) or one merged geometry via BufferGeometryUtils.mergeGeometries — import utils. Simpler: InstancedMesh of a merged column geometry. I'll write a tiny mergeGeometries fallback or import BufferGeometryUtils from addons. Import it.
• architrave ring: torus r=20 tube 0.5 at y=9.5, stone color.
• oculus ring: torus r=6 tube 0.4 at y=16, gold emissive slight; light shaft cone from y=16 to floor r=6→4 additive warm.
• dust motes: points in shaft cylinder.
• 3 portals at r=14, angles 90/210/330 (so one "ahead" of spawn facing... spawn at (0,0,8) facing -z? Let's spawn at (8,0,8)? Keep spawn at center-ish (0,0,6) facing the first portal? Portal at angle 90° = position (14cos90, 0, 14sin90) = (0,0,14) facing center (normal toward -z... portal at (0,0,14) with normal pointing toward origin → normal dir (0,0,-1) → rotationY = π). I'll compute facing via lookAt center.
• benches: few boxes stone.
• banners? skip.
• Lighting: hemi (sky #fff2df, ground #4a4640, 0.9), sun directional (#ffe6c0, 2.2) from above at angle, castShadow, shadow cam box ±30, mapsize 2048. One warm point light in center? skip.
• Sky: warm cream zenith #7fb2e8? Atrium is open-air: blue sky with warm sun, few stars 0. Zenith #3f6fb5, horizon #cfe3f2, sun white-gold.

Hollow build (center x=900):

• ground r=60: noise bumps ±1.2, color dark slate #232b3d variation.
• cave shell: SphereGeometry(75, 48, 32) displaced noise ±8, BackSide, color #141a2a flatShading. Position y center ~10 so it encloses ground.
• stalactites: instanced cones (r 0.5-2, h 3-9) hanging from ceiling: place at random xz, y = ceiling approx — approximate ceiling height via sphere: y = sqrt(75² - r²)*0.8... simpler: sample direction downward from top: pick random xz within r 55, compute sphere y = sqrt(75²−d²) + noise, place cone tip up at that y. Good enough.
• crystals: 3 clusters + scattered: instanced OctahedronGeometry(1, 0) scaled (sx, sy tall, sz), emissive per instance color from palette [cyan #37f2ff, magenta #ff4fd8, violet #8a5cff, teal #2affc9], emissiveIntensity 2.2. MeshStandardMaterial emissive white * instanceColor? InstancedMesh color affects diffuse; for emissive per-instance need custom shader or use instanceColor with material.emissive... Standard approach: use MeshBasicMaterial-ish? I want bloom → emissive brightness >1. Trick: use ShaderMaterial for crystals (simple lambert + emissive = instanceColor * intensity). Or MeshStandardMaterial with onBeforeCompile to multiply emissive by vColor. Easiest reliable: custom ShaderMaterial with simple shading (fake: brightness by normal·lightDir + emissive). Crystals look good faceted flat — flat shading via computed face normals (octahedron non-indexed? OctahedronGeometry is indexed... use .toNonIndexed() + computeVertexNormals for flat). Custom shader: color = instanceColor * (0.25 + 0.75max(dot(n, keyLight),0)) + instanceColoremissiveBoost. Fine.
• big central cluster: 5 large crystals manual.
• pool: r=8 dark glossy disc at y=0.05 with subtle cyan ripple shader.
• spores: points cyan drifting up.
• point lights: cyan (0,6,-10, intensity 60, distance 60, decay 2), magenta (15,4,12 ...).
• fog: #0a0f1e near 10 far 90.
• sky dome: not visible (cave shell) but keep dome anyway behind (cheap) — set stars 0, zenith/horizon near-black. Actually cave shell occludes dome entirely. Keep dome for simplicity of env code.
• walkR 48.

Dunes build (x=1800):

• ground r=110: dunes height = fbm-ish: 3 sine waves combined + noise, amp ~3.5; color sand gradient by height + noise speckle.
• sky: sunset: zenith #2a1b4a, horizon #ff9a3c, sun dir low (0.25, 0.18, -1 normalized...), sunColor #ffd9a0, sunSize big 0.08, stars 0.25.
• sun sprite glow: additive radial sprite at sun dir * 280.
• spires: instanced displaced cones terracotta #b06a4a, 14 of them, tall 8-22, at r 20-95.
• arch: TorusGeometry(8, 1.6, arc=π) standing, stone #a35f45, at (30, ?, -20) half-buried.
• monolith ring: big torus r=10 tube 1.2 at (-35, 2, 25), tilted, dark #2b2b33 with emissive glyph stripes (canvas texture: random glyph-ish rects) emissive #ffb060.
• sand drift: points, stretched horizontally? plain points, wind strong, warm color, alpha low.
• rocks: instanced dodecahedra small.
• fog: #3a2030 near 20 far 160. hemi: sky #ffb37a ground #5a3040 int 0.7. sun directional #ffb060 int 1.6 low angle (no shadow... enable? shadows off for perf; dunes self-shade via normals).
• walkR 85.

Vale build (x=2700):

• ground r=70: gentle noise ±0.8, color deep teal-green #0e2a24 with moss speckle.
• mushrooms: stems instanced (CylinderGeometry r0.18-0.5 h2-6, pale #cfd8c8), caps instanced (SphereGeometry half, emissive per-instance [teal #2affd4, lime #a8ff5e, blue #4fc3ff, violet #c07aff], emissiveIntensity 1.6). Big ones: 26 large (cap r 1.5-4, h 3-8), 160 small (cap 0.3-0.9). Cap spots: skip (shader cost) — gradient cap shader: emissive stronger at rim? Simple custom shader like crystals: fresnel rim glow — pretty! Cap shader: color = base0.15 + emissiveColor * (0.35 + 0.65pow(1-|dot(n,view)|,2)) → glowing rims.
• light shafts: 4 cones additive pale green from y=25.
• fireflies: points gold-green, strong twinkle, slow drift.
• rocks, fallen logs (cylinders lying, dark brown).
• canopy: big dark disc at y=26 with holes? Use ring of dark spheres? Simplest: sky dome very dark (zenith #061410, horizon #0a2c22, stars 0.6, moon: small sun disc pale). Add a few hanging vines? skip.
• fog #061512 near 12 far 110. hemi sky #1c5c4c ground #04100c 0.5. point lights: 2 (teal, lime) low intensity.
• walkR 55.

PART 4 — portals:

Portal surface shader:

vUv from circle geometry: position.xy / vec2(rx, ry) → pass as attribute-ish via uv? CircleGeometry uv is 0..1 mapped over disc → vUv = uv*2-1. Good.

Portal render pass:

Wait: uDepth is a shared uniform across all portal surface materials — set via a shared object {value:0} referenced by each material's uniform. Yes: uniforms.uDepth = sharedDepth.

Also hide the surface of the portal we're rendering INTO? When rendering p's RT, the virtual camera is at link portal looking out — link's own surface is behind camera (culled). But p's surface in the OTHER world... p is in current world which is far away (culled by far plane). OK.

Edge case: when in hub, 3 portals each render their linked world. RT per portal. Good.

Oblique plane: link portal plane: normal = link world +Z (facing into its world... wait link surface normal faces its own world (viewers in that world see it). Virtual camera is positioned just in front of link portal (on +Z side) looking outward along +Z. Geometry between camera and portal plane = nothing (camera is in front). Geometry BEHIND the portal (on -Z side, outside the world... e.g., the backside of frame, or stuff placed behind) would be visible in the RT where the aperture is — must clip everything on -Z side. Clip plane: keep +Z side. Plane normal = link +Z world dir, constant = -dot(n, linkPos) - epsilon (push slightly toward camera... to keep +Z side starting a hair in front of the portal to avoid z-fighting the surface itself — but surface isn't in this world... the LINK's surface IS in this world but behind camera. Other geometry exactly at plane: the frame torus — partially at z≈0. Push plane slightly INTO the world (+Z) by 0.05: constant -= 0.05? Plane: n·x + c = 0 with c = -n·p. Points with n·x + c > 0 are kept (in front). To move plane into world by d: p' = p + n*d → c' = -n·p' = c - d. So subtract d=0.05.)

Transform plane to view space of virtual cam: plane.applyMatrix4(vCam.matrixWorldInverse). Then Lengyel.

Sign function: GLSL-style sign with 0→1? Standard code uses (x>0?1:-1). Use Math.sign || fallback with x>=0?1:-1.

Teleport:

Careful: after teleport, must update prevZ for ALL portals to avoid stale sign triggers. Simplest: after teleport, recompute and store prevZ for all portals in both worlds? Just recompute for all portals everywhere (6 portals, cheap). Also add small cooldown 250ms.

teleport(p):

Note camera.matrixWorld needs to be current — update before. Since controls set camera.position/quaternion directly each frame, call camera.updateMatrixWorld() at teleport time.

Ground follow: after teleport, y set by ground fn of new world + eye. The relation preserves height automatically IF both portals sit at matching heights above their grounds. I'll place portals so their local origin y=0 at ground level, aperture center at y≈2.2 (ry 2.2 → aperture spans 0..4.4? ellipse centered at origin → spans -ry..ry; bottom would be underground. Better: build portal geometry so aperture center is at local y = 0 and place portal group at y = groundY + ry + 0.15 (so ellipse bottom ~15cm above ground). Then camera eye at 1.7 above ground is within aperture (local y of camera = 1.7 - (ry+0.15) ≈ -0.65, |−0.65| < ry ✓). And relation maps heights consistently if both sides use same ry and sit on their grounds similarly. If grounds differ in height at the two portal sites, there'd be a y jump — ground-follow lerp smooths it. Fine.

rx, ry: use rx=1.6, ry=2.3 for all portals (consistent mapping both directions).

PART 5 — controls:

State: yaw, pitch, pos = camera.position, vel, keys. Pointer lock: on canvas click → requestPointerLock (skip in test mode). mousemove: if locked: yaw -= mx0.0022; pitch -= my0.0022 clamp ±1.55. If not locked but dragging (mousedown): same with drag deltas. Touch: two-zone.

Move: dir from keys (w/a/s/d/arrows), rotated by yaw; accelerate vel toward dirspeed (walk 5.5, run 9 with shift); friction damp. pos += veldt. Clamp to walkR circle (in world-local coords: lx = pos.x - center.x, lz = pos.z - center.z; if len>walkR scale back, kill radial velocity). Ground: targetY = height(pos) + eye; pos.y += (targetY - pos.y) * min(1, dt10). Head bob: subtle: bobPhase += speeddt; camera y += sin(bob)*0.04 when moving & grounded. FOV kick when running: lerp fov 72→78.

Camera quaternion from yaw/pitch: euler YXZ.

PART 6 — audio:

AudioCtx lazy. Nodes: master gain → destination. Per-world gain (0 except current, lerp on change).

• makePad(world, freqs[], type, filterFreq): oscillators → gain → filter → worldGain.
• wind: noise buffer source → bandpass → gain, LFO on bandpass freq.
• chimes: schedule random notes: setInterval-ish via lookahead scheduler or simply setTimeout chain gated by ctx.state; play sine env. Use a scheduler every 400ms check.
• whoosh on teleport: noise → bandpass sweep 300→3000, gain env 0.4s; plus sine pitch drop. Keep implementation compact: a small helper lib.

Volume slider → master gain. Mute toggle M.

PART 7 — post/UI/loop:

Composer as described. Grade shader: vignette + grain + slight saturation boost.

UI wiring: buttons (mute, snapshot, quality cycle, return-to-atrium), sliders (volume, bloom strength, speed), world name readout, position readout?, fps counter. Keyboard shortcuts. Toast function.

Loop: dt clamp 0.05; update controls; update portals prevZ & teleport check; update shaders time; particles time; renderPortals(); shadow needsUpdate; composer.render(); stats.

Test hooks: window.__demo = { ready:false→true after first frame, goto(worldIdx) teleports player in front of return portal? Provide warpTo(worldIdx): place camera in world i at spawn point facing a nice view; snap() returns stats }. URL param ?test: low quality, no pointerlock, auto hide overlay, start muted.

Spawn: hub at (0, 0, 10)?? facing portal at (0,0,14)?? That portal faces center; spawn facing it: pos (0,0,8), yaw = π (facing +z? yaw definition: forward = (−sin yaw, 0, −cos yaw)? I'll define forward = (sin(yaw)*-1...) — standard: with euler YXZ, yaw=0 → facing -Z. Portal at (0,0,14) is +Z from spawn → yaw = π. OK.

Warp points per world: {pos, yaw} defined per world for tour/test.

Also a "camera tour" auto mode? Previous demos had tours; add simple "auto-walk" toggle? Skip tour to bound scope — add "orbit showcase" ? No — keep warp buttons: UI has 4 world quick-warp chips (also serves accessibility). Good.

Alright — also the label sprites above portals: canvas text. And a small "plinth" glow.

One more consideration: portal frame visibility from behind — frame torus is 3D, fine from both sides; surface mesh: single-sided (FrontSide) — from behind you'd see through the doorway... The return journey uses the OTHER portal's front. But standing in hub, portal's front faces center (you). Walking past/around it you'd see its back: surface invisible from back (FrontSide) → you'd see the world beyond through the frame hole — breaking illusion slightly but acceptable; better: make surface DoubleSide but shader shows only dark shimmer on backface (gl_FrontFacing check). Nice: if (!gl_FrontFacing) { dark shimmer }. Also frame blocks little. Good.

Also portals must be visible only in their world — they're positioned in their world, culled by distance elsewhere. Fine.

RT allocation: 6 portals × RT. Create RTs for all at init: 1024×576 half-float samples 2? MSAA+HalfFloat RT: samples: 4 might be heavy on swiftshader but only 3 rendered per frame max. Use samples: 2, size 960×540. Quality setting scales: High 1280×720, Med 960×540, Low 640×360 — recreate RTs on quality change (dispose old).

Wait, also main canvas MSAA: composer RT samples 4 — on quality low set samples 0? Recreate composer target... simpler: keep samples 4 always; quality affects portal RT res + bloom resolution + pixelRatio. OK.

Far plane & sky dome: dome radius 300, far 400. Distant worlds at 900+ culled.

Cave shell radius 75 at x=900 — dome r=300 centered at 900 extends to x=1200 < 1800-300=1500 ✓ no overlap with dunes dome. Good.

Fog: linear Fog, per pass set color/near/far. Sky dome material must ignore fog (fog:false) — set in ShaderMaterial (fog:false default for ShaderMaterial ✓).

Hemisphere light: one global, update per pass (color/ground/intensity). Directional: one global w/ shadow; per pass set color/intensity/position (relative to world center: pos = center + sunDir*80, target = center). target needs matrix update: light.target.position set; scene.add(light.target) once.

Point lights: static per world with distance falloff. Total: 2 (hollow) + 1 (dunes? maybe 0) + 2 (vale) = 4-5. OK.

Now, emissive crystals shader with instanceColor: ShaderMaterial with instanced attribute color — three provides instanceColor attribute automatically when mesh.instanceColor set, but ShaderMaterial needs #ifdef USE_INSTANCING_COLOR handling... In raw ShaderMaterial, declare attribute vec3 instanceColor; manually? Three injects instancing attributes only for built-in materials? No — for ShaderMaterial, three binds instanceMatrix attribute automatically IF geometry is used by InstancedMesh? Actually the instanceMatrix attribute exists on InstancedMesh and shaders get it via #include <common>? For ShaderMaterial you must declare attribute mat4 instanceMatrix;? Hmm — three.js automatically prepends attribute declarations for ShaderMaterial? No. For RawShaderMaterial you declare everything. For ShaderMaterial, three prepends built-in attributes (position, normal, uv, and ALSO instanceMatrix when USE_INSTANCING defined...). Let me recall: WebGLProgram builds prefix including #ifdef USE_INSTANCING attribute mat4 instanceMatrix; for ShaderMaterial too? The prefix for ShaderMaterial includes standard attributes: position, normal, uv — and instancing defines are set when object.isInstancedMesh (defines USE_INSTANCING automatically? I believe material needs defines.USE_INSTANCING? No...).

Reality check: For ShaderMaterial used with InstancedMesh, three.js (r150+) automatically adds instanceMatrix attribute binding — the program prefix includes:

and USE_INSTANCING is defined when rendering an InstancedMesh (parameters.instancing = object.isInstancedMesh). Yes — WebGLPrograms sets instancing parameter based on object, independent of material type. Similarly instancingColor when instanceColor !== null → defines USE_INSTANCING_COLOR and declares attribute vec3 instanceColor;. This applies to ShaderMaterial as well (it's in the vertex prefix for all materials). I'm fairly confident this works in r170. In the shader I then write:

And transform: mat4 im = #ifdef USE_INSTANCING instanceMatrix * #endif — messy in GLSL. Write:

Wait modelMatrix * instanceMatrix is correct order (instance transform in mesh local space). Normal: transform by mm normal matrix — approximate: use mat3(mm) (non-uniform scale skews normals but acceptable for glowy crystals; or normalize after).

OK. For caps rim-glow shader similarly.

To reduce risk, I could avoid custom instanced shaders and instead use MeshStandardMaterial with emissive and per-instance color via instanceColor (affects diffuse color only, emissive stays uniform white*intensity — all crystals same hue). I want varied hues → custom shader it is. I'll be careful.

Alternatively use MeshBasicMaterial with instanceColor and colorIntensity>1? MeshBasicMaterial color can exceed 1 via material.color multiplyScalar — but per-instance colors clamp? instanceColor values can exceed 1 (float buffer). MeshBasicMaterial with vertexColors-ish instanceColor: final = color * instanceColor; set material.color white, instance colors as hue*2.5 → HDR values → bloom picks up. That's MUCH simpler and reliable! Crystals = MeshBasicMaterial (unlit, glowing) + a second instanced mesh for dark crystal cores? Faceted shading lost — crystals look flat-colored... For glow crystals, flat bright is actually fine (they're "light sources"). But some shading helps form. Compromise: custom ShaderMaterial — I'll just write it carefully. Actually, let me do a hybrid that's both safe and pretty:

Crystal material = MeshStandardMaterial({ color: #0b0e18 (dark), emissive: white, emissiveIntensity: 1.0, roughness: 0.15, metalness: 0.1, flatShading: true }) with onBeforeCompile injecting: totalEmissiveRadiance *= vInstColor; — need varying from instanceColor. Standard chunks: with USE_INSTANCING_COLOR, vColor varying exists if material.vertexColors? The color chunks use vColor when defined(USE_COLOR) or instancing color? #include <color_vertex> handles vColor *= instanceColor under USE_INSTANCING_COLOR, and vColor exists when defined(USE_COLOR) || defined(USE_INSTANCING_COLOR). So: set material.vertexColors = false but ensure defines include... The chunk color_pars_vertex declares vColor if USE_COLOR or USE_INSTANCING_COLOR. And emissive chunk: totalEmissiveRadiance is uniform emissive. Inject after #include <emissivemap_fragment>: totalEmissiveRadiance *= vColor; — vColor available in fragment if declared (color_pars_fragment with same conditions). USE_INSTANCING_COLOR auto-defined by renderer when instanceColor present.

So: crystals = InstancedMesh + MeshStandardMaterial + onBeforeCompile adding that one line. Reliable and gives real lighting + emissive hues.

Mushroom caps: same trick: standard material emissive white * vColor, plus rim? Keep simple: emissive*vColor with moderate intensity, roughness 0.6. Good enough with bloom.

Portal frame: MeshStandardMaterial dark + emissive rim via onBeforeCompile? Use emissive color per portal (uniform material per portal, few materials fine): emissive = portal color, emissiveIntensity 1.4, plus animated pulse via material.emissiveIntensity update per frame (cheap, few portals).

Light shafts: custom ShaderMaterial additive (no instancing) — safe.

Particles: custom ShaderMaterial with Points (no instancing) — safe.

Sky dome: ShaderMaterial — safe.

Portal surface: ShaderMaterial — safe.

OK. Ripple pool: ShaderMaterial additive rings — safe.

Now the grade pass shader:

Need vUv — ShaderPass provides via copy shader convention (varying vUv). Use THREE's shader pass pattern with varying vec2 vUv; in vertex — standard.

UI design consistent with collection: dark glassy panels, accent color — pick portal-violet/gold: accent #8ab4ff? Use accent #a78bfa (violet) + gold #f0c878. Title "THRESHOLD". Subtitle "A PORTAL WALKER · FOUR WORLDS".

Panels:

• top-left: title + hints (WASD move, mouse look, walk through glowing doorways, M mute, P snapshot, 1-4 warp).
• top-right: readout: world name, fps, calls.
• bottom-left: controls: world warp chips (Atrium/Hollow/Dunes/Vale), sliders: volume, bloom, speed; buttons: mute, snapshot, quality, reset view.
• center: crosshair (small dot + ring).
• toast center-top.
• start overlay: big title, "Click to step through", controls summary; fades on click.

Testing plan (smoke.js):

• puppeteer launch args: --use-gl=angle? For headless WebGL: --use-gl=swiftshader or newer --use-angle=swiftshader, --enable-unsafe-swiftshader (newer chrome needs it). Previous run succeeded — likely used such flags. I'll set: ['--no-sandbox','--enable-unsafe-swiftshader','--use-angle=swiftshader','--disable-gpu-sandbox'].
• page.goto file://.../index.html?test=1
• wait for window.__demo.ready
• capture console errors; fail on any.
• screenshot hub; warpTo(1..3) with settle frames; screenshots; check pixels not all black (sample via png parse? simpler: page.evaluate readPixels? Use screenshot buffer and check variance via a tiny PNG decode — use 'pngjs'? extra dep. Alternative: canvas readback: in page, after render, renderer.domElement.toDataURL() length check + sample pixels via 2D canvas drawImage + getImageData variance. Do it in page context via __demo.sampleFrame() returning {mean, std}. Nice — no extra deps.
• assert std > threshold and no console errors.

Alright, time to write. I'll write the file in ~7 append chunks using bash heredocs with quoted 'EOF' to avoid interpolation. Total maybe ~1900 lines. Let me be methodical.

Also remember: update /space/demos/index.html adding card 018 at top of list.

Let me now write PART 1 (HTML head + CSS + UI skeleton + importmap + start of module).

Actually, to reduce risk of heredoc issues with backticks/$ in JS template literals — quoted heredoc ('EOF') is safe for everything except the delimiter line itself. Good.

One more design decision: file name/folder: /space/demos/018-threshold/index.html. Title: "Threshold — A Portal Walker".

Let me carefully write the JS. I'll mentally compile as I go.

Key math utilities:

Portal relation: p.rel = new THREE.Matrix4().copy(p.link.group.matrixWorld).multiply(FLIP).multiply(new THREE.Matrix4().copy(p.group.matrixWorld).invert()); — wait order: rel = M_link * FLIP * M_src⁻¹. Matrix multiply in three: A.multiply(B) → A = A*B. So:

✓.

Virtual camera from main camera: vMat = p.rel * camera.matrixWorld:

vCam.projectionMatrix = oblique(camera.projectionMatrix, planeView). Also set vCam.projectionMatrixInverse = invert. And vCam.matrixWorld/matrixWorldInverse: after decompose set vCam.updateMatrixWorld().

Oblique:

wait q is vec4 (qx,qy,qz,qw); clip plane vec4 C = (n.x,n.y,n.z,w). scale = 2 / dot(C, q). Then row: e[2] = C.xscale; e[6] = C.yscale; e[10] = C.zscale + 1 (clip... for OpenGL-style with -w? Lengyel: M3 row: (C.x, C.y, C.z + 1, C.w) after scaling where C = scaleC. Yes e[10] = Czscale + 1.0, e[14] = Cwscale. Also e[2], e[6] as scaled. ✓ (This is the standard "Oblique Near-Plane Clipping" — works with perspective matrices; sign(0) must be treated as 1? Lengyel uses sgn: x>0?1:x<0?-1:0... common impl: (plane.x > 0 ? 1 : -1). Hmm if normal component is 0 → qx = (±1 + e8)/e0 — using +1 when 0 is standard (corresponds to corner of clip cube). I'll use s = v >= 0 ? 1 : -1.)

Then set vCam.projectionMatrix.copy(p); vCam.projectionMatrixInverse.copy(p).invert();

Plane in view space:

wait sign: plane n·x + c = 0; moving plane along +n by d: new c = c - d. Push INTO the world means along +n (n points into world). d=0.05 → c -= 0.05. Hmm but that clips a sliver of the world right at the portal — intended (prevents surface z-fight). But careful it doesn't clip the frame bottom plinths visible through portal — 5cm sliver fine.

Then _plane.applyMatrix4(vCam.matrixWorldInverse).

Normal world: nWorld = new Vector3(0,0,1).applyQuaternion(linkQuat).

Also cull portal pass when portal not visible: compute portal center in camera space: if z > 0 (behind) skip; also if angle large skip. Simple: _v.copy(portalWorldPos).applyMatrix4(camera.matrixWorldInverse); if (_v.z > -0.5) skip (behind near plane). Also could check facing: portal front faces viewer if dot(camDir, portalNormal) < 0. If viewer behind portal (seeing backface), skip RT render (surface shows shimmer backside). Do both checks.

prevZ tracking: store on portal: p.prevCamZ. Init null → set first frame.

Cooldown: teleportCooldown = 0.3s after each teleport.

Walking through requires crossing while within aperture at crossing moment — I test with current local pos when sign changes; between frames the camera could move past center — fine at 60fps with speed ≤ 12 u/s → 0.2 u/frame, aperture half-width 1.6 — ok.

After teleport, set prevZ for all portals from new camera local positions (prevents immediate re-trigger of the link portal: after emerging, camera is on +Z side of link moving +Z; prevZ positive, no sign change ✓ — but numerical: if exactly at z≈0.05, fine).

Also block teleport if moving away: sign change from + to - means entering (for src portal front +Z). Emerging from link: you're on +Z side moving away (+Z). If you walk BACK into link portal (+Z → -Z crossing) → teleport back to hub portal. ✓ symmetric.

Edge: hub portal backside — if you walk around and cross from -Z to +Z within aperture from behind: that would also trigger (sign change) and fling you to link world emerging from link's... rel maps correctly regardless of direction? The flip construction assumes entering from front. Entering from back (-Z side going +Z... wait crossing from -Z to +Z): rel maps a point at local z=+0.1 (after crossing) → RotY π → z=-0.1 in link space → BEHIND link portal, inside the wall/void! Bad. Prevent: only teleport when crossing from +Z to -Z (front entry): require prev > 0 && now <= 0. From behind, no teleport; you'd walk through the frame seeing shimmer backside — acceptable (and frame plinths partially block). ✓ Also add invisible barrier? Skip — acceptable.

Hmm, but wait: is the portal's front (+Z) facing the walkable area? Hub portals face center ✓. World return portals face into the world ✓. Good.

Surface shader backside: gl_FrontFacing false → dark shimmer (no RT). ✓

Audio crossfade: worldGains[i].gain.linearRampTo... use setTargetAtTime(timeConstant 0.4) on teleport.

Now — write everything. Also include a tiny seeded PRNG and value noise:

Dune height:

Keep amplitude ~±4. Also flatten near portal site: multiply by smoothstep(dist to portal, 4→12) so portal sits on flat ground. Similarly vale/hollow: flatten near portal. I'll implement flatten(h, x, z, px, pz, r0, r1).

Portal positions per world:

• Hub: r=14, angles: A (hollow) at 90° → (0,14)... let me place: hollow portal at angle 90°: (0, 0, 14) facing center (rotY = atan2 of direction... to face center from (0,0,14): normal toward -Z → rotY = π). Dunes portal at 210°: (14cos210, 0, 14sin210) = (-12.1, 0, -7). Vale at 330°: (12.1, 0, -7). Facing center: rotY = angle + π? Portal normal +Z should point toward center: dir = -pos normalized; rotY = Math.atan2(dir.x, dir.z). ✓ compute programmatically.
• Hollow: portal at (-30, 0, 18)?? place at edge-ish facing inward toward center: pos (-26, 0, 14), lookAt center-ish. Actually simpler: place at distance 20 from center at angle 200°, facing center. Emerge walking toward center. ✓
• Dunes: at dist 24 angle 160°, facing center.
• Vale: at dist 22 angle 190°, facing center.

Spawn/warp points:

• Hub: (0,0,7) yaw π (facing hollow portal at (0,0,14))... portal at z=14 north; spawn at z=7 facing +Z ✓.
• Hollow: near portal emergence: portal at angle 200° dist 20 → pos ≈ (center + (20cos200, 0, 20sin200)) = (-18.8, 0, -6.8); warp point a bit inward: (-14, 0, -5) facing center → yaw = atan2(-(dx), -(dz))? facing dir toward center: d = center - pos (local) = (18.8, 6.8); yaw such that forward (-sin yaw, -cos yaw) ∥ d_norm... forward = (-sinYaw, -cosYaw) in XZ. Set yaw = atan2(-d.x, -d.z). ✓ compute programmatically: yawToward(pos, target).

OK, writing time. I'll also add renderer.debug.checkShaderErrors = true (default) so smoke test catches shader errors via console.

Let me write the file now, chunk by chunk. Chunk 1: HTML + CSS + body UI + importmap + module start (imports, config, utils, renderer). I'll keep CSS moderately elaborate (matching collection style).

Also note: previous demos link back? Not necessary.

Let me think about the exact UI ids:

• #stage canvas
• #title-panel, #readout, #controls, #toast, #crosshair, #start-overlay, #loading
• controls: warp chips (data-world), sliders: #vol, #bloom, #speed; buttons: #btn-mute, #btn-snap, #btn-quality, #btn-reset.

Readout: #ro-world, #ro-fps, #ro-calls.

Now write. I'll do the whole thing in ~6 heredoc appends, then node --check? It's a module inside HTML — extract and syntax check with node by writing the JS separately? Simpler: after writing, run a quick node script that extracts the module script and runs new Function? Module syntax (import) breaks Function. Use node --input-type=module --check? node --check doesn't support stdin module... I can extract to /tmp/x.mjs and run node --check x.mjs? --check works for files with .mjs → module parse. Imports of 'three' won't resolve but --check only parses.

Then the puppeteer smoke test.

Writing chunk 1 now. Also — I must remember GLSL texture2D vs texture: three r170 uses WebGL2 → GLSL3? ShaderMaterial default GLSL1 (auto-upgraded: texture2D works via define). Use texture2D in GLSL1-style shaders; three injects compatibility defines. ✓ gl_FragColor fine.

Points shader with wrap drift:

Simpler: store base positions in a cylinder volume; in shader: offset = windt; p = mod(base + offset - min, size) + min. Use mod on each axis relative to world center with box size (e.g., 120 x 30 x 120). Twinkle: alpha = 0.4 + 0.6sin(t*(1+seed3)+seed40). Size: uSize * (1+seed) / -mvPosition.z * 300... standard: gl_PointSize = uSize * (200.0 / -mv.z). Color uniform + per-particle brightness seed.

OK writing now. Given the size, I'll write 6 chunks of ~300-350 lines each.

Let me also decide numeric constants:

• EYE = 1.7
• Walk speeds: 5.5 / 9.5 (shift)
• Portal rx 1.6 ry 2.35, frame tube 0.18, plinths.
• RT default 1024x576 (med), high 1280x720, low 640x360.

Bloom: strength 0.75, radius 0.55, threshold 0.72.

ToneMapping ACES exposure 1.05.

Let me write chunk 1.

*****************************************************************************************************ms.

The checkpoint says "progress_threshold" with maxTime at 50% threshold, timeProgress 0.7775 — hmm, that suggests I'm using a lot of wall-clock time. Wait, timeProgress 0.777 means 77.7% of time used? That's concerning. Actually "threshold": 50 might mean the checkpoint threshold... Let me interpret: status "progress_threshold", reasons ["maxTime"], threshold 50, timeProgress 0.7776. It seems 77.76% of the max time is consumed. I need to move much faster.

I should accelerate: write the remaining chunks quickly, skip overly ambitious testing if needed. But a broken demo would be worse. Let me be efficient: write remaining code in fewer, larger chunks, then run one smoke test, fix critical errors only, update index, and finish.

Puppeteer install may still be running. Let me continue writing chunks 3-7 quickly but carefully, then test once.

Let me write chunk 3 (shared builders: sky, ground, particles, shafts, text sprite) and chunk 4 (world builders) now — combine into fewer writes.

I'm at 80.5% of max time already. I must drastically cut scope and finish fast. The full portal demo as designed is too big to complete safely in remaining time.

Decision: compress aggressively. I'll still deliver the portal walker but with a much more compact implementation — combine all four worlds into a single large chunk with simplified builds, single chunk for portals+controls+audio+loop. Skip puppeteer smoke test if install isn't done; do a minimal syntax check via node instead, plus a fast headless test only if puppeteer is already installed.

Actually — even simpler and safer: I could reduce to writing the rest as ONE big chunk (worlds + portals + controls + audio + UI + loop) of maybe 700-900 lines, then syntax-check, quick test if possible, update index page, done.

Let me check puppeteer install status quickly in the same command as writing the next chunk to save round-trips.

Let me write chunk 4 (world builders) compactly. I'll simplify:

• Atrium: ground, gold rings, columns (instanced), architrave torus, oculus shaft, dust, pool.
• Hollow: ground, cave shell, crystals (instanced w/ onBeforeCompile emissive*vColor), stalactites, spores, 2 point lights.
• Dunes: ground dunes, sky sunset, spires, arch torus, sand particles, monolith ring.
• Vale: ground, mushrooms (2 instanced meshes), shafts, fireflies, rocks, 2 point lights.

Then chunk 5: portals + controls. Chunk 6: audio + UI + loop + test hooks. Let me write fast but correct.

I made a typo in chunk 4: emissive: 0x coğa — that's invalid JS! I wrote it in the oculus material. I must fix that. Let me note it and fix with replace: emissive: 0x coğa → emissive: 0x8a6a2a, emissiveIntensity: 0.5.

Also puppeteer install status didn't print — the tail command output nothing visible before "chunk4 ok" (output only shows the echo). Actually the stdout shows only "chunk4 ok" — the tail and ls printed nothing, meaning install.log may not exist or is empty, and node_modules/.bin doesn't exist yet. I'll check later.

Fix the typo now and write chunk 5 (portal system + controls).

96% of time used! I need to finish NOW. I cannot complete the full portal system + controls + audio + UI + loop + testing in the remaining time.

Critical decision: I must wrap up immediately. The file currently has: HTML/CSS/UI, imports, utils, renderer setup, shared builders, and 4 world builders — but NO portal system, NO controls, NO main loop, NO closing tags. The file is incomplete and won't run.

Options: A) Rapidly append a minimal but functional remainder (portals simplified to the extreme, basic controls, loop, closing tags) in ONE write, then update index, then exit. Risky but doable if I keep it tight (~300 lines). B) Abandon the demo folder (delete it) and exit with failure — bad.

I'll go with A — write a compact finale in one shot. Simplifications:

• Portals: keep render-to-texture portals (core wow) but trim: no labels sprites (skip makeLabel usage), minimal frame (torus + surface), 3 pairs.
• Controls: pointer-lock optional; drag-look + WASD; no touch.
• Audio: skip entirely? UI has volume slider... I'll stub audio minimally (mute button toggles a simple drone) — or better: remove audio wiring and make those buttons minimal. To save time, implement a tiny audio: single pad + whoosh. Actually skip audio completely and make mute button toggle a class "soon"? No — dead buttons are bad. Fastest: implement ultra-compact audio (~40 lines): master gain, per-world filtered noise/pad, whoosh. I'll compress hard.
• Loop + post: composer with bloom + grade pass.
• Test hooks: window.__demo minimal.

Let me write it all in one giant chunk NOW, then close the file, syntax check quickly with node (extract module), update index.html, and exit. No time for puppeteer test — rely on careful code + node syntax check.

Key remaining pieces, compressed:

Wait — portal group y: ground at site + ry + 0.12. Ground heights at portal sites are flattened to ~0 in hollow/vale/dunes (flatten() makes them ~0 near P) — hub is 0. So y ≈ ry + 0.12 = 2.47. Use heightFn to be safe.

Surface shader with uMap, uResolution, uDepth, uColor, uTime; vUv from circle uv*2-1; backface → dark shimmer.

Frame: TorusGeometry(1, 0.09, 10, 48) scaled geometry (rx+0.12, ry+0.12, 1) → elliptical ring; MeshStandardMaterial dark with emissive portal color.

Plinths: two small boxes at base sides? skip plinths, add a ground glow disc (additive circle) — cheap and pretty.

linkPortals(a,b): compute rel matrices both ways after scene.updateMatrixWorld(true).

Pairs:

• hub portal A at local (0,14) rotY π ↔ hollow portal at (-18.8,-6.8) facing center: rotY = atan2(-x, -z)... normal toward center: dir = normalize(-pos) → rotY = atan2(dir.x, dir.z). For hollow P=(-18.8,-6.8): dir=(0.94,0.34)→ rotY≈1.22.
• hub B at 210°: (-12.1,-7) rotY facing center ↔ dunes portal at (-9.4,-21.8) facing center.
• hub C at 330°: (12.1,-7) ↔ vale portal at (-20.7,-3.6) facing center.

Colors: hollow 0x37f2ff, dunes 0xffb060, vale 0x2affd4; return portals gold 0xf0c878.

Render passes + teleport + controls + audio + UI + loop + hooks. Compress audio:

Controls compact:

Teleport:

Portal rendering:

Note: camera.matrixWorldInverse must be current: camera.updateMatrixWorld() then matrixWorldInverse — three updates matrixWorldInverse in updateMatrixWorld? For cameras, updateMatrixWorld also updates matrixWorldInverse. Yes (Camera.updateMatrixWorld computes matrixWorldInverse).

applyOblique as designed.

applyEnv(i):

sun.target matrixWorld updates during render (it's in scene). ✓

Main loop:

Wait — shadow needsUpdate should be set BEFORE the first render that uses shadows (portal views render scene too). Set it before renderPortalViews. ✓

Composer + grade shader + bloom; resize handler; quality button cycles RT sizes (recreate RTs); snapshot; warp chips → warpTo(i): set curWorld, position at spawn, yaw; storePrevZ; setAudioWorld; toast.

Readout update; fps counter.

Test hooks: window.__demo = {ready, warpTo, sample()} — sample: draw canvas to 2d and compute mean/std.

Overlay click: hide, initAudio, request pointer lock.

Also portalsByWorld array.

RT creation: function makeRT(size) → WebGLRenderTarget(w,h,{type:HalfFloatType, samples:2, colorSpace: LinearSRGB? default}). Portal surface samples it raw (linear HDR) — good since composer works in linear until OutputPass.

Wait — main render goes through composer RenderPass into HalfFloat RT (linear), bloom adds, grade, OutputPass converts to sRGB. Portal RT content is linear scene render — sampled by surface shader and output as gl_FragColor into linear buffer. ✓ consistent.

One catch: renderer.outputColorSpace = SRGB affects direct-to-screen renders; when rendering to RT, three keeps linear. ✓

Portal surface shader: needs uMap per portal (own RT texture) — material per portal.

Also uResolution shared.

Aperture geometry: CircleGeometry(1, 40) then geo.scale(rx, ry, 1). UVs: circle geometry uv covers [0,1]² mapped from the disc → vUv = uv*2-1 gives ellipse coords where length<=1 inside. ✓

Frame torus: TorusGeometry(1, 0.055, 8, 64) scaled (rx1.12, ry1.1, 1)... torus tube 0.055 in unit space scaled by ~1.8 → ~0.1 tube. OK.

Ground glow disc under portal: CircleGeometry(rx*1.4) additive, color, opacity pulsing — cheap shader? Use MeshBasicMaterial with color, transparent, blending additive, opacity 0.25, rotated flat. Basic material color can't exceed 1 but additive glow fine.

Label sprites: skip to save time? They add a lot of polish... makeLabel exists already (written in chunk 3). Use it — 3 lines per portal. OK include.

Also spawn: warpTo(0) at init.

Edge case — portalsByWorld for hub has 3 portals; others 1 each.

Let me also handle "H" toggle UI, "M" mute, "P" snapshot, 1-4 warp.

Snapshot: composer.render(); canvas.toBlob → a.download.

Quality: sizes [[1280,720],[960,540],[640,360]] cycle; recreate each portal RT: p.rt.dispose(); p.rt = makeRT(); p.mat.uniforms.uMap.value = p.rt.texture.

pixelRatio: setPixelRatio(min(dpr,1.5)); low quality → 1.

Resize: camera aspect, renderer size, composer size, uResolution = drawingBufferSize, bloom resolution.

Write it ALL now in one chunk + closing tags. Then node syntax check + index update + exit. GO.