Voxelia - Pocket Voxel Wilderness Demo

The task is "Wake up and do as you please." This is a free-form task where I can create a new Three.js demo in my space under /space/demos/.

The last execution created demo 049-sakura-grove. So the next demo should be 050-something. Let me check the current state of the demos folder first.

Let me install shell tools and explore the current state.

Now let me look at the current state of the demos folder.

There are 49 demos. The task says "Wake up and do as you please." I should create a new advanced Three.js demo — number 050. That's a nice milestone number, so let me make something special.

Let me look at the index.html to understand the format, and check the style of a recent demo to match conventions.

The index is up to date with 049. The current task is "Wake up and do as you please" — so I should create demo 050. That's a milestone number (demo 50!), so I should make something special and impressive.

Let me think about what to build for demo #50. Existing demos cover a huge range:

• galaxies, black holes, fluid dynamics, gravity, mandelbulb, audio reactors, runners, oceans, physarum, powder sim, clocks, neon rain, aurora, skitter (ants?), coral, threshold, attractors, murmuration (flocking), terraforge (terrain), cloudsea (clouds), frostline (ice), koi pond, ferrofluid, synchrony (pendulums/metronomes), cymatics, teslasphere, pyrosymphony (fireworks), morphogenesis, galton cascade, wavefront, gossamer (spider web?), magnetosphere, cloud chamber, wavefunction (quantum), epicycle (orbits), sandpile, kinetic theory, lumen lab (optics), squish lab (soft bodies), neon tilt (marble game), hyperfold (4D), photon garden, critical point (phase transitions), bridge works (bridge building), primordial (Lenia), coasterworks (roller coaster), sakura grove.

For #50, something spectacular. Ideas:

1. Black hole / wormhole with gravitational lensing — done already (006-event-horizon).
2. Ray-traced / path-traced scene — a real-time path tracer in Three.js (progressive rendering) with spheres, mirror/glossy/dielectric materials, environment. A Whitted ray tracer or path tracer with GLSL via fullscreen quad would be very impressive. 040-lumen-lab might already be optics though — let me check what lumen lab does.
3. Volumetric nebula with ray marching — done-ish (nebula galaxy).
4. Ocean with FFT waves (Tessendorf) — 009-azure-odyssey and 022-cloudsea might cover water. Let me check.
5. Cloth simulation — maybe.
6. A star destroyer / spaceship scene.
7. Real-time path tracing demo: "Cornell Box Path Tracer" — progressive accumulation, moving camera, spheres with glass/metal/diffuse, depth of field. This is a classic "wow" graphics demo. Let me check 040-lumen-lab and 044-photon-garden to avoid overlap.
8. Tessendorf ocean with foam + floating boat — beautiful.
9. Solar system / orbital mechanics — done (037-epicycle?).
10. A "data center" / circuit board city flythrough.
11. Fractal flame renderer.
12. Procedural planet with atmosphere — maybe done by terraforge.

Let me check a few existing demos to avoid duplicating concepts. Let me look at descriptions in index.html for lumen-lab, photon-garden, azure-odyssey.

Path tracing is done (044). Ocean sailing done (009). Black hole done (006). Volumetric clouds done (022). Optics done (040). Quantum done (036).

Ideas for demo 050 that haven't been covered:

1. Procedural city / cyberpunk flythrough — a neon procedural city with traffic, lit windows, rain... 014-neon-rain might be neon rain though. Let me check.
2. Cloth / flag simulation with wind + character — 033-gossamer may be cloth/spider web.
3. L-system / procedural plants — 049 has trees.
4. Voxel destructible terrain — minecraft-like, with digging/building? Cool and interactive.
5. Wormhole / portal demo.
6. Flocking dragons / flight game.
7. Marble run generator — 031-galton cascade is balls through pegs.
8. Rube Goldberg machine?
9. A "solar eclipse / space station" scene.
10. Underwater submarine exploration — 010-abyssal bloom might be underwater.
11. Interactive music machine / sequencer 3D — a 3D step sequencer with physics balls hitting notes? That's fun: "Tone Matrix 3D". Balls bouncing on a grid triggering notes.
12. Rocket launch / orbital mechanics game — launch a rocket into orbit, gravity sim around a planet. 037-epicycle is orbital mechanics? Let me check.
13. Rain on a window with droplets shader — cozy scene.
14. Train / railway builder.
15. Fireworks — done (029).
16. Voxel engine with caves + day/night + mining game — "Voxelcraft" — dig, place blocks, procedurally generated terrain with caves, ores, water. That's a strong interactive demo. Though terraforge is terrain... terraforge is likely heightmap terrain generation/erosion. A voxel builder would be distinct: greedy meshing or instanced cubes, first-person walking with gravity/collision, dig & place, procedural caves, ambient occlusion per-voxel, water, clouds, day/night.

Actually for a 50th demo milestone, something impressive like "Starport" — a space station docking simulator? Or "Orbital" — a KSP-like 2D/3D orbital mechanics game? Let me check epicycle first.

Let me also check what 014-neon-rain, 016-skitter, 018-threshold, 030-morphogenesis, 037-epicycle, 038-sandpile, 041-squish-lab, 043-hyperfold, 045-critical-point, 008-void-runner are about so I don't duplicate.

Great overview. Notable absences:

• No voxel building/mining demo
• No rocket/space launch sim
• No ray-traced demo... wait, 044 is path tracing
• No train sim
• No cloth sim (gossamer is a web)
• No aquarium (koi pond is close)
• No 3D snake
• No fractal flames
• No double pendulum? (026-synchrony is probably coupled pendulums/metronomes)
• No buoyancy/boat builder (009 is sailing)
• No rocket / orbital mechanics game — epicycle is Fourier drawing, not orbital mechanics!
• No flight simulator
• No "infinite procedural tunnel"
• No "winter cabin snow globe"
• No "interactive DNA/protein"
• No "KSP-style" orbital game
• No voxel sandbox

For a milestone #50, a voxel sandbox game would be super cool — "Voxelia" or something: procedural voxel terrain with caves, first-person mining/building, day/night, water, ambient occlusion, greedy meshing or per-face meshing with texture-less colored blocks, torches/lights, trees, clouds. That's a big build but doable.

Alternatively an orbital mechanics rocket game: launch from a planet, achieve orbit, land on a moon — with patched conics, maneuver nodes... that's complex.

Another idea: "Star Harbor" — a starship docking sim.

Or "Pendulum Waves" — done-ish (synchrony).

Or "Typhoon" — a hurricane/weather sim with clouds? Clouds done.

Or "Origami" — folding paper simulator? Interesting but hard.

Or "Labyrinth" — a procedurally generated 3D marble labyrinth game.

Or "Aquarium" — a fish tank sim with plants, bubbles, fish AI — similar to abyssal bloom/koi pond.

Or "Firefly Forest" — similar to sakura grove.

Or "Wind tunnel / aerodynamics visualizer" — place airfoils, smoke streamlines, lift/drag readouts. That's a nice physics viz that hasn't been done! Interactive: draw an airfoil shape, watch streamlines, lift/drag coefficients, stall. Could compute flow with a lattice-Boltzmann or potential-flow solver on GPU. LBM wind tunnel in a fragment shader is very doable and impressive. Kinetic theory (039) is gas molecules; wavefront (032) is waves. A wind tunnel with LBM (D2Q9) advecting smoke and showing vortices behind obstacles — classic "wow" demo. Let me check 032-wavefront and 039-kinetic-theory to be sure.

Actually, let me think about the most "wow" yet achievable in a single self-contained HTML:

Option A: "Wind Tunnel" (LBM fluid sim) — D2Q9 lattice Boltzmann on GPU via WebGL float framebuffers (ping-pong), obstacles you can draw, airfoil presets, smoke dye advection, velocity/vorticity color modes, lift/drag measurement, time controls. Interactive and educational. 2D though, rendered with some 3D flourish. The demos collection already has 004-fluid-dynamics... let me check what that is. It might be Navier-Stokes already.

Option B: "Voxelcraft" — first-person voxel world. Big but classic wow.

Let me check 004-fluid-dynamics first.

OK, fluid dynamics (Navier–Stokes dye solver) is done. A wind tunnel would overlap somewhat with fluid dynamics.

Let me settle on the voxel sandbox idea — it's a classic crowd-pleaser and very distinct from everything in the collection: "Voxelia — Procedural Voxel Wilderness" — a first-person Minecraft-like world:

Features:

• Procedurally generated voxel terrain from seeded value/simplex noise: rolling hills, mountains, trees, caves, water, sand beaches, snow caps, flowers/grass decorations.
• First-person controls (WASD + mouse look via pointer lock), walking with gravity and collision, jump, fly mode toggle.
• Dig (left click) and place blocks (right click), block palette selection (1-9 keys + scroll wheel), raycast voxel picking with a highlight wireframe.
• Efficient chunk meshing with face culling (build mesh per chunk, rebuild dirty chunks), simple per-vertex ambient occlusion? AO might be a stretch but doable — vertex AO gives that classic Minecraft look. Yes, let's include per-vertex AO (the 4-neighbor algorithm).
• Day/night cycle with sun/moon, sky color shader, stars at night.
• Dynamic lighting: sunlight via day/night tint + torch blocks with per-block light propagation? Full flood-fill light propagation is doable but complex; maybe simpler: torches as point lights baked into vertex colors using BFS light propagation within a chunk+neighbors. This is the classic approach. It's quite some code but manageable. Let me consider scope.

Actually, realistic scope: I need this robust and bug-free. Let me plan:

• World: 128×128 blocks footprint, ~48 height, chunked in 16×16 columns with full height. 8×8 = 64 chunks. Each chunk meshed with culling. Mesh count fine.
• Blocks: grass, dirt, stone, sand, water (translucent), wood/log, leaves, snow, flower variants? Keep flowers as cross-billboards maybe too much; keep it simpler: colored wool-ish blocks for building: brick, glass, plank, torch (as a small cube with light), glowstone.
• Terrain gen: 2D noise heightmap with multiple octaves + biome-ish moisture; 3D noise for caves; trees placed deterministically; water level; snow above altitude; sand near water.
• Meshing: for each chunk, iterate blocks, add visible faces with AO per vertex; separate translucent geometry for water/glass/leaves? Leaves can be opaque with cull; water translucent with its own mesh and animated texture-ish color via shader.
• Lighting: vertex colors = AO × sunlight tint × (torch light). BFS propagation for torchlight stored per chunk in Uint8 arrays (16 levels). On block change, recompute affected chunk(s) light + rebuild meshes. Day/night just scales sunlight color in shader uniform (so no remeshing needed) — but vertex-baked torch light stays constant, which is fine (torches glow at night).
• Player physics: AABB vs voxel collision, gravity, jump, step; fly toggle (F). Sprint (shift). Pointer lock; touch fallback with joystick? Touch controls add complexity — I can add basic touch: left half virtual joystick to move, drag right half to look, buttons for jump/dig/place. Hmm, that's a lot. The guidelines want full touch support, and previous demos have it. I'll add a reasonable touch implementation.
• Raycast picking: DDA voxel traversal, highlight box, dig/place.
• Particles: block break particles (small instanced quads with gravity) + place/dig sounds (WebAudio synthesized noise bursts).
• Ambience: generative WebAudio wind/birds at day, crickets at night; dig/place thock sounds; footstep ticks.
• HUD: crosshair, hotbar with 9 slots, FPS/chunk counter, help overlay, time-of-day slider, fog toggle, fly toggle, seed display + regenerate.
• Post: keep it light — maybe just a subtle vignette via CSS/canvas overlay rather than EffectComposer (first-person + bloom can be tricky with big draw calls; but bloom on torches/lava at night would be nice). I could include UnrealBloomPass with low strength. Rendering is mostly one big mesh so bloom cost is the fullscreen passes; acceptable with adaptive quality. I'll include bloom with adaptive quality tiers like other demos.

That's a lot of code (~1500-2000 lines) but very achievable and it's a strong demo. The risk: bugs. I'll write carefully and self-test with node where possible (logic parts: noise, meshing counts, light propagation, raycast DDA).

Alternatively something smaller but still cool... The instructions say "Wake up and do as you please" and the milestone #50 deserves something substantial. I'll go with the voxel world: 050-voxelia.

Actually, let me reconsider the name. "Voxel" names: Voxelia, Voxelvale, Blockwild, Cubewild... I'll go with "050-voxelvale" or "050-voxelia". "Voxelia — Pocket Voxel Wilderness". Good.

Let me check one recent demo's structure to match conventions (import map version, style, footer, etc.). Let me look at 049-sakura-grove/index.html briefly (structure only).

Good — Three.js 0.160.0 with import maps from unpkg, HUD overlay style, monospace font. I'll follow the same conventions.

Now let me design 050-voxelia in detail:

Architecture

Constants:

• CHUNK = 16 (x,z), WORLD_HEIGHT = 64, chunks 8×8 → world 128×128. Actually maybe world 160×160 (10×10 chunks) — meshing cost fine. Let's do 9×9 chunks of 16 = 144×144, height 64. Blocks total = 14414464 ≈ 1.3M voxels stored in Uint8Array = 1.3MB. Fine.
• Block ids: 0 air, 1 grass, 2 dirt, 3 stone, 4 sand, 5 water, 6 log, 7 leaves, 8 snow, 9 planks, 10 brick, 11 glass, 12 torch, 13 glowstone? Let me also add gravel? Keep list manageable but interesting: grass, dirt, stone, sand, water, log, leaves, snow, planks, brick, glass, torch, glowstone, flower-red (cross sprite?), flower-yellow. Cross sprites complicate meshing; skip flowers as blocks; instead scatter them as part of terrain decoration using instanced planes... simpler: skip flowers entirely, focus on solid cube gameplay. Actually small cross-billboard flowers add a lot of life cheaply. I can handle them in the mesher as a special case (two quads). Let me include: flower (id 14) with per-block hue variation? Use two variants: 14 flower-red, 15 flower-yellow. And tall grass? Skip tall grass.

Hotbar: grass, dirt, stone, sand, planks, log, leaves?, brick, glass, torch, glowstone, snow... 9 slots: grass, dirt, stone, planks, brick, glass, sand, torch, glowstone. Number keys 1-9 select; scroll wheel cycles. Selected block shown in hotbar UI (DOM-based hotbar is easier than 3D). DOM hotbar with colored swatches.

Terrain generation (seeded):

• Hash-based value noise with multiple octaves (like sakura demo probably has). I'll write my own seeded PRNG (mulberry32) + value noise 2D with quintic smoothing + fbm.

• Height: base 20 + continent fbm * 26 + mountain ridge noise where mountainous. Add a "mountain mask" from another noise channel: ridged noise for dramatic cliffs.

• Biomes by temperature/moisture noise: desert (sand surface), forest (trees dense), plains, snow caps above y>threshold.

• Caves: 3D noise (value noise 3D) carve where noise > threshold for y < some level; also "spaghetti" via two 3D noises product. 3D value noise fbm for 14414464 voxels = 1.3M × maybe 3 octaves × 2 fields — 8M noise evals; each eval is ~8 hash lookups... ~64M ops, should run in ~0.5-1.5s in JS. Acceptable with a loading indicator. I can carve caves with a single 3D fbm (3 octaves) + a second one for tunnel: use classic trick: cave if |n1|<0.08 && |n2|<0.08 (intersection of two 3D noise fields). That's 2×3 octaves = 6 evals/voxel = 8M evals ~ 1-2s. OK with "generating world" overlay. Only carve below surface and not into water level to avoid flooding lakes... water is fine — carve only below y < waterLevel-2 OR allow caves under sea but then they'd flood visually (water blocks only placed at gen on surface; caves under sea floor that breach would show holes). Simplest: don't carve caves within 3 blocks of the surface (based on heightmap). Caves then exist underground only.

• Ores: sprinkle glowstone clusters in caves (as natural "crystals"!) — glowstone ore veins underground. Nice: mining glowstone.

• Trees: deterministic per (x,z) via hash: if forest biome & rand < density & terrain ok → place tree: log height 4-6, leaves blob. Pine trees on snow.

• Water level fixed ~ y=22 (sea). Beaches: sand near sea level.

Storage: Uint8Array world [x + zSX + ySXSZ]? Memory layout (y-major contiguous per column?) Meshing iterates y inner — use index = x + zSX + ySXSZ so y inner loop is strided by SXSZ (2048) — cache unfriendly but fine. Better: index = (xSZ + z)*H + y → y contiguous. I'll use idx = (x * SZ + z) * H + y with SX=SZ=144, H=64.

Light:

• Two light channels: sunlight (sky) and torch light. Storing both nibbles in one Uint8 per voxel: high nibble sky, low nibble torch. 1.3MB extra.
• Sunlight: computed at gen by vertical flood: from top, sky=15 until hitting opaque; then BFS spread horizontally/downward with attenuation. Classic Minecraft algorithm. To keep it simpler and robust: compute skylight column-wise (vertical) then one BFS pass to bleed into caves/overhangs. BFS over 1.3M voxels fine.
• Torch: torch blocks emit light 14, BFS spread with attenuation (opacity: solid blocks block, leaves/water reduce by extra 1?). BFS from all torches at gen; on block place/remove, do incremental update: simplest robust approach = recompute light for affected chunk region... Full recompute of world light on each edit is too slow? 1.3M voxels BFS ~ maybe 100-300ms — borderline. Better: incremental update via the standard "light removal + re-add" BFS within radius 15 of the edit. Implement:
  • removeLight(x,y,z,channel): BFS collecting cells whose light came from this source, set to 0, and collect boundary cells to re-propagate from neighbors... The classic algorithm: BFS flood clearing, remembering neighbor cells that still have light >0; then re-add BFS from those. This is well-known; I'll implement carefully.
  • For torch place: addLight BFS.
  • For block place/remove: affects sky light too: recompute the column sky light and propagate. This is getting complex.

Simplification decision: Sky light recomputed lazily per column on edit (column = 64 voxels, cheap: scan from top; then BFS bleed pass within radius ~16 around the column to fix horizontal bleeding). And torch light via local add/remove BFS radius 14. Both then mark affected chunks dirty for remesh. I'll implement a generic BFS for both channels with a max radius to bound cost. Given the day/night cycle changes the sun color via uniform anyway, the baked sky-light matters mostly for caves being dark — good enough.

Hmm, wait — is full lighting worth the complexity/risk? The classic look strongly benefits. But risk of bugs is high. Alternative: skip baked light entirely; use per-face directional shading (top faces brighter) + AO + day/night uniforms, and torches as THREE.PointLight? Too many torches → no. Baked vertex light is really the way; point lights for torch can't scale.

Decision: implement baked light with sky+torch channels. I'll write it carefully and unit test the BFS functions in node (I can extract the module JS and test pieces). The self-test from previous demos suggests they ran node --check and some logic tests. I'll structure the JS so core logic (noise, worldgen, mesher, lighting, raycast) is in plain functions that don't depend on THREE where feasible, so I can import-test in node. Actually simplest: put the module code in the HTML as one big module; for testing, extract via regex to a temp .mjs file and run node --check; plus write a small node test harness that stubs 'three' imports? That's heavy. Alternative: put the pure logic in a separate <script type="module">? The demo must be self-contained single HTML; I can still extract the whole module and run node --check for syntax, and separately hand-test key algorithms by copying them into a test file (duplicating code, risk of divergence).

Better approach: write the demo logic in a separate JS file (e.g. voxel.js) and have index.html reference it — the guidelines say "self-contained single-page HTML files using Three.js from a CDN" but also "plus any assets" are allowed in the demo folder ("containing an index.html (self-contained demo) plus any assets"). A local module file is fine and testable in node directly! Demos so far seem single-file, but having main.js alongside is acceptable ("plus any assets"). Hmm — but for maximal compatibility with how people open demos (file://), ES module imports of local files can hit CORS issues on file://; everything else loads from unpkg anyway which requires network. Previous demos are single-file; I'll keep single-file for consistency and safety, and for testing I'll extract the inline module to a temp file for node --check, plus structure the code so pure functions can be tested by evaluating a marked section.

Actually — simplest robust test plan: I'll write the inline script so that all pure logic (PRNG, noise, world gen, lighting BFS, mesher geometry generation, raycast) is defined as top-level functions NOT requiring THREE. Then in node, I extract the module, strip the import ... from 'three' lines and the THREE-dependent tail (I can guard execution: wrap the "start app" part in if (typeof window !== 'undefined' && !window.__VOXEL_TEST__))... but top-level THREE usage in function bodies is fine since functions aren't called during import. Only top-level statements must avoid THREE. I can then import the extracted module in node with imports stripped, and call the pure functions for tests. To export functions from the module for node, I can add export { ... } — in the browser inline module, export is legal? An inline <script type="module"> can contain export statements; they're just ignored since nothing imports it. Yes, that's valid HTML/JS.

So plan: single index.html with inline module; functions exported for testability; app bootstrap guarded by typeof document !== 'undefined'. In node, extract script, replace the three import lines with stubs, import, run tests.

For node import of 'three' — I could actually npm install three in a temp dir and keep imports intact! Node can import three from node_modules if I set up package.json. That allows even THREE-dependent tests (mesher uses THREE.BufferGeometry only in the build step... I can make the mesher produce plain arrays {positions, normals, colors, indices} and have a thin THREE wrapper). Then all logic testable with real three installed. Let's do that: check if node and npm exist, npm install three@0.160.0 in /tmp, extract module, run tests with a small import-map-ish loader: since the module imports "three" and "three/addons/...", node needs those resolvable. With three installed, import 'three' resolves. Addons import path "three/addons/..." maps to examples/jsm via package exports? Three's package.json has "./addons/": "./examples/jsm/" export mapping since r15x. Yes, three@0.160 supports "three/addons/*". So node can import it natively.

But the app bootstrap code touches document/window immediately at top level (creating renderer etc.) → guard with if (typeof window !== 'undefined' && typeof document !== 'undefined') start(); and in node define no window/document, so start() never runs. But three's WebGLRenderer import is harmless (class definition only). PointerLockControls import fine.

Then my node test can: generate a world from seed, assert block counts, run mesher, assert face counts > 0 and indices valid, run lighting, place/break blocks, raycast checks.

This is a solid plan.

Mesher with AO: For each block & face, if neighbor transparent (and not same translucent type), emit face. Vertex AO per corner using side1, side2, corner occupancy (opaque counts). Also bake light: per-vertex light = max-ish of the light at the 4 neighboring voxels around that corner (classic: average of face-adjacent voxel light + 3 corner neighbors). Simpler common approach: light sampled from the voxel adjacent to the face (the air cell in front of the face), same for all 4 verts, then AO multiplies. That gives flat per-face light; smooth light needs per-vertex sampling of the 4 cells touching that corner in the plane just outside the face. I'll do per-vertex: for the corner, sample the 4 voxels in the neighboring slice touching that corner, average sky and torch separately, multiply by AO. Store as vertex color rgb (encode: r=sky, g=torch? then shader mixes day color). Use vertex colors with a custom onBeforeCompile? Simpler: use MeshLambertMaterial with vertexColors:true and bake final color = blockColor * (skyLightsunTint + torchLighttorchTint) * AO * faceShade at mesh build time... but then day/night wouldn't update without remesh.

To get dynamic day/night without remeshing: encode light in vertex color channels and use a custom ShaderMaterial:

• attribute color.r = sky light 0..1, color.g = torch light 0..1, color.b = AO*faceShade.
• uniform uSunColor (rgb), uTorchColor (rgb warm constant), per-block base color: pass as another attribute? Base color per block type with slight variation: use a second attribute aColor (vec3) OR use texture atlas. Texture atlas: I could generate a small canvas texture atlas procedurally (16 tiles, noise-speckled) — that gives the Minecraft-y texture look cheaply and avoids a per-vertex color attribute. Procedural canvas atlas: grass top (green speckle), grass side (dirt+band), dirt, stone, sand, log side/top rings, leaves (with holes?), planks, brick, glass, torch, glowstone, snow, water (animated via uniform time offsetting UV). This is very doable and looks way better than flat colors.

UV mapping: faces pick tile from atlas by block type + face direction (top/side/bottom). Water animated: shift uv.y by time in shader for water material only (separate mesh+material).

Shader (custom ShaderMaterial "voxelMat"):

Add small ambient floor so caves aren't pitch black (0.03) plus torch.

Fog: manual linear fog in shader (cheap, consistent).

Translucent water: separate mesh, same shader + uniform alpha, animated UV scroll + slight vertex wave? Keep vertex static, uv scroll, depthWrite false.

Glass: semi-transparent tile in atlas; glass faces meshed into the translucent mesh too (alpha ~0.4, but with texture alpha; discard where tex.a<0.1 for window frame pattern?). Simple: glass tile mostly transparent with border; render in translucent mesh with alphaTest? Using transparent:true sorting issues between water/glass are minor.

Leaves: opaque with alphaTest texture holes (classic fast graphics) → mesh into opaque mesh with alphaTest 0.5. Light-wise treat leaves as transparent-ish for light (attenuate by 2) but solid for culling? For simplicity: leaves are opaque for culling (full cube) — looks fine.

Torch: not a full cube — model as a small cuboid (0.2×0.5×0.2) centered? Non-cube geometry in mesher: special-case torch: emit a small box (8 faces? 6 faces smaller cube). UV from torch tile. It's non-opaque, so neighbors render faces against it. Collision: treat as non-solid (walk through, like MC flowers). Placement: on top of solid blocks only (or sides? just top for simplicity).

Physics: Player AABB 0.6×1.8×0.6, eye 1.62. Gravity 28, jump vel 9.5, walk 5.5, sprint 8, fly speed 14. Collision resolve axis-by-axis (move x, resolve; y; z). Solid = block id in solidSet (not air/water/torch/flowers). Water: swim? Make water slow movement + buoyancy lite: if in water, gravity reduced, jump swims up. Simple and fun.

Raycast: Amanatides & Woo DDA up to 7 blocks from eye along look dir. Highlight wireframe box (THREE.LineSegments with EdgesGeometry of unit box). Dig: mine target (not bedrock... add bedrock at y=0 unbreakable, id 16). Place: adjacent cell if empty/water and not intersecting player AABB.

Particles: pooled instanced small cubes (InstancedMesh, 512), on break spawn 12-20 with block color (sample average tile color), gravity, fade/shrink, land none. Also place "puff".

Sound: WebAudio: break = filtered noise burst pitched by block type; place = thock; footsteps every distance while grounded (soft noise tick); ambient: wind noise loop (slow LFO), birds by day (random chirp synth), crickets by night (rapid pulsed high blips), cave rumble? Keep birds+crickets+wind. Master mute button + M key. Start audio on first user gesture.

Sky: big inverted sphere with shader: gradient by sun elevation, sun disc + glow, moon disc opposite, stars (hash sparkle) at night, horizon haze. Uniform time-of-day. Plus hemisphere+directional light for... wait, shading is baked in shader; do I need THREE lights at all? No! My custom voxel shader does its own lighting. So no three lights needed except maybe for the player-held... no held item. Keep it fully custom: day/night only changes uniforms (uSkyTint, sky shader, fog color).

Clouds: flat voxel-ish clouds: a few hundred white translucent boxes drifting at y~70, or a scrolling noise texture on a plane. InstancedMesh of ~120 flattened boxes with soft white material (MeshBasicMaterial transparent 0.5, no lighting) — matches voxel aesthetic.

Day/night cycle: time param 0..1, auto-advance (adjustable speed, default 1 full day = 4 min), slider in HUD. Sun direction from time; uSkyTint = mix(nightBlue, dayWhite, daylight) etc. Torch light constant.

HUD: title, seed, FPS, position/biome? hotbar (DOM 9 slots with canvas-rendered tile icons? Simpler: CSS colored swatches with labels). Crosshair. Help overlay listing controls. Buttons: New World (seed), Fly toggle, Sound, Snapshot, Time slider. Overlay start screen ("click to play") for pointer lock.

Mobile/touch: left joystick (move), right side drag look, tap = dig? MC-style: tap place, long-press dig? Simpler: two buttons [MINE] [PLACE] + [JUMP] + joystick + look drag. Raycast from screen center still. I'll implement: joystick left; drag right half to look; buttons JUMP / MINE / PLACE / FLY. This is standard and doable.

Adaptive quality: measure fps; tiers change: render pixelRatio (1 → 0.75 → 0.6), clouds count, particles, view-distance fog? Keep 3 tiers. Auto + manual? Auto only with display of tier, like previous demos (they show quality in stats).

Snapshot: render then toDataURL, download PNG.

Scope check: This is big — maybe 1800+ lines. That's fine; I'll write it in chunks and test thoroughly with node. Risks: mesher bugs, lighting BFS bugs, physics tunneling. I'll be careful and test in node.

Let me also handle world borders: bedrock walls at edges (x/z boundary columns unbreakable stone→bedrock) or invisible walls + fog. Simplest: treat out-of-bounds as solid stone for culling/collision (so edge faces not rendered... actually then boundary shows a cliff — fine, it's an island? Making the world an island surrounded by endless water plane would look great: render a large water plane at sea level extending to fog. Terrain gen lowers edges into ocean (falloff mask toward edges). Out-of-bounds treated as air for meshing (so island cliffs render) but collision clamps player inside. Falling into water: swim; can't leave bounds (invisible wall). Good: "island" aesthetic + endless sea plane + fog.

Sea plane: big plane with the water shader (semi-transparent, animated uv) at y=seaLevel+~0.9? The voxel water tops at seaLevel (water fills up to sea level where height < seaLevel). Plane at same height minus tiny offset. Z-fighting between plane and voxel water tops at distance — plane extends beyond island; voxel water only within world. Offset plane by -0.02 and rely on fog. Fine.

Let me now also double check the physics/mesh constants to keep perf good:

• World 144×144×64 = 1,327,104 voxels (Uint8 blocks + Uint8 light = ~2.6MB).
• Chunks 9×9 = 81 chunk meshes, each up to 16×64×16. Typical surface chunk emits ~3-8k triangles. Total maybe 300-500k tris — OK for desktop; adaptive pixelRatio helps mobile.
• Rebuild chunk on edit: fast (iterate 16k voxels). Edits also dirty neighbor chunks if on border.
• Lighting BFS bounded radius 15.

Alright — but before diving in, let me reconsider whether the voxel thing is really what I want to build vs. something with more "visual wow" per effort. The collection already has 49 highly-polished demos; a first-person voxel sandbox is genuinely different in kind (playable game vs. observatory), and a milestone #50 as "a whole little world you can walk in" feels right. Yes. Build it.

Name: "Voxelia" — hmm, maybe "VOXEL VALE" or "TERRACUBE"... "050-voxelia" folder, title "Voxelia — Pocket Voxel Wilderness". Wait, is there any existing demo with "voxel"? grep to be sure.

****************************************************************************************************************************on.

**************************************************************************************************************************************************************************************************************************************de.

three@0.160.0 installed in /tmp/voxeltest. Now write the demo. I'll write it in chunks using read_write_file_in_shell_environment (write mode for first chunk, then append via shell cat >>? The tool writes full content; appending via execute_shell_command heredoc is risky with special chars. Better: write several part files via read_write_file_in_shell_environment then concatenate with cat. read_write_file with mode write writes entire content — for appends I'd need shell. Plan: write /tmp/parts/p1.html ... p5.html via the file tool (full content each), then cat p1 p2 ... > /space/demos/050-voxelia/index.html. That avoids heredoc escaping issues entirely.

Let me now write the full code carefully.

Chunk/part plan:

• p1: HTML head + CSS + HUD DOM + importmap + <script type="module"> open + constants + PRNG + noise.
• p2: blocks/atlas generation + worldgen.
• p3: lighting + mesher.
• p4: sky/clouds/particles/audio.
• p5: player physics/input/touch + main loop + UI + boot + exports + close tags.

Now write the actual code. I'll be meticulous.

Key decisions recap:

• SX=SZ=144, H=64, CX=CZ=9, CS=16, SEA=22.
• idx = (x*SZ + z)*H + y.
• Light Uint8: hi nibble sky, lo nibble torch.
• Blocks enum: AIR=0, GRASS=1, DIRT=2, STONE=3, SAND=4, WATER=5, LOG=6, LEAVES=7, SNOW=8, PLANKS=9, BRICK=10, GLASS=11, TORCH=12, GLOWSTONE=13, FLOWER_RED=14, FLOWER_YELLOW=15, BEDROCK=16, GRAVEL=17? skip gravel. CACTUS? skip.
• solidOpaque: grass,dirt,stone,sand,log,leaves(leaves opaque-ish for culling but alphaTest), snow,planks,brick,glowstone,bedrock. glass separate (translucent), water translucent, torch/flowers non-solid decor.

For culling: face drawn if neighbor is "transparent": air, water(if self not water), glass(if self not glass), torch, flowers, leaves? Leaves drawn against leaves? MC fast graphics: leaves cull against leaves — treat leaves as opaque for culling. Glass: cull glass-vs-glass.

emitFace condition: neighborOpaque = opaque(nb). if opaque(self): emit if !neighborOpaque && nb!==WATER? No: emit if neighbor is transparent-ish: !opaque(nb) — that includes water (draw face against water: yes, e.g. sand under water shows). If self===WATER: emit if nb===AIR or nb===TORCH/FLOWER (rare) — basically nb!==WATER && !opaque(nb). If self===GLASS: emit if nb!==GLASS && !opaque(nb).

Atlas tiles: 4 cols × 5 rows of 16px → canvas 64×80. UV scale per tile: u0=col/4, v0=1-(row+1)/5 (canvas row 0 is top; texture v=1 top after flipY). THREE CanvasTexture flipY default true. I'll compute with flipY=true semantics: uv = (u0 + lu/4, v0 + lv/5) where v0 measured from bottom: tile row r (0=top) → v0 = 1 - (r+1)/5.

Tile map: row0: grass_top, grass_side, dirt, stone row1: sand, water, log_side, log_top row2: leaves, snow, planks, brick row3: glass, torch, glowstone, bedrock row4: flower_red, flower_yellow, (spare), (spare)

Block→tile per face:

• GRASS: top grass_top, bottom dirt, side grass_side.
• LOG: top/bottom log_top, side log_side.
• others single tile.

AO + light sampling per vertex: for face with normal n at voxel (x,y,z): neighbor cell base = (x+n.x, y+n.y, z+n.z). For each of 4 corners: offset tangent axes t1,t2 with signs s1,s2 ∈{0,1}: sideCell1 = base + t1s1', etc where s1' = s1?0? Hmm the standard: corner = base + t1(s1) + t2*(s2) with s∈{-1,+1} relative to face min corner... Let me define per-face explicit vertex data: each face defined by: dir vector n, and 4 corners in CCW with (u,v) coords. I'll hardcode FACES array:

faces = [ { // +x n:[1,0,0], corners: [ [1,0,1, 0,0], [1,0,0, 1,0], [1,1,0, 1,1], [1,0,1? ...]] } ]

Careful winding for outward-facing CCW. Let me define each face's 4 corners and the two tangent axes (du, dv) used for AO sampling. Standard table (used in many voxel tutorials):

px: corners (1,0,1),(1,0,0),(1,1,0),(1,1,1) with uv (0,0),(1,0),(1,1),(0,1); check winding: viewed from +x, axes: u goes -z? Let me verify normal via cross product: v0=(1,0,1), v1=(1,0,0), v2=(1,1,0). e1=v1-v0=(0,0,-1); e2=v2-v1=(0,1,0). normal=e1×e2=(00-(-1)1, (-1)0-00, 01-00)=(1,0,0). ✓ CCW from +x. nx: corners (0,0,0),(0,0,1),(0,1,1),(0,1,0): e1=(0,0,1), e2=(0,1,0); n=e1×e2=(00-11, 10-00, 01-00)=(-1,0,0) ✓. py: corners (0,1,1),(1,1,1),(1,1,0),(0,1,0): e1=(1,0,0), e2=(0,0,-1); n=(0*(-1)-00, 00-1*(-1), 10-00)=(0,1,0) ✓. ny: corners (0,0,0),(1,0,0),(1,0,1),(0,0,1): e1=(1,0,0), e2=(0,0,1); n=(01-00, 00-11, 0)=(0,-1,0) ✓. pz: corners (0,0,1),(1,0,1),(1,1,1),(0,1,1): e1=(1,0,0), e2=(0,1,0); n=(0-0, 0-11? compute: e1×e2=(00-01, 00-10, 11-00)=(0,0,1) ✓. nz: corners (1,0,0),(0,0,0),(0,1,0),(1,1,0): e1=(-1,0,0), e2=(0,1,0); n=(00-01, 00-(-1)0, -11-0*0)=(0,0,-1) ✓.

UVs: map corners in order to (0,0),(1,0),(1,1),(0,1) — but must match so textures upright: for side faces, u along horizontal tangent, v along +y. For px face: corners y: 0,0,1,1 → v= y. u: z values 1,0,0,1 → u = 1-z. Texture may appear mirrored; irrelevant for noise textures. Grass side band must be at TOP of texture → v=1 top of tile → corner with y=1 must have v=1 ✓ (corners 2,3 have uv v=1). ✓ for px (uv assignment in order (0,0),(1,0),(1,1),(0,1)) since corner order is y=0,0,1,1. For pz: corners y=0,0,1,1 ✓. nx: (0,0,0),(0,0,1),(0,1,1),(0,1,0) ✓. nz: (1,0,0),(0,0,0),(0,1,0),(1,1,0) ✓. Top/bottom orientation arbitrary.

AO sampling per corner: face normal n; tangent axes a,b (the two axes != normal axis). For corner c (with signs s_a = c[a]?1:-1 relative to face plane at base... standard: for the corner, side1 = voxel at base + a_dir, side2 = base + b_dir, cornerV = base + a_dir + b_dir, where base = voxel + n (the adjacent air cell), a_dir = unit axis a * (corner[a]), with corner[a]∈{0,1} mapped to sign: the corner's offset along a is 0 or 1; the direction from face-center: sign = offset==1 ? +1 : -1. Since face plane sits at the boundary, cells "beside" the corner outside the face are base + asign etc. where sign depends on which side of the face's own voxel the corner lies. Since face is at the boundary of its voxel, corner offsets along a are either 0 or 1; the adjacent-cell plane spans the face at n side; the side cell for corner with offset oa∈{0,1} is base + a(oa==1?+1:-1)? No wait — base cell occupies [base, base+1); the face's own voxel occupies [v, v+1). Along axis a (not the normal), base and v have same coordinate. The side cell touching that corner within the plane of base cells: if corner offset along a is 0, the neighbor is at base[a]-1; if 1, neighbor is at base[a]+1. Yes: sign = oa?+1:-1.

So per face, axes: axisA = first axis index where n[axis]===0 (e.g. for px: a=y? order: choose a=the axis of uv? any consistent). I'll compute in code: for face with normal axis k, a=(k+1)%3, b=(k+2)%3.

vertexAO = (s1&&s2) ? 0 : 3-(s1+s2+sC) → levels 0..3, brightness curve [0.45,0.62,0.8,1.0]? MC-ish: ao curve [0.4,0.6,0.8,1.0] — tunable. Only apply AO to... all faces (top faces too — subtle under trees ✓).

Per-vertex light: sample the 4 cells: base, side1, side2, cornerV (cells in the adjacent plane touching this corner): sky = average of sky nibbles; torch = average torch nibbles. That's smooth-ish. Normalize /15.

Shade per face direction: py 1.0, ny 0.55, px/nx 0.8, pz/nz 0.7? Multiply into vLight.b along with AO.

Water: top face slightly lower (0.875 height) for shore blending: special-case water top face corner y offset 0.875; skip AO for water (or light AO — fine, apply). Also don't draw water bottom/side against glass? edge cases fine.

Torch geometry: small box cx∈[0.375,0.625], y∈[0,0.625], z same. Emit all 6 faces of this mini box with torch tile, no AO, light sampled at its base cell. Its faces never culled. Flowers: cross quads: two diagonal quads (0.15..0.85, y 0..0.9), both windings (double-sided) — emit two quads with indices both orders, or set material side: DoubleSide for opaque mesh — leaves fine with DoubleSide? DoubleSide on the whole opaque mesh is wasteful but simplest: backfaces are culled gains little since most faces face outward; enabling DoubleSide globally lets flowers work. I'll set side: FrontSide and emit flowers double-quads explicitly (8 verts, 12 indices). Cleaner perf.

Flower light: sample base cell.

Translucent mesh: water + glass. Same shader, transparent:true, depthWrite:false, alphaTest 0? water alpha uniform ~0.78; glass tile has alpha in texture ~0.35 with frame opaque... single material: alpha = texture alpha * uAlpha? Set uAlpha=1 and bake water tile alpha 0.75 in atlas! Glass tile: mostly alpha 0.25 + frame lines alpha 0.9.

But wait — opaque pass with alphaTest for leaves: leaves tile alpha 0/1 pattern, alphaTest 0.45, opaque mesh material transparent:false.

Mesher output: {pos:Float32Array, norm?, uv, light(vec3), idx} — normals not needed by shader (face shading baked in vLight.b). Drop normals entirely! Positions, uv, light.

Geometry: BufferGeometry with position(3), uv(2), aLight(3). Index Uint32.

Chunk dirty system: world.dirty Set of chunkIndex; rebuild in tick (max 2/frame to avoid hitches... rebuilds are ~1-3ms, fine).

getBlock/getLight bounds: outside world horizontally: for meshing treat as AIR (island cliffs visible); below y<0: BEDROCK-ish opaque (so bottom faces not drawn); above: AIR. For collision: outside horizontal bounds → solid invisible wall? I'll clamp player position to [2, SX-3] etc. plus treat outside as solid in collision to be safe. Below y<0 solid.

Worldgen details:

Temperature/moisture noises → desert if temp>0.55 & near sea; snow if height>44 or temp< -0.45.

Surface layering: top block: sand if h<=SEA+1.5 (beach/desert), snow if cold, grass else; sub 3-4 dirt (or sand depth 4 in desert/beach), then stone. Underwater floor: sand if h<=SEA+1.5 else dirt... use sand near shores, dirt/gravel else: floor block = sand if h>SEA-6 else stone? Keep sand for h<=SEA+1.5.

Caves: two 3D fbm fields (2 octaves each for speed) n1,n2 at scale 0.06; cave if n1n1+n2n2 < 0.02 (tunnel-ish); only y in [6, h-4]; don't carve if above SEA-2 and block is under water body... since y<=h-4 and h may be below sea (ocean floor caves → would open to water; acceptable? water won't flow in (no sim), you'd see dry caves under seabed with water above — fine, actually cool "air pockets". To avoid weird surface holes: y<=h-4 ensures ≥3 blocks cover. ✓ Also cap y<=40.

• Glowstone "crystal" veins: where cave noise near threshold & hash(x,y,z)<0.02 → glowstone embedded in cave walls: simpler: after carving, for each cave air cell with hash<0.004 set a random solid neighbor to glowstone? Cost fine. Simpler: when carving, if the carved cell had hash>0.995, leave glowstone instead of air → glowstone blobs floating in caves? Place glowstone where n1²+n2² in [0.02,0.028] (shell around tunnels) & hash<0.3 → embedded veins at tunnel walls ✓.

Trees: for each (x,z) with grass surface: hash01(x73,z91 ^ seed): plains 0.006, forest 0.02 prob; skip if another tree within 2 (use hash grid). Tree: trunk 4-6 logs; leaves: sphere-ish radius 2 around top (|dx|+|dy-ish|... use 5x5x3 with corner trimming). On snow biome: pine: trunk 6-8, leaves layers narrowing. Desert: cactus? skip cactus; desert has dead bushes? skip.

Flowers on grass: hash<0.015 → flower red/yellow.

Water fill: for y from h+1..SEA where h<SEA → water.

Bedrock y=0 (+ y=1 scattered? just y=0).

Skylight gen: for each column: l=15; for y=H-1..0: if opaque: l=0 else l stays 15 until? Vertical: sky=15 for all air above surface; below first opaque → 0. Then BFS: queue all cells with sky>0; propagate: neighbor gets max(0, l-1) if > current; down direction no attenuation if current==15 (MC rule) — include it (cheap check). Bound: full world BFS ok (only visits reachable air; caves bounded). Use Int32Array queue preallocated size V? Worst case huge but typical visits small; to be safe cap queue at V entries (1.3M×4B=5.3MB, fine) or use plain array with push (slower but simpler). I'll allocate Int32Array(V) reuse — V=1.3M → 5.3MB ok. Actually BFS over the whole world's air (~60% of 1.3M = 800k) with push/shift on JS Array is fine (~fast enough, one-time). But per-edit relight also uses BFS — with bounded radius. I'll implement generic floodLight(channel, seeds[], maxR) using Int32Array ring buffer allocated once (say 1<<20 entries... need up to surface area of radius-15 ball ~ 4πr²≈2800 cells in queue at once; but removal pass enqueues region volume 4/3πr³≈14000; allocate 65536 ring with wrap handling? Use plain JS arrays with head index — simpler and safe.)

Torch BFS similar, seed all torch/glowstone cells with 14/15 at gen.

Relight on edit:

• setBlock(x,y,z,id):
  1. old=id at cell; set.
  2. Torch channel: if old was emitter → removeFlood(torch, x,y,z); if new emitter → addFlood. If opacity changed → removeFlood from that cell then re-propagate from all 6 neighbors (addFlood seeds = neighbors with their values minus atten)... The classic general approach for opacity change: run removeFlood seeded at cell with its old light (0 if none) — this clears dependent light; then addFlood seeded from all neighbors (each contributing theirLight-attenuated through... hmm attenuation depends on target cell opacity (now changed). addFlood normally: for seed cells list of (pos,value): BFS: for each neighbor: nv = value - atten(neighbor); if nv > light(neighbor): set, continue. With seeds = the 6 neighbors of the edited cell with their current values, propagation recomputes through the edited cell too. That works for both opacity increase & decrease IF we first clear: removeFlood(seed=cell, oldValue=cell's light before change) clears light that depended on the cell... but clearing only from the cell itself misses light that flowed through it from elsewhere? The standard algorithm (seed removal at the changed cell with the cell's previous light level) is correct: removeFlood spreads from cell clearing values ≤ propagated values... I'll implement the well-known version:

Wait the classic: neighbor with nl < cl gets cleared (it was lit by us), neighbor with nl >= cl is a source to re-add. This handles everything (approximation is exact for unit atten graphs). Then after removal(s), addFlood(requeueSeeds + neighbor seeds).

For sky channel on edit: simpler full approach: recompute the column scan (cheap) then addFlood from all cells in the column that have light + removeFlood from cells that lost it. Complicated. Alternative used by many tutorials: on block change at (x,y,z):

• sky removal: if we placed opaque where sky was, removeFlood sky from the cell below... ugh.

Cleaner: implement relightColumn(x,z):

1. For the column, compute new vertical values: scan y top→down, val=15 until first opaque → below 0. Collect cells where value DECREASED vs stored → those need removal flood; cells where INCREASED → addition seeds. But horizontal bleed complicates: stored value may exceed vertical value due to sideways propagation (e.g., cave mouth). Robust simple method:

• removalSeeds: cells in column where stored > newVertical → removeFlood(stored value) (which collects reprop seeds).
• set column cells to newVertical (min of stored-after-removal and newVertical? After removal flood those cells are 0; but removal flood may also clear horizontally-bled light that should return — the reprop seeds handle it).
• additionSeeds: all cells in column with newVertical>0 (set their stored to newVertical first, they act as sources) + reprop seeds from removal.
• addFlood(additionSeeds) — but addFlood seeds must already have their light SET to the seed value (BFS then spreads). ✓ Vertical rule: downward propagation of 15 stays 15 — in column scan, cells above first opaque all 15 ✓; in addFlood BFS, moving down from a 15-cell into air gives 15 (no atten) ✓.

Torch channel analogous but only when emitter added/removed or opacity changed:

• emitter added: addFlood(seed=cell value=14 after setting).
• emitter removed: removeFlood from cell (value=stored), then addFlood(reprop seeds).
• opacity changed (solid placed/broken, non-emitter): removeFlood(cell, stored) → set stored 0 → addFlood(neighbor seeds as sources with their stored values + reprop seeds). General addFlood needs seeds to have stored light already = value; neighbor seeds: their stored values unchanged ✓.

I think implementing generic removeFlood/addFlood per channel with atten(cellType) and using them as above works. Cost bounded by region affected (radius ≤15).

Testing in node will validate: place torch in dark cave → light around; remove → dark; build wall across lit area → shadow side dark-ish etc.

atten(cell): opaque→16 (blocks), leaves→2? leaves opaque in my table... make leaves attenuate 2 but cull opaque. WATER→2, GLASS→1, air/torch/flower→1. Sky atten same.

Hmm wait: if leaves are "opaque" for the vertical sky scan, tree canopies create dark shadow columns — with horizontal bleed radius it's soft-ish. But attenuation through leaves=2 conflicts with opaque scan (scan sets 0 below canopy). Compromise: leaves NOT opaque for sky scan (light passes with atten 2 per cell: scan: val = max(0, val - (leaves?2: opaque?16:0))... vertical scan with gradual atten: l = opaque? 0 : max(0, l - extra(leaf=2, water=2)) with l reset rule for 15-down? Keep simple: vertical scan: if opaque→0 else if leaves/water→ max(0,l-2) else l unchanged. Then BFS bleed fixes sides.

opaque for scan = solidOpaque minus leaves? Define lightOpaque(id): solid && id!==LEAVES && id!==GLASS... glass in solid set? Glass solid for collision & cull-separate. lightOpaque: all solid opaque + not glass, not leaves.

Player collision: AABB half extents 0.3, height 1.8, eye 1.62. collideSolid(id): solidOpaque + glass + bedrock (i.e., all cubes except air/water/torch/flowers). Move axis steps with substepping if dt large (clamp dt 0.05, single step fine at 60fps: 8m/s*0.016=0.13m per step — no tunneling through 1m blocks ✓).

Swim: if head or feet in water: gravity*0.35, velocity damp 0.92, jump = upward swim 4.5; sink slow. Exit water near shore: jump onto block works since swim up + move.

Highlight: LineSegments box + also a slightly transparent dark face overlay? Just wireframe white box, scale 1.002.

Break/place cooldown: 0.18s; hold-to-mine repeat.

Hotbar UI: DOM: 9 slots; each slot a div with mini canvas icon (24×24) rendered from atlas tile (drawImage of the canvas region scaled, plus top-face skew? simple flat tile image fine). Slots: [GRASS, DIRT, STONE, PLANKS, BRICK, GLASS, SAND, TORCH, GLOWSTONE]. Keys 1-9, wheel cycles.

Stats HUD: FPS, quality tier, XYZ, time HH:MM, "looking at" block name, chunk rebuild count? Keep: FPS · Q · pos · time.

Help panel: toggled H, listing controls. Start overlay describes too.

New world: button prompts seed via input? Use prompt()? Avoid; use dice button → random seed; plus seed shown; maybe allow ?seed= URL param. ✓ Also R key? R conflicts none (R=regen with confirm? just regen instantly — but accidental... overlay button only + key N).

Snapshots: key P.

Quality tiers: measure avg frame time over 60 frames: >19ms → tier down (pixelRatio 1→0.8→0.66; clouds 140→80→40; disable bloom at LOW; particles cap). >improve if <12ms and tier below start. Bloom: include UnrealBloomPass? With custom ShaderMaterial output, bloom pass works on rendered frame ✓. Threshold 0.85 strength 0.35 radius 0.4 — makes torches/glowstone/lava pop at night, subtle in day. Additive sky sun disc will bloom nicely. I'll include composer with RenderPass + Bloom + OutputPass. At LOW tier use plain renderer.render. Import from addons: EffectComposer, RenderPass, UnrealBloomPass, OutputPass ✓ (0.160 paths).

Colorspace: renderer.outputColorSpace = SRGBColorSpace; with composer, OutputPass handles tone map/sRGB. Set renderer.toneMapping = ACESFilmicToneMapping? With bloom + OutputPass in 0.160: OutputPass applies tone mapping & color space. My custom shader outputs linear-ish colors; textures from canvas are sRGB → set atlasTexture.colorSpace = SRGBColorSpace so three converts on sample (three r152+ auto decode in shader when colorSpace set ✓).

Sky shader: sphere radius 600 (inside, BackSide), uniforms sunDir, daylight, time. Color: zenith/horizon mix by sun elevation; sun disc: smoothstep(cos angle); moon: disc at -sunDir with crater texture? plain soft disc; stars: hash on direction (only night): star = step(0.9995, hash(floor(dir*300))) twinkle by time. Clouds-in-sky? we have voxel clouds. Fog color = horizon color at eye level → share uniform.

Sun/moon as THREE directional lights not needed (custom shading), but clouds InstancedMesh uses MeshBasicMaterial (unlit) tinted by uniform-ish — set material color per frame (day white, night dim blue) ✓. Particles material: MeshBasicMaterial vertexColors? InstancedMesh color per instance × basic material with fog — particles should glow slightly at night? Keep basic material; fine.

Crosshair: CSS.

Touch controls:

• joystick div bottom-left (appears on touch), look = drag anywhere right 60% screen; buttons: JUMP (bottom right), MINE / PLACE (right side), FLY toggle small. Use pointer events with pointerId tracking.
• tap (short, no drag) on look area = MINE? MC PE uses tap-place... I'll do: short tap = place? Risky; buttons only. Fine.

Pointer lock: click overlay/canvas → requestPointerLock; ESC shows overlay again (pause). While unlocked, game pauses (time continues? pause sim except ambient). Show "click to resume".

Alright — also URL params: ?seed=123 ✓.

"Biome" readout: temp/moist at player pos → label (OCEAN/BEACH/PLAINS/FOREST/DESERT/SNOWY PEAKS) in stats. Cheap, nice.

Footsteps: distance accumulator while grounded & moving; play soft tap every 2.2m, pitch by block under feet (stone higher, grass softer...).

Ambient audio: wind (looping filtered noise, gain by altitude+weather), day birds: random chirps every 4-9s (two osc blips), night crickets: pulsing 4.2kHz ticks. Implement lightweight scheduler in tick.

OK. One more mechanic for fun: TNT? No. Buckets? No. Keep polish over features.

Also torch placement on walls? only top faces — enforce: placing torch uses the face normal; only if normal is +y and cell above target empty; else fallback normal placement but torch floats? Simply: if selected is torch/flower and hit face isn't top → place anyway as floating? Disallow with a soft error sound. Keep: torch requires top face; flowers too.

Glowstone: normal cube, light 15.

Block break rules: bedrock unbreakable. Water not mineable (skip water in raycast? MC raycast passes through water — my DDA: treat water as pass-through (continue), so you mine blocks under water ✓).

InstancedMesh particles with per-instance color: use setColorAt. Update matrix per frame for active particles (max 384). Fine.

Alright, also the world name/seed HUD and saving? no persistence (localStorage optional: save world edits? skip — seed regen only. Actually a nice touch: persist edits to localStorage keyed by seed? Skip — scope.)

Now — write the code. I'll aim for clarity+compactness. Let me start writing part 1.

Note on module exports for testing: end of script: export { mulberry32, fbm2, generateWorld, buildChunkMesh, floodAdd, floodRemove, raycastVoxel, WORLD_CONSTS... }. Guard boot: if (typeof window !== 'undefined' && typeof document !== 'undefined') { boot(); } — but imports of addons (EffectComposer etc.) execute fine in node ✓.

Careful: pointer lock import not needed (custom mouse look with movementX — write own: yaw/pitch from mousemove). Yes, custom look avoids PointerLockControls quirks.

Renderer antialias true.

Let me write the code now. I'll write it in 6 parts to /tmp/vx/partNN.txt then cat into /space/demos/050-voxelia/index.html.

Let me carefully write out everything. Start.

Part 1: doctype, head, css, hud, importmap, script open, constants, rng, noise.

CSS needs: overlay, crosshair, hotbar slots, hud panels, touch controls, help panel. Let me write.

Details for atlas drawing (16px tiles): helper: function tile(col,row, painter) — get ctx, loop pixels.

• grass_top: base #5da336 with speckle ±12, few lighter blades pixels #6fbf45.
• grass_side: dirt base (#8a5f3c speckle), top 3-4px green band with jagged edge (green hangs down 3 + hash%3).
• dirt: #8a5f3c speckle.
• stone: #8d8d8d speckle ±10, few darker cracks.
• sand: #e0d29a speckle.
• water: #3f76e4 with slightly lighter horizontal streaks, alpha 0.75 → need rgba pixels: use fillStyle with alpha and clearRect first. In atlas canvas with transparency: water tile pixels alpha ~190.
• log_side: vertical bark stripes #6b4a2a / #5a3d22.
• log_top: rings: concentric squares alternating #b08a4f/#8a6a3c.
• leaves: #3e7d2c speckle with ~18% transparent holes (alpha 0).
• snow: #f2f7fa speckle slight blue.
• planks: horizontal boards #a9814b with darker seams every 4px + nail dots.
• brick: 2-row offset bricks #9e4b3c with mortar #b7a89a 1px.
• glass: alpha 0.28 fill #cfe8ff, border frame alpha 0.85 #e8f4ff, diagonal shine line.
• torch: mostly transparent; draw handle brown 3px wide center bottom half, top 4px flame yellow/orange alpha 1. (Torch rendered as small cube so texture shows on all faces.)
• glowstone: #f7d774 with brighter blobs #fff3b0 speckle — luminous.
• bedrock: #3a3a3a with big dark/light noise #222/#555.
• flower_red: transparent bg; stem green 2px center; petals red circle top; alphaTest material — but flowers are in OPAQUE mesh with alphaTest 0.45 ✓.
• flower_yellow same yellow.

Water in translucent mesh (transparent true, no alphaTest) ✓. Glass also translucent mesh ✓.

All tiles drawn with a seeded RNG so consistent.

UV inset: to avoid bleeding between tiles at mip levels: inset uv by 0.5px of tile: e=0.5/16 of tile size. Also generateMipmaps true + LinearMipmapLinear; anisotropy 4. With inset fine.

Water UV scroll: shader uniform uTime; in fragment: if uWater>0? separate material for translucent mesh with uWater uniform (only water scrolls; glass static — glass uv would scroll too if same shader! Offset only when a flag attribute... simplest: two materials for translucent mesh? One mesh one material. Trick: water tiles have v in specific range; in shader scroll uv.y only if uv within water tile row? Hacky. Alternative: give translucent shader uniform uTime and scroll based on an attribute aWater (float) per vertex (1 for water, 0 glass). Add float attribute to translucent geometry only. ✓ fine.

Vertex wave for water top: skip.

Now the voxel vertex shader:

fragment:

For the translucent material add attribute float aWater; and uv.y += aWater * sin? — scroll: uv.y += aWater * uTime * speed? Scrolling texture within atlas tile: uv += small offset mod tile size — scroll within tile requires wrapping: fract((uv - tileOrigin)tileSize ...) — simpler: subtle distortion: uv += aWater * 0.02 * vec2(sin(uTime1.3 + position.y... position not varying... use vUv40). Just wobble: uv += aWater0.015vec2(sin(uTime1.7+vUv.x40.0), cos(uTime1.3+vUv.y*40.0)); — gentle shimmer without wrap issues (stays near tile since amplitude small). ✓

light calc: vec3 L = uSkyaLight.r + uTorchaLight.g; L *= aLight.b; also min ambient: L = max(L, vec3(0.03)); color = tex.rgb * L. fog: f = smoothstep(uFogRange.x, uFogRange.y, vFogDepth); mix(color, uFogColor, f). alpha: tex.a (×uniform for water overall? bake in atlas).

Opaque material defines alphaTest 0.45 in material (three injects? For ShaderMaterial, alphaTest uniform isn't automatic — implement manually: if(tex.a < 0.45) discard; via #ifdef ALPHATEST). I'll write two ShaderMaterials sharing shader source with different defines/uniforms.

Sky shader: as described.

fogRange: near 60, far 220 (day) — animate far with tier? fog far = 200 high, 150 low tier (hides far chunks? whole world is 144 wide — max view across ~200 diag; fog far 190 ok).

Clouds: boxes at y=66..72, sizes 6-14 x 1.5 x 4-8, drift +x wrap around world bounds; MeshLambert? use MeshBasicMaterial color animated. transparent 0.55 opacity, depthWrite false.

Moon/sun: in sky shader only ✓.

Now — hotbar icons: render tile canvas → use atlas canvas drawImage region into slot canvas with image-rendering: pixelated, scaled 16→28px. ✓

Biome label: from temp/moist/height at player.

OK, writing parts now. Also add keyboard: WASD move, Space jump, F fly, E cycle hotbar? (wheel does), 1-9 select, H help, M mute, N new world, P snapshot, Shift sprint, Ctrl? none. Q/E? Q = toggle fly alt? Keep F only.

Also add subtle hand viewmodel? skip.

Looking-at readout: block name in stats.

Alright, code time. To minimize risk of tool-write mistakes, I'll write each part file with read_write_file_in_shell_environment (mode write, full content per part), then concatenate.

Let me draft the entire JS mentally once more for correctness on tricky functions:

floodAdd(world, ch, seeds): seeds = array of [x,y,z] (light already stored). Use arrays qx,qy,qz (plain JS arrays as stacks/queues with head pointer).

Wait GLASS atten 1 (clear). TORCH/FLOWER 1. solid others 16 (>15 → blocks).

BFS neighbor: nl = cl - atten(nid); if nl > curL(n) { setL; push }. Down special: if ch===SKY && cl===15 && dir down && atten small? MC: vertical sky 15 propagates down at 15 through air. Implement: if ch sky, cl===15, moving down, nid not opaque → nl=15. ✓ (with leaves atten? keep simple: nl=15 if lightAtten(nid)<16 → treat leaves as atten 2 → nl = 15-? — simplest: if down && cl===15 && lightAtten(nid)<=2 → nl = 15 - (lightAtten(nid)-1) → air 15, leaves/water 14. OK.)

floodRemove(world, ch, x,y,z):

Note: when cl could be 0? seeded with val>0 always (only call when removing known light). Neighbor with nl >= cl → reprop. BFS continues through cleared cells only. ✓ This is the standard algorithm. For sky vertical: removal of a 15 column: cells below with 15... neighbor below has nl=15 >= cl=15 → reprop seed → floodAdd re-spreads 15 downward ✓✓.

But careful: floodAdd from reprop seeds: seeds' stored light already set (they weren't cleared) — floodAdd treats seeds as sources: for each seed, try spread to neighbors. ✓

Column relight (sky):

Then also horizontal seeds: cells adjacent (same y) outside column get re-lit via floodAdd spread ✓. And removed sideways light handled by floodRemove's own clearing + reprop ✓.

Torch on setBlock:

✓ handles emitter place/remove AND opacity change (placement of opaque clears via remove since oldTorch may be 0 — hmm: placing opaque block in a lit area: oldTorch at cell = e.g. 10 (air cell had light). oldTorch>0 → floodRemove clears light that depended on that cell ✓; new emission 0; neighbors re-spread but the new opaque cell atten 16 blocks ✓. Breaking a block: oldTorch=0 (opaque had 0 stored? we don't store light in opaque cells — floodAdd never sets into opaque since atten 16 → nl negative ✓ stored 0). Breaking: cell becomes air with 0; neighbors spread in ✓ (no remove needed).

Edge: placing torch INTO lit area — same flow ✓.

Sky on setBlock: relightColumn(x,z) always (cheap 64-scan + floods) ✓.

After light updates: markDirty chunks around (x,z) radius 1 + vertical all in column (chunk column same since chunks full height) → dirty chunk of (x,z) plus neighbor chunks if x/z near border (within 1 or within light radius 15? Lighting changes bleed up to 15 → chunks beyond immediate neighbor could change vertex light! For mesh correctness, light changes affect chunk meshes within radius 16. Marking a 3×3 chunk area (radius 16/16=1 chunk) — light 15 reaches 15 blocks < 16+? A torch at chunk border could affect vertices up to 15 away → up to 1 chunk beyond? 15 < 16 so only immediate neighbor chunks (the ones touching) — vertex light samples cells up to 2 away from the face... mark dirty all chunks intersecting circle radius 17 → chunk coords floor((x±17)/16) → 3×3. Remeshing 9 chunks per edit too slow? Each ~2-4ms → 30ms hitch. Compromise: mark 3×3 only when light changed significantly (torch/glowstone involved or sky column changed surface); plain digs mark 1+neighbors-if-border. Even 9 chunks × 2ms = fine occasionally. I'll mark radius-based always but rebuild spread over frames (max 2/frame) → smooth. ✓

Chunk rebuild iterates 16×64×16 = 16384 cells × faces — with light sampling per vertex (4 cell samples × 4 verts × 6 faces)... per chunk worst case heavy but typical surface chunk ~2-5ms JS. OK.

For meshing light sample inline: lightOf(x,y,z): bounds: outside horizontal → sky 15 torch 0; y<0 → 0; y≥H → sky15. For vertex: average of 4 cells: (base, s1, s2, corner). Implement per face with axis math.

AO: occ(cell) = solidOpaque(no leaves? MC counts leaves as occluders off; I'll count solid && id!==LEAVES && id!==GLASS) — smooth.

Face shade: py 1.0 / ny 0.5 / px,nx 0.75 / pz,nz 0.62? Slight variation. ✓

Water surface: top face at y+0.875: corner offsets y scaled: when emitting py face for WATER use height 0.875. Also side faces of water: full height? Then side sticks above top by 0.125 — visible at shore against air: MC draws water sides full. Fine.

Skip drawing water top face if cell above is water ✓ (culling handles: neighbor water → no face). Side face between water and air ✓ drawn.

Raycast DDA (Amanatides-Woo) with water passthrough, returns {x,y,z,nx,ny,nz,id} or null, maxDist 7.

Break particles color: average color per block id (precomputed table).

Audio engine: minimal wrapper: ctx lazy; master gain; noise buffer precomputed; helpers: blip(freq,dur,type,gain), noiseBurst(dur,filterFreq,Q,gain,pitch?). Ambient: windSrc = looping noise through lowpass 400 + gain LFO via setTargetAtTime in tick. birds/cricket schedulers with setTimeout guarded by ctx running.

Footstep/break/place mapping by block: stone/brick/glowstone/bedrock → 'stone' sounds; sand/snow → soft; wood log/planks → knock; grass/dirt → thud; glass → chime-break (higher noise + ring).

Now HUD layout:

• top-left: title + seed.
• top-right: stats.
• bottom-center: hotbar.
• bottom-left: panel with buttons: NEW WORLD, FLY, SOUND, HELP, SNAP + TIME slider + speed? Keep panel minimal: row1: time slider; row2 buttons NEW/FLY/SOUND; row3 HELP/SNAP. Hint text bottom-right? Controls listed in help overlay.
• center crosshair.
• overlay start screen.
• touch UI container.

Alright, and the help overlay (H): absolute panel listing keys; hidden by default after start? Show start overlay with full controls; H toggles compact help.

Edge cases to remember in code:

• requestPointerLock with unadjustedMovement? skip.
• On pointerlockchange exit → show resume overlay (not the title one; reuse with "PAUSED — click to resume").
• prevent context menu.
• wheel selects hotbar (deltaY sign).
• Resize handler.
• Snapshot: renderer.render then canvas.toBlob → a.download. With composer: composer.render() then read renderer.domElement ✓ (preserveDrawingBuffer not needed if toBlob same frame right after render ✓).

Quality tiers: HIGH: pr=min(dpr,2), bloom on, clouds 130; MED: pr=1, bloom on(weaker), clouds 90; LOW: pr=0.75, bloom off, clouds 50, fog far shorter (uFogRange.y=150) — fog hides nothing important. Auto: ema frame ms: >19 →down; <12 → up (max HIGH). Cooldown 3s between changes.

Stat DOM updates every 0.25s.

The boot sequence: build atlas → world gen (sync ~1-2s with loading text via overlay: do gen in setTimeout chunks? Simpler: show overlay "GROWING WORLD…", then setTimeout(()=>{gen; buildAllChunks; hide loading; show start}, 30)). Gen includes light floods (torch seeds all at once: collect all emitter cells during gen, one floodAdd with all seeds ✓ efficient).

Sky light gen: per-column scan (144×144×64 loop = 1.3M iterations fast) + then one global floodAdd sky seeded from... after vertical scan, horizontal bleed: seed = every air cell with sky>0 adjacent to sky=0? Simpler: seed ALL cells that have sky>0 (that's ~500k seeds...) too many. Better: seed only boundary cells: cell sky>0 with any neighbor sky < cell-? Actually floodAdd semantics: pushing a seed re-spreads its value to worse-lit neighbors; seeds = cells with sky>0 that have at least one neighbor with lower light → boundary only. Compute boundary set in one pass (check 6 neighbors) — only surface perimeter cells qualify (~few k). ✓ That's how caves mouths get lit.

But note the vertical-scan already gives 15 to all open-air; interior cave cells 0; boundary = surface cells adjacent to cave openings etc. ✓

Glowstone veins emit torch-light: seeds = all glowstone cells value 15? Glowstone cell itself solid — light stored IN the solid cell (MC stores emission in the block cell). floodAdd spreads from it to neighbors (atten applies to neighbor cell type ✓). Torches: value 14 stored in torch cell ✓.

BFS queue arrays: use Int32Array ring buffer sized 1<<21 (2M entries × 3 arrays? encode pos in one int: p = (x*SZ+z)*H+y fits in 21 bits (1.33M < 2^21 ✓). Single Int32Array(1<<21) = 8MB ring buffer reused globally ✓ with head/tail and mask. If overflow risk (whole world flood?) — sky gen boundary seeds bounded; worst flood visits all air cells ~800k < 2M ✓. Torch radius-bounded ✓. OK: QUEUE = Int32Array(1<<21), mask = (1<<21)-1, reset head=tail=0 per flood; push: q[tail&mask]=v; tail++. Overflow guard: if tail-head > mask → skip (shouldn't happen).

floodAdd(world,ch,seeds): seeds as pos ints (with stored light already set). For each pop: read cl=getL; if cl<=1 continue; for 6 dirs: np in bounds; nid=getBlock(np); att=atten(nid); if att>=16 continue; nl = cl - att; special sky-down rule; if nl > getL(np): setL push. Bounds: horizontal inside world only; y 0..H-1. ✓

getL/setL nibble ops per channel.

Emission table: EMIT[id]: TORCH 14, GLOWSTONE 15 else 0.

I think the design is solid. One more: caves reach surface? carve y in [6, min(h-4, 40)]: entrances exist where terrain dips? y<=h-4 keeps 3-block cover → no surface entrances → caves unreachable without digging — that's FINE (mining game! dig down to find caves & glowstone). But more fun with entrances: allow carve up to h-2 near cliff sides? Skip - digging down is core loop anyway. Actually entrances make caves discoverable... add occasional "ravine": where |n1| tiny at surface scale... skip, scope.

Fall damage? No.

Right — the start overlay says "CLICK TO ENTER". First click → pointer lock + audio init.

Now write everything. Part sizes ~ keep each < ~30KB per write for safety. Let me write.

Actually let me reconsider world size: 144×144 with 9×9 chunks: buildAllChunks at load: 81 chunks × ~3ms = ~250ms ✓ plus gen ~1s. Loading overlay handles wait. Mobile OK.

Also spawn: find height at center (SX/2, SZ/2); if under water, search spiral for land; spawn y = h+2. Face yaw toward island center-ish.

Fly default OFF; F toggles. In fly: no gravity, Space up, Shift down? Shift is sprint... in fly: Space up, C/Ctrl down. Sprint in fly = Shift still speed multiplier; use Space up / Alt? Use: fly: Space=up, Shift=down (sprint moot in fly). ✓ document.

Double-space to toggle fly? nice: implement (space pressed twice within 300ms while not in water) ✓ plus F key & button.

Alright — WRITE IT. I'll produce parts now. Keep code tight but readable. Also add a hidden window.__vox debug handle? Not needed.

Let me be extra careful writing the mesher face table & AO math, and DDA.

Face table with axes: for each face: n, corners[4] each [x,y,z,u,v].

const FACES = [ { n:[-1,0,0], c:[[0,1,0],[0,0,0],[0,0,1],[0,1,1]] ... wait must match my verified windings: nx: (0,0,0),(0,0,1),(0,1,1),(0,1,0) ✓ (computed above normal (-1,0,0) ✓) px: (1,0,1),(1,0,0),(1,1,0),(1,1,1) ✓ ny: (0,0,0),(1,0,0),(1,0,1),(0,0,1) ✓ py: (0,1,1),(1,1,1),(1,1,0),(0,1,0) ✓ nz: (1,0,0),(0,0,0),(0,1,0),(1,1,0) ✓ pz: (0,0,1),(1,0,1),(1,1,1),(0,1,1) ✓ uv per corner order: (0,0),(1,0),(1,1),(0,1) with v=y for sides ✓ as defined. } Indices per quad: (0,1,2),(0,2,3).

For AO: for face with normal axis k (0=x,1=y,2=z): tangent axes a=(k+1)%3, b=(k+2)%3. Corner offsets (ca,cb) = corner[a], corner[b] ∈{0,1}. side1 cell = base + a*(ca?1:-1); side2 = base + b*(cb?1:-1); corner cell = base + a*(ca?1:-1) + b*(cb?1:-1). base = voxel pos + n.

ao = (s1&&s2)?0:3-(s1+s2+sc). light: avg of [base, side1, side2, corner] cells' nibbles (sky & torch separately) /15. Hmm if side cells opaque they contribute 0 (stored 0) ✓ fine.

Flip quad diagonal when a00+a11 < a01+a10? For anisotropy-free AO flip: if ao[0]+ao[2] > ao[1]+ao[3] use (1,2,3),(1,3,0)?? Standard: flip when a00+a11 > a01+a10 → indices (0,1,3),(1,2,3)? I'll implement: if (ao0+ao2 > ao1+ao3) idx=(0,1,3, 1,2,3) else (0,1,2, 0,2,3). Wait standard flip: quad (0,1,2),(0,2,3) default; flipped = (0,1,3),(1,2,3). Condition ao[0]+ao[2] < ao[1]+ao[3] → flip? The rule: connect the edge between the two brighter vertices... flip if a00 + a11 < a10 + a01? I'll use: if (ao[0]+ao[2] > ao[1]+ao[3]) flipped. (Visual subtlety either way.)

Water top: scale corner y: if block WATER && face py: cornerY=0.875 → positions y = y+0.875 for all corners (they all have y=1) ✓.

Torch mini-box: use same FACES table but with offset+scale transform of corners: pos = base + min + corner*size. min=[0.375,0,0.375], size=[0.25,0.625,0.25]. AO skip (ao=3 → shade 1), light sample = base cell of torch itself (its own emission lights it) → bright torch ✓. uv: map full tile.

Flowers cross: quads: q1 corners (0.15,0,0.15)-(0.85,0,0.85)-(0.85,0.9,0.85)-(0.15,0.9,0.15); both windings; q2 (0.85,0,0.15),(0.15,0,0.85),(0.15,0.9,0.85),(0.85,0.9,0.15) + reverse. Light = cell light. ao=1.

Translucent pass: WATER (all exposed faces; top lower) & GLASS (cull glass-glass). aWater attribute 1/0.

Which mesh gets LEAVES: opaque (alphaTest handles holes) ✓ but note: with alphaTest material shared by whole opaque mesh, all tiles need alpha 1 except leaves/flowers — my atlas: ensure all opaque tiles fully alpha=255 ✓ (torch tile has transparent areas — torch in opaque mesh with alphaTest 0.45: handle/flame drawn alpha 255, bg 0 → discarded ✓ good).

Torch light itself: torch cell torch-light 14 → mini-box bright ✓.

Emit face culling for TORCH/FLOWER cells: always emit (no culling needed — tiny geo). Neighbors of torch: torch not opaque → neighbor faces drawn ✓.

Glass: cull vs glass; draw vs air/water/etc in translucent pass; opaque neighbors draw faces vs glass (glass not opaque) ✓.

Leaves vs leaves: cull (leaves opaque flag for culling) ✓.

Water vs glass: water face drawn if nb not opaque && nb!==WATER → glass counts → water face drawn against glass (fine). Glass face drawn if nb!==GLASS && !opaque(nb) → against water drawn ✓ double faces ok.

Now the DDA:

✓

Player collision:

Player half=0.3, height 1.8 (box from feet y to y+1.8). ✓ Eye = feet+1.62.

Water check: block at eye → headInWater (fov? tint? skip tint — could add blue overlay div opacity when headInWater ✓ cheap & nice: #water-tint div). Feet in water → swim physics.

Block placing intersect player check: AABB overlap test vs player box ✓.

Now — writing. For real this time. Part files: /tmp/vx/p1..p6.

One more decision: single script at end of body. Import map in head. Use three@0.160.0 exactly like sakura.

Let me also decide names/labels: Title "VOXELIA"; subtitle "POCKET VOXEL WILDERNESS · SEED n". Folder 050-voxelia. Card title: "Voxelia — Pocket Voxel Wilderness".

Writing part 1 now (head/css/hud/importmap/script start/constants/rng/noise).

***************************************************************l).

Part 2 done. Wait — there's a subtle bug in floodRemove: the down15 case — if the neighbor below has nl===15 and cl===15 moving down, we treat it as a reprop source rather than clearing. But that neighbor might genuinely depend on us vertically... If cl===15 and the cell below is 15, it could be lit from elsewhere too. Treating it as reprop source is safe (it re-spreads). But we never clear the column below when breaking... Actually in relightColumn we call floodRemove per-cell where stored > nv. For a placed block at y: cells below had sky>0 from the shaft; when we process cell y+? Hmm: after placing an opaque block at (x,y,z), scanning top-down: cells above the block still have nv=15 (unchanged); at the block cell, id is opaque → nv=0; stored was e.g. 15 → floodRemove(0, x,y,z) with startVal=15 → clears... neighbors below with nl=15 moving down: down15 → reprop instead of clearing! That's WRONG for this case: the shaft below should be cleared. Hmm.

Wait — the down15 exception is designed for the case where the light comes from a vertical shaft ABOVE that continues. In floodRemove we process the placed block cell (opaque, value 15 stored). Its neighbor below (air, 15): nl(15) < cl(15)? No, nl === cl, so nl < cl is false → goes to reprop anyway even without down15 exception! The condition nl < cl fails → reprop. So the cells below a removed shaft never get cleared by floodRemove... they become reprop seeds, re-add 15 downward — WRONG: after placing an opaque block, cells below should lose sky light (except what bleeds in from sides).

BUT — relightColumn continues its scan downward: at cells below the placed block, nv is now 0 (since opaque above), stored is 15 > 0 → floodRemove called on EACH of those cells with stored 15. Each call clears that cell (setSky 0) and floods: neighbors with nl < 15 get cleared... but horizontal neighbors in a cave at value 13 < 15 → cleared ✓; vertical neighbor below with 15 → reprop... then the scan reaches that cell below, stored... was set? The reprop doesn't change values; the cell below still has 15 stored, nv=0 → floodRemove clears it ✓. So sequentially the scan clears each shaft cell individually. The reprop seeds with value 15 would re-add 15 down?? That's a real problem: reprop contains cells below with nl=15 (added during the first floodRemove call), and after the scan those cells were cleared (set 0) — but reprop seeds assume stored light is correct. floodAdd(reprop) reads their CURRENT stored light (0) → spreads nothing ✓ (cl<=1 continue). Phew — floodAdd uses getSky at pop time, so stale reprop seeds that got cleared are harmless.

But one more subtlety: reprop seeds are only popped and read their current value — if the value changed between (e.g. cleared), no harm. If a reprop seed cell still has 15 (e.g., beyond the scan column — impossible: the shaft is vertical in this column; horizontal neighbors with 15 at the same y level... e.g. placing one block at y but adjacent column cells at same y have 15 (open sky) — those are legit sources ✓.

One more: within floodRemove for SKY channel, a neighbor ABOVE (d=2) with nl=15 ≥ cl → reprop ✓ (the sky above remains a valid source — correct, and it re-floods down into... the cell we cleared is opaque now, atten 16 blocks ✓; for cells below cleared by later scan iterations, re-add from above would be wrong? Re-add from above: floodAdd spreads 15 down into air cells below... which we cleared because an opaque block is above them — wait no: floodAdd from the above-seed spreads down through the placed block? The placed block is opaque → atten 16 → blocked ✓. But cells BELOW the block that we cleared: can light re-enter from above? Path must go through the opaque block → blocked. From sides → legitimate bleed ✓.

OK the algorithm holds. The down15 special case in floodRemove: neighbor below with 15 when cl=15 → without special case it'd be reprop anyway (nl<cl false). When would nl < cl with cl=15 happen below? nl=14 below (through leaves): nl<cl → clear, and push with val 14 → continues clearing below... but that 14-cell might be fed from above by a different shaft... edge case, acceptable approximation (MC's own algorithm has similar subtleties). The down15 check as written: channel === 0 && cl === 15 && d === 3 && nl === 15 — as analyzed it's equivalent to the else branch. Fine — harmless.

Now potential queue overflow in floodRemove: entries pack pos32+val, clearing a huge region (the whole sky shaft region on dig?) — bounded by region ≤ VOL... QSIZE 2M ≥ VOL? VOL = 1.33M < 2M ✓, each cell enqueued once per removal wave (values decrease monotonically — actually a cell could be enqueued twice if reached from two paths before... after clearing value is 0 → nl===0 continue prevents re-clear ✓ but a cleared cell could still be pushed? We push only after setL 0 with its old val; each cell cleared once ✓).

floodAdd worst case: cells can be re-queued multiple times as light improves... bounded in practice.

relightColumn ordering issue: scanning top-down, when stored > nv → floodRemove immediately clears around — this mutates light of cells we haven't scanned yet in the SAME column (below). E.g. placed block: at block cell y: floodRemove clears cells... below cells with nl<cl cleared partially; then scan continues to y-1: stored may now be 0 (if cleared) while nv=0 → stored===nv → skip ✓; if still 15 (reprop case) → floodRemove again ✓. Consistent.

One more in relightColumn: when breaking a block (digging), nv at the dug cell becomes 15 (air, open above) > stored 0 → set 15, seed ✓ then cells below: stored < nv? Below cells: nv stays 15 (air) → stored e.g. 0 (was dark shaft) → set 15 seeds ✓ → floodAdd spreads down through the shaft ✓ and sideways into caves ✓.

And when the dug cell is under water/leaves: nv decays correctly ✓.

Now — relightAfterEdit: the torch seeds from neighbors: pushing ALL lit neighbors as seeds re-spreads their light ✓. But NOTE: floodAdd can only INCREASE light; after placing an opaque block, the remove pass cleared what depended on the cell ✓.

There's an issue though: floodRemove for torch when PLACING an opaque block where oldT>0: we clear starting at the cell. But light that flowed AROUND (not through) the cell remains ✓. Light that flowed through the cell to the other side gets cleared ✓ (nl < cl chain).

Edge: floodRemove startVal for torch when placing GLOWSTONE where torch light existed: oldT could be 12 (from another torch); clear it, then set emission 15 and re-add ✓.

Part 2 looks solid. One perf concern: relightColumn runs per edit; scans 64 cells + floods; drag-mining 10 blocks/s → fine.

Also computeInitialLight step 2 boundary seeds: checks neighbors with getSky which for out-of-bounds returns 15 (horizontal) — cells at world border: neighbor 15 ≥ l-1 for l<15 → skipped unless l=15... border cells with l=15, neighbor (outside) 15: 15 < 14 false → not seeded ✓ fine.

The triple loop for emitter scan: 1.3M iterations, fine.

Now Part 3: mesher (faces, AO, light sampling, water/torch/flower special cases) + atlas texture painting + materials/shaders.

Let me write the mesher carefully.

Check nx winding: (0,0,0),(0,0,1),(0,1,1): e1=(0,0,1), e2=(0,1,0) → cross (00-11, 10-00, 0-0) = (-1,0,0) ✓. px: (1,0,1),(1,0,0),(1,1,0): e1=(0,0,-1), e2=(0,1,0) → (00-(-1)1, ...)= (1,0,0) ✓. ny: (0,0,0),(1,0,0),(1,0,1): e1=(1,0,0), e2=(0,0,1) → (01-00, 00-11, 0) = (0,-1,0) ✓. py: (0,1,1),(1,1,1),(1,1,0): e1=(1,0,0), e2=(0,0,-1) → (0*(-1)-00, 00-1*(-1), 0) = (0,1,0) ✓. nz: (1,0,0),(0,0,0),(0,1,0): e1=(-1,0,0), e2=(0,1,0) → (0-0, 0-0, -1) = (0,0,-1) ✓. pz: (0,0,1),(1,0,1),(1,1,1): e1=(1,0,0), e2=(0,1,0) → (0,0,1) ✓.

UVs: corners in order get uv (0,0),(1,0),(1,1),(0,1). For side faces, corner y: nx: 0,0,1,1 → v=0,0,1,1 ✓ matches y up = v up.

For AO: need per-corner sign along tangent axes: sign = corner[a] ? +1 : -1 where a is tangent axis index. Axes: k = dominant axis of n. a=(k+1)%3, b=(k+2)%3.

For water top face: lower to 0.875: if id===WATER && face.n[1]===1 → corner y replaced by 0.875.

Light per vertex: base = (x+n[0], y+n[1], z+n[2]); for corner c:

But getSky with out-of-bounds → 15 horizontal: means island edge faces fully sky-lit ✓.

occlusion counts: occ(x,y,z) = OPAQUE[getBlock(...)] (treat out-of-bounds horizontal as 0; y<0 as 1?).

AO curve: AO_L = [0.42, 0.62, 0.82, 1.0].

vLight.b = shade * AO_L[ao]. Also for water, soften AO? Fine as is.

Mesher output arrays as plain JS arrays (push), then Float32Array.from. For perf fine.

buildChunk(w, cx, cz) returns { opaque: {pos, uv, light, idx}, trans: {...} }.

For the torch and flowers: light sampled at the block cell itself; vLight = (sky/15, torch/15, shade=1). Torch tile uv full.

For glass: translucent, light at face.

Also mesh borders between chunks need neighbor access → getBlock works across chunk borders via world array ✓.

Emit rules:

Note LEAVES in OPAQUE → adjacent leaves cull ✓; leaves against glass: OPAQUE[glass]=0 → leaf face drawn ✓; glass against leaves: OPAQUE[leaves]=1 → skip ✓ good.

Tile selection:

Tile indices (col,row): grass_top (0,0), grass_side (1,0), dirt (2,0), stone (3,0), sand (0,1), water (1,1), log_side (2,1), log_top (3,1), leaves (0,2), snow (1,2), planks (2,2), brick (3,2), glass (0,3), torch (1,3), glowstone (2,3), bedrock (3,3), flower_r (0,4), flower_y (1,4).

TILE_INFO: per tile average color for particles: grass #5da336 etc.

UV mapping: u0 = col/4, v0 = 1 - (row+1)/5 (flipY=true: canvas row 0 at top ↔ v=1). Inset eps = 0.35/16 of tile in uv: epsU = 0.35/(4*16)=0.35/64, epsV = 0.35/80? canvas 64×80: tile 16px → uv tile = 1/4 × 1/5. eps = 0.4px → in u: 0.4/64, v: 0.4/80.

uv corner: (u0+eps + u*(tileU-2eps), v0+eps + v*(tileV-2eps)).

Water top face: since water tile semi-transparent... fine.

Now — atlas painting (needs document; guard for node tests — keep paintAtlas separate and only called in boot).

Mesher chunk count & geometry: create BufferGeometry in boot-side wrapper.

Then part 4: sky, clouds, sea, particles, audio. Part 5: player, input, raycast, edit. Part 6: HUD/UI, loop, quality, boot, exports.

Actually raycast is pure → include in part 3 for tests. Collision pure too → part 5 but export.

Let me write part 3 now.

Wait — there's an issue with the water top face culling logic. I wrote:

The second check is redundant/confusing — for the top face, emit is true only if nb is air/torch/flower/glass. If nb is glass, water top drawn (fine). The extra continue skips top face when nb is not air/torch/flower — but emit would already be false for opaque; for glass nb → skip top? That would cull the water surface under a glass ceiling — actually fine/better. Hmm, but the condition also skips when nb is... let me trace: nb===GLASS → emit true (not opaque, not water) → then the continue: nb!==AIR ✓, !==TORCH ✓, !==flowers ✓ → continue → skips. OK so water top under glass is culled. Acceptable.

But there's a real bug: for the water BOTTOM face (n=[0,-1,0]) with nb = glass below? Rare, fine.

One more: opts.noAO = isGlass — noAO only for glass; water gets AO (darkens edges of water surface at shore — actually looks decent).

Also water side faces full height but top at 0.875: at water-air boundary the side face extends above the top surface plane by 0.125 — from above you'd see a slight lip. MC does exactly this (side faces full height, top lowered). Looks fine.

Torch emission: light sampling at own cell gives torch/15 = 14/15 bright ✓.

Now there's a subtlety in emitFace for water top with topShrink: corner py = y + 0.875 for ALL 4 corners — but face.c y values for py face are all 1, so all shrink to 0.875 ✓. But careful: if (opts.topShrink) py = y + opts.topShrink; — for faces where corner y=0 this would wrongly raise... but topShrink only set for the +y face where all corners y=1 ✓.

AO sampling for shrunken water top: the base cell is above (air) ✓ fine.

Now — one concern in buildChunkMesh: the light arrays push sky/60? skySum is sum of 4 values 0..15 → /60 → 0..1 ✓.

Next part 4: THREE-side — atlas painting, materials/shaders, sky dome, clouds, sea plane, particles, audio.

Atlas painting details: canvas 64×80. Draw per tile with pixel loops using a seeded rng.

I'll write with helper px(ox,oy,x,y,color) using fillRect 1×1.

Tiles:

• grass_top: base green with per-pixel vary: color rgb(80+ r30, 150+r40, 45+r*20)? Let me use helper to jitter an hsl-ish rgb. Simpler: c = ['#5da336', vary lightness]: compute rgb = [93,163,54] + delta. Write function shade(rgb, d) → clamp.
• grass_side: dirt base then top 3px grass + jagged down to 5: for x: depth = 3 + floor(rng()*3): y<depth → grass color else dirt.
• dirt: [138,95,60] ±12.
• stone: [141,141,141] ±10 + occasional darker [110] cluster pixels.
• sand: [224,210,154] ±10.
• water: rgba(63,118,228,0.75) with streaks: every 4 rows lighter rgba(90,150,240,0.75); slight per-pixel jitter. Note: canvas premultiplied alpha — setting fillStyle rgba works fine.
• log_side: vertical stripes: col hash: base [107,74,42] with darker stripes where (x%4==0)? + jitter.
• log_top: rings: d = max(|x-7.5|,|y-7.5|) square rings: color = (floor(d)%2? [176,138,79] : [138,106,60]).
• leaves: base [62,125,44] jitter ±14; holes: rng()<0.16 → alpha 0 (clearRect px).
• snow: [240,246,250] ±5.
• planks: rows of 4px: y%8<4 boards alternate shade [169,129,75] ±8, seams at y%4==3 darker [120,88,48]; vertical seam every 8px offset per board.
• brick: mortar [183,168,154]; brick [158,75,60] ±8; pattern: rows 4px; offset 8 on odd rows; mortar lines at y%4==3 or x%8==(row? 0 : 4)... standard.
• glass: fill rgba(207,232,255,0.16); border 1px rgba(230,244,255,0.85); diagonal shine: pixels x+y in [6..7] or so rgba(255,255,255,0.35).
• torch: transparent; handle: x in 6..9, y in 6..15 → [120,80,40] jitter; flame: x 5..10, y 1..6: [255,200,80] with [255,240,170] center, full alpha.
• glowstone: [247,215,116] jitter ±12 + bright blobs: rng<0.12 → [255,243,176].
• bedrock: [58,58,58] with rng<0.3 → [34,34,34] or [85,85,85] chunky (2px cells: use x>>1,y>>1 hash).
• flower_r/y: stem x 7..8, y 5..15 [60,120,40]; head: circle center (7.5,3.5) r 2.5 red [212,58,58] / yellow [232,212,74]; center dot darker.

texture: CanvasTexture, magFilter Nearest, minFilter LinearMipmapLinear, generateMipmaps true, colorSpace SRGB, anisotropy 4.

Shaders:

Hmm — the aWater attribute only exists on translucent geometry. ShaderMaterial with custom attribute: declare in vertex attribute float aWater; — if geometry lacks it, WebGL would bind default 0... but the opaque material uses a different shader without that attribute anyway. Two separate shader programs: opaque (with ALPHATEST) and trans (with aWater). Fine.

frag opaque:

trans frag: alpha from tex, water wobble via uTime & vUv.

Vertex for trans: same + attribute float aWater; varying float vWat;.

Sky shader: dome sphere r=700 (fog far 200 → dome beyond; sky material fog none, depthWrite false, renderOrder -1, frustumCulled false).

Sun also tints horizon near sun azimuth: warm glow: pow(max(dot(dirH, sunH),0),4)*duskF.

uDay: I'll compute uniforms on CPU each frame: sunElev = sin(angle)... Actually simpler CPU: compute sunDir, dayF etc on CPU and pass final colors as uniforms (uZen, uHor, uSunCol, uNightF...) — less GLSL branching, easier to tune. Let me do CPU-computed: uniforms: uZen, uHor, uSunDir, uSunCol (rgb incl intensity), uMoonI (float), uStarI (float), plus uGlowCol horizon-sun tint. frag just mixes.

Moon should be opposite sun: moonDir = -sunDir ✓ (full moon every night, fine aesthetically).

Stars: hash in shader: fract(sin(dot(g, vec3(...)))*43758) — deterministic per cell; twinkle by uTime.

Clouds: InstancedMesh box(1,1,1) scaled per instance; positions random x∈[-40,SX+40], z ∈ full range, y 64..74; drift +x speed 1.2; wrap. Material MeshBasicMaterial({color, transparent, opacity:0.5, depthWrite:false, fog:true}) — fog on basic material works (built-in). Color updated per frame (day white → night slate). Count by quality tier: rebuild instance buffer on tier change — simpler: allocate max 140, set .count per tier.

Sea plane: PlaneGeometry(1400,1400) rotated -PI/2 at y=SEA+0.875-ish (match voxel water top 22.875 → plane at 22.86 to avoid z-fight). Material: ShaderMaterial similar water style: semi-transparent blue with moving voronoi-ish glint? Keep simple: MeshPhongMaterial? No lights in scene... I'll add the sea as another ShaderMaterial: color = mix(deepBlue, skyHor, fresnel-ish via view angle) + subtle moving stripes via sin; alpha 0.8; fog applied. Write small shader with fog uniforms shared.

Actually simpler & pretty: use the same voxel shader trick: sea material = custom shader: uniform uTime/uFog; frag: base color gradient by world pos stripes sin(wx*0.3+t)... nice enough with transparency + fresnel from view dir varying (need normal=up).

Particles: InstancedMesh(BoxGeometry(0.12,0.12,0.12), MeshBasicMaterial({vertexColors:false, fog:true})) with instanceColor. Pool 384. Each particle: pos, vel, life, color. update per frame: vel.y -= 22dt; pos += veldt; life -= dt; scale = min(1, life*3); matrix compose; if life<=0 → hide (scale 0). Count always pool size but hidden by zero scale.

Spawn break: 14 particles color from blockAvgColor jitter, vel random sphere*3 + up 2.

Audio engine (WebAudio):

Sounds:

• dig(hit): short noise burst lowpass 300-900, gain 0.15, 60ms — thock. Per material type: freq map.
• break: noise burst 180ms bandpass freq by type + slight downward pitch (playbackRate ramp), gain 0.3.
• place: short square blip 90Hz→60 + noise click, 70ms.
• footstep: noise burst 45ms lowpass 500, gain 0.06, vary playbackRate 0.9-1.1.
• torch place: little crackle? place sound fine.
• ambient wind: looping noise → lowpass 300 + gain 0.045 with slow LFO (osc 0.07Hz → gain.gain via GainNode chain).
• birds (day): every 3-8s if daylight: 2-4 chirps: osc sine freq 2200→3200 quick ramps, 60ms each, gain 0.05.
• crickets (night): every 0.9-1.6s: burst of 3 pulses 4200Hz, tiny gain 0.02.
• splash when entering water: noise burst lowpass 1200, 0.25s.
• cave mood: skip.

Scheduler in tick: check time accumulators.

Part 5: player & input & touch.

Player object:

update(dt):

• input vector from keys (forward/strafe) rotated by yaw; fly: also vertical from space/shift.
• speeds: walk 5.4, sprint 8.2, fly 13 (sprint fly 20), water mul 0.55.
• accel: ground: vel.x/z approach target quickly (lerp factor 1-exp(-12dt)); air control weaker (factor 4).
• gravity 26; jump vel 9.2 if onGround; swim: if inWater: gravity 6, vel.y damp, jump→ vel.y=4.2 (can hold to swim up: if space held vel.y approach 3.5), terminal -10.
• integrate & collide axis-by-axis.
• clamp to world [1.2, SX-1.2]... soft clamp + treat outside as solid: collideSolidAt(x,y,z): outside bounds → true (so can't leave). But island edges have ocean... clamp at boundary. Also below y<0 solid.

collideAxis: standard AABB scan:

Implement with explicit per-axis code for clarity. On y collision delta<0 → onGround=true.

Order: move y first? Common: x,z then y. Any order ok; do y last for stable onGround.

Water detection: block at feet+0.1 or at eye: water → inWater.

Input:

• keydown/up map: KeyW/A/S/D, Space, ShiftLeft, KeyF toggle fly, KeyM mute, KeyH help, KeyN new world (with confirm? instant), KeyP snapshot, KeyT pause sun, Digit1-9 hotbar, KeyR? nothing.
• double-space fly: track last space tap time; only when not in water.
• mouse: pointerlock on canvas click (via overlay start & canvas click). mousemove: yaw -= mx*0.0023; pitch clamp ±1.55.
• mousedown: 0 dig (hold repeat), 2 place; contextmenu prevent. Hold-to-repeat: track buttons state, in tick with cooldown 0.22s dig, 0.18s place? MC-ish: dig repeat 0.25, place 0.2.
• wheel: hotbar cycle.
• touch: as designed. Look drag: touchmove on right area → yaw/pitch. Joystick sets move vector. Buttons set flags (jump held, mine/place repeat while held).

Editing API:

Rebuild dirty chunks in tick: take up to 2 per frame: dispose old geometry, build new from buildChunkMesh arrays.

Chunk objects: for each chunk: {meshO, meshT} THREE.Mesh with geometries. Rebuild: create new BufferGeometry each time (dispose old).

Geometry attrs: position Float32, uv Float32, aLight Float32, (aWater for trans). Index Uint32 if verts>65535 → use Uint32Array always (needs no extension in WebGL2).

Materials shared across chunks (2 materials).

Highlight box: THREE.LineSegments(EdgesGeometry(BoxGeometry(1.002,...)), LineBasicMaterial white transparent 0.9, depthTest true). Position at hit cell center; hide when no hit.

Also a subtle break crack animation? skip.

Part 6: sky/day-night CPU logic, HUD wiring, loop, quality, snapshot, boot.

Day/night:

Auto-advance: t += dt/240 (4-min day) unless paused (T / button). Slider sets t (0..1000 maps).

Clock display HH:MM from t: hours = t*24.

Biome label from temp/moist/height at player: OCEAN if feet below SEA-1 & no ground? use ground height < SEA-1 → "OCEAN"; h<=SEA+1 "SHORE"; snow "PEAKS"; desert "DUNES"; forest "FOREST"; else "MEADOW".

Stats: FPS ema; pos; look target name.

Boot flow:

Loading via overlay text update with setTimeout yields.

URL seed param; NEW WORLD button → location.search = '?seed='+random (reload) — simplest robust. But audio context etc — reload is cleanest. N key same. Use location.href with param.

Quality tiers:

Set renderer.setPixelRatio, composer.setPixelRatio & size.

Bloom: UnrealBloomPass(res, 0.35, 0.5, 0.85).

Snapshot: render composer, toBlob, download link.

Renderer: antialias:true, powerPreference high-performance. outputColorSpace default SRGB; with OutputPass handles. toneMapping ACESFilmic exposure 1.05 — set on renderer; OutputPass applies.

Careful: ShaderMaterial outputs linear; with ACES + OutputPass → fine.

Water tint overlay when headInWater: opacity 0.75.

Pause when pointer unlocked: keep rendering (orbit? no — freeze player input; time continues; sounds keep). On lock exit → show overlay "PAUSED — CLICK TO RESUME".

First boot: overlay click → init audio + request pointer lock. On touch devices: no pointer lock — overlay click just hides + audio.

Detect touch: 'ontouchstart' in window || navigator.maxTouchPoints>0 → body.classList.add('touch').

Movement without pointer lock (touch): joystick etc ✓.

Fallback if pointer lock fails: mouse drag to look? add: if not locked and mousedown drag → look (nice for trackpads). Implement drag-look fallback.

FPS counting + adaptive.

Also st-q shows tier.

OK — also remember exports at end + guard:

Individual exports already via export function. THREE-dependent things (boot etc.) not exported — fine. But node import will execute top-level THREE-free code only — but top-level code includes... I must ensure NO top-level DOM/THREE calls outside boot. Materials etc. created inside boot/functions. Constants like QUEUE fine. const isTouch = ... must be inside boot. ✓

Node test will import the extracted module with 'three' & addons resolvable in /tmp/voxeltest (three installed; addons resolve via three package exports ✓). window/document undefined → boot not called ✓.

Edge: new Int32Array(QSIZE) top-level fine.

Also for node: performance exists in node ✓ (not used top-level anyway).

Let me now write part 4 (atlas paint + shaders + sky + sea + clouds + particles + audio). All as functions creating things inside boot; pure helpers separate.

Careful with GLSL: WebGL2 → three ShaderMaterial defaults GLSL1 syntax (texture2D ok with three's auto conversion? For ShaderMaterial three injects #define texture2D texture when GLSL3? No — ShaderMaterial defaults to GLSL1 (no glslVersion set) and three prepends compatibility defines? Actually for WebGL2, three compiles GLSL1 shaders with auto prefix converting? No: WebGL2 accepts GLSL ES 1.00 shaders directly. texture2D valid in ES 1.00 ✓. attribute/varying valid ✓. So plain GLSL1 fine.

Attributes: three injects built-in attributes (position, uv, normal) declarations for ShaderMaterial ✓; custom: declare attribute vec3 aLight; myself ✓.

Fog: manual via uniforms ✓ (material.fog false).

Write part 4 now.

************************************************************************ls.

I'm at 50% time threshold. I need to be efficient. Part 6 remains (main boot/loop/HUD), then assemble, syntax check, node logic tests, index update. Let me write part 6 now, being careful and complete.

Part 6 contents:

• Day/night uniform computation
• Chunk mesh manager (build/rebuild/dispose)
• Clouds
• Particles
• Hotbar UI
• Overlay handling
• Main loop
• Quality scaling
• Snapshot
• boot() guarded
• exports already inline; final close tags

Let me write it compactly but carefully.

Key pieces:

Hmm sunDir with z tilt 0.5 → sun path tilted ✓ moon = -sunDir.

dayF = smoothstep(-0.09, 0.22, el); duskF = exp(-elel18) — peak at el 0. nightF = 1 - dayF (approx), starI = smoothstep(0.02, -0.18, el) (JS smoothstep helper with edge0>edge1 — write my own sst(e0,e1,x) handling either order).

Colors:

• zen day (0.24,0.47,0.78), dusk zen (0.10,0.10,0.24), night zen (0.012,0.018,0.045).
• hor day (0.72,0.86,0.96), dusk hor (1.0,0.55,0.30), night hor (0.03,0.05,0.10).
• zen = lerp(night, day, dayF) then lerp toward dusk by duskF*0.75.
• hor similar.
• sunCol = (1.0,0.85,0.6) * (dayF0.9+duskF0.4) + disc intensity handled in shader.
• glowCol = dusk (1.0,0.5,0.22)duskF0.5 + day subtle (0.35,0.3,0.2)dayF0.12.
• moonI = nightF.
• voxel uSky = lerp(nightAmb (0.10,0.14,0.24), dayLight (0.99,0.97,0.90), dayF) + dusk tint slight: multiply by lerp(white, (1.0,0.75,0.55), duskF*0.5).
• fogColor = hor color.
• cloud color = lerp((0.08,0.10,0.16),(1.02,1.0,0.98),dayF) + dusk tint.
• sea colors: deep lerp((0.01,0.03,0.07),(0.05,0.28,0.42),dayF), skyCol = hor.
• windGain base 0.03 + altitude... keep 0.035.

Time advance: t += dt/240.

Chunk manager:

Geometry from arrays: if pos.length===0 → no mesh (or empty geometry fine, skip mesh).

Materials:

Water inside lakes seen from below? depthWrite false with FrontSide: looking down into water you see top faces ✓; from underwater you'd see... top faces from below are backfaces → invisible → see through to bottom. Use DoubleSide for translucent — then from underwater see surface ✓. ok DoubleSide for trans.

Shared uniforms object referenced by both materials (same uniform objects → update once): uniforms: { uAtlas:{value:tex}, uSky:{value:new Color}, uTorch:{value:new Color(1.0,0.70,0.36).multiplyScalar(1.5)}... wait torch tint >1 → HDR pre-tonemap, bloom picks up. Set uTorch = new THREE.Color(1.35, 0.85, 0.42). uSky as Color updated per frame. uFogColor Color; uFogRange Vector2(60, 210); uTime {value:0}.

const PMAX=384; InstancedMesh(boxGeo, MeshBasicMaterial({fog:true}), PMAX); instanceColor via setColorAt at init. pool array {pos, vel, life, maxLife, size} spawnBurst(x,y,z,colorHex, n) update(dt): iterate active, write matrices via dummy Object3D; dead → scale 0.

const clouds = InstancedMesh(BoxGeometry, MeshBasicMaterial({transparent:true, opacity:0.5, fog:true, depthWrite:false}), 140); per-instance data: x,z,w,d,y,speed; set matrices once + update x drift in tick (rewrite matrix when moved; cheap for 140).

let last=performance.now(); function tick(now){ requestAnimationFrame(tick); let dt=(now-last)/1000; last=now; dt=min(dt,0.1); // time of day if(!sunPaused){ tod += dt/240; tod%=1; } // player if (started) updatePlayer(world, input, dt); // mine/place repeat actCd -= dt; if(actCd<=0){ if(input.mine){doMine(); actCd=0.22} else if(input.place){doPlace(); actCd=0.2} } // highlight raycast ... // dirty chunks rebuild (max 2) // clouds, particles, sky uniforms, water tint, audio ambience scheduling // camera sync: pos = feet + eye; rotation from yaw/pitch: camera.rotation.order='YXZ'; rotation.y=yaw; rotation.x=pitch; position=(x, y+1.62, z) // render: tier bloom? composer.render() : renderer.render() // fps ema + stats update every 0.25s }

const dir = lookDir(tmpV); const eye = (pos.x, pos.y+P_EYE, pos.z); const hit = raycastVoxel(world, eye.x,eye.y,eye.z, dir.x,dir.y,dir.z, 7); if(!hit) return; if(hit.id===BEDROCK){ Snd.digSfx(STONE); return; } setBlockAndUpdate(world, hit.x,hit.y,hit.z, AIR); Snd.breakSfx(hit.id); spawnBurst(...blockAvgColor)

hit = raycast...; if(!hit) return; tx=hit.x+hit.nx, ty=..., tz=... if ty>=H or ty<0 return const cur = getBlock(world,tx,ty,tz); if(cur!==AIR && cur!==WATER) return; const id = HOTBAR[hotSel]; if(id===TORCH || id===FLOWER...){ if(hit.ny!==1){ Snd.digSfx... return;} const below=getBlock(tx,ty-1,tz); if(!SOLID[below]) return; } if(SOLID[id] && playerIntersectsBlock(tx,ty,tz)) return; setBlockAndUpdate(...); Snd.placeSfx(id);

const TIERS=[{name:'LOW',pr:0.7,bloom:false,clouds:50,fogFar:150}, {name:'MED',pr:1,bloom:true,clouds:90,fogFar:180}, {name:'HIGH',pr:Math.min(devicePixelRatio,1.75)||1,bloom:true,clouds:140,fogFar:210}] start HIGH; monitor: ema frame ms; every frame: if ema>20 && t-lastChange>3s → tier--; if ema<11.5 && ... → tier++ (max HIGH). apply: renderer.setPixelRatio; composer.setPixelRatio? composer has setPixelRatio & setSize; clouds.count; uFogRange.y=fogFar; bloomPass.enabled.

let world, scene, camera, renderer, composer, bloomPass, skyMat, seaMat, cloudMesh, ... async function boot(){ const app = document.getElementById('app'); renderer = new THREE.WebGLRenderer({antialias:true, powerPreference:'high-performance'}); renderer.setPixelRatio(...); renderer.setSize(...); renderer.toneMapping = ACESFilmic; exposure 1.06; app.appendChild(renderer.domElement); scene = new THREE.Scene(); camera = PerspectiveCamera(74, aspect, 0.1, 900); isTouch → body class seed from URL or random seedVal text overlay blink 'GENERATING WORLD…' await raf(); world = makeWorld(seed); await idle chunks: generateWorld(world); (use await between phases for UI paint: wrap steps in await new Promise(r=>setTimeout(r,10))) computeInitialLight(world); build atlas tex + materials + shared uniforms build all chunks (await each 9) sky dome mesh; sea plane; clouds; particles; highlight box setupInput(env callbacks) UI wiring: buttons, slider overlay ready: 'CLICK TO ENTER' click handler → start loop start } if (typeof window !== 'undefined' && typeof document !== 'undefined') boot();

Now assemble and syntax check. Also, I notice a few issues to fix:

1. In p6, const dummy = (typeof THREE !== 'undefined') ? null : null; — dead code, harmless but ugly; remove.

2. In computeSky: out.zen.lerp(out.tmp, 0); — no-op line, harmless but remove.

3. env.started — in setupInput I referenced env.started (via getter) ✓ defined as getter in env object ✓. But in canvas mousedown handler: if (!locked() && !env.isTouch) → requests pointer lock — but env.isTouch is a plain property ✓.

4. In setupInput, overlay param destructured but unused — fine.

5. tick references slider — defined in boot scope before tick ✓.

6. In doMine/doPlace: tmpV.set(...) for eye, then lookDir(new THREE.Vector3()) — allocates per call; fine.

7. In tick, hit used in stats update — declared in tick scope ✓.

8. particle setColorAt: particleMesh.setColorAt(pNext, cc) — bug: I increment pNext BEFORE using as color index: const p = particles[pNext]; pNext = (pNext+1)%PMAX; ... setColorAt(pNext, cc) — color applied to wrong index (next slot, not the one used). Fix: store const pi = pNext; ... setColorAt(pi, cc).

9. updateClouds uses pDummy — defined in initParticles which runs before initClouds? boot: initClouds() THEN initParticles() → pDummy null during first updateClouds? updateClouds called in tick, after both inited ✓ pDummy exists by then. The fallback new THREE.Object3D() covers anyway ✓.

10. matShared object: I stuff uFogRange reference into it for applyTier — I wrote matShared.uFogRange.value.y in applyTier ✓ defined. And seaMat uniform uFogRange is a SEPARATE Vector2 (not shared) → applyTier updates both ✓. But fog near stays 60 ✓.

11. matShared.tra uniforms: Object.assign({uTime:{value:0}}, shared) — shared refs reused ✓.

12. In p5 input: keydown 'Space' toggles fly on double tap — also sets input.jump=true; preventDefault ✓.

13. Potential issue: env.onKey assigned AFTER setupInput(env) called — in setupInput, keydown handler calls onKey && onKey(e) — onKey is the destructured param onKey from env at call time... I destructure const { renderer, overlay, onMine, onPlace, onKey } = env; — onKey undefined at destructure time (assigned later)! Then onKey && onKey(e) never fires. Fix: call env.onKey && env.onKey(e) instead. Must edit p5.

14. In tick: document.getElementById(...) every 0.25s — fine.

15. computeSky: sunDir z tilt 0.5 constant → at midnight el=-1: sunDir=(0,-1,?) normalized with z 0.5... fine.

16. skyOut.tmp usage — remove junk lines.

17. sst(0.10, -0.12, el) — edge0 > edge1: my sst: (x - e0)/(e1 - e0) → el=0.10→0, el=-0.12→1 ✓ works with negative denominator ✓.

18. In spawnBurst: also cap: when bloom off... fine.

19. THREE.CanvasTexture colorSpace SRGB ✓.

20. matShared.opq side: default FrontSide ✓ (flowers have explicit double quads ✓).

21. Highlight for torch cell: box 1×1×1 around small torch — fine.

22. updatePlayer water: feetId at pos.y+0.2 — if standing IN water 1 deep: feet in water ✓.

23. Swim-up out of water onto shore: vel.y approach 3.8 while jump held; at surface, block collision... should be able to climb out onto 1-high bank: swim up + forward; MC-like enough.

24. In moveAxis Y downward: p.pos.y = by + 1 — by is the solid block's min y; standing on top = by+1 ✓. Head bump: p.pos.y = by - P_HEIGHT - 1e-4 ✓.

25. Potential tunneling at high fall speed: vel.y max -38 * dt 0.016 = 0.6m < 1 ✓; dt clamped 0.05 → 1.9m > 1 block! At 20fps (dt 0.05), fall 380.05 = 1.9m could tunnel through a 1m floor. Mitigate: substep physics when dt large: n = ceil(delta magnitude / 0.5)? Simple: clamp dt in updatePlayer to 0.05 already; add substeps for y movement: split into 2 if |vel.ydt| > 0.5. I'll add general substepping: steps = ceil(maxDelta/0.4); loop moves. Let me patch updatePlayer: compute dx=vel.x*dt etc; steps = clamp(ceil(max(|dx|,|dy|,|dz|)/0.4),1,4); loop moveAxis with delta/steps. onGround reset before loop; set within. I'll rewrite that section.

26. Also player.onGround=false before y move — with substeps inside loop.

27. updateClouds initial matrices: initClouds writes all 140 with its own dummy d ✓.

28. Bug: in initClouds I use variable dd for depth and d for dummy — ok.

29. slider.matches(':active') ✓.

30. In snapshot: if bloom on, composer.render() then read canvas ✓.

31. sea plane y at SEA+0.86 vs voxel water top SEA+0.875 → plane 0.015 below → voxel tops visible slightly above plane near island ✓ no z-fight (different heights) ✓.

32. Bloom threshold 0.82: day sky bright areas (horizon ~0.7-1.0 with ACES exposure) may bloom slightly — nice.

33. One thing: opaque mesh + alphaTest in shader discards leaves holes ✓ but transparent:false default ✓ depthWrite default true ✓.

34. VOXEL_FRAG for opaque: uses #ifdef TRANS not defined → alpha 1 ✓.

35. matShared.tra DoubleSide: water side faces visible from both sides; glass too ✓.

36. aLight for translucent: computed ✓ (glass noAO ✓, water AO applied via AO curve — I set noAO only for glass; water top at shore darkened by adjacent sand — good).

37. fog uniforms shared between opq/tra materials via same object refs ✓; but uTime only on trans material (own entry) ✓.

38. camera near 0.1 far 900 ✓ sky sphere r 700 ✓.

39. renderer.domElement mousedown requests pointerlock when not locked — but also overlay click does. After lock, clicking mines (input.mine). The FIRST click that requests lock also sets... in mousedown, if !locked → request + return (no mine) ✓ good.

40. Missing: prevent digging while overlay visible? started flag gates in tick ✓ and input.mine only set when locked or touch... canvas mousedown when overlay visible: overlay covers canvas (z-20) so no canvas mousedown ✓.

41. iOS Safari: pointer lock unsupported → isTouch true → touch path ✓.

42. Edge: input.mine stays true if pointer released outside window while locked? mouseup on window ✓.

43. In setupInput destructure: onMine, onPlace unused — remove from destructure (harmless though).

Let me fix the real bugs:

• p5: onKey destructure → change call to env.onKey && env.onKey(e).
• p6: spawnBurst color index.
• p6: physics substepping (in updatePlayer — that's p5). Rewrite movement integration part.
• p6: remove junk lines (const dummy..., out.zen.lerp(out.tmp, 0);).

Apply fixes via replace_in_file after assembly. Assemble now.

Assembled: 2214 lines, 87KB. Now apply the fixes:

1. p5 → in file: onKey && onKey(e); → env.onKey && env.onKey(e);
2. Physics substepping in updatePlayer.
3. spawnBurst color index.
4. Remove junk const dummy = ... line and out.zen.lerp(out.tmp, 0); line.

Also remove the now-unused tmp: new THREE.Color() from skyOut? It's harmless. Leave it.

Now extract the module script and run node --check, then run logic tests. Extraction: get content between <script type="module"> and </script> at end. Use awk/sed. The importmap script also matches <script ...>; I need the LAST script block. Let me use python or node to extract.

Test plan in node:

1. Import module (three installed in /tmp/voxeltest — but the file also imports addons; EffectComposer imports might reference document? UnrealBloomPass module top-level — should be safe class definitions. Let's try.)
2. makeWorld + generateWorld: assert counts of blocks (some water, some glowstone > 0, grass > 0, bedrock at y=0), heights in range.
3. computeInitialLight: check sky=15 above ground at spawn; check a cave cell near glowstone has torch>0; check underground dark cell has sky small.
4. buildChunkMesh for a chunk: verify arrays consistent lengths (pos/3 verts, lig/3, uv/2, idx multiple of 3, indices < vertCount), some faces exist.
5. raycastVoxel: cast straight down from above terrain at (72.5, top+5, 72.5) → hit non-air, ny=1.
6. Edit: place torch at surface, check getTorch>0 nearby; remove, check ~0. Dig down 3 blocks: check sky light increases below.
7. Flood sanity: place glowstone in dark cave → neighbors lit.

For extracting and importing: the module ends with the boot guard requiring window/document — undefined in node → skipped ✓. But top-level const QUEUE = new Int32Array(...) fine. THREE imports fine.

One concern: performance used only inside functions ✓. location, document only inside boot/functions ✓.

Extract via node script: read file, find '' index and last ''.

Let me do it.

The extraction included the importmap </script> — no wait, the issue: html.indexOf('<script type="module">') finds the module script start, but lastIndexOf('</script>') — the last </script> in the file... there are two scripts: importmap (before module). lastIndexOf gives the module's closing tag. Hmm, but the extracted content includes </script> at position 2004? That means the module script contains... no wait — the indexOf found the FIRST <script type="module">... there's only one. Let me check: the extracted text at ~2004 chars contains "" — meaning within the first 2004 chars of the module there's a </script>?? No...

Oh! I see — the CSS/overlay? No. Actually: the module start index is computed correctly; but end = html.lastIndexOf('</script>') — is there a </script> AFTER the module's? No, module is last. Hmm, unless the importmap closing </script> comes BEFORE module start (irrelevant).

Wait — error at vox.mjs:2004 — line 2004! Not char 2004. The file is 77677 chars; line 2004 contains </script>. So extraction grabbed too much: the slice went past the actual module end. Why? Because... there must be TWO </script> occurrences after module start? The module content itself might contain a string '</script>'? No. Hmm — lastIndexOf returns the LAST occurrence in the whole HTML. If the module script is the last element before </body></html>, its </script> IS the last. Unless... my p6 ends with </script>\n</body>\n</html>\n ✓.

Line 2004 of the extracted module — the module is ~2200 lines total? The whole HTML is 2214 lines; module starts around line 120. So line 2004 within the module ≈ HTML line ~2124 — near the end. So the extracted content DOES include a literal </script> line near its end?? That means the slice end went beyond — impossible with lastIndexOf unless... OH WAIT. I bet there are TWO closing </script> tags: the importmap one... no, lastIndexOf finds the LAST one in the file, which is the module's closer. Then the slice end = that closer's index → excluded. So how does </script> appear inside?

Unless the file contains </script> somewhere in the middle — e.g., in p1? No... Let me actually check: maybe I have a stray </script> inside the module from one of the parts. grep it.

There's an extra </script> at line 2223 — after the module's close at 2212. The file has 2223+ lines? wc said 2214 earlier but that was before edits (edits added lines). So there's a trailing </script> at 2223 after </html>. Where did that come from? Each part file... p6 ends with </script></body></html>. But there must be a stray </script> in one of the parts — likely p6 has </script>\n</body>\n</html> and... wait, grep shows </script> at 207 (importmap), 2212 (module end), 2223 (stray). Let me look at the end of the file.

The end of the file is duplicated/corrupted: after the proper ending there's leftover text ("ick();" ... duplicate tail). This looks like one of my replace_in_file operations duplicated content — probably the first replace. Actually the pattern: file ends with proper ending, then a fragment "ick();\n setTimeout..." through a second full ending. This suggests the file got the p6 tail appended twice — likely from the replace operations? No... Actually looking at byte counts: after assembly 87287; replaces: 87252, 87434, 87263, 87241, 87184, 87139 — they shrink/grow per edit as expected. The duplication existed from the start? wc -l right after cat said 2214 lines — let me count parts: p1 331, p2 316, p3 229, p4 383, p5 312, p6 648 → sum 2219, but parts 2-6 each start with a blank line... close to 2214 (cat of parts where p1 ended without trailing newline?). Hmm.

The important thing: there's a duplicated tail fragment. It likely came from p6 write itself? The p6 preview showed "affectedEndLine: 648" and ended correctly with . Let me check /tmp/vx/p6.html tail.

p6 itself is fine (ends correctly). So the corruption happened in the assembled file — likely a replace_in_file edit went wrong (perhaps the "search" matched near EOF and the tool wrote incorrectly, or the s3fs-backed file got a bad write). The duplicated tail starts at "ick();" — a truncation of "a.click();". So somewhere, an edit re-wrote the file: truncated around "...a.click();" then the tail repeated?

Actually, interpreting: the file's proper content ends at line ~2213, then lines 2214-2223 contain a partial duplicate of the tail (from "a.click();" fragment). This looks like an s3fs write anomaly (stale cached tail). Rather than fight it, safest: truncate the file at the first proper </html> occurrence after module end — i.e., remove the trailing duplicate. I'll use node to cut everything after the FIRST occurrence of "" + newline.

Wait — but which edits are in the good part? The replaces reported sensible previews. The good ending at line 2204-2213 contains the full snapshot() + boot guard + closing tags. The stray tail begins after. Cut at first "".

Truncated. But wait — the truncation removed the duplicate tail; however I must double-check whether the replace edits landed in the kept portion correctly and the kept file has the correct content. The file is 87252 bytes now — earlier byte count after first replace was 87252! Suspicious: that equals the count after the first replace... that suggests that some of my subsequent replaces may have operated on a file with the duplicate tail, and the byte counts I saw (87434, 87263, etc.) included it. After cutting the duplicate, we may have lost... no wait: the duplicate was at the END; replaces happened in the MIDDLE. The math: final replaces totaled 87139 with duplicate tail (~113 bytes? the duplicate tail was ~10 lines ≈ 250 bytes...). Hmm, bytes don't need to reconcile exactly — what matters is the kept portion is coherent. Let me verify integrity: check that all my fixes are present (grep for "env.onKey", "pi, cc", "substeps"), and that the file parses. Then re-extract and node --check.

Syntax OK now, but two of my fixes are MISSING (setColorAt(pi, cc) count 0, substep fix count 0), and const dummy is still present (count 1)! So the file that got truncated was a STALE version — the replace operations went to a different (duplicated) version. The s3fs-backed filesystem must have served inconsistent states.

Ugh. The replace tool reported success and showed previews of the changes... but the final truncated file lost them. Actually more likely: each replace rewrote the file, but due to s3fs caching, writes interleaved weirdly. The safest path: reconstruct the file locally in /tmp (fast local disk), apply all fixes, verify, then copy ONCE to /space. Let me:

1. Rebuild from parts in /tmp: cat p1..p6 → /tmp/vx/index.html
2. Apply the 4 fixes with sed/node in /tmp (local, reliable).
3. Extract module, node --check.
4. cp to /space/demos/050-voxelia/index.html.
5. Verify by reading back from /space.

The fixes:

• onKey && onKey(e); → env.onKey && env.onKey(e);
• integrate+collide block → substep version
• spawnBurst pi fix (two edits)
• remove const dummy = ... line
• remove junk computeSky lines

Let me do all with node string replaces in /tmp.

/tmp/vx/index.html: Permission denied — hmm, /tmp/vx dir was created by the read_write tool (which runs as different user?) Let me check permissions. Use a different directory: /tmp/voxeltest exists and I could write vox.mjs there earlier (that worked via node fs). So use /tmp/voxeltest/ for assembly. The parts are in /tmp/vx/*.html — can I read them? cat should read fine (write is the issue). Let me assemble into /tmp/voxeltest/index.html.

All fixes applied, syntax OK. Now run the logic test suite in node. I'll write a test that imports the module and exercises worldgen, lighting, mesher, raycast, edits.

Test file /tmp/voxeltest/test.mjs:

Note: V.getSky(w, ...caveCell) spread of array ok.

One concern in test "dug cell sky 15": digging one block at gy: cell gy open to sky above (gy+1 air) → relightColumn: nv=15 down to gy... at gy (now air): stored 0 < 15 → set ✓.

"filled cell sky 0": placing stone at gy: scan: nv=15 above, at gy opaque → nv=0; stored 15 > 0 → floodRemove; cells below gy-1: their stored... before digging, below were solid with 0; after dig, gy-1 still solid (stone) → not affected ✓. After remove: cell gy = 0 ✓. Reprop seeds re-add 15 from above into... cell gy is opaque now, blocked ✓. Then set to nv=0 (already 0) ✓.

Roof test: placing stone at wy+3 (in mid-air, open sky column): column scan: nv=15 from top down to wy+3; at wy+3: opaque → 0; below: air with nv = 0 (after opaque, stays 0? my scan: if at>=16 nv=0; else nv = max(0, nv-(at-1)) → after opaque cell, nv=0; air cells below: nv stays 0 ✓). stored at wy+2..wy+1 etc was 15 > 0 → floodRemove each... wait scan order: top-down: first hits wy+3 (the stone): stored 0 (stone cells have 0), nv=0 → stored === nv → no action. Then wy+2 (air): stored 15 > nv 0 → floodRemove(wy+2) clears vertical shaft below + sideways bleed ✓ reprop seeds collected. Continue wy+1: likely already cleared → stored 0, skip. wy: skip or clear. Then floodAdd(reprop seeds) → sideways light bleeds back: cell at wy gets ~12-13 from sides (distance 1 from open columns: neighbors at same y have 15 → 15-1=14). So underAfter should be 14. My assertion < 15 && >= 11 ✓.

After removal: column restored 15 ✓.

Also V.relightAfterEdit signature (w, x, y, z, oldId, newId) ✓.

Edge in test: placing stone roof — also floodRemove's down15 special: at cell wy+2 with cl=15, neighbor below wy+1 nl=15: down15 → reprop (not cleared!) → but then scan reaches wy+1: stored 15 > nv 0 → floodRemove clears ✓. OK.

But hmm — during floodRemove(wy+2), reprop includes wy+1 (down15) — later wy+1 cleared by its own floodRemove. Reprop seed stale → floodAdd reads current 0 → harmless ✓.

Another subtle issue in floodRemove: when clearing the shaft, horizontal neighbors at each level with nl=14 < 15 → cleared recursively — this clears bleed light near the shaft; reprop from boundary re-adds ✓. Classic algorithm ✓.

One thing to double check in relightColumn: after floodRemove, I set setSky(w, x, y, z, nv) only if nv>0; else cell stays 0 ✓.

And in the dig test: digging at gy where gy+1 is air (open sky): scan from top: nv=15 at gy+1... at gy: air now: nv stays 15 → stored 0 → set 15, seed ✓. floodAdd spreads down: gy-1 solid → blocked ✓. Below irrelevant.

But wait: height[gx,gz] — if tree/flower above? At (50,50) maybe a flower at gy+1 — then getBlock(gy+1) is FLOWER (atten 1) → nv stays 15 ✓ fine.

Now — one REAL bug I should double-check in relightColumn: when scanning, for a solid cell (e.g., stone at gy), stored sky light might be > 0 from previous bleed (solid cells store 0 always? floodAdd never sets into opaque ✓; initial scan sets 0 for opaque ✓ — but wait: initial vertical scan sets l=0 for opaque; bleed floodAdd skips opaque ✓. So solid cells always 0 ✓. But the column scan sets stored > nv only when stored > nv... for solid cell stored 0, nv 0 → nothing ✓.

Another check — relightColumn nv computation for the TOP of the world: y=H-1 down. If trees above height... handled ✓.

Potential perf gotcha: floodRemove/Add use the shared QUEUE ring buffer — nested calls? relightColumn: floodRemove (uses QUEUE), then floodAdd (uses QUEUE) — sequential, no interleave ✓. relightAfterEdit: floodRemove, then floodAdd ✓. OK.

Overflow: floodAdd seeds from relightColumn could be up to 64 cells + reprop; BFS spread — bounded by lit region; sky spread from a dug cell in a huge cave could light a big cave → many cells; QUEUE 2M with mask; cells can be re-enqueued multiple times (light improvements) — in practice fine.

Now run the test.

Good news: worldgen 113ms, lighting 80ms, meshing fast. But failures:

1. grass: 1108 (too few) — most of the island must be underwater or beach/snow. World might be mostly ocean. Need to tune terrain: raise overall heights. heightAt: base 24 + cont9 + hills6.5 + mmridge30; SEA=22; falloff pulls edges to SEA-9=13. Island center should be higher. With grass only 1108 columns of 20736 total... most land is sand (beach h<=SEA+1=23, or desert t>0.42) or snow. Let me check distribution. Probably lots of sand (beach threshold wide since heights cluster at 23-24) and snow (t<-0.28 half the world?). Tune: raise base to 27, beach only h<=SEA+1 (keep), desert t>0.5, snow t<-0.45 or h>=46. Also make continent noise stronger.

2. torch spreads 0 → 0 — torch at dark cell: getTorch(dx,dy,dz) === 14 passed ✓ (test says only spread failed). Spread to (dx+3,dy,dz): 0. Why? floodAdd from torch cell: neighbors atten... the cave air cells should get 13, 12, 11 at distance 3. But got 0. Hmm — wait: in relightAfterEdit, torch channel: oldT = getTorch(cell) — the cell BEFORE setting torch emission... I call V.setBlockRaw(w, dx,dy,dz, TORCH) FIRST, then relightAfterEdit. In relightAfterEdit: oldT = current torch light at cell (0) → no removal. e = EMIT[TORCH]=14 → setTorchL(cell, 14); seeds=[cell]; plus neighbors with light>0; floodAdd(1, seeds).

floodAdd: pops cell: cl = getTorch = 14 ✓ >1. For neighbors: nid = AIR → at=1 → nl=13 > cur 0 → set & push ✓... should work! Unless... getTorch reads w.light[i] & 15 — setTorchL: w.light[i] = (w.light[i] & 240) | v ✓.

Hmm wait — did the test place the torch where atten>=16? dark cell is AIR ✓. Let me debug: maybe floodAdd's unpacking of position is wrong! p = idx(x,y,z) = (x*SZ+z)*H+y. Unpack: y = p % H; xz = (p-y)/H; z = xz % SZ; x = (xz-z)/SZ. ✓ correct.

DIRS[d]: floodAdd loops d 0..5: [1,0,0],[-1,0,0],[0,1,0],[0,-1,0],[0,0,1],[0,0,-1]. ✓.

Hmm — wait, in relightAfterEdit I compute oldT = getTorch(w, x, y, z) — that's 0; skip removal. Then const e = EMIT[newId] — newId is passed as V.B.TORCH=12; EMIT[12]=14 ✓.

Let me test directly with a minimal case to debug. Actually — hold on. In the test for "torch lit 14" — that PASSED (no FAIL printed for it). So the cell has 14. Spread failed → floodAdd not spreading.

OH WAIT. I see it — in floodAdd, seeds are pushed: QUEUE[tail & QMASK] = seeds[i]; tail++. Then while (head < tail): head=0... I initialize let head = 0, tail = 0; at function start ✓. Pop: const p = QUEUE[head & QMASK]; head++; ✓...

Hmm, but QUEUE is module-global and floodRemove uses packed values pos*32+val — after a floodRemove, stale values... but we reset head/tail ✓.

Let me look again at floodAdd's neighbor condition: if (nl > cur) → set. cur for neighbor air = 0, nl=13 ✓ set, push.

Wait — but do I ever call floodAdd in relightAfterEdit? if (seeds.length) floodAdd(w, 1, seeds); seeds has [cell] ✓...

Hmm, unless the ISSUE is in the test: V.setBlockRaw(w, dx, dy, dz, V.B.TORCH) then relightAfterEdit. Let me check EMIT indexing: EMIT is Uint8Array(32); EMIT[B.TORCH]=14 — B.TORCH=12 ✓.

Let me just debug interactively in node.

3. 'open cell sky pre' = 0 at (60, wz=60, wy=height) — getSky at the surface BLOCK (solid grass) is 0 (solid cells store 0!). My test is wrong-ish: surface solid cell has sky 0; the "open cell" should be wy+1 (air above). The earlier check sky 15 above surface at h72+3 passed. So test bug, not code bug. For the roof test, use the AIR cell at wy+1 and place roof at wy+4. But careful: wy+1 might contain a flower... choose cell: use wx=60,wz=60; check getBlock(wy+1) is AIR else pick another column.

But wait — that also explains "cave light sky/torch: 0 14" — fine (cave dark, near glowstone vein torch 14 ✓).

4. grass 1108 — terrain tuning needed.

Let me debug the torch spread issue first.

Torch spread works in isolation! So why did the test fail? In the test, the "dark" cave cell was found via getSky < 4 && getTorch < 2. The spread check reads V.getTorch(w, dx + 3, dy, dz). If (dx+3, dy, dz) is SOLID (cave wall 3 blocks away), getTorch returns its stored value = 0 → "spread 0". The cave at y 10-24 is a tunnel — 3 blocks away may be wall. Similarly glowstone spread +2+1 could hit wall. So likely test-target issue, not engine issue. I'll pick the spread target as a known-air neighbor: scan the 6 neighbors for air and check that one.

Also 'torch removed, dark again' passed ✓, 'dug/fill' passed ✓, determinism passed ✓, mesh integrity ✓.

Fix the test: choose air neighbor cells for spread checks. Fix roof test to use air cells. Fix grass via terrain tuning:

Terrain tuning: raise base land. Current: h = 24 + cont9 + hills6.5 + mmridge30, then blend toward SEA-9 by falloff. Center fall≈1: h ≈ 24 ± noise... SEA=22 → beaches at h≤23: a big fraction of land is 21-24 → sand. Also snow threshold t<-0.28 (temp ~ fbm in [-1,1], so ~30% snow) and desert t>0.42 (~20%) → grass ~1108 plausible.

Retune:

• base 27.5, cont10, hills7 → typical land 27-35, beaches only near coast.
• snow: t < -0.45 || h >= 46.
• desert: t > 0.52 && h < 40.
• mountains: mm = smoothstep(0.08 → keep) ridge*30 → peaks ~57 (H-12=52 clamp... H=64, clamp H-12=52 — mountains up to 52, snow ≥46 gets snowy caps ✓).

Also make trees a bit denser on plains (0.005 → fine), forest mo>0.02.

Let me edit heightAt & biome cutoffs in the part file, reassemble, retest. I'll do edits directly on /tmp/voxeltest/index.html (the fixed master), and later copy to /space.

Edits:

1. let h = 24 + cont * 9 + hills * 6.5 + mm * ridge * 30; → let h = 27.5 + cont * 10 + hills * 7 + mm * ridge * 30;
2. In generateWorld: const beach = h <= SEA + 1 || t > 0.42; → const beach = h <= SEA + 1 || (t > 0.52 && h < 40); const cold = t < -0.28 || h >= 44; → const cold = t < -0.45 || h >= 46;
3. tree line if (r < p && ...) — forest predicate moist > 0.02 && t <= 0.42 — t cutoff raise: desert only t>0.52 now; forest condition t <= 0.5? Use t <= 0.5. And beach/surf===GRASS only anyway.
4. biomeAt: t > 0.42 DUNES → 0.52; t < -0.28 SNOWCAPS → -0.45; heights 44 → 46.

Also for spawn: finds h>SEA ✓.

Apply and retest with fixed test targets.

Time check: 80% used. I need to be very efficient now. Three failures:

1. glowstone removed dark: 14 — after removing glowstone, the airNb cell still has 14? Hmm wait: before glowstone, airNb had some value from the environment (cave near glowstone veins could have torch light from natural veins!). Actually before was captured for TORCH test. After glowstone removal, floodRemove should clear. Getting 14 at airNb... if natural glowstone nearby, relightAfterEdit re-adds neighbor seeds — neighbor cells with light>0 re-spread. If the cave had natural glowstone veins, the value could legitimately be 14 from another vein. But it said torch<2 at dark cell... airNb 3 away could still be near a vein. Possible legit. But 14 exactly — suspicious: distance from another glowstone must be 1. Hmm. Alternatively my floodRemove has a bug: the seeds for reprop include the NEIGHBORS of the edited cell with light>0 — those neighbors include airNb if airNb adjacent? airNb is 3 away.

Wait, actually, potential real bug: in relightAfterEdit torch removal: oldT = getTorch(cell) = 15 (glowstone cell) → floodRemove(1, cell) → clears dependent light; but the glowstone cell's own light after floodRemove = 0; then e=EMIT[AIR]=0 → no seed. Neighbors with light>0 → seeds. If all light in region came from the removed glowstone, neighbors were cleared (their light came through the cell? no — neighbors got light DIRECTLY from glowstone: nl = 15-1 = 14 < cl=15 → cleared ✓). So after removal all should be ~0 unless another source. Getting exactly 14 at airNb means another light source 1 away from airNb... The dark cell had torch<2 but the cave is riddled with glowstone veins (30% of shell cells!) — very plausible airNb is adjacent to a natural vein. Test issue most likely. I'll change assertion: after removal, torch at airNb should be <= value before the test began +1? Before value was captured before TORCH placement... natural state. ok(V.getTorch(...) <= before + 1). Hmm but before was getTorch(airNb) BEFORE torch placement — captured. Use that. Actually wait, in the glowstone removal check I asserted <= 2 while the natural before could be higher. Fix test to compare with before.

Hmm, but actually there's a subtle REAL bug possibility: floodRemove for glowstone at cell with cl=15: neighbors nl=14 < 15 cleared ✓ recursive... a cell at distance 2 with nl=13: cleared if reached via chain 15→14→13: at second step cl=14, nl=13 < 14 cleared ✓... good. Cells that ALSO received light from elsewhere (nl >= cl at some step) → reprop → re-added ✓. OK engine fine.

2. shaft sky 15 deep: 0 — digging a 4-deep shaft: each dig calls relightAfterEdit → relightColumn. After digging gy-1 (below surface), the column: surface gy is already AIR (from previous test... wait the dig/fill test FILLED gy with STONE). Then shaft dig: gy-1 down to gy-4. But gy is STONE (filled) → sky can't pass! Of course: I filled the top with stone, then dug BELOW it → sealed cave → sky 0. Test logic error. Fix: dig shaft from gy (re-break the stone) down 4: for y in [gy-1..gy-4]... but gy is stone — the loop starts at gy-1 leaving gy stone as roof. Change: also re-dig gy first. Fix test: dig cells y=gy-1..gy-4 AND gy stays air? The fill test filled gy. So before shaft test, re-break gy: setBlockRaw(AIR) + relight. Then shaft gets 15 down to gy-4 ✓ (all air in column above).

Wait but down rule: sky 15 falls straight down through air ✓ → gy-4 = 15 ✓.

3. mesh integrity bad=24 — need to find which chunk/arr. Likely arr.uv.length/2 !== pos.length/3 for tra — no wait — the check includes BOTH. Hmm, or idx max >= pos/3. Let me debug: find the bad chunks and print stats. Possibly the EMPTY mesh case: pos.length=0, idx empty → mx=0, pos/3=0 → mx >= 0 → bad++! A chunk with no translucent geometry: mx starts 0, 0 >= 0 → flagged. Test bug ✓ (skip empty arrays). Let me fix test: skip when pos.length===0.

So likely ALL THREE failures are test bugs. Let me fix and re-run. Also grass is now 6370 ✓ (sand 50619 — lots of ocean/beach, that's fine for an island; maybe lots of shallow sea floor sand since h<=SEA+1 → underwater floor sand ✓ fine).

Also — while I'm at it, sand 50619 seems high (includes seabed columns where top is sand up to SEA+1 → deep floor at h 13..23 all sand ✓ intended).

Fix test and re-run. Then finalize: copy to /space, update index, done. Also quickly sanity check browser-specific pieces by code review (can't run WebGL here).

All 23 tests pass. Now let me do a final browser-side review pass of things node can't test, then deploy.

Quick review of critical browser paths:

1. matShared.tra.uniforms.uTime — accessed in tick ✓ exists.
2. shared.uSky, shared.uFogColor — tick updates ✓ shared with both materials ✓.
3. In boot, matShared = { uFogRange: shared.uFogRange, opq: ..., tra: ... } — applyTier uses matShared.uFogRange.value.y ✓.
4. rebuildChunk uses matShared.opq/tra — defined before first rebuildChunk call? In boot: matShared created → then chunk loop ✓.
5. updateClouds(dt, count) — cloudMesh.count setter ✓.
6. Highlight: hit from raycast ✓.
7. Snd.init() on overlay click ✓.
8. Overlay hidden after click ✓; pointerlockchange → hideOverlay ✓.
9. On touch: no pointer lock; overlay tap hides ✓; look drag works without lock ✓. But NOTE: canvas mousedown handler is for mouse; on touch, pointerdown handler on window handles look; MINE/PLACE via buttons ✓.
10. On touch devices, started set on overlay click ✓ (overlay covers screen, tap = click ✓).
11. Canvas pointer events: I attach 'mousedown' — on touch, tapping canvas also fires synthetic mousedown? We gate with isTouch for pointer lock; input.mine would be set on synthetic mousedown with button 0 → mining while look-dragging! Guard: in canvas mousedown, if (env.isTouch) return; first. Let me check the current handler: canvas.addEventListener('mousedown', (e) => { Snd.init(); if (!locked() && !env.isTouch){...return;} if (e.button===0) input.mine=true; ...}) — on touch, synthetic mousedown after pointerdown → not locked, isTouch true → skips first block → sets input.mine=true on every look touch! BAD. Fix: early return if env.isTouch at top.
12. Wheel on touch — not fired ✓.
13. Also mousemove drag fallback when pointer lock unavailable ✓.
14. Hotbar slot pointerdown → also triggers window pointerdown look handler? Slot is inside #hotbar; my look handler checks e.target.closest('.tbtn, #hud-panel, #hotbar, #joy') ✓ excluded.
15. document.getElementById('water-tint').style.opacity per frame — fine.
16. st-look initial ' ' ✓.
17. iOS: AudioContext resume on gesture ✓ Snd.init called from touch handlers.
18. renderer.domElement.toBlob — WebGL canvas needs preserveDrawingBuffer OR capture right after render ✓ we render immediately before ✓.
19. Sky sphere radius 700 < camera far 900 ✓. gl_Position.z = w pins to far ✓ works with depthTest? Fragment at far plane, depthWrite false, drawn first (renderOrder -1) ✓; with depth test LESS and cleared depth 1.0, z/w=1.0 → equal → fails LESS?? three's default clear depth 1.0; depthFunc LessEqual? THREE default depthFunc = LessEqualDepth ✓ (THREE.LessEqualDepth is default). ✓ safe.
20. fog on MeshBasicMaterial for clouds/particles — scene.fog NOT set (manual fog in voxel shaders). Clouds/particles use built-in fog → need scene.fog! Without scene.fog, built-in materials get no fog (fine — uniform defaults fogFar huge? THREE Fog default... if scene.fog undefined, fog has no effect ✓ but then clouds won't fade at distance... they're within 200 units, fine). Actually to fade clouds at the same range, set scene.fog = new THREE.Fog(color, 60, 215) and update color/far per frame. Simple: add scene.fog and sync in tick with skyOut.hor and tier fogFar. Let me add that — cheap.
21. Particles basic material with fog ✓ then.
22. Also spawnBurst color when bloom... fine.
23. Sea plane transparent over sky: renderOrder 1, depthWrite false ✓. Voxel translucent renderOrder 2 ✓ drawn after sea → water surfaces inside world render over sea ✓.
24. Chunk meshes matrixAutoUpdate false — identity at origin ✓ positions are absolute world coords ✓.
25. Frustum culling: chunk geometry computeBoundingSphere ✓ default culling works ✓.
26. camera.rotation.order='YXZ' set once ✓.
27. In tick when !started (before overlay click), updatePlayer skipped, raycast skipped, camera stays at default position (0,0,0)... camera positioned only in tick after player — I set camera position every tick regardless (camera.position.set uses player pos ✓ even when !started) ✓ good — shows the world behind overlay.
28. Audio scheduler uses Snd.ctx ✓ null-guarded.
29. Snd.windGain.gain.setTargetAtTime — only if Snd.ctx ✓ guarded.
30. Hotbar icons use atlasCanvas ✓ painted before buildHotbar ✓.
31. UnrealBloomPass with custom shader materials — operates on final render ✓.
32. ACES tone mapping + OutputPass ✓.
33. renderer.outputColorSpace default SRGB ✓; when useBloom false → direct render: ShaderMaterial output not tone-mapped? Direct renderer.render applies tone mapping + output color space conversion in the material shaders automatically for built-in materials; for ShaderMaterial, tone mapping is NOT auto-applied (needs #include tonemapping_fragment). Hmm — when bloom is ON, RenderPass renders to float buffer (no tone map), OutputPass applies ACES + sRGB ✓. When bloom OFF (LOW tier), direct render: my custom shader output goes through... ShaderMaterial skips tone mapping & color space conversion → colors will look washed/darker? Without sRGB conversion, output appears darker. Fix: apply sRGB conversion manually in shader? Better: always use composer but toggle bloomPass.enabled! Composer with RenderPass + (disabled bloom) + OutputPass → OutputPass still applies tonemap/sRGB ✓. So: keep composer always, set bloomPass.enabled = useBloom. Update tick: always composer.render(). Fix applyTier: bloomPass.enabled = t.bloom; and tick: composer.render() always. And snapshot: composer.render() ✓ simplify.

Let me patch these three things: A. canvas mousedown: early return for touch. B. scene.fog add + sync (also applyTier far sync). C. Always composer.render(); bloomPass.enabled toggle.

Also remember skyOut.tmp no longer used — leave.

Then final: copy /tmp/voxeltest/index.html → /space/demos/050-voxelia/index.html (single cp), verify read-back checksum, update /space/demos/index.html (write new version locally then cp), node --check final extract, done.

For the index page update: read current index.html, find insertion point (after first demo-card? or at end). Check its structure: cards listed; I'll insert 050 card right after <main or before </main>. Let me check the tail structure of index.html. Also there may be a "demo count" somewhere — grep.

**************************************************************************************************************************************************************************************************************************************le.

Actually the snapshot patch DID apply (function shows composer.render() only) — my verification string just didn't match due to the exact newline pattern. All good.

Now: copy the final file to /space/demos/050-voxelia/index.html, then update the demos index page. Let me also do one more quick sanity review of a couple of remaining browser-only spots I want to verify by reading the final file: the boot flow order and tick function — but time is tight; the syntax check + tests + careful review are done. One more quick check: the useBloom variable is now only used to set bloomPass.enabled — fine.

Also check: TIERS[tier].clouds used in updateClouds ✓; applyTier uses composer — applyTier called after composer created ✓ (in boot after composer setup ✓ — verify order: composer created → ... → applyTier() near end ✓).

Also bloomPass.enabled — UnrealBloomPass has .enabled property (all passes do) ✓.

Deploy + verify checksum, then index page. For the index page, read the current one to find structure.