Fluid simulation · particle-1

Let me write a fluid sim. I'll use WebGL with float textures (OES_texture_float or half float). To be safe, use half-float via WebGL2 with EXT_color_buffer_float, fallback. Actually simpler: implement classic stable fluids in WebGL1 with floating point textures using OES_texture_half_float + WEBGL_color_buffer_float. Hmm, risk with render-to-texture half float.

Alternative: CPU simulation at low res (e.g., 128x85) with advection + pressure solve using Jacobi. That's fully reliable and fast enough. 128*85 = ~10880 cells. Pressure iterations 20 → 200k ops per frame, fine. Advection with RK2 semi-Lagrangian for dye at higher res? Dye could be at same grid resolution as velocity, but rendering dye upscaled to canvas would look blocky. We can render dye at higher res, e.g., 256x170 = 43k cells, advect with velocity sampled via bilinear interpolation. That's fine on CPU.

Actually let's do CPU: velocity grid 128x85 (or 160x106), dye grid 256x170. Total per frame: dye advection 43k * bilinear ~ maybe 2ms. Pressure solve 20 iterations over 128*85 ~ 217k ops. Should be a few ms. Then render to ImageData at dye resolution and drawImage scaled up with smoothing. That'd be blurry but ok. Better: render dye to a small canvas via putImageData then drawImage scaled with imageSmoothingEnabled=true → smooth gradient look. Nice.

Physics steps:
- addForces from pointer: velocity += dragForce along drag dir within brush radius; dye += color.
- advect velocity (semi-Lagrangian) with decay.
- projection: compute divergence, solve pressure (Jacobi), subtract gradient.
- advect dye with dissipation.

Boundaries: set velocity to zero at edges (or reflect). Use simple: treat outside as zero velocity, and clamp indices.

Initial seed: add a few swirls of dye + velocity on load.

Let me write efficient typed-array code.

Grid: NX, NY for velocity, DYEDX = NX*2 etc. Actually simpler: use one resolution for both, e.g. 200x133 (~26600 cells) → dye upscale 6x → 1200x800. 26600 cell advection x2 (velocity advected in both u and v? each needs 26600 samples) plus dye advection → ~80k bilinear samples/frame, fine.

Pressure Jacobi 20 iters * 26600 = 532k → fine.

Rendering: dye canvas 200x133, putImageData then drawImage scaled to 1200x800 with smoothing → looks smooth and nice. Good.

Let's define grid dimensions based on aspect: NX = 220, NY = round(220 * H/W) for aspect... but canvas is full screen; we can fix simulation grid aspect to window aspect. On resize, re-init.

Let's write code.

Indexing: idx = x + y*NX.

Velocity arrays u, v (Float32Array size NX*NY), uPrev, vPrev, dyeR, dyeG, dyeB, dyeRprev...

Semi-Lagrangian advection:
```
function advect(dst, src, dt, dissipation) {
  for y, x:
    px = x - dt*u[idx]*NX/ (maybe scaled)
```
Velocity stored in "cells per second" units — set velocity in grid cell units per second. Then backtrace: x0 = x - dt*u[idx], y0 = y - dt*v[idx]; bilinear sample src, multiply by dissipation.

Projection:
divergence[idx] = -0.5*(u[x+1]-u[x-1] + v[y+1]-v[y-1]) / h ... with h=1: div = -0.5*(u[i+1]-u[i-1]+v[j+1]-v[j-1]).
Pressure p: jacobi: p = (div + p_left+p_right+p_up+p_down)/4.
Then u -= 0.5*(p[i+1]-p[i-1]); v -= 0.5*(p[j+1]-p[j-1]).

Boundaries: zero velocity at edges. Use clamped indexing helper for sampling, and for divergence use velocity zero at boundary neighbors.

Let me write with a small inline function for boundary: at x==0 or x==NX-1, force u=0. Similarly y.

Pointer injection: on move while pressed, compute dx,dy in grid coordinates; add force: for cells within radius R: u += dx*strength*falloff; v += dy*strength*falloff; dye += color * falloff.

Dye radiance: dye stored 0..1 per channel. Advect with dissipation 0.999 per step maybe; add slight fade: multiply by 0.9995 each frame -> after ~10 s still visible. Let's do dissipation per-second: pow(0.997, dt*60)? Simpler: mult = Math.pow(0.995, dt*60)... At 60fps, dt=1/60 → mult 0.995 per frame → halves in ~2.7s. Too fast maybe. Task requires "gradually dissipate" — a bit of fading is fine but should stay visible after release for a while. Use 0.999 per frame → half life ~11s. Good. Slight fading.

Velocity dissipation: 0.999 per frame too? Momentum should remain visible. Use 0.998 → decays over ~6s.

Rendering: color map dye with a slight tone-mapping: c = 1 - exp(-d*k)? Let's map: value v in [0,1], out = 255*(1-exp(-v*2.2)) maybe. Keep background near #05070d.

Now, the dye canvas: create offscreen canvas NX x NY with ImageData; putImageData; then ctx.drawImage with smoothing to main canvas. Main canvas fillRect background then drawImage. Note dye res 220x146 scaled to 1200x800 → ratio ~5.45, fine.

Actually to improve quality slightly, could advect dye at 2x velocity res. Let's do dye at 2x: NXd = 440, NYd = 292 (128k cells) — advection sampling cost 128k bilinear/frame ~ maybe 3-5ms. Acceptable. Hmm, keep single res 260x~173 and vignette? Let's test perf. I'll use DYE_SCALE = 2 but check FPS, and reduce if needed. Let's start with 1.6? Keep it simple: same grid but NX=256, NY = round(256*H/W). At 1200x800 → NY=171 → 43,776 cells. Pressure 20 iters = 875k ops → fine (~2-4ms). Dye at 2x → 175k cells advect → maybe 3ms. Total < 10ms. OK.

Let me just use one grid for velocity at NX=192 and dye at 2x (384x256 = 98k). Hmm, velocity grid coarse gives smoother swirls when upsampled? Velocity sampling from coarse grid used for dye advection - fine.

I'll implement velocity NX=192,NY from aspect, dye 2x that.

Bilinear sample function for velocity during dye advection needs to handle out-of-range. Use clamp.

Write the code.

Also required UI: color selector, Pause/Resume, Clear. Style them as floating glass panel top-left. Color selector: swatches (several) — "Provide a color selector" — swatch buttons count as color selector. I'll also add an HTML color input? Custom swatches plus a hue slider maybe. Let's do 6 swatch buttons + rainbow-ish custom input type=color (native, no network). Native color input is fine, no external resource.

Implementation details for injection strength: drag movement in grid cells. On pointermove: dxg = (x - lastX) * NX/width. Force u += dxg * 0.6 * falloff. Since these are cells/s, a fast drag of 300px = 300*192/1200 = 48 cells → u ~ 29 cells/s. Reasonable.

Clamp velocity magnitude to avoid explosion: cap at e.g. 60 cells/s.

Also, injection should also happen on pointerdown with small motion hint? If click with no movement, add small dye and slight random velocity.

Frame loop with dt clamped to 1/30 max, fixed sub-steps: use fixed dt = 1/60 and up to 2 steps per frame? Simpler: dt = min(elapsed, 0.033). Use multiple substeps if dt large to keep stability. Semi-Lagrangian stable anyway. I'll do step with dt clamped.

Dissipation applied per step with dt scaling: velocity mult = Math.pow(0.985, dt*60)? Hmm per-frame 0.985 → half-life 0.75s too fast. Let's compute: I want velocity to decay mildly: per-frame factor 0.9985 → half-life ~ 460 frames ~7.7s. Use pow(0.9985, dt*60).

Dye dissipation: want maybe 20s half-life: per frame 0.9993 → 2.3%. half-life ~ 1000 frames ~16s. Fine.

Let me write it.

Also seed initial scene: add several vortex blobs of dye with diverging swirl velocity. E.g., 4 colored blobs with tangential velocity field.

Pressure jacobi with 25 iterations. Need p, pPrev arrays and div array.

Code:

```js
function sampleBilinear(arr, x, y, NX, NY){...}
```

Let me write the whole thing carefully.

Time budget: write file, then run browser checks.

Rendering: main canvas full screen, devicePixelRatio limited to 1? Use dpr but smaller to keep perf. Set canvas.width = innerWidth, height=innerHeight (CSS pixels) — fine.

Edge handling in advect: bilinear with clamped coordinates → okay, gives smearing at edges but boundary velocity zero keeps it fine.

Let me write.

```html
<!DOCTYPE html>
<html><head><meta charset="utf-8"><title>Fluid & Dye</title>
<style>...</style></head>
<body>
<canvas id="c"></canvas>
<div class="panel">...</div>
<div class="hint">...</div>
<script>
...
</script>
</body></html>
```

Panel: swatches with data-color; buttons.

Now full JS:

```js
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d', {alpha:false});
let W=0,H=0;
let NX, NY, NXD, NYD, SCALE=2;
let u,v,u0,v0,p,div,dR,dG,dB,dR0,dG0,dB0;
let dyeCanvas, dyeCtx, dyeImg;
let color = {r:1,g:0.35,b:0.1};
let paused=false;
let last = performance.now();

function setup(){
  W = window.innerWidth; H=window.innerHeight;
  canvas.width = W; canvas.height = H;
  const base = 200; // velocity grid long side
  NX = base; NY = Math.max(24, Math.round(base * H / W));
  ...
}
```
Wait: aspect. If H/W = 800/1200=0.667 → NY=133.

Dye grid: NXD = NX*2, NYD = NY*2.

On resize, we should re-init and re-seed (or resample). Simplest: re-init and seed.

Actually resize on mobile scroll could reset. Fine.

Accumulated dye arrays at dye res. Advection of dye uses velocity sampled at dye grid coords mapped to velocity grid coords: gx = x * NX/NXD.

Velocity advection on velocity grid.

Let me write step:

```js
function step(dt){
  // advect velocity
  u0.set(u); v0.set(v);
  advectVel(u,v,u0,v0,dt);
  project();
  advectDye(dt);
  applyDissipation(dt)? 
}
```

Hmm for dye advection, I'll advect from dR0 etc.

Injection should happen before advection in the frame (called from pointer handler writing directly into current arrays). Fine.

Details of advectVel:

```js
function advectVel(dt){
  u0.set(u); v0.set(v);
  const decay = Math.pow(0.9985, dt*60);
  for(let y=0;y<NY;y++){
    for(let x=0;x<NX;x++){
      const i=x+y*NX;
      const x0 = x - u0[i]*dt;
      const y0 = y - v0[i]*dt;
      sampleVel(u0,x0,y0) -> u[i]=val*decay;
      ...
    }
  }
}
```
That's two bilinear samples per cell (one for u, one for v), 192*133=25.5k cells * 2 → 51k samples. Fine.

I could combine: compute indices once then sample both arrays. Do that.

Sample function inline for speed with typed arrays.

Then boundaries: enforce zero normal velocity at edges:
for x: u[0 + y*NX]=0; u[(NX-1)+y*NX]=0; for y: v[x]=0, v[x+(NY-1)*NX]=0. Also clamp.

Projection:
```js
function project(){
  // divergence
  for y 0..NY-1: for x:
    const i=x+y*NX;
    const xl = x>0? i-1 : i, xr = x<NX-1? i+1 : i;
    const yl = y>0? i-NX : i, yr = y<NY-1? i+NX : i;
    div[i] = -0.5*(u[xr]-u[xl] + v[yr]-v[yl]);
    p[i]=0;
  // jacobi iterations
  for k<iters:
    for y,x:
      const i...
      p[i] = (div[i] + p[xl]+p[xr]+p[yl]+p[yr])*0.25
    // alternate arrays to avoid copying? simple in-place with slight bias, fine
  // subtract gradient
  for ...
    u[i] -= 0.5*(p[xr]-p[xl]);
    v[i] -= 0.5*(p[yr]-p[yl]);
}
```
Using p array clamping at boundaries (index same as center) works as Neumann-ish. Standard implementation does that. OK.

In-place Jacobi converges fine visually.

advectDye: for each dye cell, sample velocity bilinear at (x*NX/NXD, y*NY/NYD), backtrace, sample dye bilinear, multiply dissipation.

Dye advection cost: 400x266=106k cells with 3 dye channel samples → need combined sample of 3 arrays: compute indices once and bilinear weight once, apply to R,G,B → good.

Also add slight dye decay and maybe diffusion? No diffusion needed; semi-Lagrangian adds numerical diffusion.

Rendering: 
```js
for each dye pixel: 
  r = dR[i] etc
  tone map: v = 1-exp(-c*1.8)? 
  Actually dye accumulates, values can exceed 1. Use c = 1-Math.exp(-val) 
  img data.
```
106k pixels * 3 exp calls = 318k exp per frame — might be ~5ms. Optimize with Math.min(1, val) then a lookup table? Use simple clamp and gamma: out = 255 * (1 - 1/(1+val*1.4))? That's cheap arithmetic. Let's use x/(1+x) style tone map: c = val; out = 255*(c*(1.3))/(1+c*1.3)... Actually saturating: y = c/(1+c). With c=1 → 0.5, c=3 → 0.75, c=9 → 0.9. Fine, brightens nicely. Then gamma: pow 1/1.1? Skip gamma, keep x/(1+x) with scale.

Use: f = c/(c+0.9) maybe. Let's do factor: t = c/(1+c*0.85) to get brighter early. Test visually.

Also add slight bloom-ish? no.

Background: fill black-ish gradient then drawImage.

Also aspect: dye canvas NXD x NYD exactly matches canvas aspect ratio, so scaling is uniform.

Perf: drawImage of 400x266 → 1200x800 uses smoothing, should be cheap on GPU.

Anti-alias blur is desirable for fluid look.

Now clear(): zero all arrays, then optionally seed faint small dye? "Clear removes dye and resets velocity; the next drag can start a new flow." So zero everything, no seed.

Seed initial: 
```js
function seed(){
  // add a few blobs with velocity
  const blobs = [
    {x:0.30,y:0.4, r:0.18, c:[0.1,0.6,1.0], spin:1},
    ...
  ];
```
Add dye radially with falloff and swirl velocity: for velocity grid, for each cell within radius, tangential velocity around center: dir perpendicular.

Implement helper addSwirl(cx, cy, radius, strength) on velocity grid in grid units.

Also add a stretched dye streak maybe. Keep it simple: 3-4 blobs of different colors and swirly velocity → visible motion on load.

Color selector: swatches: cyan, magenta, lime, orange, violet, white-ish. Clicking sets color. Also native input color for custom.

UI state: paused button text toggles.

Pointer handling on canvas:
- pointerdown: set dragging, lastX/lastY, capture, inject small dot.
- pointermove: if dragging, inject.
- pointerup/cancel: dragging=false.

Injection function inject(px, py, dx, dy):
convert to grid coords: gx = px/W*NX, gy = py/H*NY for velocity; dye coords separately.
radius in velocity cells: R = 0.05*NX? Let's use brush radius in pixels: 45px → velocity radius ~ 45*(NX/W) ≈ 7 cells. Good. For dye: radius ≈ 45*(NXD/W).

Force: u += dxCells * 0.55 * falloff where dxCells = dxPixels * NX/W. Hmm unit: dx cells added directly to velocity (cells/s) → fast drag multiply. Let's scale 0.4 and clamp velocity magnitude to 80.

Also add dye: dR += color.r * 0.6 * falloff etc. Maybe accumulate limited.

Falloff: f = exp(-d²/r²) or (1-d²/r²) clamp. Use smoothstep: 1 - (d/r)^2 smooth.

Moving average: use interpolated points between last and current to avoid gaps: step along segment by radius*0.5.

Let me also ensure pause stops injection? Pause should stop simulation but allow... Simpler: while paused, no injection (or dye injection but no step). I'll skip injection while paused, and show state. Actually better allow drawing while paused for clarity? Requirement only says pause/resume. I'll block injection while paused to keep dynamics consistent... Hmm, if paused user drags and nothing appears, confusing. I'll allow injection (dye + velocity writing) but no advection step while paused; when resumed, the injected stuff flows. That's nice.

But with paused, dye won't render? Rendering dye arrays each frame still happens (we render every frame regardless). Fine.

Fixed timestep loop with accumulator:
```js
let prev = performance.now(), acc=0;
function frame(now){
  const raw = Math.min((now-prev)/1000, 0.05); prev=now;
  if(!paused){
    acc += raw;
    let steps=0;
    while(acc >= 1/60 && steps<2){ step(1/60); acc -= 1/60; steps++; }
    if(acc > 1/60) acc = 0;
  }
  render();
  requestAnimationFrame(frame);
}
```

Also, velocity clamp: after projection, clamp to 100 cells/s.

Additionally pointermove only gives events at ~60Hz; inject on each event using accumulated distance interpolation.

Write now.

One concern: canvas 2D with alpha:false and filling each frame. Use black background with subtle radial gradient created once per resize (create a gradient) — can just fill with solid color, simpler & cheap.

Let me write the file.

For the dye ImageData: create once at setup.

Rendering loop reads dR, dG, dB, writes Uint8ClampedArray data. Then dyeCtx.putImageData(img,0,0); ctx.imageSmoothingEnabled = true; ctx.drawImage(dyeCanvas, 0,0, W,H).

Also maybe add a subtle "glow" via globalCompositeOperation 'lighter' second blurred draw? Skip for perf.

Let me handle devicePixelRatio: use canvas.width = Math.round(W) with dpr 1 for perf. On high-dpi it'll be slightly soft — acceptable.

Code the sample helper as inner function using closures on typed arrays.

Write it.

Also: sage — pointer events on canvas need `touch-action: none` CSS.

Let me write out the code fully.

```js
(function(){
'use strict';
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d', {alpha:false});
let W=1,H=1;
let NX=1,NY=1,NXD=1,NYD=1;
let u,v,u0,v0,pr,div;
let dR,dG,dB,dR0,dG0,dB0;
let dyeCanvas, dyeCtx, dyeImg;
const FBASE = 190; // velocity grid long side
const DSCALE = 2;
```

Arrays allocated in init.

Injection brush radius: BRUSH_PX = 52.

Now details of sampling velocity in dye advect: velocity grid coord = (x+0.5)*NX/NXD - 0.5 for cell-centered alignment. Use that.

Similarly velocity sample positions align.

For velocity advection, backtrace in grid space direct.

Bilinear sampling of velocity with clamp:

```js
function sampleVelAt(arr, x, y){ // arr u0 or v0
  if(x<0) x=0; else if(x>NX-1) x=NX-1;
  if(y<0) y=0; else if(y>NY-1) y=NY-1;
  const x0=Math.floor(x), y0=Math.floor(y);
  const x1=Math.min(x0+1,NX-1), y1=Math.min(y0+1,NY-1);
  const fx=x-x0, fy=y-y0;
  const i00=x0+y0*NX,i10=x1+y0*NX,i01=x0+y1*NX,i11=x1+y1*NX;
  const a=arr[i00]+(arr[i10]-arr[i00])*fx;
  const b=arr[i01]+(arr[i11]-arr[i01])*fx;
  return a+(b-a)*fy;
}
```
For dye advect I need both u and v at same point, so compute indices once and interpolate two arrays. I'll write a helper that returns via a module-scope temp object? Faster: inline the code in the loop, sampling u0 and v0 inside the dye loop with shared index computation. Let me write a function `sampleVelBoth(x,y)` returning [uVal,vVal] — array allocation per call is costly (106k arrays/frame). Use module-level variables `_su`, `_sv` set by function. Acceptable.

Actually better: do two separate calls to sampleVelAt (u0 and v0). 212k calls/frame with function overhead... maybe 3-5 ms. Fine-ish. Let's reduce dye scale to 1.75? Keep 2 and check FPS in browser.

Alternatively advect dye on the velocity grid then upscale — dye would be blocky at 190x126 upscaled to 1200x800 with smoothing → actually bilinear upscale looks quite smooth, and it's the common look. But finer dye = crisper filaments. I'll test with DS=2 and measure.

I'll add an FPS meter? Not needed for the UI but helpful for verification via console. I'll log nothing; instead measure in browser via performance timing manually... I can add a hidden debug: window.__fps available. Let me keep a small FPS display in the panel? Might be nice but not required. I'll skip UI fps but expose `window.__stats = {fps, ms}` for checking. That's harmless.

Let's write the final file now.

Seed function:

```js
function seedScene(){
  // dye blobs
  const blobs=[
    {x:0.28,y:0.38,r:0.15,c:[0.05,0.55,1.0],dir:1,s:9},
    {x:0.62,y:0.30,r:0.12,c:[1.0,0.18,0.45],dir:-1,s:8},
    {x:0.55,y:0.66,r:0.16,c:[0.25,1.0,0.55],dir:1,s:7},
    {x:0.80,y:0.55,r:0.10,c:[1.0,0.75,0.15],dir:-1,s:6},
  ];
  for each blob:
    const cx=blob.x*NXD, cy=blob.y*NYD, rad=blob.r*Math.max(NXD,NYD);
    for dye cells ... f=falloff; dR[i]+=c[0]*f*1.6 ...
    // velocity swirl on velocity grid
    const vcx = blob.x*NX, vcy=blob.y*NY, vrad=blob.r*Math.max(NX,NY);
    for cells in vrad: f; dx=(x-vcx)/vrad, dy=(y-vcy)/vrad; tangential: u += -dy*s*f*dir ... hmm units cells/s: s=9
```
Also add a gentle global flow? Add small random-ish divergence-free field? Swirls are enough.

Also for aesthetics, generate a couple of dye streaks.

Fine.

Now injecting: 

```js
function inject(x, y, dx, dy){
  const gx = x/W*NX, gy = y/H*NY;
  const vr = BRUSH_PX * NX / W; // velocity radius in cells
  const vdx = dx * NX/W, vdy = dy * NY/H;
  const speed = Math.hypot(vdx,vdy);
  // clamp
  const x0=Math.max(0,Math.floor(gx-vr)), x1=Math.min(NX-1,Math.ceil(gx+vr));
  ...
  for cells: d2 = ((x-gx)^2+(y-gy)^2)/vr^2; if d2>1 continue; f=1-d2; f=f*f? use f=Math.pow(1-d2,1.2)? keep (1-d2).
    u[i] += vdx*0.9*f; v[i] += vdy*0.9*f;
  ...
}
```
The force added per pointermove event: dx is pixels since last event. On a 200px drag in ~15 events → ~13px per event * (NX/W=0.158) ≈ 2 cells per event → u += ~1.8*... using 0.9 factor → total build up to ~ 30 cells/s. Let's use factor 1.2 and clamp speed to 90.

Also add dye at dye-grid with color, amount = 0.08 + speed-based 0.25? Dye accumulates heavily if held in one place. Cap dye at e.g. 3.0.

Also add small amount of dye when clicking without moving: on pointerdown, inject with dx=dy=0 but amount of dye — put a small dot of dye and slight velocity? Requirement: drag injects. Click alone adding a dot is nice. I'll do dye dot.

Dye radius: BRUSH_PX*NXD/W.

Pointers: use segment interpolation to avoid gaps: I'll subdivide the segment based on distance with steps of radius*0.4, injecting at each interpolated point with the per-step delta.

Simplify: in pointermove, compute steps = clamp(ceil(dist / (brushPx*0.35)),1,8), loop injecting at (last + t*(cur-last)) with delta / steps.

Now render function.

Also tone mapping: I want colors visible. Let's compute:
```
let r=dR[i],g=dG[i],b=dB[i];
// saturating
r = r/(1+r*0.9) ... 
```
Hmm if r=0.1 → 0.0917 → 23/255 too dim. Better linear then tone map with exposure: e = 2.0; then r=e*r; out = r/(1+r) → 0.1*2=0.2 → 0.167 → 43. ok. r=0.5→1→0.5→128. r=2→4→0.8→204. Good.

Add a tiny base background glow? no.

Also multiply by color-specific? no.

I'll apply: 
```
const e=1.9;
r*=e; g*=e; b*=e;
data[p]=255*(r/(1+r));
```
Then gamma correction sqrt would brighten mid-tones; use Math.sqrt? cost. Use precomputed LUT? Simpler: v/(1+v) then out^0.85 roughly linear... skip gamma.

Actually to make dye look nicer, use `x = v/(1+v)` then `out = Math.pow(x, 0.75)`. pow is costly at 320k/frame. Use sqrt-ish: Math.sqrt is fast. out = Math.sqrt(x)? That would over-brighten dark. Let's just test visually with the screenshot.

I'll include a lookup table of 1024 entries for tone mapping: tone[i] = 255*Math.pow((1.9*v)/(1+1.9*v), 0.8). Build once. Then lookup with index = min(1023, v*256). Good and fast.

Let me use table size 2048 with input scale 384 (covers 0..5.3), clamp beyond.

Now write the code.

Also handle window resize with debounce → reinit and re-seed? Resizing clears arrays → re-seed for aesthetics. But could lose user's flow. Resampling is complex; re-seed is acceptable. Actually better: don't re-seed, just clear. Hmm, if the user resizes to full screen, blank canvas — fine but a bit dull. I'll re-seed on resize only if not much state. Simpler: on resize, re-init arrays preserving nothing and re-seed a small scene. I'll do that (resize is rare in verification).

Let's write it.

Also controls: Pause button toggles text and class. Clear button clears. Color swatches.

Keyboard: space toggles pause, C clears. Nice extra.

Write file now.

Regarding NYD derived from aspect: NX=190; NY = round(190*H/W); NXD=NX*2, NYD=NY*2.

At 1200x800: NY = 127, NXD=380, NYD=254.

Now writing.

Also stats: compute fps EMA and store in window.__stats.

Let me write it all out.

One thing: `ctx.getContext('2d', {alpha:false})` — fillRect background each frame with #05070c. Then drawImage dye. Since dye canvas has opaque black background? dye canvas putImageData with alpha 255 and color values → draws over. Fine.

Now careful with the projection loop performance: NX*NY = 24k, 22 iterations → 530k iterations with array indexing. ~3ms. OK.

Implementation of Jacobi: I'll do p and p0 swap? In-place Jacobi is used in some implementations (they do p[i] = (div + neighbors)/4, using already-updated neighbors) — that's Gauss-Seidel, which converges faster and is fine. Use in-place → no extra arrays.

Write code.

For sample position offsets: standard stable fluids uses cell centers, backtrace x - dt*u. Fine.

Also `u0.set(u)` each frame: 24k floats copy ×2 arrays = cheap.

Code for advectVel:

```js
function advectVel(dt){
  u0.set(u); v0.set(v);
  const decay = Math.pow(0.9988, dt*60);
  for(let y=0;y<NY;y++){
    for(let x=0;x<NX;x++){
      const i=x+y*NX;
      const bx = x - u0[i]*dt;
      const by = y - v0[i]*dt;
      // bilinear
      let sx = bx<0?0:(bx>NX-1?NX-1:bx);
      let sy = by<0?0:(by>NY-1?NY-1:by);
      const x0=sx|0, y0=sy|0;
      const x1=x0+1<NX?x0+1:x0, y1=y0+1<NY?y0+1:y0;
      const fx=sx-x0, fy=sy-y0;
      const i00=x0+y0*NX, i10=x1+y0*NX, i01=x0+y1*NX, i11=x1+y1*NX;
      const w00=(1-fx)*(1-fy), w10=fx*(1-fy), w01=(1-fx)*fy, w11=fx*fy;
      u[i] = (u0[i00]*w00 + u0[i10]*w10 + u0[i01]*w01 + u0[i11]*w11)*decay;
      v[i] = (v0[i00]*w00 + v0[i10]*w10 + v0[i01]*w01 + v0[i11]*w11)*decay;
    }
  }
  // boundary
  for(let y=0;y<NY;y++){ u[y*NX]=0; u[NX-1+y*NX]=0; }
  for(let x=0;x<NX;x++){ v[x]=0; v[x+(NY-1)*NX]=0; }
}
```
Note sx|0 truncates toward zero; since sx>=0 fine.

Dye advect similar with 3 channels and coordinate mapping.

Alright, write.

For dye dissipation: dy decay = pow(0.9990, dt*60) → per frame 0.999 → half-life 693 frames ≈ 11.5 s. Good.

Rendering dye at dye resolution: pointer dye injection coordinate mapping: x/W*NXD.

Let me write the file now for real.

Fix the odd falloff line in seedBlob: `f = f*f*(3-2*f)*0 + f*f` → simplify to f*f. Let me clean that.

Then run browser.

The scene renders, but the blobs look static-ish (maybe they are moving). Concern: the dye diffusion is heavy from bilinear advection each frame at 2x grid, so blobs blur. Need to check motion. Let me take a motion screenshot after a bit and also check dye movement direction. Also the seed velocity is quite weak (0.055*strength with tangential magnitude ~ few cells/s). The blobs are large and diffuse because semi-Lagrangian repeatedly blurs, plus dye field at 2x upsample blurred.

Let's test drag behavior.

Drag injects dye streak. Now check whether it advects/swirls after release. Take a motion frame or screenshot after a delay. Let me use motion action to capture frames.

Frames barely change — the flow is basically frozen! Between frames, blobs look identical. That's a serious bug: the simulation is barely moving (or not moving at all).

Wait — maybe rendering only happens once? But frame 2/3/4 look identical. Note tiny green blob deformation. Hmm.

Possible problem: `frame(now)` is called with rAF timestamp, and my initial call `requestAnimationFrame(function(t){prev = t; frame(t);})` then frame schedules itself. That should be fine.

Why no motion? Possibly the velocity is tiny. Seed strength: u += -ddy*spin*strength*ff where ddy is in cells (~±10), strength 0.055 → ~0.55 cells/s. That's really slow! I intended strength in cells/s. So seed velocity is ~0.5 cells/s → moves 0.5 cells per second → 0.5 * (1200/380) ≈ 1.6 px/s. Nearly static! Similarly drag: fdx = dxPx*NX/W per event ~ 2 cells, ×1.15 factor ×falloff → u maybe ~1.5 cells/s per event, accumulating over 15 events to ~20 cells/s. That should be visible... but the drag streak barely moved within 1.7s (20 cells/s → 20 cells = ~60px in 1 s). In the frames, the streak looks static-ish but slightly different? Actually frames 1-4 nearly identical, suggesting sim isn't stepping at all.

Hmm, maybe an exception in the loop? Console shows nothing. Let's check with inspect/console eval. The browser tool: action "inspect" gives dom/console. Let me evaluate window.__stats via inspect? Probably inspect only returns console logs. I can add temporary logging.

Wait, but the dye blob near the drag start appears smeared, so something changed vs. the reload screenshot? I only see current frames.

Possible bug: in `render`, does it render every frame — yes. If simulation weren't running, screen would be static. Frames identical → suggests no update.

Bug candidate: `prev = now` then `dt = (now-prev)/1000` = 0 for subsequent? No, prev updated each frame.

Another: `FIXED` loop - acc += dt, while acc >= FIXED. Works.

Hmm — unless requestAnimationFrame(frame) inside frame isn't running because an exception is thrown before it (render throwing?). Console shows nothing though; uncaught errors appear in "console" of the tool? Possibly not captured.

Time in the motion capture: frames at +567ms intervals... that's just capture cadence.

Key suspicion: pressure projection kills velocity? If my Jacobi sign is wrong, projection could just not cancel properly but shouldn't zero velocity. Actually with div sign and gradient sign both consistent, it should reduce divergence. Fine.

Let me instrument: log stats and max velocity to console periodically, then use inspect to read console.

I need to read window.__dbg. Does the browser tool allow evaluating JS? Only actions listed. inspect returns dom/console. Maybe I can log to console periodically. Let me add console.log of __dbg every 30 frames temporarily.

Actually the "console" field may capture console messages. Let's add a temporary console.log every 60 frames.

Console is empty and the image looks different from the previous (slightly), but blobs are still circular and not moving. Also console.log doesn't show. Maybe the reload didn't pick up the file change? The image did change slightly... Hmm.

Since I can't read console, use the DOM: add a debug line in the DOM panel displaying stats via textContent. Let's add a hidden div updated each frame with stats, and read via inspect dom.

Actually simpler: update document.title with stats → dom output might include title? The dom field shows text content. Let's add a debug div inside .panel with small text showing stats.

The dbg div still shows "x" — meaning the frame loop stopped after the first frames?? Actually it updates every 20 frames; inspect may return DOM immediately after load (frame 1). The loop may still run. Let's wait then inspect again.

The sim is running (fps 60, max |u| ≈ 2.6–3.1). But velocity is tiny (~3 cells/s at peak) and the dye blobs are basically fixed. Also they look like big soft circles rather than swirling fluid. Two issues:

1. Seed/swirl velocity magnitudes are far too low (strength ~0.05 multiply by cell offsets ~5-10 → 0.5 cells/s). Need ~20–40 cells/s.
2. The seed dye is a smooth radial blob which will look boring; better to seed thin filaments/streaks so advection creates visible structure.
3. Numerical diffusion from repeated semi-Lagrangian advection at large dt relative to grid? At speed 3 cells/s it barely matters.
4. The dye rendering looks extremely smooth/blurred - because the dye is broad gaussians upscaled.

Also I need to check whether drag actually produced a visible streak earlier; the earlier screenshot with drag did show something? I didn't see it clearly (the images from before were omitted). Anyway.

Let me fix seeding with proper strengths: tangential velocity u = -ddy/vrad * strength * ff where ddy/vrad normalized (-1..1). strength ~ 25 cells/s.

Current code: u[j] += -ddy * spin * strength * ff with ddy in cells — so effectively strength * radius amplification, but strength was 0.055. With ddy up to ~10 and strength 2 → 20 cells/s. Let's set strengths ~1.6-2.2 (with ddy up to 10). Hmm cleaner: normalize: u += -ddy/vrad * spin * strength * 60 * ff? Let me define strength as peak swirl speed in cells/s: u = -ddy/vrad * spin * strength * ff. Set strength 26.

Also initial drift terms: u += 1.6*sin + 0.8 → up to 2.4 cells/s; that's fine as background, maybe keep small.

Also dye filaments: rather than gaussian blobs, seed with thin curved streaks. Approach: for each blob, use a spiral-ish density: draw a set of short filaments? Simpler and effective: seed dye along an arc with a thin profile, and give a rotational velocity. E.g., seed function seedFilament(cx, cy, radius, angle0, angle1, thickness, color, spin, speed).

Or: seed density with a ring: f = exp(-((d - r0)/thickness)^2) * angular modulation. Rings with slight noise look like sheared dye and advect into nice swirls.

Let me seed a few arcs with angle modulation: density = exp(-((d - R)/th)^2) * (0.5+0.5*sin(k*theta + phase)) — creates dashed arcs. Combined with strong rotation this will create lovely streaks.

Plus a couple of blobs for body.

Also increase overall simulation liveliness: dye dissipation 0.999/frame is fine.

Another concern: projection with in-place Gauss-Seidel 22 iterations at low velocities - fine.

Also constant re-blurring: after strong motion, dye details dissolve at rate proportional to grid resolution. Dye grid 380x254 helps.

I also want a base "temperature" ambient jitter? Not needed.

Additionally, when the user drags quickly, momentum injection: fdx = dxPx*NX/W. For a 300px fast drag in 10 events → 30px per event → fdx = 4.75 cells per event ×1.15 → 5.5 cells/s accumulating to ~50 cells/s. Fine. But those forces are added to velocity grid then immediately projected; projection subtracts a large portion (since the added force field is a blob with divergence). That's expected; final speed maybe half. Let's raise factor to 2.2 and see.

Let me also render slightly sharper: currently only linear upscale. That's OK.

Let me implement the seeding changes, boost drag force, and remove debug later. Also let me reconsider the sim look: blobs of uniform dye with low velocity look static. With strong rotation arcs will swirl.

Implement:

```js
function seedArc(cx, cy, R, thick, thetaA, thetaB, freq, cr,cg,cb, amount) { ... }
```

Let's write a generic seeding that adds dye density from a callback? Simpler: write seedDyeField() that loops over the dye grid and computes total density from a few analytic emitters:

```js
var emitters = [
 {type:'arc', x:.3,y:.35,R:.13,th:.02,a0:0,a1:6.28,freq:3,cc:[.1,.6,1],amt:2.2},
 ...
];
```
For each dye cell, sum over emitters — 5 emitters × 96k cells = 480k ops once at init. Fine.

Arc density:
```
var dx=x-cx, dy=y-(cy*aspect adjusted?) 
```
Careful: dye grid cells are not square? NXD/NYD ratio matches W/H, and W/H at 1200/800=1.5, NXD/NYD = 380/254 = 1.496 → approximately square cells. Good, so circles are circles.

d = hypot(dx,dy)/R... Use r = hypot(dx,dy), dR0 = R*maxdim... Let's use pixel-ish units: R in fraction of height: Rpx = R*H? Let's use scale S = NYD (matches H). So R = rr*NYD.

density = exp(-((r - R)/(thick*S))^2) * (0.55 + 0.45*sin(freq*theta + phase))
also add inner fill? Keep arcs.

Also add a soft central blob small amount.

Velocity: for each velocity cell: tangential about each emitter center with peak speed at r=R, decaying: f = exp(-((r-R)/(0.5*R))^2), u += -dy/r * speed * f ... plus small radial? Fine.

Let's write this replacing seedBlob/seedScene.

Speed ~ 30-45 cells/s for good visible swirl.

Let's rewrite the seeding section.

Replace seedBlob and seedScene with filament-based seeding. Let me write new code:

```js
  // ---------------------------------------------------------------- seeding
  function seedArc(e) {
    var S = Math.max(NXD, NYD); // dye grid scale
    var cx = e.x * NXD, cy = e.y * NYD;
    var R = e.r * S;
    var th = Math.max(1.0, e.th * S);
    var outer = R + th * 3;
    var x0 = Math.max(0, Math.floor(cx - outer)), x1 = Math.min(NXD - 1, Math.ceil(cx + outer));
    var y0 = Math.max(0, Math.floor(cy - outer)), y1 = Math.min(NYD - 1, Math.ceil(cy + outer));
    for (var y = y0; y <= y1; y++) {
      for (var x = x0; x <= x1; x++) {
        var dx = x - cx, dy = y - cy;
        var r = Math.sqrt(dx*dx + dy*dy);
        var radial = (r - R) / th;
        var band = Math.exp(-radial * radial);
        if (band < 0.004) continue;
        var theta = Math.atan2(dy, dx);
        var wig = 0.45 + 0.55 * Math.sin(e.freq * theta + e.phase);
        var f = band * wig * (e.amt);
        var i = x + y * NXD;
        dR[i] += e.c[0] * f; ...
      }
    }
    // swirl velocity about the same center
    var vcx = e.x * NX, vcy = e.y * NY;
    var vR = e.r * Math.max(NX, NY) * 1.15;
    var vs = e.speed / Math.max(1, e.r * Math.max(NX, NY)); // peak tangential cells/s
```
Hmm simpler: velocity for radius rr from center: speed profile peaked near vR: prof = rr/vR * exp(1 - rr/vR)? Use f = Math.exp(-Math.pow((rr - vR)/(vR*0.8), 2)). Then u += -(dy/rr)*speed*f; v += (dx/rr)*speed*f.

speed in cells/s ~ 30.

Also add inner opacity: small central blob of dye.

Let me define emitters array with 5 arcs at various positions/sizes/colors/speeds, some CW some CCW.

I'll write:

```js
  function seedScene() {
    var S = Math.max(NXD, NYD);
    var emitters = [
      { x: 0.28, y: 0.34, r: 0.115, th: 0.020, freq: 3, phase: 0.4, c: [0.05,0.60,1.00], amt: 2.4, speed: 34, spin: 1 },
      { x: 0.63, y: 0.27, r: 0.080, th: 0.016, freq: 4, phase: 1.7, c: [1.00,0.15,0.45], amt: 2.2, speed: 30, spin: -1 },
      { x: 0.54, y: 0.66, r: 0.140, th: 0.024, freq: 2, phase: 2.6, c: [0.20,1.00,0.50], amt: 2.4, speed: 36, spin: 1 },
      { x: 0.84, y: 0.58, r: 0.075, th: 0.016, freq: 4, phase: 0.9, c: [1.00,0.72,0.12], amt: 2.0, speed: 28, spin: -1 },
      { x: 0.15, y: 0.76, r: 0.065, th: 0.014, freq: 5, phase: 3.4, c: [0.60,0.28,1.00], amt: 1.8, speed: 26, spin: 1 }
    ];
    ...
  }
```
Note: e.r*S with S = max(NXD,NYD) = 380 → r=0.115 → 44 dye px radius. Screen scale 1200/380 = 3.16 → arc radius ~138px. Good.

th = 0.02*380 = 7.6 dye px → ~24 px on screen. Reasonable filament thickness.

Also add a faint filling blob to give some body: use band also add small gaussian core: f += 0.25*exp(-(r/(R*0.55))^2). Hmm might muddy it. Let's include a subtle core amount 0.35.

Also the "gentle large-scale drift" removed; instead add small global rotation? Not needed.

Velocity emitters also applied to velocity grid with e.speed in cells/s relative? velocity grid NX=190 so scale: speed 34 cells/s → 34*6.3 px/s = 214 px/s. Good.

Now also drag injection force: factor 1.15 → 2.0 and MAX_SPEED 90 fine.

Let me write the replacement.

Now visible arcs. Let's check motion over a second.

Now it's swirling and deforming over time (frames differ: purple loop deforms, magenta vortex rotates). Good motion.

But there's a lot of smearing/blurriness — the dye quickly becomes soft giant ribbons. This is partly because dye advection blurs (semi-Lagrangian) at a fairly high velocity relative to dye grid, and also because the initial filaments are wide with a big core. Looks decent though, like ink.

Issues to improve:
1. The dye looks too washed/dark? Actually looks vivid.
2. The dye decays: dye max ~1.0. Fine.
3. There's a black gap in the middle; feels like a bunch of big blobs. Acceptable "colored dye and motion" but could be more interesting with finer filaments. Reduce th a bit and core amount, and maybe increase velocity slightly for swirls. Also reduce blurriness by less numerical diffusion: use a higher-order advection (e.g., MacCormack) — too much for now. Alternative: reduce dye grid resolution? no, that's more blur.

Actually the blur mostly comes from dye profiles widening in high shear — that's realistic. Fine.

4. Test drag: need dye to follow the drag and continue swirling. Then test 2nd drag in another direction, Clear, and fresh flow. Also Pause/Resume.

Let me remove debug overlay and do the verification. But first, let me look at drag response with debug values.

Also important: with dt-based drag injection factor 2.1 — a fast sweep injected max |u| earlier? Let's test.

Also: does dye injected at pointer look like a ribbon? Let's test now.

The drag injected a thick orange stroke. It's quite bloated/soft (brush radius and dye amount). The stroke does carry velocity (surrounding dye gets displaced — see the smearing around the line).

Improvements:
- Make the injected stroke thinner and brighter for a nicer ribbon: reduce dye radius multiplier from 1.15 to ~0.75, increase amount slightly.
- Drag stroke should deform into a swirl after release — the drag injects momentum along the line direction, so it will be pushed further along the direction, and the existing vortices will bend it.

Also, `u` max ~18 during drag seems low-ish; my force injection of ~2.1. Let's check after release. Actually increase to ~3.0 for a more obvious momentum effect (velocity max ~30 cells/s = 190px/s).

Wait, why is max |u| only 18 while seeded swirl was 21? Because projection removes much of the injected field's divergent component. 30 cells/s is a good target. Bump force factor to 3.2.

Also the dye looks blurred - injected dye radius = 0.05*1200=46px*1.15=53px wide → ~106px diameter stroke. On screen the stroke looks ~90px wide. Reduce brush to 34px and dye radius factor 1.0.

Let me also make the pointer dye add sharper: amount 0.16+... fine.

Additionally, the semi-Lagrangian smear makes the whole thing blurry; the classic fix is a MacCormack/BFECC correction. Time cost: maybe implement simple MacCormack on dye advection: forward advect then backward advect then correct, limited. That triples dye advection cost (~100k × 3) — currently render ms 0.5! Plenty of headroom (sim total maybe 5-8ms). FPS reported 60 and render 0.5ms. So we have room.

MacCormack for dye:
1. phi1 = advect(phi, dt)  (forward)
2. phi2 = advect(phi1, -dt) (backward)
3. phi_new = clamp(phi1 + 0.5*(phi - phi2), min/max of 4 neighbors of phi)

Implementing requires extra buffers and a general advect routine. Given time budget (~10 min left), maybe skip; blur is acceptable and looks like ink. Risk of introducing bugs. I'll skip MacCormack but tighten injection visuals.

Actually the blur is partly due to the dye texture upscale (380→1200 = 3.16x bilinear) which is inherent.

One more improvement: velocity grid 190 is coarse; dye structure at 380. Fine.

Let me tune:
- BRUSH_PX 40
- dye radius factor 0.8, amount base 0.22
- force factor 3.2, MAX_SPEED 110

Then verify: drag, release, sample (screenshot at intervals), second drag in another direction, Clear, drag again. Remove debug overlay at the end.

Do edits.

Fresh load shows dashed rings (onion-like), which will swirl. Looks fine and clearly shows motion soon after (they become ribbons). Slight concern: the initial look is a bit "flower-like" but acceptable. The mod uses sin(freq*theta) with freq 2-5 causing symmetric dashes. It will shear into interesting structures.

Now do the drag verification with a fresh load: drag, release, wait, screenshot.

Drag injected orange streak with max |u| ≈ 31. Now sample after release over a couple seconds to verify continued swirling and movement.

The flow is swirling and dye follows. The drag stroke has been stretched/curled by the vortices and momentum persists after release (u max ~18-20 decaying gradually). 

Now test a second drag in another direction, then Clear then drag again, and Pause/Resume. Also remove the debug overlay at the end.

Second drag: horizontal from right to left, with a different color (click cyan swatch).

Cyan selected (highlight ring). Now second drag in another direction: from left-middle to right (horizontal).

The second drag didn't produce a visible cyan stroke! The dye values shown: dye max 0.66. Hmm, the previous cyan injection... Wait, the color got selected but the drag produced nothing visible?

Look carefully: the image shows no new cyan arc along (80,120)→(1120,430). Max u barely changed from 16.48 → 16.25. So injection did nothing?? Or the drag tool doesn't send intermediate pointermove events? Earlier drags did produce strokes. Here maybe drag was too fast/single event? Actually drags earlier did emit the stroke.

Hmm, u went down (decay) which suggests no injection at all. Possibly the drag started on... (80,120) is over the panel? Panel occupies top-left ~ (16..250) x (16..135). Point (80,120) might be within the panel (panel bottom edge ~135). The pointerdown at that point hit the panel, not the canvas! Then dragging wouldn't inject (pointerdown listener is on canvas).

Yes — panel overlaps. So drag test invalid. Let's drag from below the panel.

Also note the canvas pointerdown is only on canvas, which is fine.

Let's redo the second drag starting at (300, 600) → (1050, 120).

The cyan stroke is drawn, agile and crisp (a bit too solid/uniform — it has saturating tone so appears flat). It's fine but a straight solid band looks synthetic. Slight improvement: reduce dye amount so it doesn't clip to full white; currently dye amplitude ~0.22-0.56 per injection plus accumulation along the path? Each injection point adds to nearby cells, so the line saturates. Max dye 0.58 reported... hmm, that's not saturating; but tone display at value 0.58: k = 0.58/6*2048 = 198 → tone ~ 255*(x/(1+x))^0.82 where x=0.58*1.95=1.13 → 0.53^0.82 → 0.59*255 = 150. But the stroke appears ~#5FE0FF, bright. Fine.

The stroke being solid cyan is because the color is pure cyan and the value maps to bright. It's acceptable. Could give a bit more texture by reducing amount and adding more variance. Not crucial.

Now check it continues swirling (deform), then test Clear and new drag, and pause.

Let's wait ~2s and screenshot.

The cyan ribbon is bending/curling and moving (right edge lifts and curls between frames). Flow continues after release with persistent vortices.

Notice color rendering: orange areas look brown/dull because of tone map with sqrt-ish gamma. Also the initial arcs have become large smeared regions — a bit low-contrast/muddy, but acceptable.

I'd like the dye to look more vivid. Currently dye is decaying and the tone curve makes mid values dim. Let me increase saturation a bit: apply per-pixel "dye color" normalization? A common trick is to render dye with slight gamma and additional boost for small values: out = 255*(1 - exp(-v*1.2)) gives similar. The current curve: k=v/6*2048; x = (k/2048)*6*1.95 = v*1.95; y = x/(1+x); out=255*y^0.82. For v=0.1: x=0.195→y=0.163→0.163^0.82=0.226→58. That's not dim. But some areas look brown because orange dye at v=0.5 → x=0.975 → y=0.49 → ^0.82=0.55 → ~140 in R, G ~ 0.42*... hmm the green channel of orange is 0.42 → 0.42*0.5=0.21 → x=0.41→y=0.29→0.37→95. So orange (140,95,36) looks brown. To make colors more vivid, increase contrast: subtract a small ambient and boost saturation. Try using power 1.0 (linear) for the shoulder + higher exposure: y^0.9? Hmm.

Better: make tone mapping more "vivid" by raising the dye color saturation: mix = c/(1+x) with a per-channel saturation boost:
out_c = clamp(1 - exp(-v_c * k))? That yields for orange v=(0.5,0.21,0.06): (0.62,0.34,0.11) → still brownish because the recorded channels differ.

Actually the brownness is because of dye structure mixing with green/other colors, and because dye is thin/faded. Not a big deal. Fluids sims look like this.

One thing that hurts: the overall brightness of thick strokes saturates to whitish-cyan. Fine.

I think visuals are acceptable. Time check: about 6-7 min used. Remaining tasks:
1. Verify Clear then fresh drag.
2. Verify Pause/Resume.
3. Remove debug overlay and stats instrumentation (keep window.__stats fine, but remove the visible div).
4. Keep from over-tuning styling.

Also improve: dye persistence — currently max dye 0.46 after ~6s from 0.58. Fine, "gradually dissipate".

Clear test: click Clear then drag.

Clear worked: canvas blank (the debug readout is one frame stale, showing u 8.5). Now drag again to verify a fresh flow starts.

Also note the canvas didn't cover the whole viewport? Screenshot shows black everywhere (canvas background #05070c is near-black) — fine.

Now drag a swirl-ish motion with orange (currently cyan selected). Let's drag with a curve? Tool supports single straight drag. Do two drags.

Fresh flow starts after Clear. The debug readout shows u:0, dye:0 — stale from before the drag (it updates every 20 frames... hmm, it should have updated). It says u:0 dye:0 which is from the frame right after clear. But dye is visible. Maybe the readout div updates only when document.getElementById("dbg")… it does every 20 frames. Possibly the drag screenshot captured quickly and the dbg lags. Fine.

Now the stroke in an empty field stays a straight bar and curls slowly — needs vigour. The drag injects momentum along the drag direction, and with no other vorticity, the bar just translates and diffuses. That's expected physics: it will move left/down and stretch. Let's verify it moves and continues swirl after release for a while.

Also Pause test. Let me first check motion of the fresh bar.

The fresh flow after Clear: the stroke translates a bit and the endpoint curls into a hook (frames show a hook forming at bottom-right). Velocity max ~7-10. It works but the resulting motion is weak/limited — after Clear the field is empty so only the injected momentum remains, and projection removes much of it. The stroke curls at the end (vorticity sheet roll-up) which is nice.

Concerns:
1. Dye amount after clear: max dye only 0.05?? The readout says dye max 0.054 — yet the stroke looks bright cyan. Wait, tone mapping at v=0.054 → k=18 → x=0.105 → y=0.095 → ^0.82 = 0.14 → 36/255. But the rendered stroke is much brighter than that... unless the readout is stale/lagging. Frame values differ (0.0517 vs 0.0652) suggesting they update. Hmm, dye max 0.065 giving that bright cyan? 0.065*1.95 = 0.127 → /(1.127)=0.113 → ^0.82 → 0.164 → 42. The stroke appearance ~ (40,170,200)? Rendering from dye (r=0.08,g=0.72,b=1) * 0.065 = (0.005, 0.047, 0.065) → tone → (5, 30, 42). That would be near-black. But the visible stroke is bright cyan (~(30,170,200)). So the maxAbs of dR is not representative — dR max is the red channel max which may be low, while green/blue are brighter... yes! maxAbs(dR) is the red channel only; the cyan dye has small red. So the readout is just red-channel max. Fine.

2. Dye persistence after Clear+drag: the stroke's brightness looks constant, good.

Notable issue: injected dye amount is large enough to saturate to a solid band. Acceptable.

Now, after this fresh drag, the bar moves slowly (velocity ~7 cells/s → 44px/s) and it curled at the tip. Physics-wise, drag momentum is added along the drag direction with Gaussian falloff, which mostly gets projected away. Fine.

The key check "drag through the canvas and sample the flow after release; dye follows the drag, continues swirling, responds to second drag" — verified with seed present. With empty field (post-Clear) it curls but doesn't swirl much. Might be nicer to add more curl: when injecting, add a small tangential/rotational component? Not physically justified, but "approximate fluid behavior acceptable". Real fluid drag along a line does create a shear layer that rolls up — which we see (the hook). I'd like stronger rolling: increase force factor to ~4.5 and increase dye amount so more visible. Let's test slightly.

Also, the pause button needs verification.

Now cleanup: remove dbg div and its updates, remove maxAbs? Keep maxAbs harmless but unused → remove both for cleanliness. Keep window.__stats.

Also ensure the injection isn't too pixel-blocky: the stroke has hard-ish edges but smooth enough.

Let me also reduce the initial dye "onion rings" look... at load, dashed concentric-ish arcs. It looked decent in motion. Keep.

One more improvement: after Clear, the empty scene remains black until drag — fine per requirements.

Let me now: bump force to 4.2, remove debug, then test pause and final full flow.

No matches for dbg/maxAbs → replaced. But 4.2 not found? The replace of '3.2);' should have happened... grep found nothing including "4.2);" Let me check the drag line.

Now the initial scene is clearly visible (concentric dashed rings around vortices), though quite "flowery"/symmetric. It will shear into ribbons quickly. But visual quality: rings with dark cores look a bit artificial, and each ring has uniform color. Improvement: add asymmetric variation, offset arcs, and mix colors — e.g., break the rings into arcs with angular windows and shift phase, plus smaller sub-blobs at different radii to create more organic seed.

Quick improvement: make each ring only cover part of the circle (angular mask) and add a couple of smaller tilted arcs. Let's modify the density: mod = base + sin(freq*theta+phase) and additionally multiply by an angular window that zeroes a portion: e.g. window = smoothstep on cos(theta - a0) — creates crescents. Simpler: multiply density by (0.35 + 0.65*max(0, sin(freq*theta + phase)))^1.5 already dashes.

Alternatively accept: it's colorful, visible and will swirl. Time budget: ~8 minutes used. I should prioritize verifying required behaviors (pause, resume, second drag after clear) rather than aesthetics. But the "dark core in every ring" look is distinctive and might read as a designed look. Let's do one quick aesthetic tweak: add several sub-arcs offsets with varying radius and phase, per emitter, so it looks less like 5 identical flowers. Implement by giving each emitter a list of rings? Quick approach: within the emitter loop, use r0 = R*(1 + 0.18*sin(theta*e.freq2 + e.phase2)) — an r modulation making the ring wobbly/organic. Cheap and effective.

Let me add: R_eff = R * (1 + 0.22*Math.sin(e.freq * theta + e.phase)*... hmm careful not to tie with mod.

Add fields freq2/phase2 per emitter and modulate ring radius:
var wob = 1 + 0.20 * Math.sin(2.3 * theta + em.phase);
var radial = (r - R*wob) / th;

That makes organic squiggles. And vary thickness slightly.

Let's apply that, then verify and finish.

Fine (dx,dy unused now except for r; the theta computed from x-cx same thing). outer bound may clip wobble (0.29R beyond R) → outer = R + 3.2th which for th≈7 and R≈44 = 66 > 1.29*44 = 57. OK.

Reload and inspect.

It's already evolved (reload screenshot taken slightly after a frame or two). It's vivid, colorful, and clearly moving. Good enough — the "black cores" are holes in the seeded ring, which reads as dye ribbons.

Now, remaining checks:
1. Pause/Resume.
2. Reload + drag + release + second drag → verify.
3. Confirm a fresh flow after Clear with new force 4.2.

Pause: click the Pause button and take two screenshots ~1s apart to confirm no change; then Resume and confirm change. Screenshots at 1200x800. Pause button is at about (65,104).

Let me click Pause.

Excellent — this is exactly the swirling-dye look. Button now says Resume. Now confirm the frame is frozen: take a screenshot after a delay (motion capture 1200ms) and compare frames visually.

Note: the screenshot above shows lots of beautiful structure, and the simulation had been running ~8 s.

Now motion while paused.

Paused: all four frames identical → pause works. Note the orange swatch also appears highlighted alongside cyan? Looking at panel: orange (first) and cyan (second) both look ringed? First swatch orange has a white ring... Hmm the click on swatch happened earlier: I clicked at (72,66) which is the cyan swatch → cyan pressed. But orange still shows a ring? In the screenshots, swatch 1 (orange) and swatch 2 (cyan) both appear with white borders — the first has a lighter ring. Hmm, `setColor` sets aria-pressed true only for matching. But CSS `aria-pressed=true` styling vs base border. Looking closely at images: swatch 1 border white-ish, swatch 2 border white-ish, swatch 6 (orange at end) also. Might be just the image rendering. Non-issue.

Also note that colors in the sim look great.

Now click Resume and verify motion resumes.

Resumed (button says Pause). Now verify it moves again with a motion capture, plus test second drag and clear once more with the stronger injection. Let me do: drag in a new direction (orange), capture frames.

Current color is cyan. Click orange swatch (36,66)? The swatches start at x=16+14 padding ≈ 30, each 22px + 7 gap. First swatch center ≈ 30+11=41; second ≈ 70; third ≈ 99; etc. I clicked 72 for cyan earlier — consistent.

Click first swatch (41,66), then drag diagonally.

Resumed and flowing (structure changed). Now drag in another direction (orange) and sample after release.

The drag injected an orange ribbon in a different direction. It's a bit too "solid"/uniform (looks like a painted bar) but acceptable; it will deform.

Sample after release to make sure it swirls and stays.

This looks great — the second drag's orange ribbon gets bent and drawn into the vortices, dye advects continuously. Motion between frames is clearly visible (swirls continue).

Noticed: there's an orange rectangle swatch at the far right of the swatch row (x≈222) — that's the native color input rendered as a filled orange box. Fine (it's the custom color picker). It looks like a 7th swatch, acceptable.

Remaining verification: Clear then fresh drag with new force value. Also verify pointer injection while paused? not required.

Let me do Clear then drag to confirm fresh flow at 4.2 force, and take one screenshot after ~1s.

Clear works — canvas is fully blank (velocity reset too). Now drag a fresh flow after clear and check it develops motion.

Use orange swatch (41,69) then drag.

Fresh flow starts after clear. But the stroke looks quite washed out and blurry (soft brown), because the dye amount is low relative and tone mapping makes it dim, plus it's a straight bar with no momentum curl visible. Compare with the earlier cyan stroke which was vivid.

Issue: the injected dye is fairly dim because each pointermove adds amount ~0.3 in falloff regions; the max at center accumulates across steps. Yet resulting max brightness looks like ~0.3. Let's boost dye amount somewhat and make it more vivid: multiply amount by ~1.6 total. Also the stroke thickness ~120px looks large; it's the brush radius 34px*0.95 in grid terms? rr = (34/1200)*380*0.95 = 10.2 dye px → on screen 10.2*3.16 = 32px. But the rendered stroke looks ~110px wide including the soft glow — because falloff (1-q²)² spans the full radius and the bilinear upscale spreads. Actually the bright core is ~30px and the soft halo extends. Fine.

The blurriness suggests the dye grid is coarse (380 wide) → on-screen cell = 3.16px. The stroke edges are ~90px soft. Hmm, that's wider than expected. The injection uses rr for both velocity and dye; plus step spacing 34*0.45=15px between injection centers → overlapping adds many times → soft wide band with flat top? But the middle looks uniform flat.

Honestly it's acceptable, but let me improve vividness/detail:
1. Increase dye amount: `amount = 0.30 + min(0.4, speed*0.005)` and multiply by 1.2 → stronger core.
2. Make the profile sharper: g = pow(1-q2, 3) instead of (1-q2)^2 → tighter core.
3. Reduce rr factor to 0.8.

Then the stroke will be narrower and denser.

Also the momentum: after release, does this post-clear bar curl? Earlier we saw a hook form. With force 4.2, more roll-up expected. Let's take a motion capture after tuning to check.

Also there's an important physical detail: a smooth straight-line injection with no ambient field just translates; we saw rolling at the ends. Acceptable ("momentum remains visible... gradually dissipate").

Let me apply the injection tuning, reload, and do a final full verification pass (drag, second drag, clear, pause quickly).

Time: roughly 11 min used. Need to wrap up within ~4-5 min. Let's be efficient: apply tweak, reload, one drag + one motion check, then finalize.

The initial scene now shows larger, blob-y radial bursts. Hmm — this screenshot is from a slightly later frame where arcs have expanded/deformed. It looks like 5 "flowers", a bit repetitive but colorful and clearly in motion.

I'm concerned that the initial scene reads as "blobs" rather than fluid at t=0, but within a second it turns into flowing structures — the requirement is only that the initial scene has dye and motion.

Wait: the reload screenshot shows the scene already deformed, meaning the initial concentric-arc seeding then quickly expanded. The readout shows the arcs have widened into thick bands. Somewhat OK.

Given time (~12 min), let me do the final verification of drag after this reload, then finish. Also I should double check `resize` behavior doesn't break, but that's unverified — mention it.

Drag test final.

This looks like a proper fluid sim — spiral vortices and a crisp dye stroke crossing the field. 

Final check: after release, the stroke should be dragged/curled by the flow. Let's confirm with a motion capture (2 frames), then finalize.

The four frames show clear continuous motion: swirls rotate, filaments stretch, the drag stroke's orange ribbon is carried and deformed. Momentum persists after release.

The scene is now quite bright/soft (large soft color regions) — the drag ribbon got folded into a light yellow swirl. It's very "milky" at this point after ~15s because dye diffuses & brightens where overlapping. Acceptable.

One concern: the sim looks blurrier than an ideal sharp filament sim, because dye dissipation/diffusion has smeared everything into large soft areas. Notice how the field is dominated by broad bands rather than fine filaments. This may be due to my advection adding a lot of numerical diffusion... standard semi-Lagrangian at 60fps on dye grid with velocity of 20-30 cells/s: CFL ~0.5, which gives moderate diffusion. Also the visible upscale (3.16x) smooths.

Given time constraints (~13 min), I'll wrap up. But one quick cheap improvement for crisper dye: since it's mostly blur, the tone mapping could apply contrast (e.g., boost low values) — no real fix. Alternatively, reduce dye dissipation a bit (0.9993) so more dye persists and structure holds. Not needed.

Actually one visible artifact: overall brightness grows since dye stays but colors combine into near-white/yellow. Fine.

Let's do a final check that no debug artifacts remain, verify the file is self-contained (no external URLs), and glance at the code for the unused variables and leftover strings. Then finish.

Also make sure the panel isn't capturing canvas drags (verified: starting drag over panel did nothing).

Final: search for http/cdn references.

Self-contained, no external refs. 

Let me double-check a couple of code-level things quickly:
1. `pointerPos` uses clientX-rect.left; canvas is fixed at 0,0 so fine.
2. Resize handler re-inits and re-seeds — could reset on mobile URL bar changes; acceptable.
3. Injection while paused: allowed; dye appears; step disabled. Fine.
4. When paused, `acc` keeps not accumulating → on resume no jump. Good.
5. `dyeAmount` cap check `if (dR[j] < 4)` fine.

One thing: `window.addEventListener('pointermove', onMove, {passive:false})` with preventDefault on move — could block page scroll; page doesn't scroll anyway.

Also `setColor` for custom input keeps `aria-pressed` cleared; the native color input shows selection — fine.

Potential bug: `onDown` returns early for right-click mouse only if pointerType==='mouse'. OK.

Another: `MAX_SPEED = 90` clamp: at 90 cells/s with dt 1/60, backtrace 1.5 cells — stable.

I verified: initial scene visible + animated; drag injects dye + momentum; dye follows and swirls after release; second drag works; Clear empties and a fresh drag starts a new flow; Pause freezes and Resume continues; color selector works (cyan/orange swatches and native picker); performance ~60fps, render ~0.5–0.7ms.

Unverified: resize/re-init behavior, touch input on mobile, custom color picker interaction (only swatches), long-run stability beyond ~20s, keyboard shortcuts.

I'm at ~14 min. Done. Final short report.