Bouncing balls in a heptagon · qwen3.8-flash

Let me build a single-file HTML canvas physics simulation.

Key requirements:
- 20 balls numbered 1-20, compact non-overlapping initial arrangement near center, fall under gravity.
- Rotating heptagon, 1 revolution / 5 seconds, fully visible.
- Ball-ball and ball-wall collision detection custom. Moving-wall velocity in bounce response. Damping/friction.
- Angular motion (spin) with number rotating with ball.
- Stable constants.
- Pause/Resume, Reset.

Design:
Canvas ~ 900x700? Let's do a responsive canvas with devicePixelRatio.

Heptagon: circumradius R = 260. Center at canvas center. Walls as line segments; rotate by angle theta = (2π/5)*t (one revolution per 5 seconds).

Ball radius: with 20 balls packed in a hexagonal-ish arrangement near center, need radius small enough. Let's do ball radius ~ 14-18 px. Actually let's make radii vary slightly? Requirement: "Choose reasonable sizes" — I'll make all balls same radius for simplicity of packing, maybe slight variation. Let's use r = 16 for all, and place in a triangular lattice arrangement of 20 balls (rows 4,4,4,4,4 or 5 rows: 2,3,4,5,6=20). Rows of a triangular lattice: spacing 2r+gap.

Let's compute: r=16, spacing dx = 2*r = 32 plus small gap 2 => 34. Rows: 5 rows of 4? 4*5=20. Triangular lattice with rows of 4, alternate offset. Width = 3*34 = 102, height = 4*34*0.866=117.7. Total fits inside heptagon inradius (R*cos(π/7) = 260*0.9009 = 234). At center, the container half-width... fine. Balls must be non-overlapping with wall initially? Requirement says near the center, so fine.

Physics: Use semi-implicit Euler with substeps. Gravity g = 1200 px/s². Restitution e = 0.42 (ball-ball), wall restitution 0.5, tangential friction.

Ball spin: angular velocity ω, moment of inertia I = 0.5 m r² (solid disk). Wall friction impulse applies torque.

Wall collision with moving wall: heptagon rotating with angular velocity Ω = 2π/5 rad/s. Wall point velocity at contact point p: v_wall = Ω × (p - center) = Ω * (-(p.y-cy), (p.x-cx)) for CCW rotation in standard math coords; in canvas coords y is down, so rotation with increasing theta in canvas coordinates corresponds to clockwise visually but math same: velocity = Ω * (-(dy), dx) where d = p - center, using the same rotation matrix as used for the vertices. Let's define vertices via angle a_i = theta + i*2π/7 - π/2 (to have a vertex up) at center C. Position p_i = C + R*(cos a_i, sin a_i). With theta increasing, dp/dtheta = R*(-sin a, cos a)*dtheta. So wall velocity = Ω * (-(dy), dx) where dx = p.x - C.x, dy = p.y - C.y. Good.

Collision detection with the segments: for each ball, compute the signed distance to each of the 7 edges (inward side). Since the heptagon is convex, ball inside. Penetration = r - (distance to edge line along inward normal) — Actually for a convex polygon, distance from interior point to edge line along inward normal = (inward normal · (p - vertex_i)). Compute penetration depth; if < 0 collide. But need to handle near-vertex cases: for fast rotating container and balls, the simple "closest edge" approach using half-plane distances works well for convex polygon containment (each half-plane constraint). That handles the corner case correctly since being inside all half-planes = inside polygon. But a ball near a vertex could penetrate two half-planes simultaneously; resolve each sequentially — fine.

Response: relative velocity v_rel = v_ball - v_wall. Normal n = inward normal. If v_rel·n < 0 (moving into wall, i.e., moving outward relative to wall — careful sign): let's define n = inward normal (pointing into the polygon interior). Velocity of ball toward the wall = -v_rel·n > 0 means approaching. So if v_rel·n < 0 → approaching.

Impulse: j = -(1+e) * (v_rel·n) / (1/m + ...) — for a wall (infinite mass, but moving), j = -(1+e)*m*(v_rel·n). Then v_ball += j/m * n. Also tangential friction with contact point including spin: contact relative velocity including ball surface velocity: v_t = v_rel - (v_rel·n)n; contact point on ball is at p - r*n (since n points inward, wall is outward from ball): the material point velocity = v_ball + ω × r_vec where r_vec = -r*n (vector from center to contact point). In 2D, ω × r = ω * (-r_y, r_x).

Friction impulse magnitude limited by μ * |j_normal|. Apply tangential impulse and torque: L += cross(r_vec, J).

Let me implement:
```
n = inward normal (unit)
contact point on ball: rc = -r * n  (from center to contact)
vWall = Ω × (contactPos - C) ... where contactPos = p + rc = p - r*n
vrel = v - vWall
vn = dot(vrel, n)
if vn < 0:
   jn = -(1+e)*vn*m  (impulse along n)
   t = normalize(vrel - vn*n)  // tangential direction
   vt = dot(vrel, t)
   // include surface velocity due to spin: velocity at contact = v + ω_perp(rc)
   // full contact relative velocity: vc = v + ω × rc - vWall
   vc = v + crossW(ω, rc) - vWall
   vct = dot(vc, t)
   jt = -vct * m / (1 + k) where k = m*r²/I ... for rolling friction with I = 0.5 m r², the effective mass for tangential impulse at contact: 1/m + r²/I = 1/m + 2/m = 3/m → jt = -vct / (1/m + r²/I) = -vct*m/3.
   clamp |jt| <= μ*|jn|
   v += (jn*n + jt*t)/m
   ω += cross(rc, jn*n + jt*t)/I
```
Also position correction: push ball inward by penetration along n.

Ball-ball: standard with restitution and friction including spin.

I = 0.5*m*r², m = r² (density uniform) maybe. Let's set m = r² * density.

Stability: use substeps (e.g., 4 substeps per frame with dt clamped), cap velocities.

Also add sleeping/damping: global linear damping small (air drag 0.999 per substep), and gravity.

Rotation: constant angular rate regardless of balls (kinematic container, infinite inertia). That's simplest and stable.

UI: buttons Pause/Resume, Reset, maybe sliders for gravity? Keep focused. Show stats: ball count, omega, max speed, energy.

Rendering: draw heptagon with a glow, balls with color per number, number text rotated by ball angle. Draw radius marker to make spin visible (a small line/dot from center), plus number rotating.

Requirement: "Give each ball angular motion and rotate its number with the ball so spin is visible." So draw number rotated by ball angle, plus maybe a marker line.

Let me also ensure balls remain contained even when moving fast: use penetration-based resolution plus velocity clamp, and clamp substep.

Initial arrangement: 5 rows × 4 balls triangular lattice centered at container center (slightly above center? "near the enclosure center"). Give zero initial velocity. They fall under gravity and the rotating walls shepherd them.

Canvas size: use fixed logical size 900x760 with CSS scaling. Let's do width 900, height 700, heptagon center at (450, 375) with R=270? Inradius = 270*0.90097=243; so the polygon spans vertically: with vertex up, top vertex at y = 375-270 = 105; bottom edge at... For a vertex-up heptagon, vertices at angles -90 + k*(360/7): -90, -38.57, 12.86, 64.29, 115.71, 167.14, 218.57(=-141.43). Bottom-most vertex: angle 64.29 → y=+0.9015*R? sin(64.29°)=0.9008 → y = 375+243 = 618. And angle 115.71 → sin = 0.9008 too. So vertical extent = R*(1+0.9008)=513 → 105 to 618. Horizontal extent: max cos: cos(12.86°)=0.975 → ±263. So width ~526, height 513. Fits in 900x700. Good, fully visible.

Let's write the code.

Physics constants:
- gravity G = 1400 px/s²
- restitution ball-ball 0.35, wall 0.45
- friction μ wall 0.35, ball-ball 0.25
- ball radius: with R=270 and 20 balls, r=17 seems fine. Packed lattice 4 columns × 5 rows: width = 3*(2r+2)=... r=17, spacing 36 → 3*36=108, rows spacing 36*0.866=31.2 → 4*31.2=125. Total height 125+34=159, width 142+34... fine within inradius.

Actually let's have slight radius variation: r = 16 + (i%3)*1.5? That complicates packing. Keep uniform r = 17 for guaranteed non-overlap and simplicity. Hmm, variety looks nicer. I'll do r in [15,19] but pack on lattice with spacing = 2*maxR + 2 = 40. That keeps non-overlap.

Let me do: radii alternate between 15, 16.5, 18 deterministic by index; lattice spacing 2*18+3 = 39. Rows of 4 with offsets 5 rows → 20 balls. Lattice rows y offset: dy = 39*0.866=33.75. Row x offsets staggered by 19.5. Widths: row with 4 balls spans 3*39 = 117 plus radii. Staggered rows: x = (i - 1.5)*39 + (row%2)*19.5. So max x extent = 1.5*39+19.5 = 78 plus r=18 → 96. Half-height = 2*33.75 = 67.5 + 18 = 85.5. Container inradius 243 at fixed orientation but corners... The ball positions must be inside all half-planes. Distance from center to each edge line = 243. Point (96, 85.5) — need to check with the polygon orientation (vertex up, edges). For a regular heptagon with vertex up, the bottom edges... Actually the constraint: inside all half-planes at distance 243 from center. Max |point| = sqrt(96²+85.5²) = 128.9 < 243-18 = 225. Since distance from center to each edge = 243 and the inward normal dot product ≥ 243 - |p| > 0. So fine, definitely contained.

Substepping: dt from requestAnimationFrame, clamp to 1/30 max, then substeps = 4, each dt/4. Speed cap: |v| ≤ 3000.

Also add continuous-ish safety: if a ball ends up outside the polygon (distance to center > R), teleport back inside / clamp. Implement: after integration, check containment via half-planes; if a ball is outside (penetration > r for some edge i.e. outside a half-plane by more than ...), clamp position to inside. Actually the half-plane penetration check already handles this: for each edge, signed distance d_i = inwardNormal_i · (p - v_i). If d_i < r → collision. Resolve the deepest first, iterating a few times. That handles containment robustly even if it exits through one edge (position correction pushes it back in). Good.

Wall rotation: update theta each substep: theta += Ω*dt. Then recompute vertices/normals.

Let me now write the full code.

```js
const canvas = document.getElementById('sim');
const ctx = canvas.getContext('2d');
const W = 900, H = 700;
// handle DPR
```

Render: background gradient, heptagon stroke with thick band, balls with radial gradient fill, number text.

Also a HUD: FPS, max speed, contacts count.

Buttons: Pause/Resume toggling, Reset.

Let me write.

Number drawing: ctx.save(); translate(ball.x, ball.y); rotate(ball.angle); draw marker line from center to edge (spoke), and text at center. Text rotated with the ball. Draw a small dot at rim too.

Colors: hue by number: `hsl(${(n-1)*18 % 360}, 70%, 55%)`.

Ball-ball collision:
```
for i<j: d = p_j - p_i; dist; if dist < ri+rj:
  n = d/dist; overlap = ri+rj-dist
  // positional correction proportional to inverse mass
  rel = v_j - v_i; vn = rel·n; if vn < 0:
    e = 0.35
    jn = -(1+e)*vn / (1/mi + 1/mj)
    apply impulses with friction using contact points rc_i = -ri*n... 
```
Include spin in tangential: contact velocity vc = v_i + ω_i × rc_i ... Let me implement a helper for impulse with friction:

```
function resolveContact(pA, vA, wA, mA, IA, rA, pB, vB, wB, mB, IB, rB, n, wallVel) 
```
Might be over-engineered. Let me write two dedicated functions but share a friction helper.

Ball-ball tangent relative velocity including spin:
contact point on A: rcA = rA * n (from A toward B); on B: rcB = -rB*n.
surface velocity of A at contact: vA + ωA × rcA = vA + ωA*(-rcA.y, rcA.x).
Similarly for B: vB + ωB × rcB.
rel = (vBsurf - vAsurf) with wall handled by treating wall as infinite-mass body with velocity = wallVel and ω contribution... For the wall, the "material point" velocity is wallVel (kinematic). Its ω about the ball center irrelevant; friction on the ball uses the ball's surface velocity vs. wall material velocity.

Let me define generic: body A = ball, body B = other ball or wall (infinite mass, velocity = wallVel at contact point, no rotation-inertia coupling).

For simplicity write separate code paths — clearer.

Wall:
```
// n inward normal at edge, contactPos = p - r*n (approximate)
wallV = rot90(contactPos - C) * Ω   where rot90(x,y) = (-y, x)
rc = -r*n
vs = v + ω*(-rc.y, rc.x)   // ball material velocity at contact
rel = vs - wallV
vn = rel·n
if vn < 0:
  e=0.5, mu=0.4
  jn = -(1+e)*vn*m   (B is infinite mass => 1/mB=0)
  t = perp(n)
  vt = rel·t
  // tangential effective mass: ball only: 1/m + r²/I  (wall infinite, no own rotation)
  jt = -vt / (1/m + r*r/I)
  clamp |jt| <= mu*|jn|
  J = jn*n + jt*t
  v += J/m; ω += cross(rc, J)/I
```
Note: with jt = -vt/(1/m + r²/I) that's the impulse that kills relative tangential velocity (full rolling), clamped by Coulomb. Good — that gives spin-up from wall friction, which makes visible spin.

Ball-ball:
```
n from A to B
rcA = rA*n, rcB = -rB*n
rel = (vB + ωB×rcB) - (vA + ωA×rcA)
vn = rel·n
if vn<0: jn = -(1+e)*vn/(1/mA+1/mB)
t = perp(n)
vt = rel·t
jt = -vt/((1/mA + rA²/IA) + (1/mB + rB²/IB))
clamp to mu*|jn|
J = jn*n + jt*t
vA -= J/mA; ωA -= cross(rcA,J)/IA
vB += J/mB; ωB += cross(rcB,J)/IB
```
Positional correction: separate: move apart along n by overlap*0.8 weighted by inverse mass.

Also apply restitution only when vn < 0; if overlapping but separating, just positional correction.

Add small restitution threshold to prevent jitter: if |vn| small, e=0.

Air damping: v *= (1 - 0.15*dt) maybe; ω *= (1 - 0.4*dt) hmm rolling balls should keep spinning somewhat; use ω *= exp(-0.2dt).

Now the container drawing: rotate a hex...

Also: balls should not tunnel through the rotating corners; using half-plane containment resolution each substep, with dt/4 ≈ 0.004s at 60fps and speeds up to 1500 px/s → move 6px per substep, less than r=17. Fine.

Let me also add a "spin" indicator: draw a spoke line and rotate the number.

HUD elements: buttons + labels. Also maybe a speed limiter.

I'll also handle canvas resize: set canvas.width = W*dpr etc.

Let's write the file.

Also the verify step: run in browser, check console, screenshots, do pause/resume and reset checks via clicking. Coordinates: buttons need to be within 1200x800 viewport. My layout: header with controls at top, canvas below. Canvas 900x700 logical might be too tall for 800px viewport with header. I'll scale canvas via CSS to fit: width: min(900px, 92vw) and height auto. The 1200x800 viewport: header ~60px + canvas ~ 900*(700/900)=700 → total 760 + padding. Might be slightly tight; use CSS max-height with object-fit? Simpler: set canvas CSS width to min(900px, 92vw, ...) and it scales proportionally. Let me make logical size 920x640 and heptagon R=250 to be more landscape-friendly. Vertical extent = R*(1+0.9008) = 475 → fits in 640 with margins. Center at (460, 330): top vertex y = 330-250 = 80; bottom = 330+225 = 555. Horizontal: ±244 → fine.

CSS: canvas { width: min(920px, 96vw); height: auto; } At 1200 viewport, width 920, height 640 → total with header ~700-720. Good.

Physics scale relative to R=250, r=16.

Let me finalize radii: rBase variation 14,15.5,17 → lattice spacing = 2*17+3 = 37. Rows of 4, 5 rows.

Check packing heights: rows y = (rowIdx - 2)*37*0.866 = -64..64, ±. plus r → 81. Width ±(1.5*37+18.5=74) + 17 = 91. Fine.

Gravity: G = 1500. Terminal speeds inside 250-radius container... fall from top 150px → v = sqrt(2*1500*150) = 670 px/s. Fine.

Now write code carefully.

Also the number text: font size ~ r*0.95 bold. Rotated by ball.angle.

Also add "energy/speed" HUD readouts. And a pause indicator.

Let me write it.

One more: "Sample several moments of the initial fall and collisions" — the verify instruction for me via browser tool: screenshot at a few times, check motion via `motion` action.

Implementation of reset: store initial config, rebuild balls, theta = 0.

Also keep simulation time advancing only when not paused.

Let me code:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Rotating Heptagon — 20 Ball Physics</title>
<style>...</style>
</head>
<body>
<header>
  <h1>...</h1>
  <div class="controls">
    <button id="toggle">Pause</button>
    <button id="reset">Reset</button>
    <label><input type="range" id="speed" min="0" max="2" step="0.1" value="1"> Wall speed ×</label>
    ... maybe skip extra.
  </div>
  <div class="stats">...</div>
</header>
<main><canvas id="sim"></canvas></main>
<script>...</script>
```

Keep the wall speed control at 1 default; but requirement says constant rate one revolution per 5 seconds. A slider might violate "constant rate" if changed... I'll include a slider defaulting to 1.0 and labeled, that's an extra feature; maybe safer to omit or make it just display. Hmm, "Rotate the heptagon at a constant rate of one revolution every five seconds." Adding a control could be seen as deviating. I'll include a toggle for showing trails or the "gravity" only? Simplest: no sliders. Just Pause/Resume and Reset, plus stats. I'll add a checkbox "show vectors"? Not needed. Keep clean: two buttons + stats + hint text.

Now code the JS.

```js
const canvas = document.getElementById('sim');
const ctx = canvas.getContext('2d');
const VW = 920, VH = 640;
function fitCanvas(){ const dpr = Math.min(window.devicePixelRatio||1, 2); canvas.width = VW*dpr; canvas.height=VH*dpr; ctx.setTransform(dpr,0,0,dpr,0,0);}
```

CSS handles display size.

Heptagon:
```js
const CX=VW/2, CY=VH/2+6, R=250;
const OMEGA = 2*Math.PI/5; // rad per second
let theta=0;
function vertices(th){ const v=[]; for(let k=0;k<7;k++){ const a = th - Math.PI/2 + k*2*Math.PI/7; v.push({x:CX+R*Math.cos(a), y:CY+R*Math.sin(a)});} return v;}
```
Edges: from v[k] to v[k+1]. Inward normal: For CCW/CW ordering in canvas coords... vertices in increasing angle a → in canvas coords (y down) that's clockwise visually? Let's just compute: edge direction e = p1-p0; normal candidates n = (e.y, -e.x) normalized or (-e.y, e.x). Pick the one pointing toward the center: dot(n, mid - C) < 0 means n points inward. So compute n = (-e.y, e.x)/|e| then flip if dot(n, C-mid)<0... let's define: n points inward if dot(n, (C - mid)) > 0. Then signed distance for ball at p: d = n·(p - p0). Inside polygon: d>0 for all edges. Ball touches wall when d < r.

Since the polygon is regular and centered, I can precompute normals as -radial direction of edge midpoint. Fine, use generic approach.

Ball array:
```js
function makeBalls(){ balls = []; const order=[0,1,2,3,4]; ... for i in 0..19: row = Math.floor(i/4), col = i%4; x = CX + (col-1.5)*37 + (row%2?18.5:-18.5)... }
```
Hmm staggering: use x = (col - 1.5)*Dx + (row%2 ? Dx/2 : 0). Max extent: col 3 → 1.5*37 + 18.5 = 74. Good.

y = CY - (row - 2)*Dy. Where Dy = 32.

Give each ball a small random initial ω for visible spin (or 0? "Give each ball angular motion" — start with small random spin). Start with ω random in [-3,3] rad/s plus spin generated by friction. Fine.

radii: const RADII = [14,16,17.5]; r = RADII[i%3]... but ensure non-overlap: spacing 37 ≥ 2*17.5=35 ✓ (diagonal spacing = 37 too in triangular lattice with these params... in a triangular lattice with horizontal spacing Dx=37 and row offset Dx/2 and Dy=Dx*0.866=32, the nearest diagonal distance = sqrt((Dx/2)^2 + Dy^2) = sqrt(342+1024)=37. ✓). So min distance between lattice points = 37 > max sum radii 35 ✓. Good.

Mass m = r*r (density 1). I = 0.5*m*r*r.

Physics step:
```js
function step(dt){
 theta = (theta + OMEGA*dt) % (2*Math.PI);
 for each ball: v.y += G*dt; x += vx*dt; y += vy*dt; angle += ω*dt;
 // damping
 resolve collisions: iterate 2 passes over walls, and ball-ball
}
```
Better: substeps loop with 4 substeps, each: integrate + resolve (walls then pairs, 2 iterations).

Cap speed: if |v| > 2200 → scale.

Restitution threshold: if vn > -0.6 (slow) → treat e=0 to rest nicely? Use e_eff = vn < -30 ? e : 0.

Let me write the code now, then test in browser.

Energy stats: compute total kinetic energy, max |v|, contacts.

Rendering: 
- background: dark radial gradient.
- Heptagon: fill with subtle, stroke thick with gradient, plus vertex markers.
- Balls: radial gradient sphere, outline, spoke line, number.
- Also draw center hub? no.

Let me write file.

Also I should add: pause when tab hidden? Use rAF with dt clamp anyway.

Write it.

For text: `ctx.font = 'bold ' + Math.round(r*1.05) + 'px ...'` Use system font stack (no external). Use "ui-sans-serif, system-ui, -apple-system, Segoe UI, Roboto, Helvetica, Arial, sans-serif".

Let me write.

Also add trail toggle? skip.

Code:

```js
'use strict';
const G = 1500;
const REST_BALL = 0.32, REST_WALL = 0.45;
const MU_WALL = 0.45, MU_BALL = 0.28;
const MAXV = 2200;
const SUB = 4, ITER = 2;
```

Physics loop:
```js
let last=performance.now(), acc=0;
function frame(now){
  let dt=(now-last)/1000; last=now;
  if(dt>0.05) dt=0.05;
  if(running){ simulate(dt); }
  draw();
  stats...
  requestAnimationFrame(frame);
}
function simulate(dt){
  const h = dt/SUB;
  for(let s=0;s<SUB;s++){
    theta += OMEGA*h; if(theta>TAU) theta-=TAU;
    geo = computeGeo(theta);
    for(b of balls){
      b.vy += G*h;
      b.vx *= (1-0.12*h); b.vy*=(1-0.12*h); b.w*=(1-0.3*h);
      b.x += b.vx*h; b.y += b.vy*h; b.a += b.w*h;
      cap speed
    }
    for(let it=0; it<ITER; it++){
      for(b of balls) wallCollide(b);
      ballCollide(it===ITER-1);
    }
  }
}
```
Hmm, wallCollide applying restitution multiple times per iteration may double-count impulses. Only apply normal impulse when approaching (vn<0), so after first pass it's separating → second pass only positional correction. That's fine.

Let me write wallCollide with position correction always, impulse only if approaching.

Ball-ball: check all pairs (20 balls → 190 pairs) fine.

Now draw.

Let's write out the whole file.

I'll write it now and test.

Stats: FPS, Ω, "1 rev / 5.00 s", max speed, contacts, KE.

Also add a paused overlay text.

Let me produce the code.

function computeGeo(theta): returns array of {p0,p1,n,inward length}. Also mid.

Implementation:
```js
function computeGeo(th){
  const verts=[];
  for(let k=0;k<7;k++){const a=th-Math.PI/2+k*TAU/7; verts.push([CX+R*Math.cos(a),CY+R*Math.sin(a)]);}
  const edges=[];
  for(let k=0;k<7;k++){
    const p0=verts[k], p1=verts[(k+1)%7];
    let ex=p1[0]-p0[0], ey=p1[1]-p0[1];
    const L=Math.hypot(ex,ey); ex/=L; ey/=L;
    let nx=-ey, ny=ex;
    // ensure pointing inward (toward center)
    const mx=(p0[0]+p1[0])/2-CX, my=(p0[1]+p1[1])/2-CY;
    if(nx*mx+ny*my>0){nx=-nx;ny=-ny;}
    edges.push({p0,p1,nx,ny});
  }
  return {verts,edges};
}
```

wallCollide(b):
```js
let deepest=null, dp=0;
for(const e of geo.edges){
  const d = e.nx*(b.x-e.p0[0]) + e.ny*(b.y-e.p0[1]);
  const pen = b.r - d;
  if(pen > -0.01){ // consider contact with small band
    if(pen>0) handle
  }
}
```
Simpler: loop over edges; if pen > 0 handle immediately (position + impulse). Iterate over all 7 for each ball — handles corners.

```js
function wallCollide(b){
 for(const e of geo.edges){
   const d = e.nx*(b.x-e.p0[0])+e.ny*(b.y-e.p0[1]);
   const pen = b.r - d;
   if(pen>0){
     b.x += e.nx*pen; b.y += e.ny*pen;   // push inward fully (or 0.8)
     const cx = b.x - b.r*e.nx, cy = b.y - b.r*e.ny;
     const wvx = -OMEGA*(cy-CY), wvy = OMEGA*(cx-CX);
     const rcx=-b.r*e.nx, rcy=-b.r*e.ny;
     const vsx = b.vx + (-b.w*rcy), vsy = b.vy + (b.w*rcx);
     let rvx = vsx - wvx, rvy = vsy - wvy;
     const vn = rvx*e.nx + rvy*e.ny;
     if(vn < 0){
       const en = (-b.w... )
       const jn = -(1+effRest(vn))*vn*b.m;
       // tangential
       const tx=-e.ny, ty=e.nx;
       const vt = rvx*tx+rvy*ty;
       const invEff = 1/b.m + (b.r*b.r)/b.I;
       let jt = -vt/invEff;
       const maxF = MU_WALL*Math.abs(jn);
       jt = Math.max(-maxF, Math.min(maxF, jt));
       const Jx = jn*e.nx + jt*tx, Jy = jn*e.ny + jt*ty;
       b.vx += Jx/b.m; b.vy += Jy/b.m;
       b.w += (rcx*Jy - rcy*Jx)/b.I;
       contacts++;
     }
   }
 }
}
```
Note ω×r in 2D: ω is scalar (z-axis), ω × r = (-ω*r_y, ω*r_x). So vs = v + (-w*rcy, w*rcx). ✓. Torque = rc × J = rcx*Jy - rcy*Jx ✓.

Wall velocity: Ω × (p - C) where Ω vector along z: (-Ω*(p.y-C.y), Ω*(p.x-C.x)). And since we increase theta with position (cos, sin) in canvas coords, that's the same convention (positive z rotation appears clockwise visually but consistent math). ✓.

For the number text rotation to visually match spin direction: b.a increases → rotate(b.a) in canvas = clockwise visually. Consistent since positions rotate the same way. ✓

effRest(vn): return Math.abs(vn) < 40 ? REST*0.4 : REST? Use: e = vn > -60 ? REST*(|vn|/60) : REST → smooth. Let me do `const e = REST * Math.min(1, Math.abs(vn)/80)` to kill jitter at low speeds.

Ball-ball:
```js
function ballCollide(){
  for(i...)for(j>i){
    dx=bj.x-bi.x, dy=..., dist=hypot
    const rs=bi.r+bj.r;
    if(dist<rs && dist>1e-6){
      nx=dx/dist, ny=dy/dist;
      const pen=rs-dist;
      const totInv=1/bi.m+1/bj.m;
      bi.x -= nx*pen*(1/bi.m)/totInv*0.9; ... 
      // contact velocities
      rcix=nx*bi.r, rcy=ny*bi.r;  (from i center to contact)
      rcjx=-nx*bj.r, rcjy=-ny*bj.r;
      vsix = bi.vx - bi.w*rciy, vsiy = bi.vy + bi.w*rcix;
      vsjx = bj.vx - bj.w*rcjy, vsjy = bj.vy + bj.w*rcjx;
      rvx = vsjx - vsix, rvy = vsjy - vsiy;
      vn = rvx*nx+rvy*ny;
      if(vn<0){ jn = -(1+e)*vn/totInv; t=(-ny,nx); vt=rvx*tx+rvy*ty; invEff = 1/bi.m + bi.r²/bi.I + 1/bj.m + bj.r²/bj.I; jt=-vt/invEff; clamp MU_BALL*|jn|; J...
        bi.vx -= Jx/bi.m; bi.vy -= Jy/bi.m; bi.w -= (rcix*Jy - rciy*Jx)/bi.I;
        bj.vx += Jx/bj.m; ... bj.w += (rcjx*Jy - rcjy*Jx)/bj.I;
      }
    }
  }
}
```

Draw balls with spin: number + a spoke.

OK, write the file now. Then test.

One thing: initial arrangement "let them fall under gravity" — with zero initial velocity, and near center. Since the container bottom is below, they'll fall and pile. With 20 balls in a rotating bowl they'll be stirred. Good.

Also verify containment: bottom edge is at CY + 225 (approx) = 555, pile of 20 balls r~16: they'd form a layer ~ 20*32/... in the bottom region of width ~2*230... they will fit.

Let me write the HTML file.

Let me run it in the browser and check the console + initial view.

Wait — there's a bug: `drawOverlay` uses `simTime` before declaration? `let simTime` is declared later in the same function scope (module IIFE). Since draw is called after `let simTime = 0` executes (in frame loop started at the bottom via rAF, which happens after the whole script runs), TDZ is fine.

Also `R_RADII[i % R_RADII.length]` cycles 14,16,17.5 — fine.

Let me test.

Initial view looks good: 20 balls in a compact staggered lattice near center, heptagon fully visible, numbers rotated per ball (initial angles differ).

Now let me sample moments: check motion frames and console. Let me take a screenshot after a couple seconds, and inspect state programmatically... The browser tool has no "evaluate" action. I can only screenshot/motion/inspect. Hmm, `inspect` returns DOM text. The stats are in DOM (max |v|, KE, fps) — useful.

Let me do a `motion` capture to see frames over time.

The simulation is working: balls fell, contained, heptagon rotating (angles 342°, 25.2°, 66°, 106.8° advancing at ~72°/s = 1 rev/5s ✓), numbers rotating with balls, no persistent overlaps, energies bounded (KE decreasing 1136k → 854k).

One observation: the balls pile at a corner and appear to be dragged around; they remain contained. Good.

Note: at t=4.75 the wall angle 342° while t=5.35 → 25.2°: consistent (342+0.6*72=385.2 → 25.2 ✓).

Max speed ~394 px/s, bounded. Good.

Let me check a longer run for stability (e.g., 20-30 s) to ensure no tunneling/escape and no runaway. Then test Pause and Reset.

Let me capture motion again after some time (motion captures ~2s). Better: take a screenshot now (time has advanced), then again.

Actually, let's do a couple more motion passes to reach ~20s, then check stats and screenshot.

At t≈14.7s: stable, contained, no tunneling, KE bounded (~750-870k), max speed ~200-280. Balls remain in a pile being stirred by the rotating walls. Numbers clearly rotate with balls.

One thing: the balls mostly settle in the bottom-left corner region and get dragged; the pile doesn't spread much. That's fine physically (rotating polygon bucket). Actually with 1 rev/5s and gravity, balls are carried up by the wall then tumble — visible across frames.

Now test Pause: click the Pause button (at ~x=383,y=31 in the 1200x800 viewport coordinates — the screenshot is 1200x800? The images appear 1200x800). The button center in the image: around (383, 31). Let's click.

Pause works — button label changed to "Resume", PAUSED overlay shown, time frozen at 21.42 s.

Now verify pause actually freezes: take a screenshot after a moment and compare the t value. Let me use `screenshot` twice? The screenshot action returns one image; time should be frozen. Let me do a motion capture (which spans ~1.7s) and check the DOM t value stays 21.42 s.

Actually, simpler: click Reset while paused — it should restore the initial arrangement and orientation (theta=0). Then resume and compare with the initial view.

Let me first do a quick motion to confirm frozen, then reset.

Frozen at t=21.42 s across 1.7s of real time — pause works. (The stats numbers changed slightly because the stat readouts update from ball velocities... wait, they shouldn't change while paused. max|v| went 281 → 335 and KE 651.8k → 718.0k. Hmm, that means velocities changed while paused? No — updateStats is called every frame regardless of running, but if paused, velocities don't change... unless... Ah, actually the earlier "281" reading was from the click frame, and the 335 came from... hmm.

Wait: the click on Pause happened at some point; the stats displayed 281/651.8k right at the click frame. Then motion shows 335/718.0k. That suggests velocities changed between the click and the motion call — meaning the sim was still running for a bit? No, once paused, simulate() isn't called.

Unless the click's DOM snapshot was taken before the pause actually applied... Actually the click frame's DOM readout could have been captured at the moment right after the click event but before/at the same frame; the values 281/651.8k correspond to the last updateStats before pausing. Then... after pause, updateStats still runs and would recompute the same values (statAcc accumulates and updates every 0.2s, recomputing from unchanged velocities → same values). So it should stay 281.

Hmm, unless the pause happened and then between the click and motion, the velocities changed. That can't be if running=false.

Wait — maybe the click at (383,31) didn't hit the button on the first attempt... no, the label changed to "Resume", so it did.

Alternative explanation: the stats differ because the DOM snapshot in the click result was taken mid-frame, and one more simulate() step happened after? Actually the order in frame(): simulate → draw → updateStats. If the click handler fired between frames, the displayed stats were from the last frame before pausing. Then after pausing, updateStats runs again with statAcc accumulating; it recomputes from the same velocities → identical. So 281 → 335 is inconsistent.

Unless... `updateStats` is called with dt even when paused, and statAcc reaches 0.2 → recompute. Same values. Hmm.

OH WAIT. I see: the ball velocities are unchanged but `Math.hypot` etc — same. So something else changed. Let me think about whether simulate could still run: `if (running){ simulate(dt); simTime += dt; }`. simTime stayed at 21.42 → so no simulate ran (t frozen). So velocities frozen. So max|v| should be frozen too.

Unless the click DOM snapshot was taken before the last few frames... The click result image shows t = 21.42 s already, with max|v| 281. Then motion shows t = 21.42 with 335. Contradiction unless the stats element update happened at a different time than the canvas overlay draw. Both happen in the same frame though.

Hmm, actually maybe: the click's screenshot was taken at frame N where the canvas had already frozen (paused at 21.42), but the DOM stats text still showed the *previous* frame's values (281/651.8k) — no wait, stats update only every 0.2s, so the displayed value could lag up to 0.2s behind. But if frozen, the last computed value... Let's trace: at frame N-1 (still running), stats updated to 281/651.8k. Then pause. Then in subsequent frames, stats recompute from the frozen velocities → should give the same 281/651.8k, not 335/718k.

Unless the pause click happened, and then the browser tool's click caused a re-render... hmm, or unless the "click" result image was captured at a moment where the canvas had t=21.42 but stats showed values from an earlier update (which is exactly the last computed). Then the frozen recompute should be identical.

Wait — is it possible that requestAnimationFrame's `now` timestamps and the stat values differ because of the `fps` smoothing? No, that's fps only.

Hmm, one real possibility: `updateStats` reads `balls` — the array is replaced on reset, but no reset happened.

Actually! I bet the difference: between the click snapshot and the motion snapshot, more frames ran, and the *first* stats update after pausing recomputed with statAcc crossing 0.2 — but the values should be identical since velocities are frozen... unless the previous display was stale from before the last simulation step. Yes! That's it: stats update only every 0.2 s (≈12 frames). So at the moment of pausing, the DOM showed values computed up to 0.2 s earlier (281/651.8k). The first post-pause recompute reflects the true final velocities (335/718k). That's consistent and harmless. Good — no bug.

Now test Reset while paused, then compare with initial view.

Reset restored: t=0.00s, heptagon 0.0° (vertex up, same as initial), balls in the identical compact staggered lattice with the same numbers in the same slots and same initial rotations. The DOM stats lag (335/718k) but will update to 0/9.1k (shown in the DOM readout: max|v| 0, KE 9.1k — that's from the rotational energy of initial spins).

Now resume and check it runs again from the reset state.

Resume works — running again from t=0.03s, identical arrangement to the initial view (matches the first screenshot). 

Let me do a final longer motion pass to confirm the fall/collisions again from the fresh reset and check nothing weird (e.g., balls escaping or overlapping). Also I want to verify contact bounce response more explicitly — the earlier frames showed balls piling and being stirred, which requires collision response. Good enough, but let me do one more motion pass at ~2-4 s and one at longer time to check stability.

Also check console for errors: only the sandbox iframe warning, no JS errors. Good.

Let me do a final motion pass.

Everything is stable and behaving. Balls remain contained, no persistent overlaps, numbers rotate with balls, wall rotates at 72°/s (verified: 236.4 → 277.2 → 318.0 → 358.8, i.e. +40.8° per 0.568s ≈ 71.8°/s ✓).

The file is saved at /tmp/job-HK0a2a/index.html. Let me quickly verify file exists and no external resources referenced.

No external resources. Self-contained single file. Done.

Let me leave the sim running (it is). Final report.