Flow-field particles · laguna-s-2.1

Let me analyze this task:

1. Build a full-screen flow-field particle animation using p5.js
2. Write everything into index.html
3. Use the provided p5.min.js with a plain <script src="p5.min.js"> tag
4. No external resources

Required behaviors:
- At least 2,000 particles, motion guided by smoothly varying Perlin-noise vector field
- Nearby particles follow locally coherent directions
- Fading trails, varying particle colors over time
- Field evolves gradually
- Recycle particles at canvas boundaries, keep population bounded
- No ever-growing trail history
- Pause/Resume and Restart controls
- Restart clears trails and initializes new arrangement
- Fit viewport, controls responsive at 1200x800

Let me first look at the current directory to confirm p5.min.js is present.

p5.min.js v1.9.4 is present. Now let me check the docs for p5 to understand the API for this version. Let me look at the pi docs/examples briefly, but this is more about p5.js itself. Let me check what's available.

Actually, the docs reference is for pi itself. For p5.js, I should just use my knowledge. Let me check the p5 examples to confirm the API.

Let me just build the app. I know p5.js well. Let me design the flow field particle animation.

Key design decisions:
- Use instance mode for a clean scope (optional, global mode is fine too). I'll use global mode to be safe with the script tag, but instance mode is cleaner. Actually, since we load p5.min.js before our script, both global and instance mode work. Let me use instance mode to avoid polluting global space and conflicts.

- Vector field: compute a grid of vectors based on Perlin noise. noise(x, y, t) for smoothly varying field. The field evolves over time by animating the time dimension.

- Particles: store as array of objects with position, velocity, maybe color. 2000+ particles.

- Fading trails: use a semi-transparent background rectangle drawn each frame (blend with BLACK at low alpha) which creates the fade effect. This avoids allocating trail history. This is the classic technique.

- Color variation: use HSB color mode, vary hue over time based on noise or frameCount.

- Recycle particles: when a particle goes off the canvas, reset it to a random position (or the opposite side). Keep population bounded.

- Pause/Resume: a flag, and when paused, stop updating (but we could still draw static or just freeze). Typically freeze.

- Restart: clear particles, reinitialize new positions, clear trails.

Let me think about performance. 2000 particles is fine. Each frame:
- Update noise field (or reuse with time dimension)
- For each particle: lookup field vector, add to velocity, update position, draw point/circle
- Draw fading background

Actually computing the field vector per particle via noise() is the standard approach. But to make it more efficient and coherent, I can precompute a grid of vectors and have particles sample via bilinear interpolation. But 2000 particles each calling noise() is also fine and gives smooth coherence. Let me precompute a grid for better performance and to demonstrate "locally coherent directions" clearly. Actually, noise() with proper scaling already gives local coherence. But precomputing a grid and using bilinear interp is cleaner and faster.

Let me do a grid-based field with bilinear interpolation. Grid resolution like 20x20 or 40x40. Actually for smooth coherence, a coarse grid with interpolation works well. Let me use something like the field resolution based on a scale (pixels per cell). 

Let me think about the design more concretely:

```
let numParticles = 2500;
let particles = [];
let field = []; // array of p5.Vector
let cols, rows;
let rez = 25; // resolution: pixels per cell
let noiseScale = 0.1; // for noise input
let time = 0;
let zoff = 0; // for field evolution
let pause = false;
let sketchHueBase = 0;

function setup() {
  createCanvas(windowWidth, windowHeight);
  colorMode(HSB, 360, 100, 100, 100);
  // ...
}
```

Wait, global mode might have issues with windowWidth/windowHeight being global p5 functions. In global mode they are. In instance mode, use windowWidth/height via the instance. Let me use global mode for simplicity since we just have one sketch. Actually instance mode is better practice. But global mode is simpler and well-tested. Let me use global mode.

Actually, let me reconsider. The instructions say "global or instance mode" is fine. Let me use global mode to keep it simple and robust.

Let me think about the fading trail technique:
- Each frame, draw `background` with a semi-transparent fill? No. The classic approach: 
  - Option 1: draw everything each frame from scratch (no trails)
  - Option 2: fading trails: draw a semi-transparent black rectangle over the whole canvas each frame, then draw particles on top. This fades previous frames gradually.

But if I draw `background(0)` each frame, no trails. For fading trails, I draw a rectangle with fill(0, alpha) where alpha is small (like 10-20), which darkens existing pixels. This creates fading trails without storing history. 

But with HSB color mode, background/fill with HSB... black is fill(0,0,0) or just background(0). For the fade rectangle, I want to blend. Using fill(0, 0, 0, fadeAlpha) then rect(0,0,width,height). 

Actually a subtlety: with blendMode, the default is BLEND. Drawing a translucent black rect over previous particles makes them fade toward black. New particles are bright. This works.

Let me make it cleaner: use a separate approach where I keep the trails. I'll draw the fade rect first, then particles.

For varying colors: each particle gets a hue based on noise of its position plus a global time shift, or just based on its index. To "vary particle colors over time", I'll compute hue as a function of noise(position, time) and modulate. Let me give each particle a base hue and animate it slightly, or compute hue from field direction.

Let me make hue based on noise(p.x * something, p.y * something, time) * 360. That way colors shift and nearby particles get similar hues (coherent color). And it evolves over time. Good.

Let me write the field:
```
function computeField() {
  for (let y = 0; y < rows; y++) {
    for (let x = 0; x < cols; x++) {
      let nx = noiseScale * x;
      let ny = noiseScale * y;
      let angle = noise(nx, ny, zoff) * TWO_PI * 2; // or * 360 in degrees... noise returns 0..1
      let v = p5.Vector.fromAngle(angle);
      field[x + y * cols] = v;
    }
  }
}
```

For each particle, sample the field at its position via bilinear interpolation, then use as steering.

Actually, simpler: compute angle directly from noise at the particle's position scaled. But that's a noise() call per particle per frame which for 2500 is OK. However precomputing a grid and interpolating is more representative of "vector field" and more efficient. Let me do the grid + bilinear interp. This gives the locally coherent property nicely.

Bilinear interpolation of vectors: get 4 corners, lerp the x components and y components. Need to handle wrap or edge clamping. I'll clamp to edges (or wrap). Wrapping is nice for continuity. Let me wrap at edges (modulo). Actually clamping is simpler and fine. Let me wrap for seamless continuity, using the field as a torus. That requires cols/rows and indexing with modulo.

Let me write a helper to get the vector at (x, y) in canvas coords:
```
function fieldAt(px, py) {
  let fx = px / rez;
  let fy = py / rez;
  let x0 = floor(fx) % cols; ... // handle with wrap
  ...
}
```

Hmm, let me just do it. With wrapping:
```
function fieldAt(px, py) {
  let gx = (px / rez) % cols;
  let gy = (py / rez) % rows;
  // handle negatives
  if (gx < 0) gx += cols;
  if (gy < 0) gy += rows;
  let i0 = floor(gx); let i1 = (i0 + 1) % cols;
  let j0 = floor(gy); let j1 = (j0 + 1) % rows;
  let fx = gx - i0;
  let fy = gy - j0;
  let v00 = field[i0 + j0*cols];
  let v10 = field[i1 + j0*cols];
  let v01 = field[i0 + j1*cols];
  let v11 = field[i1 + j1*cols];
  let vx = lerp(v00.x, v10.x, fx);
  ... lerp between the two rows
  return p5.Vector... created from interpolated components
}
```

This is clean. Particles near each other sample similar grid cells → coherent motion.

Particle update:
```
for (let p of particles) {
  let f = fieldAt(p.x, p.y);
  p.v = p5.Vector.lerp(p.v, f, 0.05) * speed; // steer toward field
  p.v.mult(slowdown factor);
  p.x += p.v.x; p.y += p.v.y;
  // wrap or bounds recycle
}
```

Wait, I want to normalize the field vector and apply speed. Let me do:
```
let f = fieldAt(p.x, p.y);
f.normalize();
p.acc = f (or add with steering)
p.v.add(f * 0.01) ... 
```

Let me use a simple approach: 
```
p.v = p5.Vector.lerp(p.v, f, 0.04);
p.v.setMag(speed);
p.pos.add(p.v);
```
where speed varies. This gives nice flow following.

For recycling: if particle goes outside [0,width] or [0,height] (with some margin), reset it to a random position with random velocity, or wrap to the other side. The task says "Recycle particles at the canvas boundaries and keep the population bounded." I'll wrap particles that go off the opposite edge (toroidal) so they re-enter, OR reset to random location. Wrapping keeps trails continuous. Resetting to random is also fine. Let me do toroidal wrapping which is elegant for flow fields — particles that exit one side re-enter the other, maintaining visual flow. But the task says "Recycle particles at the canvas boundaries" — toroidal wrapping is a form of recycling. However, to be clearly "recycling," let me reset particles that go far outside to random positions, AND also wrap the nearby ones. Hmm.

Actually, let me do a hybrid: wrap particles around the edges (toroidal). This means population stays bounded (never grows) and particles recycle at boundaries. That satisfies the requirement cleanly. But "clear trails" on restart is handled by clearing. Let me go with toroidal wrapping for the edge behavior because it produces the nicest flow field visualization (continuous streams).

Hmm, but if particles wrap, then a particle could be near the left edge moving right but its "trail" appears on the right. That's fine visually.

Actually, let me reconsider — maybe a cleaner "recycling" is: when a particle leaves the canvas, reposition it randomly somewhere on the canvas (on the opposite edge or random location) with a fresh velocity aligned roughly with the field. This is the classic "recycle" behavior. I'll do this: if pos outside bounds (with small negative margin), respawn at random x,y. Let me respawn on the boundary edge opposite to direction or just random position. Random position is simplest and gives a "new arrangement" feel over time.

Let me go with: if particle exits canvas (pos.x < -margin || > width+margin etc.), reset to random position within canvas, with velocity from field at that position. This recycles at boundaries and keeps population bounded. Good.

Controls: HTML buttons overlaid. Pause/Resume toggles, Restart resets. Use fixed positioned divs top. Make responsive.

Let me also add a subtle point count display and make controls visible. Keep styling minimal but clean.

Let me also handle the fading trails alpha and colors well. I'll test in browser.

Let me consider performance with HSB and 2500 particles + fill circles. Drawing 2500 circles per frame with fill could be slowish but p5 is fine. I could draw points (point size) which is faster. But circles look nicer with alpha. Let me draw small circles/elliptical particles with low alpha for blending. Actually with the fade-rect technique, each particle drawn once per frame at full opacity leaves a fading trail. If particles overlap, the fade makes them blend. Let me draw filled circles radius ~2 with alpha. 

Actually, to get nice color trails, drawing each particle at low alpha (like 20-50) over many frames with the dark fade rect produces color smearing. That looks good.

Let me write the code now.

Let me think about color: 
```
colorMode(HSB, 360, 100, 100, 100);
let h = noise(p.x * 0.001, p.y * 0.001, time * 0.01) * 360;
fill(h, 80, 90, 30);
```

The hue uses a slow noise so nearby particles get similar hues and it drifts over time. Good for "vary particle colors over time" and "locally coherent."

Let me set speed ~1-3, with slight variation per particle.

Let me set up the structure. I'll use instance mode actually — no wait, global mode is simpler for a single sketch and the buttons are plain HTML. Let me use global mode. But global mode with p5 loaded normally works when the sketch is in a <script>. Yes.

One concern: p5 global mode auto-starts. When paused, I just return from draw early (skip update+draw). But the fade rect and everything should freeze. That's fine — freeze the frame. Actually, freezing means the last frame stays. That's acceptable for Pause. On resume, animation continues. Good.

Wait, but if I skip drawing on pause, the canvas just holds the previous frame. Good.

For Restart: reset zoff? Keep evolving. Reset particles to new random positions. Clear trails = draw full black background (or just reset). I'll reset and draw a clean background. The fade-rect technique means trails fade over time naturally; clearing on restart is instant by drawing background(0) once.

Let me also randomize fieldScale/noiseScale per restart for variety? Optional. I'll keep consistent field params but randomize particle positions and phase. Actually "new arrangement appears" — random positions suffice. I could also shift the noise phase. Let me add a per-restart random phase offset for the field so it's genuinely different. I'll add an offset applied to noise coordinates.

Let me write it.

Let me also make sure to use `noise()` which in p5 is Perlin-like (it's actually simplex-ish / improved Perlin). It's smooth. Good.

Field resolution: rez=20 means a 60x40 grid at 1200x800 = 2400 cells, computed each frame. That's cheap. Actually I could compute the field less frequently. But computing once per frame at 2400 cells with noise is trivial. However updating every frame with zoff increment gives smooth evolution. Good. Let me compute field each frame (it's cheap). Actually, I could update the field every few frames for performance, but let me just do each frame; 2400 noise calls per frame is fine.

Hmm wait, 2400 noise calls * 60 fps could add up but p5 noise is fast enough. Let me reduce: compute field at, say, rez=25 → 48x32 = 1536 cells. Fine. Or update field every 2 frames. Let me keep rez=20 and compute each frame; should be fine. If performance is an issue, I'll throttle.

Let me also consider: I can compute the field once with a time-varying zoff and it animates smoothly. Good.

Let me write the full file now.

Let me draft the JavaScript:

```javascript
let numParticles = 2500;
let particles = [];
let field = [];
let cols, rows;
const rez = 20;
const noiseScale = 0.08;
let zoff = 0;
const speed = 1.6;
let paused = false;
let hueOffset = 0;

function setup() {
  const cnv = createCanvas(windowWidth, windowHeight);
  cnv.parent('sketch-holder');
  colorMode(HSB, 360, 100, 100, 100);
  stroke(0);
  computeField();
  initParticles();
  drawBackground();
}

function draw() {
  if (paused) return;
  zoff += 0.004;
  hueOffset += 0.0008;
  computeField();
  // fading trails
  fill(0, 0, 0, 14);
  noStroke();
  rect(0, 0, width, height);
  for (let p of particles) {
    updateParticle(p);
    drawParticle(p);
  }
}
```

Hmm, the fade rect with HSB: fill(0,0,0,14) is black with alpha. Good.

But drawing the fade rect first means new particles draw over a slightly-darkened previous frame → trails fade. But the FIRST frame after setup had a full background. Good.

Wait, ordering: I draw the fade rect then particles. New particles are bright on top of fading old ones. Good.

But there's an issue: the fade rect darkens everything including bright trails, making them fade to black slowly. Good.

computeField:
```javascript
function computeField() {
  cols = floor(width / rez) + 1;
  rows = floor(height / rez) + 1;
  for (let y = 0; y < rows; y++) {
    for (let x = 0; x < cols; x++) {
      let nx = x * noiseScale;
      let ny = y * noiseScale;
      let angle = noise(nx, ny, zoff) * TWO_PI * 2;
      let v = p5.Vector.fromAngle(angle);
      field[x + y * cols] = v;
    }
  }
}
```

Wait, cols/rows depend on width/height which can change on window resize. I should recompute on resize. Let me handle windowResized. But to keep it simple, I'll recompute cols/rows in computeField each frame (since draw runs each frame). That adapts to resize. But field array size changes; the fieldAt uses cols/rows consistently. Fine. Actually recomputing grid each frame is wasteful but cheap. To be cleaner, recompute grid only when size changes. Let me just compute in setup and on resize, and assume stable size. But if width changes mid-run, field indexing mismatches. Let me recompute grid dims in computeField each frame to be safe (cheap enough). Actually the number of cells is small; recompute is fine.

Hmm, but if I recompute cols/rows each frame and the resolution is based on canvas size, on a stable 1200x800 it's constant. Fine. Let me set cols/rows once in setup and again in windowResized, and keep field as a fixed-size grid. Simpler and efficient. I'll guard fieldAt to clamp.

Let me just do: compute grid in setup() and windowResized(), store cols,rows. Recompute field vectors each frame (the angles change with zoff) but keep the grid shape. That's the cleanest.

```javascript
function setup() {
  ...
  resizeField();
  computeField();
  initParticles();
}

function resizeField() {
  cols = floor(width / rez) + 1;
  rows = floor(height / rez) + 1;
  field = new Array(cols * rows);
}

function windowResized() {
  resizeCanvas(windowWidth, windowHeight);
  resizeField();
  initParticles();
  drawBackground();
}
```

drawBackground: fill canvas black to clear trails on restart.
```javascript
function drawBackground() {
  background(0);
}
```
But background in HSB... background(0) is black. Fine. Actually background uses HSB color (0 hue, 0 sat, 0 brightness) = black. Good.

fieldAt with bilinear interp and wrapping:
```javascript
function fieldAt(px, py) {
  let gx = px / rez;
  let gy = py / rez;
  let x0 = floor(gx);
  let y0 = floor(gy);
  let x1 = (x0 + 1) % cols;
  let y1 = (y0 + 1) % rows;
  let ax = gx - x0;
  let ay = gy - y0;
  x0 = (x0 % cols + cols) % cols;
  y0 = (y0 % cols ... ) // careful
  ...
}
```
Wait, x0,y0 could be negative or beyond. Let me handle with modulo properly:
```javascript
let x0 = floor(gx) % cols;
let y0 = floor(gy) % rows;
if (x0 < 0) x0 += cols;
if (y0 < 0) y0 += rows;
let x1 = (x0 + 1) % cols;
let y1 = (y0 + 1) % rows;
```
This wraps. Good. Then index = x + y*cols.

Interpolate vector components:
```javascript
let v00 = field[x0 + y0*cols];
let v10 = field[x1 + y0*cols];
let v01 = field[x0 + y1*cols];
let v11 = field[x1 + y1*cols];
let vx = lerp(v00.x, v10.x, ax);
let vy1 = lerp(v01.x, v11.x, ax);
let vx = lerp(v00.x, v10.x, ax); ...
```
Let me do it carefully:
```
let topX = lerp(v00.x, v10.x, ax);
let topY = lerp(v00.y, v10.y, ax);
let btmX = lerp(v01.x, v11.x, ax);
let btmY = lerp(v01.y, v11.y, ax);
let dx = lerp(topX, btmX, ay);
let dy = lerp(topY, btmY, ay);
return {x: dx, y: dy};
```

Particle:
```javascript
function initParticles() {
  particles = [];
  for (let i = 0; i < numParticles; i++) {
    particles.push(newParticle());
  }
}

function newParticle() {
  return {
    x: random(width),
    y: random(height),
    vx: 0,
    vy: 0,
    baseSpeed: random(1.2, 2.4),
  };
}
```

updateParticle:
```javascript
function updateParticle(p) {
  let f = fieldAt(p.x, p.y);
  // normalize and steer
  let mag = Math.hypot(f.x, f.y);
  if (mag > 0) { f.x /= mag; f.y /= mag; }
  // lerp velocity toward field
  p.vx += (f.x - p.vx) * 0.04;
  p.vy += (f.y - p.vy) * 0.04;
  p.vx *= 0.985; p.vy *= 0.985; // slight damping
  p.x += p.vx * p.baseSpeed;
  p.y += p.vy * p.baseSpeed;
  // recycle at boundaries
  if (p.x < -50 || p.x > width + 50 || p.y < -50 || p.y > height + 50) {
    Object.assign(p, newParticle());
    // re-seed velocity from field
    let f2 = fieldAt(p.x, p.y);
    p.vx = f2.x * p.baseSpeed;
    p.vy = f2.y * p.baseSpeed;
  }
}
```

Hmm, Object.assign with a fresh particle replaces x,y,vx,vy. But baseSpeed is preserved? Object.assign(p, newParticle()) copies x,y,vx,vy from newParticle but baseSpeed from newParticle is also new (random). That changes speed. Fine actually, but let me preserve the existing baseSpeed. Let me just reset position and re-init velocity:
```javascript
p.x = random(width);
p.y = random(height);
let f2 = fieldAt(p.x, p.y);
p.vx = f2.x * p.baseSpeed;
p.vy = f2.y * p.baseSpeed;
```
Cleaner. Let me restructure newParticle and recycle separately.

Actually I realize the lerp approach p.vx += (f.x - p.vx)*0.04 is a steering toward field direction. Combined with damping. Good — produces smooth curves.

drawParticle:
```javascript
function drawParticle(p) {
  let h = (noise(p.x * 0.0008, p.y * 0.0008, hueOffset) * 360 + 360) % 360;
  fill(h, 70, 95, 45);
  noStroke();
  circle(p.x, p.y, 2.6);
}
```

Color varies with position+time noise. Good. Alpha 45 for blending with trails. Combined with the dark fade rect (alpha 14), trails persist nicely.

Hmm, wait: if I draw each particle at full brightness with alpha 45 over a darkening background, the trail is the accumulated particles from previous frames which are faded by the dark rect. New bright particles draw on top. Old ones fade to black. So we get fading color trails. Good.

Let me tune the fade alpha. 14 is mild; trails last ~7 frames to fade (100/14≈7). Actually each frame multiplies brightness by (1 - 0.14) ≈ 0.86, so after n frames 0.86^n. To fade substantially (~e^-1) takes ~7 frames, to near-black ~30 frames (0.86^30 ≈ 0.01). So trails last a fraction of a second at 60fps. Maybe a bit short; let me use alpha 8-10 for longer trails. Let me try 10. And keep particle alpha ~50 for bright trails.

Let me tune after testing in browser.

Now controls (HTML overlay):
```html
<div id="ui">
  <button id="pauseBtn">Pause</button>
  <button id="restartBtn">Restart</button>
  <span id="count">particles: 2500</span>
</div>
```

JS handlers:
```javascript
document.getElementById('pauseBtn').addEventListener('click', () => {
  paused = !paused;
  this.textContent = paused ? 'Resume' : 'Pause';
});
document.getElementById('restartBtn').addEventListener('click', () => {
  initParticles();
  zoff = 0; // maybe keep evolving; but restart wants new arrangement
  // Actually keep zoff evolving for variety, but new particles = new arrangement
  drawBackground();
});
```

Wait, but these handlers are inside p5's global scope? If I put the script after p5.min.js in global mode, the event listeners reference global `paused`, `initParticles`, etc. That works since they're global functions. Let me make sure to define them globally (which they are in global mode). But arrow functions referencing `paused` — paused is global. Fine.

But `this.textContent` in arrow won't work (this is wrong). Use the button element directly. Let me use a named function or query. Let me do:
```javascript
const pauseBtn = document.getElementById('pauseBtn');
pauseBtn.addEventListener('click', () => {
  paused = !paused;
  pauseBtn.textContent = paused ? 'Resume' : 'Pause';
});
```

For restart, should I reset zoff? The task: "Restart clears trails and initializes a new particle arrangement." New particle arrangement = new positions. Trails cleared = background reset. I'll keep zoff progressing (field keeps evolving) but reset particles. Actually to make it "new arrangement" and clearly different, random positions already give that. I could also re-randomize. Fine.

But should Restart reset the field phase so the pattern is fresh? The field evolves continuously; randomizing particle positions makes a new arrangement regardless. Let me also add a random global phase to the noise field on restart for more difference. I'll introduce a `fieldPhase` added to zoff or as an offset. Eh, let me keep it simpler: randomizing positions is enough. I'll also bump zoff by a random amount on restart. Let me do `zoffset = random(1000)` style. Actually let me add an `offX, offY` random offset added to noise sampling in computeField, regenerated on restart. That gives a genuinely different field. Let me add that.

Let me incorporate `noiseSeed`? p5 has `noiseSeed()`. I can call noiseSeed(random(1000)) on restart to change field pattern. That's clean. But noiseSeed affects all noise() calls including hue. That's fine and adds variety. Let me use noiseSeed on restart.

OK let me also double check: p5 global mode functions like `random`, `noise`, `createCanvas`, `windowResized`, `setup`, `draw` are globally registered when p5.min.js loads. Good.

Now, one concern: with 2500 particles and circle() each frame, plus field computation 1536 cells, performance at 1200x800 should be ~60fps. circle() for 2500 small circles might be okay. If slow, switch to point() or set pixels. Let me test.

Actually, calling circle() 2500 times per frame can be slowish because of ellipse rendering. point() with stroke is faster. But point() has limited size. Let me try circle first; if slow, reduce to point with strokeWeight. Let me use a mix: draw circles but test. Alternatively use beginShape points. Let me just test.

Let me also reduce particle size to ~2 for speed.

Let me write the file and test in the browser via the browser tool.

Let me also add: on initial load, the count and state. Make pause/resume work. Make sure draw returns early when paused (freeze frame). Good.

Let me also make sure that when paused, the canvas isn't being cleared — we just skip draw. Good, frame frozen.

Edge: `background(0)` on restart inside drawBackground uses HSB; background(0) → hue 0 sat 0 bright 0 = black. Good.

Let me write it.

Actually, one more: the addendum says "Use the provided `p5.min.js` (global `p5`) through a plain local script tag; the runner will inline it into the final artifact." And "load each with a plain <script src="NAME"></script> using its exact filename." So I use `<script src="p5.min.js"></script>`. Good.

Also note: "These library file(s) are ALREADY present in the current directory." So relative path p5.min.js works. Good.

Now, p5 global mode: when I include `<script src="p5.min.js"></script>` then my inline script defines `function setup(){}` etc., p5 picks them up as global sketch. Good.

Let me ensure my inline JS doesn't accidentally shadow or fail. I'll wrap nothing — keep functions global so p5 and button handlers can see them.

Let me write index.html now.

Let me also think about "keep controls responsive at 1200 by 800." The browser tool viewport is 1200x800. I'll make the canvas fill window via windowWidth/windowHeight. Controls fixed at top. At 1200x800 they'll appear at top. Good. Responsive: buttons sized fine.

Let me also add a subtle background gradient? No, black is classic. Keep black.

Let me write it.

For color variety "vary particle colors over time": hueOffset increments, and hue computed from noise(pos, hueOffset). Over time hue drifts. Good. Also field color via zoff. Two time dimensions.

Let me finalize numbers and write.

Let me write the code in the script. I'll be careful with p5 instance vs global — using global functions directly.

Let me write the file.

I'll write a reasonably complete, polished file. Let me also include a toggle for "show field" maybe not needed. Keep scope tight: two buttons + count. Maybe also show FPS. Let me keep minimal.

Let me write now.

Actually, let me reconsider performance of recomputing the field every frame with 1536 noise calls plus 2500 particles each with fieldAt (4 noise-free lookups + circle + 1 noise for hue = 2500 noise calls). Total ~4000 noise calls/frame. At 60fps that's 240k noise calls/sec. p5 noise is reasonably fast; should be okay. If not, I can reduce particles to 2000 (minimum required) or throttle. Let me start at 2500 and adjust.

Let me write and test.

Let me also make particles use beginShape(POINTS) for speed? Actually I'll draw individually. Test first.

Writing now.

Let me also handle the fade: instead of full black rect each restart, I set background(0) on restart, then subsequent frames use the fade rect. Good.

But note: on restart, if paused=false, next draw does fade rect (alpha ~10 over the just-cleared black background → still black) then draws bright new particles. Good, clean start.

Let me write.

For the circle drawing, I worry about 2500 fill circles. Let me consider using `stroke(h,...)` with `point()` and strokeWeight(2.5) and no fill. point() is much faster than circle(). And visually similar for small particles. But point() is a single pixel by default; with strokeWeight it becomes a thicker line point = a small disk. That's fine. Let me use point() for speed. Actually, circle() renders an antialiased disk; point() with strokeWeight renders a rounded point. Both fine. Let me test circle first; if slow, switch.

Hmm, to be safe on performance I'll use a hybrid: draw with `point()` and `strokeWeight`. Actually let me just use circle and measure. The browser tool lets me see.

Let me write the file and open it.

I'll set noCursor maybe. Not needed.

Let me write.

One more: the fade rect uses `rect(0,0,width,height)`. With HSB fill(0,0,0,alpha). Good. I must ensure noStroke for the rect (I set noStroke globally for particles). Fine.

Let me write the complete file.

For responsive controls CSS:
```css
#ui { position: fixed; top: 12px; left: 50%; transform: translateX(-50%); display:flex; gap:10px; align-items:center; z-index:10; }
button { padding: 8px 16px; font-size: 15px; border:none; border-radius:6px; background:rgba(0,0,0,0.5); color:#fff; cursor:pointer; }
button:hover { background:rgba(255,255,255,0.2); }
#count { color:#fff; font-size:13px; }
```

Canvas parent: I'll place canvas in body full bleed. p5 createCanvas with parent. Actually createCanvas(windowWidth,windowHeight) makes full canvas; p5 by default sets body margin 0? p5 adds the canvas to document.body and styles it. There might be body margin. Let me set body{margin:0; overflow:hidden; background:#000;} and the canvas fills. p5 canvas is drawn at 0,0. With windowWidth/Height matching. Good. I'll also use `cnv.parent(document.body)` is default. Fine. But to be safe set css.

Let me also disable default p5 context menu? right-click. I'll add `document.oncontextmenu = ()=>false;`? Not needed.

Now the sketch-holder: I don't need it; I'll just append canvas to body directly (default). Remove parent.

Let me write.

I'll set `frameRate(60)` maybe. Default 60. Good.

Let me write the file.

Now let me run it in the browser to inspect.

The page loaded. The console has a warning about iframe sandboxing (that's a browser tool warning, not a real error). The DOM shows Pause, Restart, flow-field particles · 2500 particles. 

The images field says "model does not support images" — the browser tool can't generate images for me to see. But I got a screenshot? Let me check the console more and inspect the DOM. Actually the tool returned console, dom. There's no screenshot shown. Let me try the screenshot or inspect action.

Wait, "images":"model does not support images" — this is the browser tool's response format; it seems to not produce an image for me. Let me just verify via inspect and console. Let me check the console for errors and check that particles render. I can check via inspecting canvas or a quick screenshot attempt.

Let me check the console for errors first by inspecting.

The inspect shows only the sandbox warning in console (no JS errors). The DOM is correct. But I want to verify the animation actually renders particles. The browser tool's "images" field says model doesn't support images, so I can't see a screenshot. Let me try a `motion` action which records motion frames — maybe that yields image data. Actually "motion" returns motion frames. Let me try motion; it might still say model doesn't support images.

Alternatively, I can verify the canvas is drawing by using the browser's devtools? The inspect action returns console + dom. Let me try a screenshot to see if anything renders. But image support isn't available to me.

Hmm. The tool returned `{"console":["warning..."],"dom":"Pause\nRestart\n...","images":"model does not support images"}`. So images aren't available to the model. So I can't visually inspect. I'll rely on console for JS errors and reasoning.

Let me check the console for runtime errors by waiting a moment and re-inspecting. Also, I should verify the canvas element exists and has content. Let me query the DOM for canvas. The inspect returns the body's text content ("Pause\nRestart\n..."). The canvas is there (p5 adds it). 

Let me run the browser motion for a few seconds to confirm animation runs without errors, then re-inspect console. Also I can programmatically inspect by... I can't run arbitrary JS from my side except via the click/key actions.

Actually, I can verify behavior by reasoning and checking the console. Let me do a motion capture to let it run, then inspect console again for errors.

Let me think about whether there could be runtime issues:

1. `noiseDetail(4, 0.5)` — p5 global function, valid.
2. `p5.Vector.fromAngle` — valid (p5.Vector is global in global mode).
3. `createCanvas`, `colorMode`, `frameRate`, `noise`, `noiseSeed`, `floor`, `lerp`, `random`, `background`, `fill`, `noStroke`, `rect`, `circle`, `windowWidth`, `windowHeight`, `resizeCanvas` — all valid p5 globals.
4. `windowResized` — p5 auto-calls it. Valid.
5. The `_tmp` scratch vector reused per particle — fine, avoids allocation.
6. UI setup: `setupUI` defined as `window.setupUI`. Called in second script block. Good. The pauseBtn/restartBtn elements exist because the HTML for #ui is before the script. Good.
7. restartAll uses noiseSeed. Good.

Potential issue: In `draw`, I call `flowAt(p.x, p.y, p._tmp)` then `steer(p, p._tmp)`. But `_tmp` gets overwritten each iteration for that particle; fine since sequential. But `step` after steer uses p._tmp? No, step has its own flowAt for recycling. Actually step uses p._tmp again but that's after we're done with steer. Fine. But render reads p._tmp? No, render uses noise and circle. p._tmp only used transiently. OK.

Wait, there's a subtle bug: I compute `flowAt` at current position, then steer, then step (move). The steer lerps velocity toward field at current position. Then step moves. Then if out of bounds, re-seed velocity. Fine.

Another subtle issue: `circle` in HSB with fill alpha. Good.

Performance: 2500 circles per frame. Could be fine. Let me check FPS via a console.log in draw? I could add a temporary FPS log. But I can't easily see runtime console beyond the inspect action. Let me add a one-time console check... Actually, let me just trust it but verify by letting motion run and re-inspecting console for errors (e.g., "Particle count too high").

Actually I realize I should verify the animation produces visible motion. Since I can't see images, let me add a small on-screen FPS/count so the DOM text updates, then inspect shows changing text? No, inspect returns static snapshot.

Hmm. Let me try the `motion` action — it may return motion frames that I can't view anyway. The "images" not supported means I can't see screenshots. 

Let me reconsider: Maybe I can verify rendering indirectly. The p5 canvas: if there were a JS error in draw, the console would show it. The inspect showed no errors, only the iframe warning. So draw is likely running without throwing. 

But "without throwing" doesn't guarantee particles render visibly. However, given the logic is standard and there are no errors, it should render. Let me double check a couple of logic points that could cause a silent blank:

- `colorMode(HSB, 360, 100, 100, 100)` then `fill(h, 80, 95, particleAlpha)` where particleAlpha=48 (0-100 range since last param is alpha max 100). Good, visible.
- `background(0)` clears to black HSB (0,0,0,0)? background(0) → hue 0 sat 0 bri 0 = black, full alpha. Good.
- `circle(p.x, p.y, 2.4)` draws. Good.
- The fade rect `fill(0,0,0,9)` then `rect`. This darkens each frame. With background black initially, first frame draws fade (alpha 9 over black) = barely darkens, then 2500 bright circles. Subsequent frames: fade dims old particles. Good — trails visible.

So it should render. 

One concern: `clearCanvas` calls `background(0)`. On first setup, clearCanvas makes black. Then draw fades + draws. Good.

Another: when paused, draw returns; canvas frozen. Good. On restart, clearCanvas then particles redrawn bright. Good.

Let me verify there are no errors after it runs ~2s. Let me do a motion action (which runs the browser and records motion frames) then inspect console.

Actually, the motion action records motion frames for the model to see — but model can't see images. It still runs the animation though. Let me just wait and inspect console. I'll do a `key` or just re-inspect after a short motion.

Let me try motion to advance time, then inspect console for any errors.

Still no errors. Good. The animation runs without throwing. 

Now let me actually test the Pause/Resume and Restart behavior using the click action on the buttons, then verify. The buttons are at top center. The viewport is 1200x800. The #ui is at top:14px, left:50%, transform translateX(-50%). The Pause/Restart buttons. Let me click the Pause button, then inspect console, then click Restart, then inspect.

But to click, I need coordinates. The #ui div: top 14px, centered. Each button ~ height 38px? padding 9px 18px. Pause button is first. Let me estimate: ui div centered horizontally around 600px. Buttons with gap. Pause button roughly from x ~ 600 - (width of "flow-field particles..." ...). Actually the info text is wide. Let me compute: the row is "Pause  Restart  flow-field particles · 2500 particles". The info span is wide, so the centered group spans a large width. "flow-field particles · 2500 particles" is ~ 400px wide. Plus Pause(70) + Restart(76) + gaps. Total ~ 580px. So the group spans 600±290 = 310..890. Pause button at left of group, so roughly x 310-380, y 14-52.

Hmm, clicking precisely is tricky. Let me click near Pause button. Actually, let me instead verify the controls work by checking they don't throw. But I'd want to confirm Pause freezes and Restart clears.

Since I can't see images, I need to rely on console for errors. But behavior (frozen frame, new arrangement) can't be visually confirmed by me. I can, however, confirm no errors occur when clicking.

Alternatively, I can add a temporary console.log in pause/resume/restart handlers to confirm they fire, and then inspect console. But the handlers already do things; adding logs helps me confirm execution. But I'd need to see the console update after clicking — the inspect action returns current console. Let me add logs to the handlers temporarily, reload, click, inspect.

Actually, a cleaner approach: I can verify the logic is correct by careful code review, and confirm via console that clicking the buttons triggers handlers without error. Let me add small console.logs to the button handlers and restartAll, reload, click, then inspect console.

Let me add logs. I'll edit the file to add console.log in handlers. Then reload, inspect (to get fresh console), click Pause, inspect console (see log + no error), click Resume, click Restart, inspect console.

But clicking requires coordinates. Let me figure coordinates. Actually, maybe I can click using the button via a keyboard? No. The click action needs x,y.

Let me reconsider the layout to make buttons easy to click. I could move controls to top-left with more padding so Pause is at a known spot. But centered is fine visually. For testing, let me reposition to left so I can click reliably. Actually, let me keep centered but make the buttons have explicit positions via clicking at known spots.

Alternatively I can click on the canvas region and rely on... no.

Let me just reposition the UI to top-left corner fixed so Pause button is at a predictable coordinate, test, then I could move back. Actually centered is nicer for the final artifact. Hmm. Let me keep centered but I'll click at an estimated coordinate and check the console log appears (which confirms the click hit the button). If it doesn't hit, I adjust.

Let me add console.logs first. Edit handlers:
- pauseBtn click: console.log('pause toggled', paused)
- restartBtn click: console.log('restart clicked')
- restartAll: console.log('restartAll called')

Let me edit.

Actually, I want the final file clean without debug logs. Let me add them, test, then remove. Or I can leave them — console logs on user actions are fine and not harmful. But clean is better. Let me add, test, remove.

Let me also reconsider: is there a risk the canvas isn't actually rendering because p5 in global mode needs the functions defined before p5 runs? p5 scans for setup/draw after the script executes. Since my script defines them at top level, by the time p5's preload/setup runs they exist. The two <script> blocks: first defines functions and `window.setupUI = setupUI`? Wait, I defined setupUI inside the first script block as a function declaration `function setupUI(){...}` and then `window.setupUI = setupUI;` at the end of that block. Then the second script block calls setupUI(). Good.

But wait: the first script block defines `function setup(){}` etc. as global function declarations — in global mode p5 picks them up. Good. And `window.setupUI = setupUI`? I wrote `window.setupUI = setupUI;` inside the first script? Let me check what I wrote.

Looking at my code, the first script ends with:
```
    // p5 global sketches call windowResized automatically; kick off the UI
    // once the sketch is ready.
    window.setupUI = setupUI;
  </script>
```
Yes. Then second script calls setupUI. Good.

Actually, `function setupUI(){...}` is already a global (attached to window automatically as a function declaration in module? No — this is a classic script, not a module, so function declarations become global properties on window). So setupUI is already window.setupUI. The explicit assignment is redundant but harmless. And the second script's setupUI() call works. Good.

But is setupUI called only once after DOM ready? Yes. Good. The canvas from p5 setup is added to body; #ui is before the scripts, so it exists. setupUI adds listeners. Good.

Now, one concern: p5's `setup` runs after `windowResized`? No. p5 calls setup once. setupUI is called on DOMContentLoaded (or immediately if loaded). Both run around the same time. The buttons exist in DOM already (they're in body before scripts). So setupUI can find them. Good.

Let me now add debug logs and test clicks.

Coordinates for clicking Pause button (centered, top). Let me estimate more precisely. Actually, easier: let me temporarily change CSS to put #ui at top-left fixed so Pause is at ~ (14, 14) area, click there, test, then restore centered in final. But that changes layout; I'd need to revert. Let me instead just compute.

The info text: "flow-field particles · 2500 particles". Let me estimate rendered width ~ 330px. Pause button inner text "Pause" ~ 44px wide (with padding 18*2=36 + text ~ 40 = ~76). Restart ~ 84. Gaps 10px each, plus padding 14*2=28. Total width ≈ 28 + 76 + 10 + 84 + 10 + 330 = 538px. Centered at 600, so left edge ≈ 600 - 269 = 331. Pause button left ≈ 331, right ≈ 331+76=407, y 14..~56 (height: padding 9*2=18 + font 15 + line-height ≈ 38). So Pause button roughly (331..407, 14..52). Click ~ (370, 35) to hit Pause. Restart ~ (411..495, 14..52), click (440,35).

But my width estimates may be off. Let me instead add a debug log AND click, then inspect; if log doesn't appear, try other coords.

Actually, simpler and more robust: temporarily add IDs/positions. Hmm.

Alternative: I can verify Pause/Resume/Restart by inspecting the console after clicking at a reasonable spot and seeing logs appear. Let me add logs and try clicking at (370, 35).

Actually, let me reconsider — maybe I should make the final UI left-aligned for clarity and to guarantee test clicks. Top-left controls are perfectly acceptable and common. Let me change `#ui` to top-left (left: 14px) — cleaner for testing and fine aesthetically. Then Pause button at ~ (14..90, 14..52). Click (55, 35) should hit Pause, (110,35) Restart. Let me do that — it's a legitimate design choice, not just for testing. Top-left is good.

Wait, but the task says "keep controls responsive at 1200 by 800." Top-left fixed is responsive. Good.

Let me change CSS: #ui top:14px; left:14px; transform:none. Then the group is left-aligned at top.

Let me also add debug console logs to confirm handlers fire. I'll add them, test, then optionally remove. Actually, leaving a console.log on click is fine and harmless; but to be clean I'll remove after verifying. Let me add, test, then remove in a final edit.

Let me make the CSS edit and add logs.

Now reload and inspect console to get a fresh baseline, then click Pause, inspect, click Restart, inspect.

Good, fresh baseline, no errors. Now click Pause button. The Pause button is now at top-left. With left:14px, the ui div starts at x=14. Pause button: text "Pause" + padding 18px*2=36. "Pause" width ~ 44px. So button ~ 14 + 36 = 50px wide area from x 14..64 (approx, plus text). Actually padding 9px 18px means content box. The button box: left=14, width≈ 36+44=80, so x 14..~94, y 14..~52 (padding 9+font 15+ ≈ 38 tall). Click center ~ (54, 33). Let me click (55, 33).

Pause works: the button label changed to "Resume" and console logged `paused=true`. The handler fired, no errors.

Now let me verify the frame is frozen when paused. I can't see images, but the fact that paused=true means draw returns early. Let me click Resume (now the button says "Resume" at same spot) to un-pause, then click Restart.

Click Resume at (55,33).

Resume works: paused=false, button back to "Pause". Now click Restart. Restart button is to the right of Pause. Pause button box: x ~14..~94. Gap 10. Restart button starts at ~104, width ~ 36 + "Restart"(~68) = 104, so x ~104..~208. Click ~ (155, 33).

Let me click Restart.

Restart works: restartAll fired, clearCanvas (background black), initParticles (new positions), and paused reset to false. Console logged both. No errors.

Now let me let it run for a few seconds and re-inspect console to make sure no runtime errors accumulate (e.g., from performance issues or the recycling). Let me do a motion capture then inspect.

Actually, I've verified:
- Animation runs (no errors in console after load).
- Pause/Resume works (toggles paused, button label updates).
- Restart works (restartAll fires, clears, reinitializes).

What I cannot visually confirm (no image support):
- Coherent nearby particle motion (the field grid + bilinear interp guarantees this).
- Fading trails (the dark fade rect + per-frame drawing guarantees this).
- Varying colors over time (hueOffset + noise-based hue guarantees this).
- Field evolving gradually (zoff increments each frame).
- Particles bounded (recycle at boundaries).

These are all guaranteed by the code logic. Let me run for a few more seconds to ensure no late errors (e.g., if performance chokes). Let me do a motion then inspect console.

Let me also verify performance is acceptable by checking the frame doesn't error and there's no "too many" warning. p5 doesn't warn about particle count. 

Let me run motion for ~5s then inspect.

No new errors after running for several seconds. The animation is stable.

Now let me remove the debug console.logs to keep the final file clean. Let me revert the three edits.

Actually, console.logs on user actions are harmless and even helpful for debugging in production. But the task is about a clean artifact. Let me remove them to be tidy. I'll edit them back out.

Let me remove:
1. `console.log('[ui] pause/resume -> paused=' + paused);`
2. `console.log('[ui] restart clicked');`
3. `console.log('[ui] restartAll fired');`

Now let me do a final reload and inspect to confirm the cleaned file loads without errors and the controls still work. Let me reload and click pause/resume/restart once more to confirm after removing logs.

Let me reload first.

Clean load, no errors. Let me click Pause, Resume, Restart once more to confirm controls work after cleanup.

Pause still toggles to "Resume". Now click Restart.

Restart works — button back to "Pause" (restartAll resets paused=false, and reinitializes). No errors.

Everything works. Let me do a final review of the complete file to make sure it's clean and correct.

Let me read the final file to confirm it's clean (no leftover debug logs, correct structure).