Fluid Dynamics Playground Demo Creation and Validation

The task says "Wake up and do as you please." This means I have freedom to do what I want in my space. Given my purpose is to create cool Three.js demos, I should probably create a new demo.

Let me first check the current state of the demos folder to see what exists.

Let me install shell tools and explore.

Let me look at the current state of the demos folder.

I have three demos:

1. 001-spinning-cube (basic)
2. 002-nebula-galaxy (particle galaxy)
3. 003-mandelbulb-explorer (ray-marched fractal)

The task says "Wake up and do as you please." So I'm free to create a new demo. Let me think about what would be a great next demo — something advanced with "wow" factor.

Ideas:

1. Interactive fluid simulation (WebGL fluid dynamics) - very impressive
2. Audio visualizer - needs mic access, might be limited
3. Playable mini-game - e.g., 3D asteroids, snake 3D
4. Procedural terrain with water shader - impressive
5. Black hole / gravitational lensing raymarching - very impressive (like Interstellar's Gargantua)
6. Particle life / boids simulation with GPU compute - impressive
7. Voxel-based minecraft-like demo
8. CRT/retro arcade game in 3D

A black hole raymarching demo with gravitational lensing would be extremely impressive and follows nicely from the Mandelbulb demo (also raymarched). Alternatively, a GPU fluid simulation is a classic "wow" demo.

Let me think about what would be most reliable to implement and validate in this environment. A black hole demo with:

• Raymarched Schwarzschild black hole with gravitational lensing
• Accretion disk with doppler beaming
• Starfield background that gets lensed
• Interactive controls (orbit, adjust spin/disk parameters)
• Bloom post-processing... actually raymarching in a fragment shader, bloom can be added

Actually, let me consider a different direction for variety: a playable 3D game. Games are interactive and fun. E.g., "Neon Racer" or "3D Asteroids" or a "Synthwave infinite runner".

Or GPU particle life — particles with attraction/repulsion rules creating emergent organic behavior. That's very cool and different from previous demos.

Let me weigh:

• Demo 2 was particles (galaxy).
• Demo 3 was raymarching (mandelbulb).
• For variety, a game or a fluid sim would be nice.

I think a WebGL fluid simulation with mouse interaction is one of the most mesmerizing demos ever. It's a classic. Implementing the full Navier-Stokes GPU fluid sim (like Pavel Dobryakov's) is complex but doable. It requires:

• Multiple render targets (velocity, pressure, dye)
• Shaders: advection, divergence, pressure solve (Jacobi iterations), curl/vorticity, splat
• Display with color

That's very impressive and interactive (mouse/touch stirs the fluid). It fits "GO ADVANCED".

Alternatively the black hole. Both are great. The fluid sim is more interactive and fun. Let me go with the fluid simulation — "004-fluid-simulator" — a GPU-accelerated Navier-Stokes fluid sim with:

• Mouse/touch interaction (drag to stir, colored dye)
• Adjustable parameters (vorticity, dye dissipation, velocity dissipation, pressure iterations)
• Colorful preset palettes / rainbow mode
• Maybe click to splat
• Screenshot button
• Nice HUD/UI
• Fallback messages

Three.js with render targets (WebGLRenderTarget), or raw WebGL? Since my demos use Three.js, I'll use Three.js with fullscreen quads and custom shaders, using HalfFloatType render targets. That's cleaner with Three.js r160+.

Actually, implementing in Three.js: I'll create a sim scene with an orthographic camera and fullscreen quad (or use a fullscreen triangle). Swap render targets (double buffering). Standard technique.

Key components:

1. Splat shader: adds velocity/dye at pointer position with radius and color.
2. Advection shader: moves velocity/dye along velocity field (semi-Lagrangian), with dissipation.
3. Curl shader: computes vorticity.
4. Vorticity shader: applies vorticity confinement force.
5. Divergence shader: computes divergence of velocity.
6. Pressure solve (Jacobi): iterates to find pressure.
7. Gradient subtract: makes velocity divergence-free.
8. Display shader: renders dye with maybe shading (using gradient for fake 3D lighting).

I'll write these as GLSL fragment shaders. It's a big file but manageable.

Validation: node --check for JS, @shaderfrog/glsl-parser for GLSL. Those tools worked in the previous run.

Let me also check the current index.html to see the format.

Plan:

1. Read existing index.html.
2. Create /space/demos/004-fluid-simulator/index.html with the full fluid sim.
3. Update index page.
4. Validate JS with node --check (extract module script).
5. Validate GLSL with @shaderfrog/glsl-parser.
6. Maybe do a CPU sanity test? Hard for fluid sim; static validation should suffice. Could also test in puppeteer but previous run showed environment constraints. I could still try quickly.

Let me start.

Node 24 is available. Now let me write the demo file.

There's an issue in my render() + bloom compositing. Let me think carefully:

When config.BLOOM is true, I call:

1. render(pointerActive) — blits displayPass to null (default framebuffer).
2. composer.render() — which renders bgScene (black bg) to the composer's readBuffer, applies bloom, and outputs to screen.

Problem: composer's final OutputPass renders to the default framebuffer, overwriting what displayPass drew. The order is wrong! The displayPass blit happens first, then composer overwrites it with bgScene + bloom(bgScene).

That's broken. The fluid would be invisible when bloom is on, or rather replaced by black + bloom of black = black.

I need a different approach: composite the fluid INTO the bloom pipeline. Options:

Option A: Render displayPass into a texture, then have a scene with a quad showing that texture, and render that scene through the composer.

Option B: Use a custom additive blend: render displayPass with blending: AdditiveBlending directly to screen AFTER composer.render(). Bloom threshold 0 means bg contributes bloom too... bg is nearly black so its bloom contribution is negligible. Then fluid drawn additively on top. But then the fluid doesn't get bloomed itself — just a flat composite over bloomed black background. The bloom effect would be lost on the fluid (which is the point of bloom).

Option C (best): Render the display pass into a dedicated render target ("fluidComposite" at canvas resolution), then make a "compositeScene" containing a fullscreen quad with that texture (NoBlending), and point RenderPass at that scene. EffectComposer: RenderPass(compositeScene) → bloom → output. The fluid gets bloomed properly.

Let me restructure:

And when BLOOM off: blit displayPass directly to null.

render():

then in frame: if (config.BLOOM) composer.render();

compositeTarget size must match canvas pixel size (wdpr, hdpr since renderer.setPixelRatio... actually RenderTarget sizes are in physical pixels? WebGLRenderTarget uses explicit size — setSize(w,h) sets exact buffer size. Composer handles pixelRatio internally? EffectComposer constructor uses renderer size * pixelRatio via renderer.getDrawingBufferSize(). Yes: this._pixelRatio = renderer.getPixelRatio() etc. So for compositeTarget I should size it to drawing buffer size:

Also update on resize.

HalfFloat composite target fine.

Also saveSnapshot needs same logic — call the same render path. Actually saveSnapshot duplicates frame logic: step + render + composer.render + toDataURL. With the fix, render() branches internally, so saveSnapshot works: step, render(false), if bloom composer.render(), toDataURL. Good.

Another subtle issue: in frame(), render() then composer.render() — composer.render() sets render target to null at the end (OutputPass renders to screen). But blit uses renderer.setRenderTarget — fine.

Also in render() when bloom on, displayPass blits to compositeTarget — but compositeScene's mesh uses compositeTarget.texture directly. Since RenderPass reads the texture while... no conflict: compositeTarget fully rendered before composer.render() reads it. Good.

One more issue: MeshBasicMaterial on a PlaneGeometry(2,2) — the basic material doesn't have uv attribute issue; PlaneGeometry has uv. map sampling works with uv 0..1 across the quad. Good. But note: NoBlending irrelevant for basic. Need toneMapped: false? OutputPass applies tone mapping based on renderer settings; renderer.toneMapping default is NoToneMapping. Fine.

Also the compositeScene quad: MeshBasicMaterial will be affected by OutputPass color space conversion (sRGB). Same as ShaderMaterial path — consistent.

Now, second bug check — canvas.setPointerCapture(e.pointerId) may throw if pointer already released? Generally safe. Wrap in try/catch to be safe.

Third: pointers.delete on pointerleave — with capture, pointerleave fires... ok.

Fourth: In updatePointer, division by rect.width — fine.

Fifth: auto splat happens even on frame 1 with lastInteraction = now — config.AUTO default true, so fine.

Sixth: the dblclick on panel hides it — but dblclick also triggers splats behind? Panel is positioned over canvas; pointerdown on panel doesn't reach canvas (panel is separate DOM element above). OK. But dblclick to hide is undiscoverable; the gear button shows it back. Add a small "×" hide button inside panel for discoverability. Let me add a close button in the panel header.

Also CSS selector #panel.hidden ~ #collapseBtn — collapseBtn is a sibling AFTER panel in DOM. panel.hidden ~ collapseBtn works. Good.

Seventh: renderer.autoClear = false — with RenderPass inside composer: RenderPass calls renderer.render which clears internally if clear=true... EffectComposer's RenderPass sets renderer.autoClear? No: RenderPass has clear property default true; it does renderer.setRenderTarget(...); if (this.clear) renderer.clear(...). Actually RenderPass temporarily sets autoClear? Implementation:

Yes it saves/restores autoClear. Good — my global autoClear=false doesn't break composer's clearing.

But wait — with autoClear=false globally, when I blit displayPass to null (bloom off), the default framebuffer is never cleared — displayPass writes every pixel anyway (fullscreen quad, NoBlending). Fine.

composer.render() when bloom on: RenderPass renders compositeScene with clear → covers everything. Fine.

Eighth: When BLOOM toggled off mid-run, composer no longer rendered — screen shows displayPass output directly. Good.

Ninth: bloomPass threshold 0, strength 0.65 — the whole scene blooms slightly including dark colors... acceptable, strength moderate.

Tenth: OutputPass — in r160 exists. RenderPass, UnrealBloomPass, OutputPass paths correct.

Eleventh: new UnrealBloomPass(new THREE.Vector2(w,h), strength, radius, threshold) — signature (resolution, strength, radius, threshold). I passed (0.65, 0.75, 0.0) = strength .65, radius .75, threshold 0. Good.

Twelfth: In advection shader, gl_FragColor = uDissipation * texture2D(...) — for dye with HalfFloat fine.

Thirteenth: uPointerStrength halo uses distance in uv — stretched on wide screens, minor.

Fourteenth: In splat for erase — dye splat with negative color adds negative dye → "erases" as advection moves it. Slight artifact: velocity splat also gets negative velocity when erasing (dx,dy from drag) — fine, erase still stirs. But for erase click I set color (-0.02...) and velocity (random ±300) — ok.

Wait, actually there's an issue with negative dye + shading: length() of negative vec is fine. Colors clamp at display? Not clamped; negative values → OutputPass clamps to 0. OK.

Fifteenth: pressure iterations slider live — fine.

Sixteenth: rebuilding targets on slider change disposes and loses fluid — expected.

Seventeenth: getDrawingBufferSize — initial composite target creation.

Eighteenth: displayPass uTexelSize should be dye texel — set in render() each frame. Good.

Nineteenth: check splatPass.uniforms.uAspect.value — set in splat() each call. Good.

Twentieth: On pointerdown I do an immediate splat with random velocity — nice feedback.

Also the initial camera/composer: compositeScene camera = same ortho camera. Good.

Now about the halo when pointerActive: uPointer never set from pointer position! I set uPointerStrength only. Need to also set uPointer to the first pointer's position in render().

Fix render():

I call render(pointers.size > 0) — simplify: render() reads pointers itself; drop the param. And saveSnapshot calls render(false)... I'll make render(active) but compute pointer inside. Simplify: render() always; strength computed inside.

Let me apply these fixes:

1. Replace bloom composer section (bgScene → compositeScene + compositeTarget).
2. Fix render() to blit into compositeTarget when bloom on, set pointer uniform properly, and remove parameter.
3. Update frame() call.
4. Update saveSnapshot (calls render(); composer.render() if bloom).
5. Resize: update compositeTarget size via drawing buffer size.
6. Add close button in panel.
7. setPointerCapture try/catch.

Also note the hint says right-click drag to erase — keep.

One more consideration: renderer.domElement.toDataURL after composer.render — the default framebuffer contains composer's output. Without preserveDrawingBuffer, reading right after render in same synchronous block works. Good.

Also check: OutputPass in r160 — constructor new OutputPass(). Yes.

Potential GLSL validation concern: @shaderfrog/glsl-parser might complain about texture2D in GLSL1 — it's valid GLSL ES 1.00. The parser should accept. Previously they validated mandelbulb shaders fine presumably with texture2D.

Now implement fixes with replace operations.

Now fix render():

I'm at 52% of max time already. I need to move faster. Let me apply the remaining fixes quickly:

1. saveSnapshot: fix render(false) → render()
2. frame(): render(pointers.size > 0) → render()
3. resize: update compositeTarget size
4. pointer capture try/catch
5. Panel close button

Let me do these in parallel-ish quick edits.

*********************************************************************************te.

***********************************************************************************************************************************************************************************************ml.

The search failed — likely whitespace differences. The file content shows:

The indentation was 8 spaces for the comment. Let me check exact whitespace via grep.

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

Index updated. Now validation:

1. Extract the module script and run node --check.
2. Extract GLSL shaders and validate with @shaderfrog/glsl-parser.

Let me write a validation script. The script extracts:

• The <script type="module"> content → check with node (need to handle import statements — node --check works for ESM if file has .mjs extension).
• GLSL template literals marked with /* glsl */ → parse with glsl-parser.

I'll install @shaderfrog/glsl-parser in a temp dir (may already be cached from previous run — probably not persisted since it's a different turn... the home dir may persist? The previous run installed it somewhere. Let me just npm install in /tmp).

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

All 10 shaders parse OK. Now let me do a deeper static sanity check: verify that every uniform referenced in shaders is set in JS, and every uniform declared in makePass exists in the shader (to catch typos). Also verify import map URLs are well-formed and try fetching the three.js CDN to confirm availability (network may or may not be available).

Also a quick check: THREE.MathUtils.clamp used — exists. renderer.getDrawingBufferSize(v) — exists in r160. composer.setSize exists. bloomPass.setSize exists (UnrealBloomPass has setSize). OK.

One logic check — in render(), when bloom off and blitting to null: renderer.autoClear=false; previous composer output might remain... displayPass covers full screen with NoBlending, fine.

Another check — splat() is called in pointerdown before velocity/dye exist? No, they're created at module top before listeners attach.

Check order of declarations: splatPass etc. created before splat used — yes. randomBurst(16) called at end — after everything. Good.

lastInteraction declared with let lastInteraction = 0; in the auto splat section — but updatePointer and pointerdown handler reference lastInteraction before that let declaration executes? The event listeners are registered before let lastInteraction line is reached, but handlers only run after module evaluation completes, so no TDZ issue at runtime... wait, updatePointer references lastInteraction — handlers execute later, fine. But hideHint also — fine.

Actually wait: there IS a potential TDZ issue: canvas.addEventListener('pointerdown', ...) — callback references lastInteraction. Module evaluation continues, let lastInteraction = 0 executes, then at the bottom lastInteraction = performance.now(). No event fires during synchronous module eval. Fine.

Also const pointers = new Map() declared before render() uses it — yes, pointer section comes before... let me verify order: step() → render() (function declaration, hoisted) → pointer input section (const pointers) → auto splats → UI → resize → main loop. render() is a function declaration that references pointers — called only at the end in frame() after pointers exists. Fine.

compositeTarget and drawingSize — declared in composer section before render() def and resize handler. drawingSize is const Vector2, resize mutates via getDrawingBufferSize(drawingSize). Good.

Uniform cross-check script: extract uniform names per shader (uniform ;) and compare against uniforms objects in makePass calls. Let me write a quick node script that:

• For each makePass(X_FRAG, { ... }) block, list uniform keys.
• For shader consts, list declared uniforms.

Quick regex approach. Names: VERT has no uniforms. Let me do it.

Also verify the three.js CDN URL is reachable — try import_url or curl HEAD. Network access existed in previous run? They imported URLs maybe. Let me try curl -sI quickly with a timeout.

CDN is reachable and both modules exist (200). Now, time check — I was at 52% a while ago. Let me try a quick headless browser test if possible, but previous run said it failed due to environment constraints. Skip that.

Let me do one more meaningful validation: a CPU-based smoke test of the fluid solver math is not really feasible quickly. Instead, let me do a final review of the demo file for any remaining bugs by reading key sections, particularly:

1. The blit function and render target flow.
2. The frame loop order.
3. Check that renderer.setRenderTarget(null) before composer.render() — composer handles it.

One thing to double-check: In frame(), when BLOOM is on, render() blits displayPass into compositeTarget. Then composer.render() — RenderPass renders compositeScene (a quad with MeshBasicMaterial map=compositeTarget.texture). Since renderer.autoClear=false and RenderPass temporarily handles clearing with its own clear=true. Good.

But wait — there's a subtle Three.js gotcha: a MeshBasicMaterial quad rendered with an OrthographicCamera(-1,1,1,-1,0,1): PlaneGeometry(2,2) spans -1..1 in x/y at z=0. Camera near=0, far=1, looking down -z. Plane at z=0 is exactly at the near plane. Ortho near=0 means the plane at z=0... camera at position (0,0,0) looking -z. The plane z=0 is at the camera position — depth 0, which is at the near plane boundary. This is the same setup used for the sim passes with ShaderMaterial (gl_Position set directly, bypassing camera). But MeshBasicMaterial uses the camera matrices! The quad at z=0 with camera near=0 might get clipped (z=0 maps to NDC z=-1... in ortho, near plane at distance 0 → points at z=0 in camera space are ON the near plane; typically still rendered, though precision issues can arise).

Hmm, for safety, position the camera at z=1? Actually the camera is shared. In the mandelbulb demo presumably they used ShaderMaterial with raw gl_Position so camera didn't matter. For compositeMesh with MeshBasicMaterial, camera matters. Let me think: OrthographicCamera(-1,1,1,-1,0,1), camera at origin, looking down -Z. A point at world (x,y,0) → camera space (x,y,0). Ortho projection maps z from [near, far] = [0,1]... camera-space z of 0 corresponds to depth exactly at near plane. OpenGL clip space: visible region -w <= z <= w. Point on near plane maps to z_ndc = -1, which is within [-1, 1] — rendered. It's borderline but standard practice (many fullscreen-quad setups use exactly this). However floating point could clip.

Safer: move camera position to z = 0.5? Then the plane at z=0 is 0.5 in front → maps mid-depth. Camera is shared with sim passes but they ignore camera transforms (gl_Position set in shader; but three.js still computes projectionMatrix etc. — unused). Also the RenderPass for composite uses this camera — fine.

Actually simplest: set camera.position.z = 1 once after creation. Plane at z=0 → distance 1 = far plane → z_ndc = +1, borderline again! Use position.z = 0.5. Then depth 0.5 of range [0,1] → z_ndc = 0. Safe.

Wait, but near=0, far=1, camera z=0.5, plane distance=0.5 → within [0,1]. Good, z_ndc = 0 (middle). Safe.

Let me apply that: after camera creation add camera.position.z = 0.5; Hmm but does moving the camera affect the sim passes? Their vertex shader sets gl_Position directly from position.xy — camera irrelevant. MeshBasicMaterial composite pass: geometry spans x,y ∈ [-1,1] which matches ortho frustum regardless of camera x/y/z (camera at (0,0,0.5), no rotation). Fullscreen quad still fills the frustum.

Alternatively use a second camera. But sharing is fine.

Also frustumCulled = false set on compositeMesh — good, avoids culling issues.

2. Another check: compositeMaterial.map = compositeTarget.texture — when compositeTarget.setSize is called on resize, texture object persists (setSize resizes the underlying framebuffer; texture.image dims update). Actually for WebGLRenderTarget, setSize disposes and reallocates internally but the texture instance stays valid. Good.

3. MeshBasicMaterial with a HalfFloat map sampled in the RenderPass — fine in WebGL2.

4. OutputPass: uses renderer.outputColorSpace (sRGB default in r160) — applies sRGB conversion. Sim passes render to linear targets without conversion. Consistent with typical fluid sims. Good.

5. When BLOOM off, displayPass renders directly to canvas: no sRGB conversion applied by ShaderMaterial output... colors will look slightly different (darker) vs bloom path. Minor cosmetic inconsistency, acceptable — but could add a note. Actually in r152+, three.js ShaderMaterial does NOT auto-append encoding; output will be linear values displayed as sRGB — slightly darker. Acceptable; bloom is on by default.

6. The hint mentions keys A/R/C — implemented. H for panel — implemented. Good.

7. bindSlider('simRes'...) calls rebuildSimTargets immediately during setup (update() runs on bind) — that disposes and recreates targets once at startup. Harmless.

Wait — actually there's a subtle ordering bug: bindSlider calls update() immediately, which calls rebuildSimTargets(). That function references simRes, velocity, etc. — all defined earlier. It disposes and recreates them. Fine. Same for dye. Slight waste, no bug.

8. clearDye uses clearPass with uValue 0.0 — sets dye to black. Good.

9. Erase mode: negative dye values. With HalfFloat dye texture, negative values stored fine. Display: negative color → contributes darkness. OK.

10. In applyPointerSplats, erase uses fixed -0.01 — mild erase per move event; may need multiple passes. Increase to -0.03? Minor tuning; leave.

11. The splat radius: correctRadius(config.SPLAT_RADIUS / 100 * radiusScale) — radius 0.3 → 0.003 * aspect. exp(-dot(p,p)/0.003) — at distance 0.05 uv units, dot=0.0025, exp(-0.83)=0.43. Decent.

12. auto.next initialized 0 — first auto splat happens immediately at frame 1. Fine.

13. FPS meter: fine.

14. Check the CSS selector again: #panel.hidden ~ #collapseBtn — collapseBtn is AFTER panel in DOM? Order: ... then . Yes sibling following. Good.

15. panel.addEventListener('dblclick') — dblclick inside panel could trigger canvas pointer events? Panel is above canvas (z-index 20), pointer events on panel don't reach canvas. dblclick on slider area hides panel — could be accidental but it's a minor easter egg; keep.

16. Vignette CSS conflict: none.

17. renderer = new THREE.WebGLRenderer({...}) with alpha:false — fine.

18. iOS Safari: importmap supported iOS 16.4+. Fine.

Now apply the camera.position.z fix. Also, one more potential issue: RenderPass renders compositeScene with camera — I set frustumCulled=false on the mesh. With camera moved to z=0.5, all good.

Let me apply the camera tweak and then do a final read-through of the full file quickly to catch anything else.

Wait — there's a subtlety: the sim passes use ShaderMaterial with gl_Position = vec4(position.xy, 0.0, 1.0) — camera irrelevant. But moving camera to z=0.5 doesn't break them. The composite MeshBasicMaterial quad at z=0 is now 0.5 away → within [0,1] depth range.

Now let me do a final full read-through of the file to catch any remaining issues. Given time constraints (~40% left maybe), read it in chunks quickly, focusing on JS logic. Actually, let me re-run the JS syntax check + xref since I edited, then read through the whole file once.

***************************************************************************************************************************************************sh.

Everything checks out:

• Demo file created at /space/demos/004-fluid-dynamics/index.html (39.5 KB)
• JS syntax OK (node --check)
• All 10 GLSL shaders parse OK
• All uniforms cross-checked consistent between GLSL and JS
• All 11 DOM IDs referenced in JS exist in HTML
• No placeholders/TODOs
• CDN URLs reachable (200)
• Index page updated (9 "demo-card" matches = CSS rules + 4 cards... 4 cards × ~4 occurrences... anyway, the card was added as verified by the earlier preview)

Note: the idcheck counts $('...') — 11 unique IDs. But wait, bindSlider/bindToggle use $(id) with variable names — those are passed literals like 'simRes', 'v-simres' etc. at call sites — the regex \$\('([\w-]+)'\) captures those literal call sites too since they're written as $('simRes')? No! bindSlider('simRes', 'v-simres', ...) — those are plain function calls, not $('...'). The $ calls happen only inside bindSlider as $(id) with a variable. So literal $('...') matches are only direct ones like $('toast'), $('randomBtn'), etc. — 11 found, all present. The slider/toggle IDs ('simRes', 'v-simres', etc.) weren't checked by this regex!

Let me quickly verify those exist — they were in my HTML: simRes, dyeRes, velDiss, dyeDiss, vorticity, pressure, radius, force, shading + labels v-simres, v-dyeres, v-veldiss, v-dyediss, v-vorticity, v-pressure, v-radius, v-force, v-shading + toggles auto, idleAuto, bloom, vignette. I wrote them all in the HTML. A quick grep can confirm but time is at ~88%. One fast grep to be safe — it's cheap.