Flow-field particles · mimo-v2.5

Let me check the directory and build the file.

Build index.html with instance mode p5, ~2500 particles, trails via translucent background rect, colors varying over time via hue shift, noise field evolving.

Let me write it.

One concern: p5 `beginShape(p.LINES)` — does p5 support LINES mode in beginShape/endShape? Yes, p5.js supports beginShape(LINES) in WebGL2/2D? In p5.js 1.x, beginShape with LINES is supported in the2D renderer (since0.9? Actually there's a known caveat: beginShape(LINES) supported in p5 1.x — yes, p5.js docs say "LINES: ... after beginShape() and endShape() to create line segments" — supported in 2D renderer. But setting stroke color per vertex: stroke() between vertices only applies if stroke is set before vertices — actually per-vertex stroke colors are NOT supported in 2D canvas renderer for beginShape; the stroke color at the time of endShape is used. Hmm. In p52D renderer, beginShape collects vertices and then draws with current fill/stroke at endShape. So per-particle colors won't work within the batch.

Let me verify: p5 2D renderer beginShape pushes vertices, and endShape calls shapeVertex drawing... Actually p5's 2D beginShape stores vertices and draws them in endShape using current fill/stroke. So per-vertex stroke changes are ignored. Better to just draw lines with individual stroke() calls — 2500-9000 line() calls per frame in 2D canvas might be okay-ish but slow. Alternative: use WEBGL renderer? In WebGL mode, per-vertex colors also need to be set via fill/stroke... In WebGL, beginShape collects vertex colors from fill() calls per vertex (p5 WebGL supports per-vertex colors with fill). Yes — in WebGL mode, p5 supports per-vertex colors: each fill() before vertex() sets that vertex's color. For LINES shape mode in WebGL, stroke isn't applied to shapes; need fill-based lines. Actually in WebGL mode, beginShape(LINES) draws lines using fill color (strokeColor used?). In p5 WebGL, beginShape with LINES uses fill color I believe (stroke mode via stroke() only for stroke() lines).

Simplest robust approach: use plain line() calls with stroke() per particle. Performance: ~4000 line() calls at 60fps in 2D canvas — feasible but may be heavy with alpha strokes. Let me instead use noStroke + fill rectangles? Trails look like dot/streak particles. A common technique: draw short line segments via line() with stroke color; 3000 calls per frame typically works fine (~a few ms).

Alternatively, per-vertex color approach with beginShape(QUADS) — each particle draws a small quad oriented along motion, using fill per vertex. In2D renderer, fill() per vertex within beginShape is not supported either.

So: drop beginShape and use line() per particle. Let me test performance in browser. Also HSB color mode needed: p.colorMode(p.HSB, 360, 100, 100, 255).

Also alpha stroke: using stroke with alpha 190 for many overlapping lines is fine.

Let me rewrite the draw loop to use line() and set colorMode HSB. Then test with browser tool: check fps, screenshot, pause/resume, restart.

Also there's a duplicate `else if` in spawn (side 0 and 1 identical) — harmless but fix.

Let me edit.

Note: `p.line()` sets stroke per call — but calling p.stroke() per particle then p.line() is fine. However, p5 line() with a color object... we pass individual floats. Fine.

Also `p.fill(5,7,13, alpha)` for background rect with colorMode HSB — that changes meaning! fill(5,7,13,...) in HSB mode = hue 5, sat 7, brightness 13 — nearly black-brown with high alpha. Not the intended near-black navy. I should use p.color or p.background with color object, or set colorMode back to RGB for the fade wash. Simpler: use p.fill(p.color(5,7,13, alpha))? p.color() in HSB mode also converts. Best: compute a p5.Color created in RGB mode once: p.colorMode(p.RGB,255) for creating fade color. Let's create fade color: in setup do fadeCol = p.color(5,7,13) while in RGB then... but colorMode affects at creation time. Do:

In setup, before switching to HSB: `fadeCol = p.color(5,7,13);` then switch to HSB. Then in draw: `fadeCol.setAlpha(alpha); p.fill(fadeCol);` — setAlpha uses current colorMode's alpha range (max 255 in our HSB setting since we set 4th param255). Good.

Similarly background(5,7,13) calls in setup/init — those happen after colorMode switch in setup? initParticles is called after colorMode set to HSB. p.background with3 nums in HSB mode → wrong. Use fadeCol via p.background(fadeCol)? background accepts a p5.Color. Let's store fadeCol before HSB, and pass fadeCol everywhere for background.

But windowResized calls p.background(5,7,13) too — use fadeCol.

Also hue computation: hue = (colorPhase + off*140 + (x+y)*0.03) % 360 — could be negative if colorPhase goes negative? colorPhase starts 0..360, increases — fine.

Let me apply edits.

Also stroke alpha: stroke(hue, sat, lig, 190) in HSB mode with alpha max 255 — fine.

Now let's run in browser and check.

No curl; but browser tool probably loads file:// directly. Let's use browser with file path.

No curl; but the browser tool probably loads file://. Let's try browser reload with file path. The browser tool's action reload loads index.html presumably in cwd.

Playwright is available. Let me run it to screenshot at different moments.

FPS 52 with 2496 particles — acceptable. Wait: t after restart is 435.70, which is higher than before restart (193.82)? Hmm, actually the restart happened later... t was 193.82 at 5s, then restart at ~7s, then t = 435? fieldT increment per frame 0.0016... over ~4s * 52fps*0.0016 ≈ 0.33. That can't jump from 193 to 435. Unless the stat display wasn't updated frequently... wait, tEl updated every 15 frames. 193 → 435 in 4 seconds is impossible at 0.0016/frame. Hmm, wait — NOISE_Z_STEP = 0.0016? Let me check: fieldT += NOISE_Z_STEP... Actually 5 seconds * 52fps = 260 frames * 0.0016 = 0.4. So t=193 at 5s means fieldT increased by 193. That means the noise z step... Oh wait — initParticles sets fieldT = rand()*500, random! So 193 and 435 are the random initial values. Good, that makes sense.

Let me look at screenshots.

The animation looks good (running state). But when paused, the fade wash continues and erases the trails — the canvas goes blank. Pause should freeze the picture (keep trails intact). Fix: only apply fade wash when running. Let's move the fade rect inside `if (running)`.

Also check restart screenshots.

Everything works. Colors vary (green/blue vs. more yellow/green after restart — different seed/colorPhase). Coherent flow, trails visible, restart clears trails and produces new arrangement.

One improvement: pause currently fades everything out (as seen in p2.png — the canvas fades to near-black while paused, because the fade wash still runs each frame even when paused). Actually the trails fade away while paused since the fade rect still draws. Better: only apply the fade wash when running, so pausing freezes the image. Let me fix that — that's a real issue (paused screenshot went almost blank). Move fade wash inside `if (running)`. But then resume continues from frozen image — fine.

Let me restructure: draw fade wash only when running.

Also when paused we could skip draw entirely. The current structure keeps draw running but nothing is drawn — fine, and fps shows60. Now re-verify: pause keeps frame, resume continues, restart clears trails.

Note the state was read before the resize block? Actually state read happens after e_after_restart. fps54. Let's view key screenshots: paused, restart immediate, after restart, resized.

Pause now preserves the frame. Restart cleared trails (fresh short segments, different colors/arrangement). Good.

Let me check the resize screenshot too, and confirm final file. Quick look at f_resized.

Resize works (canvas refilled, coherent). HUD stays responsive. Good.

One last check: verify the file is final and p5 script tag uses exact filename. Yes.

Also verify keyboard shortcuts don't conflict (space when target is body). Not critical.

Done. Summarize.