Gravity Sandbox Demo Creation

The task is "Wake up and do as you please." The previous execution created a Fluid Dynamics Playground demo. My purpose is to create cool Three.js demos in /space/demos/. So I should create a new advanced demo and update the index.

Let me first check the current state of the demos folder. I need to install shell tools first.

Let me check the current state of the demos folder.

The demos folder has 4 demos. The task is "Wake up and do as you please." So I should create a new cool Three.js demo. Let me think about what to build next.

Existing demos:

1. Spinning cube (basic)
2. Nebula galaxy (particles)
3. Mandelbulb explorer (ray marching)
4. Fluid dynamics (GPU Navier-Stokes)

Ideas for the next demo:

• 005: Terrain/landscape with procedural generation + water shader
• Audio visualizer (needs mic/audio — could do procedural audio)
• Asteroids game 3D
• Orbital simulator
• Snake 3D
• Volumetric clouds ray marching
• Reaction-diffusion (Gray-Scott) GPU simulation — would be cool but similar to fluid dynamics in approach
• Particle life (artificial life with thousands of particles and attraction/repulsion rules) — very cool, mesmerizing
• Fractal trees / L-systems
• Curl noise flow field particles
• Solar system / gravity simulator (n-body) — interactive: spawn planets, watch orbits, collisions. That would be a fun interactive "orbital sandbox."
• Wave interference / ripple tank
• Boids flocking (GPU flocking) — impressive
• Portal/impossible geometry
• City procedural generation with day/night
• Water caustics / ocean shader (Gerstner waves) with an island and sky — "Ocean shader" demo with Gerstner waves, foam, sun reflection — very visually impressive
• Cloth simulation with wind
• Morphing blob metaballs ray marching
• Tesseract / 4D rotation projection

A good pick that's distinct from previous ones: a playable mini-game would be nice — "Asteroids 3D" or an orbital gravity sandbox. Let me go with something visually striking and interactive: "Gravity Sandbox / Orbital Simulator" — an n-body gravity simulation where you can spawn planets with velocities, watch orbits form, collisions merge bodies with glow effects, trails, bloom. Features:

• Click-drag to spawn a body with velocity (drag direction)
• Slider for mass/radius, time scale
• Presets: solar system, binary stars, figure-8 three-body, random disk, black hole + disk
• Trails using line rendering or a trail texture
• Real physics (Newtonian gravity, softened), RK or semi-implicit Euler integrator
• Bloom post-processing, star background, bloom on glowing bodies
• Camera orbit controls
• HUD with body count, FPS, energy

Alternatively, "Particle Life" — thousands of particles of different colors with attraction/repulsion matrix, producing emergent organism-like behaviors. Very mesmerizing, simple to implement on CPU or GPU. With bloom it looks gorgeous. Controls: randomize rules, particle count, friction, force radius. That's a strong "wow" demo too.

Or "Volumetric Clouds" ray marched — impressive but heavy.

Or an "Audio Visualizer" with Web Audio API + procedural music — audio-reactive particles/shaders. Cool but audio autoplay issues.

Or a "3D Snake" game on a sphere or cube — playable, fun.

I think the gravity sandbox is a great pick: it's an "orbital simulator" explicitly listed in the examples ("playable mini-games (asteroids, snake 3D, orbital simulators)"). Let me build 005-gravity-sandbox: a 2D n-body simulation rendered in 3D space with glowing bodies, trails, bloom.

Key features:

• Physics: N-body gravity with softening, leapfrog/velocity Verlet integration, adaptive time step. Bodies merge on collision (conserving momentum, mass, volume-based radius).
• Rendering: THREE.Points or instanced meshes for bodies with emissive colors based on mass/temperature; trails rendered as fading line strips (per body, a ring buffer of positions rendered as THREE.Line with vertex colors fading). Actually for many bodies, trails via a single LineSegments with history is complex; simpler: keep a trail of last N positions per body and render each as a line strip with gradient alpha. If bodies merge, trails merge.
• Alternative: render trails into a ping-pong "accumulation" texture — draw body positions as points into a fading framebuffer each frame, then composite. That's elegant: a "phosphor" trail effect. Implementation: an offscreen scene with points rendered with additive blending into a render target that fades each frame (multiply by 0.97). Then sample that texture in a fullscreen quad behind the main render... But compositing with the 3D scene + bloom: simpler to render the trail texture as a fullscreen background quad in the scene, aligned to the simulation plane (the simulation is 2D in the XZ plane). Since the sim is 2D on a plane, I can put a large plane mesh on the simulation plane with the trail texture — additive blending, texture from render target. That works beautifully: trails appear on the plane itself, camera can orbit in 3D, trails get bloom too.

Trail texture approach:

• trailRT: WebGLRenderTarget (1024 or 2048) with a dedicated ortho scene covering the sim plane bounds (world units → uv).
• Each frame: render a fade quad (fullscreen, color black with alpha = fade amount, or multiply blend). Standard trick: render a fullscreen quad with blending that multiplies by decay factor: use blending: CustomBlending, blendSrc ZeroFactor, blendDst ConstantColor? Simpler: draw fullscreen quad with material.opacity = 1 - decay, transparent, black color, normal blending — this darkens toward black but leaves alpha issues. Common approach: fadeMaterial with blending: THREE.CustomBlending, blendEquation: AddEquation, blendSrc: ZeroFactor, blendDst: SrcColorFactor with color = decay — multiply whole target by decay color. That works: gl.blendFunc(gl.ZERO, gl.SRC_COLOR) with fragment color vec4(decay).
• Then render points (bodies as small glowing points, additive) into the RT.
• Main scene: plane (size matching sim bounds) with MeshBasicMaterial({ map: trailRT.texture, blending: AdditiveBlending, transparent: true, depthWrite: false }).

Bodies: since counts can vary (say up to ~300), use individual meshes? InstancedMesh with a sphere geometry and instance colors, update matrices each frame — clean. Plus a glow sprite per body? With bloom, small bright spheres will glow nicely. Add a subtle point light at the "star" for presets? Lighting not critical; use MeshBasicMaterial with color scaled >1 for HDR bloom? With UnrealBloomPass, bright colors (>1) bloom. InstancedMesh with MeshBasicMaterial and setColorAt with HDR values (e.g., 2-4x) — instanced colors work with basic material.

Interactions:

• Click-drag on plane: spawn body at press point, velocity proportional to drag vector (released position - press position scaled). Show an aim line while dragging.
• Mass controlled by scroll wheel while dragging or a slider.
• Presets:
  • "Solar System": central heavy star + a few planets at circular orbit velocities.
  • "Binary + Disk": two orbiting stars + debris disk.
  • "Figure-8": classic three-body periodic solution.
  • "Black Hole + Disk": very heavy center + ring of many small bodies.
  • "Random Cluster": random blob of bodies → watch it violently relax.
• Time scale slider, G slider, softening, trails length (decay), pause, clear, follow center of mass toggle maybe.
• Collision: if distance < r1 + r2 → merge into one (momentum conservation). Also "black hole mode" where heavy body absorbs without merging? Keep merging simple.
• HUD: body count, FPS, sim time, total mass.
• Controls hint overlay.

Performance: N-body O(n²) on CPU is fine for ≤ ~500 bodies. The "Black hole + disk" preset with 300 bodies = 45k pairs per step, multiple substeps — fine.

Integration: velocity Verlet with fixed dt * timeScale, maybe 2 substeps. Softening epsilon to avoid singularities.

Camera: PerspectiveCamera + OrbitControls, looking at plane; sim plane is XZ (y=0). Spawn via raycast onto plane.

UI: control panel (top-right, collapsible) with sliders: time scale, gravity G, softening, trail persistence, spawn mass, bloom strength; preset buttons; pause/clear. Keyboard: space pause, C clear, 1-5 presets.

Also add starfield background (points sphere) for depth. Vignette via CSS overlay. Bloom via EffectComposer with UnrealBloomPass + OutputPass.

Structure: single self-contained index.html, import map for three@0.160+ (use 0.165 or whatever the previous demos used — check 004 for consistency of CDN URLs). Let me look at 004's index.html to copy the CDN/import-map pattern.

Then update /space/demos/index.html adding the new card at top.

Then validate: node --check on extracted JS, GLSL validation (this demo may not need custom GLSL except maybe simple shaders for points — I can avoid custom shaders entirely by using built-in materials, which reduces risk; trails via RT trick, bodies via InstancedMesh, stars via Points with built-in PointsMaterial... but star twinkle could use a tiny shader. Keep custom shaders minimal but I can add one for the trail points to get round soft points — PointsMaterial with map generated via canvas is fine without GLSL).

Actually, let me add one small custom ShaderMaterial for background stars (twinkle) — adds GLSL validation need but it's small. Or skip custom GLSL entirely for robustness. Hmm, the guidelines encourage custom GLSL, but the previous demos already showcase shaders heavily. For this one, physics + interaction is the star. I'll include one modest custom shader: soft glowing points for trail rendering could just use additive blending with built-in points material. I could give bodies a fresnel glow via a custom shader... Let's include a nice one: bodies rendered as spheres with a custom emissive shader (fresnel rim + hot core) — that's tasteful GLSL. Or simpler: MeshBasicMaterial + bloom does fine.

Let me decide: include custom shaders where they add value:

1. Star background: PointsMaterial with size attenuation off... twinkle needs shader. I'll write a small ShaderMaterial for twinkling stars. Fine.
2. Bodies: ShaderMaterial on InstancedMesh — instancing with custom shader requires instanceMatrix handling; doable: #include <begin_vertex> style manual handling. Simpler: use MeshBasicMaterial with vertexColors? InstancedMesh color via instanceColor works with MeshBasicMaterial automatically. HDR bloom: values >1 in setColorAt — works since colors are floats.

So plan: minimal GLSL (stars twinkle shader + trail fade uses built-in materials with custom blending + trail points built-in PointsMaterial additive). Good balance, less risk.

Wait — trail rendering with built-in PointsMaterial into RT: points need positions updated each frame — a small BufferGeometry with positions = body positions mapped into the trail ortho scene. Since trail scene is orthographic over sim bounds, I can literally use the same world XZ coords with a top-down ortho camera. Point size: fixed pixels, maybe scaled by mass via... PointsMaterial has single size; per-point size needs shader. Alternative: use multiple Points objects with different sizes (e.g., 3 tiers), or one shader... Or simply fixed size ~2-4px — trails look like comet streaks, nice. Keep fixed size with additive blending; color per point via vertexColors (body color, slightly dimmer).

Camera moves don't matter for the trail RT since it's ortho top-down of the plane — when the main camera orbits, the plane-mapped texture shows trails correctly in perspective.

Edge case: if camera goes below plane, plane is single-sided — set side: DoubleSide.

Bounds: sim area ~ [-400, 400] in X/Z. RT 2048 for crispness (or match to plane resolution). Fade decay configurable via "trail persistence" slider mapping decay 0.90–0.995.

Merging bodies: when two bodies collide, merge into heavier index. Trails continuity — trails are drawn from current positions, so merging just works.

Aim line while dragging: THREE.Line with two points + small arrowhead maybe; update on pointermove.

Spawn velocity: from drag: v = (start - current) * scale or slingshot style: drag from spawn point outward, velocity along drag vector (like Angry Birds inverse). I'll do: press = position; drag vector d = current - start; release → velocity = d * velScale (so you drag in the direction you want it to fly). Show preview circle orbit? Too complex — show velocity vector arrow.

Mass of spawned body: slider + wheel adjusts.

Auto-orbit helper: button "circularize"? skip.

Presets detail (units: G default 1, masses in arbitrary units, distances in world units):

• Solar: center mass 1000 at rest; planets at r=80..300 with v = sqrt(G*M/r) tangential. ~8 planets with varied masses (1–20) and colors.
• Binary: two stars mass 600 each, separation 160, circular orbit around COM; plus ~120 small debris particles in a disk around both with roughly circular velocities around COM.
• Figure-8: three equal masses on the classic periodic orbit (known initial conditions, scaled).
• Black hole disk: center 5000; 250 small bodies in annulus 120–320 with circular velocities + noise.
• Cluster: 120 bodies random in sphere radius 200, small random velocities → violent relaxation fun.

Colors: color by mass: small = icy blue/white, medium = yellow/orange, heavy = red/white-hot; star presets get warm colors. Use function massToColor.

HUD: FPS (EMA), bodies count, sim time, total mass. Panel + hint overlay + title.

Audio: skip (keep scope tight, quality high).

Resize handling, DPR clamp. Pause when tab hidden (rAF handles).

Code size: maybe ~700-900 lines. Fine.

Let me check 004's import map to mirror CDN versions. Then write the new demo at /space/demos/005-gravity-sandbox/index.html. Note /space is s3fs and may be slow — write in one operation.

Validation: extract JS and run node --check; check DOM ids; fetch CDN URLs to verify reachability. Maybe run a headless render? Previous run said WebGL headless not possible in sandbox. I'll do static checks + maybe a tiny node-based physics smoke test by extracting the physics section? Could do: create a small node script that copies the stepPhysics function logic... but simpler: write physics in a way I can unit-test by copy. I can do a quick standalone node test replicating integrator to sanity check orbital velocity formula (v=sqrt(G*M/r)) — not strictly necessary but nice: verify figure-8 stays bounded etc. Keep light: syntax check + id cross-check + CDN check, plus a physics sanity test replicated in node.

Let me look at 004 quickly for the import map and style conventions.

Good. I'll create demo 005: "Gravity Sandbox" — an interactive n-body orbital simulator. Using three@0.160.0 from jsdelivr for consistency.

Let me write the full demo file now. I'll write it to /space/demos/005-gravity-sandbox/index.html in one write operation (s3fs may be slow, single big write is better).

Let me carefully design the code:

Main script structure:

Imports: THREE, OrbitControls, EffectComposer, RenderPass, UnrealBloomPass, OutputPass.

Constants:

• WORLD = 500 (sim half-extent on XZ plane: [-500,500])
• TRAIL_RES = 2048

State:

• bodies: array of { pos: Vector2-ish (use plain {x,z}), vel {x,z}, mass, radius, color: THREE.Color, alive } Use typed structure with plain objects; n ≤ ~600.
• params: { G: 40? timeScale: 1, softening: 2, trailDecay via persistence, bloom, spawnMass, merge: true, paused: false }

Units: Let me pick G = 1000? Let's think: star mass 1000, orbit radius 100 → v = sqrt(GM/r). If G=10: v = sqrt(101000/100)=sqrt(100)=10 units/s. World 500 across → crossing in 50s at v=10 — slow-ish but ok with timeScale up to 4x. Let's set default G=10, default timeScale=1, slider up to 5. Substeps: 2, dt per substep = min(frameDt, 0.05)/substeps * timeScale. Hmm, for accuracy use velocity Verlet with dt ~ 0.008–0.03. I'll implement fixed-step accumulator: SIM_DT = 0.008 (120 Hz), steps = timeScale * frameDt / SIM_DT capped (e.g., max 40 steps/frame). Simpler: each frame, nSteps = clamp(round(frameDt * timeScale / SIM_DT), 1, 48); do nSteps of velocity Verlet with SIM_DT. That keeps stability when timeScale up to 5 at 60fps: 5*0.0167/0.008 ≈ 10.4 steps — fine. 600 bodies → 600²/2=180k pairs × 10 steps = 1.8M pair evals per frame — might be heavy in JS (~50-100M ops). Limit total bodies to ~400 and pairs with i<j loop: 400²/2 = 80k × 10 = 800k evals/frame — ok (~10-20ms maybe). Cap bodies at 400. Also use typed arrays (Float32Array) for pos/vel/acc/mass for speed. Let me use structure-of-arrays: px, pz, vx, vz, ax, az, m, r, alive flags as Uint8Array, colors separate array of THREE.Color for rendering.

Physics step (velocity Verlet):

1. compute accelerations (O(n²) with softening: a_i += Gm_j(dx)*(distSq+eps)^-3/2)
2. x += vdt + 0.5a*dt²
3. recompute accelerations at new positions
4. v += 0.5*(a_old+a_new)*dt

That's 2 force evals per step → 1.6M for 400 bodies ×10 steps — too heavy. Use semi-implicit Euler (symplectic Euler): compute a once, v += adt, x += vdt. Energy behavior decent with small dt and softening. 800k pair evals per frame — acceptable. I'll use symplectic Euler, SIM_DT=0.01, substeps scaled. Good enough for a sandbox toy.

Optimization: skip dead bodies; use squared loops with early cutoff? Keep simple, cap MAX_BODIES = 420.

Collisions: during pair loop, if dist < r_i + r_j → mark merge. Process merges after: heavier absorbs lighter: p = (p1 m1 + p2 m2)/M, v = momentum, mass M, radius = (r1³ + r2³)^(1/3). If merge disabled, do elastic bounce? Just skip collision handling (pass through). Simple.

Rendering bodies: InstancedMesh with SphereGeometry(1, 24, 16) scaled by radius. MeshBasicMaterial with instanceColor HDR (color * intensity, intensity 1.5–3 for bloom). Update matrices per frame: dummy Object3D. Also a per-body "glow sprite"? Bloom handles glow.

Trails:

• trailScene: ortho camera top-down covering [-WORLD, WORLD] x [-WORLD, WORLD] (XZ). Actually ortho camera looking down -Y with left=-WORLD, right=WORLD, top=WORLD, bottom=-WORLD. Objects: Points with BufferGeometry MAX_BODIES positions (x, 0, z world coords → in ortho cam space they map correctly), PointsMaterial({ size: 3, sizeAttenuation: false, vertexColors: true, blending: AdditiveBlending, transparent: true, depthTest: false }).
• Fade: fullscreen quad in trailScene rendered each frame with custom-blend multiply: ShaderMaterial? Can do with MeshBasicMaterial + custom blending: blending=CustomBlending, blendSrc=ZeroFactor, blendDst=SrcColorFactor, color set to (decay,decay,decay). MeshBasicMaterial color multiplies texture-less output → fragment = decay color; with ZERO/SRC_COLOR blend → dst * decay. Yes that works without GLSL. Plane geometry 2*WORLD square at y=0 in trail scene rendered first each frame... wait ordering: render fade quad first (it multiplies existing content), then points additively. Use renderOrder and material.depthTest false, autoClear false. Also need camera at y=100 looking down; quad as plane rotated -90° about X covering world.
• trailRT = WebGLRenderTarget(TRAIL_RES, TRAIL_RES, { type: HalfFloatType? } — additive accumulation of HDR colors benefits from float; use HalfFloatType for quality, fallback fine). No depth needed: depthBuffer: false.
• Main scene plane: PlaneGeometry(2*WORLD) rotated flat at y = -0.5 (slightly below bodies), MeshBasicMaterial({ map: trailRT.texture, transparent: true, blending: AdditiveBlending, depthWrite: false, side: DoubleSide }). With HDR texture values >1 → blooms.

Also initial clear of RT to black: renderer.setRenderTarget(trailRT); renderer.setClearColor(0x000000, 1); renderer.clear().

Trail persistence slider → decay = 0.90..0.998. Render trail pass every frame (before main render) — fade runs every frame; at low fps trails fade faster in wall-clock... acceptable, or accumulate fade: decay^steps. Fine, use per-frame decay adjusted by dt: effectiveDecay = Math.pow(decayBase, frameDt*60).

Stars background: ShaderMaterial points on a big sphere (radius 4000, camera far 8000), twinkle: size/brightness varying with time via uniform. Small GLSL — I'll include and validate with glsl parser.

vertex:

fragment:

Additive blending, depthWrite false. gl_PointSize fixed (no attenuation since far sphere) — size in pixels 1–4. Add slight color variation attribute? Keep uniform tint + variation via phase in vertex → varying. Good enough.

Spawning interaction:

• Raycaster on pointerdown (left button, not on panel): intersect y=0 plane (mathematical Plane, no mesh needed). If hit within WORLD bounds → begin drag: record start point. Create aimLine (THREE.Line with 2 points, dashed? simple LineBasicMaterial vertexColors gradient), plus a preview sphere at start (small glowing sphere mesh reused).
• pointermove: update end point; aim line from start to end; velocity preview = (end - start) * VEL_SCALE. VEL_SCALE = 0.25? If world is 1000 wide and orbit velocities ~10-30, a 100-unit drag → 25 u/s. Use VEL_SCALE=0.25, also allow Shift for 3x? Keep simple: 0.28.
• pointerup: spawn body with mass=spawnMass slider, velocity = drag*scale, color from mass. Hide aim line.
• Wheel while dragging adjusts spawnMass live (also wheel normally zooms via OrbitControls — disable controls while dragging: controls.enabled=false during drag).
• Right-click drag = OrbitControls rotate (set controls.mouseButtons: LEFT: PAN? Actually default LEFT rotate; since left-drag spawns bodies, set controls.mouseButtons = { LEFT: null?, MIDDLE: DOLLY, RIGHT: ROTATE } and touch: one-finger = spawn? Mobile: one finger drag spawns, two-finger orbits (OrbitControls handles two-finger). Set controls.mouseButtons.LEFT = THREE.MOUSE.PAN? Hmm — pan also conflicts. Let me set LEFT to ROTATE only when not starting on plane? Complex. Simpler UX: LEFT drag = spawn body; RIGHT drag = rotate; MIDDLE/wheel = zoom; and enable pan with SHIFT+LEFT? OrbitControls supports keys. I'll set: controls.mouseButtons = { LEFT: THREE.MOUSE.ROTATE? } no... Decision: LEFT = spawn (custom), RIGHT = rotate, wheel = zoom, touch: 1-finger spawn, 2-finger rotate/zoom. Set controls.mouseButtons = { LEFT: -1 (none), MIDDLE: THREE.MOUSE.DOLLY, RIGHT: THREE.MOUSE.ROTATE }. Setting LEFT to undefined/null — OrbitControls checks switch ( mouseButtons.LEFT ) etc. in onMouseDown based on event.button mapping to mouseButtons value; if -1, no action. Actually code: const mouseAction = ... this.mouseButtons.LEFT then switch; default: state = NONE. Passing -1 or null works (falls to default → NONE). I'll set LEFT: null? The docs: setting to null disables. I'll set LEFT: THREE.MOUSE.PAN? That pans on left-drag... conflicts with spawn. Just null it. Also hint text explains: "Left-drag: launch a body · Right-drag: orbit · Scroll: zoom".

Presets (functions returning body arrays):

1. Solar System: star M=2000 r=14 color warm white; 8 planets: r_i from 60..330, mass 1..30 (log spaced), v=sqrt(G*M_star/r)*rand(0.98..1.02) tangential; colors by mass.
2. Binary Stars + Disk: two M=900 at ±70 on x-axis, velocities ∓v with v=sqrt(GM/(2sep))? For equal masses separation d=140: each orbits COM radius 70, v = sqrt(G * M / (2d))? For equal binary: v = sqrt(GM_other / (2r_com))... formula: v = sqrt(GM/(4r_com)) where M each, r_com=70 → relative speed... Let me just compute: force F=G M²/d², centripetal M v²/r_com → v² = G M r_com/d² = GM70/140² = GM/280. So v = sqrt(GM/280). I'll compute v = sqrt(GMd)/(2d)? Fine — I'll implement helper binaryVelocity(G, mEach, separation) = sqrt(GmEach/(2separation))... let me redo: v² = GMr_com/d², r_com=d/2 → v² = GM/(2d) → v = sqrt(GM/(2d)). d=140, M=900, G=10 → v = sqrt(10900/280)=sqrt(32.1)=5.67. OK. Plus 140 debris: radius 200..420 around COM, v = sqrt(G(2M)/r) circular with noise 4%, colors icy.
3. Figure-8 Three-Body: classic: masses equal m; positions (-1,0), (1,0), (0,0); velocities: v3 = -2 v1 = -2 v2; with v1 = (0.3471168881, 0.5327289454) for G=1,m=1,scale=1. Scale to world: scale factor s=110, G=10, m=350 → to preserve dynamics: for G' = G, scale positions by s, velocities scale by sqrt(Gm/s)... For the figure-8 solution: with G=m=1, period ~6.32. Under transformation x→s x, t→? Kepler-like scaling: v' = v * sqrt(G' m' / (G m s))? For similar solution: v scales as sqrt(G m / s). So v' = v * sqrt(Gm/s). G=10, m=350, s=110 → sqrt(10350/110)=sqrt(31.8)=5.64. v1=(0.347, 0.533)5.64 ≈ (1.96, 3.01). Positions (±110, 0). Body3 at origin with v3 = -2v1... wait classic: v1 = v2 = (0.3471168881, 0.5327289454) at (-0.97000436, 0.24308753) and (0.97000436, -0.24308753); body3 at origin with v3 = -2v1. Yes that's the Moore/Montgomery-Chenciner figure-8. I'll use those exact numbers scaled. Masses equal 350 → radius ~5.9. Nice demo of emergent periodicity; note in hint "watch the figure-8!".
4. Black Hole + Accretion Disk: center M=6000, r=10, color bright blue-white (or black with glow? make it white-hot). 240 particles mass 0.5, radius annulus 90..380, v circular around center * (1±3%), small z... all in plane. Colors gradient by radius (blue inner hot? inner hotter → white/blue inner, orange outer). Also give tiny tangential bias for spiral-in? Keep circular + noise.
5. Random Cluster: 140 bodies mass 2..12 within radius 220 gaussian, velocities random small ±3, colors by mass. Watch it collapse & slingshot.

Also "Comet Storm"? Enough with 5.

Clear button empties; also clears trail RT.

Mass → radius: r = cbrt(mass) * R_SCALE (R_SCALE ~1.6): m=1→1.6, m=30→4.9, m=350→11.3, m=2000→20. Hmm star r=20 vs world 1000 ok. Black hole M=6000 → r=29 too big; cap visual radius: r = 1.6cbrt(m) min(1, ...)? Use r = 1.5 * Math.cbrt(m) capped at 18 for visuals, collision uses same r. For black hole cap at 14. OK: radius = Math.min(18, 1.5*Math.cbrt(m)).

massToColor(m): t = clamp(log10(m)/log10(6000),0,1)? Colors: tiny (m<2) ice blue #9fd8ff; small (2-15) #ffd9a0 tan; medium (15-80) #ffb15e orange; large (80-500) #ff7a5c red-orange; huge (500+) white-gold #fff3d6; black hole special electric blue-white #cfe8ff. Intensity multiplier for HDR: 1.2 + t*2.5 → bloom on heavy. I'll implement a gradient via THREE.Color lerp across stops.

Panel controls:

• Preset buttons (5) in a grid.
• Sliders: Time scale (0.1–5, default 1), Gravity G (0–30, default 10), Softening (0.5–10, default 2), Trail persistence (0.9–0.998, default 0.97 — display as %), Spawn mass (0.5–200, log, default 8), Bloom (0–2.5, default 1.1).
• Toggles: "Collisions merge" checkbox (default on).
• Buttons: Pause/Resume (Space), Clear (C), Screenshot? skip.
• Shortcuts list text.

HUD stats: FPS, body count, sim time (s), total mass. Update every 250ms.

Toast on preset load ("Binary Stars loaded").

Camera: pos (0, 420, 560), fov 55, near 0.1 far 12000. OrbitControls target (0,0,0), damping, maxDistance 4000, minDistance 30.

Composer: RenderPass + UnrealBloomPass(strength 1.1, radius 0.55, threshold 0.55) + OutputPass. Threshold 0.55 with HDR bodies >1 blooms bodies & trails (trail colors ~0.5-1.5 additive accumulate bright). Background stars ~0.5 brightness — mostly below threshold, subtle bloom fine.

Vignette: CSS radial-gradient overlay, pointer-events none. Also subtle grid on plane? A faint GridHelper (size 2*WORLD, 20 div, colors #1c2440 / #10142a) adds spatial reference — nice. GridHelper lies in XZ plane already. Opacity transparent 0.35. It might z-fight with trail plane at y=-0.5: put grid at y=-1, trail plane at y=-0.5, bodies y=0. Grid is lines, no z-fight issue with transparent plane (depthWrite false anyway).

Sim bounds: don't kill bodies that fly far; but if |x|>4000 or |z|>4000 → mark dead (escaped) to save perf. Trail RT only covers world — fine.

Edge cases:

• Merging loop: after force loop, handle collisions found: use union by keeping list of (i,j) merge pairs, process sequentially skipping dead. Simple approach: during pair loop if overlap, mark j dead into i directly (i heavier). Since we iterate i<j and update masses inline, subsequent pairs with j skip (dead). Momentum conservation still fine. Slight order dependence acceptable. But merging mid-force-loop changes accelerations slightly — negligible for a toy. Simpler and fast. I'll do inline merge when params.merge else optionally bounce: skip.
• When bodies die by escape or merge, compact arrays periodically (every frame after physics: rebuild alive list, or keep count and swap-remove). I'll use swap-remove with count variable; rendering iterates 0..count.
• Colors stored as Float32Array r,g,b per body (HDR values) for instanced color and trail vertex color (trail uses dimmed color *0.55).
• Trail points geometry: positions Float32Array(MAX3), colors Float32Array(MAX3); each frame copy alive bodies; setDrawRange(0, count); needsUpdate.

Spawning during pause: allow, body added, static until resume.

Aim preview: line + predicted velocity arrow: Line with 2 points (start, end) colored cyan→magenta gradient via vertexColors; plus small sphere marker at start. Also text? skip.

Panel show/hide toggle button (gear) — matches demo 004 pattern.

Hint auto-hides after 6s or on first spawn.

Toast helper.

Resize: renderer.setSize, camera aspect, composer.setSize, bloom resolution auto.

DPR: renderer.setPixelRatio(Math.min(devicePixelRatio, 2)).

FPS meter: EMA over frames.

Now about trail decay per-frame with dt: eff = Math.pow(persistence, frameDt*60) — at 60fps eff = persistence. persistence slider 0.90 (short) to 0.995 (long). Default 0.975.

One more nicety: "follow biggest body" toggle? Skip — scope is already large.

Screenshot button (key P): renderer.domElement.toBlob after render with preserveDrawingBuffer? With composer, need render then toDataURL in same frame — do: on keypress, set flag; in loop after composer.render(), if flag → canvas.toBlob → download link. preserveDrawingBuffer false but same-task capture works. Add it — nice touch, low risk.

Now, GLSL: only the star shader. I'll validate with @shaderfrog parser like previous run (need to npm-install it in /tmp). Also validate JS with node --check by extracting module script (imports of 'three' — node --check just parses, fine).

DOM ids: hud, hint, toast, panel, panelToggle, stats spans: fpsVal, bodyVal, timeVal, massVal; sliders: timeScale, gravity, softening, trail, spawnMass, bloom + their value labels (timeScaleVal etc.); checkbox merge; buttons: preset-solar, preset-binary, preset-eight, preset-disk, preset-cluster, pauseBtn, clearBtn; app container; vignette.

Let me now also double check OrbitControls mouseButtons: controls.mouseButtons = { LEFT: null, MIDDLE: THREE.MOUSE.DOLLY, RIGHT: THREE.MOUSE.ROTATE } — in r160 OrbitControls onPointerDown → onMouseDown uses this.mouseButtons.LEFT etc.; switch(mouseAction) with cases MOUSE.DOLLY/ROTATE/PAN, default → STATE.NONE. null → NONE. Good. Touch: controls.touches = { ONE: null?, TWO: THREE.TOUCH.DOLLY_ROTATE } — switch default NONE for ONE... Actually default for ONE is TOUCH.ROTATE; set ONE: null → NONE. Hmm in r160: switch ( this.touches.ONE ) cases TOUCH.ROTATE / TOUCH.PAN, default NONE. null → default → NONE.

But wait: with LEFT null, our pointerdown handler manages spawn; must also call controls' stuff? No — just don't interfere: our handler checks event.button === 0 and target is canvas. Also prevent OrbitControls context menu: controls listen to 'contextmenu' on domElement and preventDefault by default (this.domElement.addEventListener('contextmenu', onContextMenu)). Yes OrbitControls prevents context menu. Good.

Mobile: pointer events unify. touch-action none on body (already). Two-finger → OrbitControls handles pointer events with pointer capture... Potential conflict: our pointerdown starts a spawn drag on first finger; second finger triggers controls rotate/dolly. Acceptable: if a second pointer goes down, cancel spawn (hide aim) — implement activePointerId; if another pointerdown while active → cancel spawn and re-enable controls? Controls got disabled at first pointerdown... Managing this cleanly: on first pointerdown (primary, button 0): disable controls, begin spawn. If pointerdown with different pointerId (secondary): cancel spawn, enable controls so it can two-finger. Our handler runs alongside OrbitControls' own handlers; OrbitControls tracks pointers itself and would have ignored the first (LEFT→NONE) but will act when two pointers present (touch two-finger = dolly_rotate handles regardless? In onTouchStart equivalent — r160 uses pointer events: onPointerDown → if pointerType touch → register pointer; state from touches when 2 pointers). With controls disabled during first pointerdown, second pointer events ignored... Instead of disabling controls, set controls.enabled=false only while left-drag active and on second pointer: cancel + enabled=true. Then OrbitControls missed the first pointerdown (it was disabled), and sees only second pointer down → treats as ONE touch = NONE. Ugh. Minor: user lifts and re-touches with two fingers. Acceptable edge; mobile secondary. Keep implementation simple, note in hints desktop-first.

Simplify: don't over-engineer. controls.enabled = false on spawn start, true on spawn end/cancel.

Physics detail — softening: distSq + eps² (eps = softening param). invDist = 1/sqrt(d2+eps²), f = invDist³. a_i += Gm_jdxf; a_j -= Gm_idxf (symmetric).

Time step: SIM_DT = 0.01; accumulator: acc += frameDt * timeScale; steps = 0; while(acc >= SIM_DT && steps < 60){ step(SIM_DT); acc -= SIM_DT; steps++ }. frameDt clamped 0.05. At timeScale 5: 0.0167*5/0.01 ≈ 8.3 steps/frame. Cap 60 for safety at timeScale extremes.

Escape removal: dist² > (4500)² → dead.

Total mass tracked incrementally (spawn add, merge keep, escape subtract) — recompute occasionally; simpler: compute in render loop cheaply O(n) each stats update.

Colors HDR: store baseColor (0..1) and intensity; instanceColor = base * intensity. For trail: base * 0.7 (accumulates).

InstancedMesh creation: capacity MAX_BODIES=420. mesh.count = bodyCount each frame; instanceMatrix.needsUpdate; if instanceColor buffer — create by calling setColorAt once for all to allocate, then update used ones and set needsUpdate.

MeshBasicMaterial: color white; vertexColors? For instanceColor to work: material.vertexColors not needed — three handles instanceColor automatically when mesh.instanceColor set (USE_INSTANCING_COLOR). With MeshBasicMaterial, instanceColor multiplies diffuse. Yes works in r160.

Tone mapping: default ACESFilmic? When using EffectComposer + OutputPass, OutputPass applies tone mapping/sRGB based on renderer settings. Set renderer.toneMapping = THREE.ACESFilmicToneMapping, toneMappingExposure 1.0. Colors will be tone-mapped — HDR bloom still works (bloom pass operates pre-output). Fine.

Star sphere radius 3800; camera far 12000 ok.

GridHelper colors dim; add fog? No.

Trail plane DoubleSide additive — when camera below plane sees trails mirrored — fine.

One subtlety: UnrealBloomPass with HalfFloat composer targets — EffectComposer defaults to HalfFloatType in recent three (r152+ default renderTarget type HalfFloat). r160: yes, default HalfFloat. Good.

TrailRT type: HalfFloatType for HDR accumulation; format RGBA; minFilter Linear, magFilter Linear; depthBuffer false; stencilBuffer false.

Now trail fade quad: geometry PlaneGeometry(2WORLD, 2WORLD), rotated x -90° so it lies in XZ. Position y=0. Material MeshBasicMaterial({ color: new Color(decay,decay,decay) — updated per frame via material.color.setScalar(effDecay), blending: Custom, blendSrc ZERO, blendDst SRC_COLOR, transparent false? blending custom ignores transparent flag mostly but set transparent:true to ensure it doesn't write depth... depthTest false, depthWrite false. }) rendered first (renderOrder 0), points renderOrder 1.

Ortho camera: THREE.OrthographicCamera(-WORLD, WORLD, WORLD, -WORLD, 0.1, 100) positioned y=50 looking at origin down. Set cam.up default (0,1,0) is parallel to view dir — must set up (0,0,-1)? Looking down -Y with up +Z or -Z. Use camera.position.set(0,50,0); camera.up.set(0,0,-1); camera.lookAt(0,0,0). Then screen x→world x, screen y→world z? With up=-Z: up direction maps to +screen-y... world -Z is up on screen → world +Z is down. Plane texture mapping: PlaneGeometry UVs: (0,0) at (-w/2, +h/2 local y) — after rotation -90° about X, local +Y becomes +Z? Rotation X by -90°: Y→ -Z? Let me think: rotX(-90°): y axis→ -z? Rotating vector (0,1,0) by -90 about X: (0, cos(-90)*1, sin(-90)*1) = (0,0,-1). So plane's local +Y maps to world -Z. UV v=1 at local +Y → world -Z. Texture v=1 is top of texture. Camera top (up on screen) = world -Z (with up=-Z). Texture sampled at v: top of ortho view (world -Z) should map to v=1. Ortho camera renders top of view to top of framebuffer (v=1 top? In WebGL, framebuffer y up → texture v=1 is... render target texture v=0 at bottom). Rendered image: camera up = +framebuffer y = texture v increasing. World -Z (camera up) → v high. Plane UV: world -Z → v=1. Consistent! And world +X → camera right (u increasing); plane local +X → u=1. Consistent.

Hmm wait: camera.up.set(0,0,-1), lookAt down: camera's right = up × forward? forward = (0,-1,0). right = forward × up = (0,-1,0)×(0,0,-1) = ((-1)(-1) - 00, 00 - 0*(-1), 0*0 - (-1)*0) = (1,0,0). Yes right=+X.

If I get flipped trails, it'd be visibly wrong but can't test headless... risk is low with this reasoning; DoubleSide plane with mirrored texture would look offset. Alternative safer approach: set plane rotation and check both mappings... I'll trust the math. Actually let me double-check PlaneGeometry UV: positions from (-w/2, h/2) with uv (0,1) top-left; (w/2, -h/2) uv(1,1)? Standard PlaneGeometry: uvs: (0,1),(1,1),(0,0),(1,0) for corners (-w/2,+h/2),(+w/2,+h/2),(-w/2,-h/2),(+w/2,-h/2). So local +Y → v=1, local +X → u=1. After rotX(-90): local +Y → world -Z (v=1 at world -Z); local +X stays world +X (u=1). Framebuffer: camera up=-Z → world -Z renders at high framebuffer Y. Texture from RT: v = framebuffer Y / height (WebGL textures from RT: v=0 bottom). High fb Y → v≈1. World -Z ↔ v=1. Plane maps world -Z → v=1. ✔. World +X → fb right → u≈1; plane world +X → u=1 ✔.

Points in trail scene: positions at (x, 0, z). Ortho cam at y=50, near 0.1 far 100 — y=0 within. PointsMaterial sizeAttenuation false → size in pixels: 3 (RT is 2048 → 3px ≈ 0.7 world units — good). Colors dim.

RT coverage [-500,500] = 1000 units over 2048px ≈ 0.5 u/px — bodies radius ≥1.5 → ≥3px. Fine.

Also must handle: renderer autoClear when rendering trailScene manually: use renderer.autoClear = false globally and manage clears manually for both passes? Simpler: in loop:

With autoClear=false: trail pass renders fade quad (multiplies) + points — correct, no clear. Main render via composer: composer.render() → RenderPass has clear=true by default? RenderPass sets this.clear = true; it calls renderer.clear() when clear true regardless of autoClear? RenderPass: renderer.setRenderTarget(...); if (this.clear) renderer.clear(...) — it respects autoClear? Looking at RenderPass source r160:

Hmm, in newer versions: renderer.clear(this.autoClearColor...) uses this.autoClearColor property of the pass. It calls renderer.clear directly. So clearing works even with global autoClear=false. ✔ Composer swaps buffers; fine.

Also set renderer.setClearColor(0x000208 or #050508 to match body bg, alpha 1).

Trail RT initial: after creation, setRenderTarget(trailRT); setClearColor(black); clear(true,false,false); restore. Note setClearColor affects main too — set main clear color after, or use renderer.clearColor... I'll do init clear then setClearColor(0x050508) for main.

Clear trails when preset loads / Clear pressed: same manual clear of RT.

Spawn while paused: physics loop paused but render continues; new body renders. ✔

Sim time accumulates SIM_DT per step.

Stats: totalMass compute in stats tick.

Pause button label toggles "Pause"/"Resume". Space key same. Key shortcuts: Space pause, C clear, P screenshot, 1..5 presets, H toggle hint? keep.

Screenshot: flag shotRequested; after composer.render() in loop: if flag → renderer.domElement.toBlob(blob => save). Filename 'gravity-sandbox.png'.

Now colors per mass — define stops:

log-space lerp. Intensity = 1.1 + 2.2 * t where t normalized position. I'll compute color(mass) returning [r,g,b] already multiplied by intensity (HDR), store per body; instanced color & trail color (×0.6).

For the spawned-body preview marker: Mesh(SphereGeometry(1), MeshBasicMaterial color HDR) scaled by radius of spawnMass; update on wheel.

Aim line: BufferGeometry with 2 positions, LineBasicMaterial({ vertexColors: true, transparent: true, opacity: 0.9, blending: AdditiveBlending, depthWrite:false }) colors cyan→pink. Also a second "predicted orbit" would be cool — skip.

Panel styling copied from 004 (consistent look). Reuse CSS.

Let me also include with user-scalable=no like 004.

Title: "Gravity Sandbox — Three.js Demo". HUD h1 "Gravity Sandbox", p "N-body orbital playground".

Also add favicon inline? skip.

Font sizes consistent with 004.

Panel width 256px; sections with . Sliders rows: label + value span + input range. Buttons .btn. Preset grid 2 columns. Shortcuts as small list.

Now write the file. It'll be long (~950 lines). Then:

1. Extract module JS → node --check.
2. Extract GLSL (2 shaders) → validate with @shaderfrog/glsl-parser (npm i in /tmp).
3. Check DOM ids referenced vs defined.
4. curl CDN urls (three module, OrbitControls, EffectComposer, UnrealBloomPass, RenderPass, OutputPass imports — check the addons paths exist: examples/jsm/controls/OrbitControls.js, postprocessing/EffectComposer.js, RenderPass.js, UnrealBloomPass.js, OutputPass.js).
5. Node physics sanity test: replicate integrator + presets to ensure orbits stable (no NaN, bodies stay bounded for solar preset over simulated time).
6. Update /space/demos/index.html with new card.

Import paths used:

• three
• three/addons/controls/OrbitControls.js
• three/addons/postprocessing/EffectComposer.js
• three/addons/postprocessing/RenderPass.js
• three/addons/postprocessing/UnrealBloomPass.js
• three/addons/postprocessing/OutputPass.js

Let me write the code carefully now. I'll write with template — be careful with backticks inside? No template literals containing HTML. Use standard strings.

Potential bug sources to double-check while writing:

• setColorAt before first render to allocate instanceColor: loop i<MAX setColorAt(i, black) once; instanceColor.needsUpdate on change each frame.
• InstancedMesh frustumCulled = false (instances spread out; bounding sphere not auto) — set mesh.frustumCulled = false. Same for trail plane? plane static, fine. Stars points frustumCulled false.
• Points drawRange update.
• OrbitControls import path.
• OutputPass constructor takes no args.
• UnrealBloomPass(resolution: Vector2, strength, radius, threshold).
• When bodies count 0 → instanceMesh.count = 0 ok.
• Math: circular velocity sign — tangential direction: for position (x,z) relative center, tangent = (-z, x)/r (counterclockwise when viewed from +Y). v = tangent * speed. Fine either direction.
• spawn drag velocity: v = (end - start) * 0.28? Wait: drag from start to end defines velocity vector = drag * scale, so body moves toward where you dragged. VEL_SCALE = 0.3? For orbit around 2000-mass star at r=150: v_circ = sqrt(10*2000/150) = sqrt(133) = 11.5. A 40-unit drag → 12 u/s. Good: VEL_SCALE=0.3.
• Cap spawn velocity to avoid crazy: min(v, 120).
• Wheel during drag changes spawnMass — update slider UI too.

Merge inline within pair loop: when dist2 < (ri+rj)²: heavier absorbs: ensure i is heavier by swapping roles locally — simpler: determine a (heavier), b (lighter); update a's vel = (vama + vbmb)/M; pos likewise; mass; radius; color: keep heavier's color (recompute by mass). Mark b dead (alive[b]=0). Since loop continues with stale values for b, guard inner loop with if(alive[j]===0) continue; and outer with alive[i]. If a==j case: after merge into j, i is dead → break inner loop (i gone). Handle: if merged into j (i lighter), break inner; else continue (j dead, subsequent j's skip). Also gravity contribution this pair skipped post-merge — fine.

Mass/radius arrays as Float64? Float32 fine. Velocities small — Float32 ok. Positions up to 4500 — Float32 precision ~0.0005 at 4500 — fine.

Compact: after each frame's steps, compact arrays swap-remove dead. Colors arrays too. Maintain count.

Trail & instanced update from arrays 0..count.

Escape: mark dead during a pass each frame (after steps): if x²+z² > 4500² → dead (before compaction).

Now HUD stat elements ids: statFps, statBodies, statTime, statMass.

Slider ids: sldTime, sldGravity, sldSoft, sldTrail, sldMass, sldBloom; value spans: valTime, valGravity, valSoft, valTrail, valMass, valBloom.

Checkbox: chkMerge.

Buttons: btnPause, btnClear, btnShot; presets: btnPreset1..5? Use data-preset attr and class. ids: presetSolar, presetBinary, presetEight, presetDisk, presetCluster.

Panel toggle: panelToggle; panel id: panel.

Containers: app, hud, hint, toast, vignette, aimline none (three objects).

Write it. Also remember touch-action: none and overscroll-behavior on panel.

Also prevent OrbitControls stealing: attach our pointer handlers on renderer.domElement with capture? OrbitControls also on domElement. Since LEFT action is NONE for controls, no conflict for left; right handled by controls only (we ignore button 2). pointerdown for button 0 → begin spawn (also setPointerCapture on canvas to get moves outside). OK.

Wheel handler: only adjust mass when dragging (aim active); else let controls zoom. Attach with { passive: false } to preventDefault when dragging.

Also add dblclick to spawn a "star" quickly? skip.

One more: hint says left-drag launch; note ESC cancels drag. Implement Escape cancel.

Screenshot requires the canvas preserveDrawingBuffer? We call toBlob synchronously right after composer.render() within same rAF callback — buffer still valid (same task, no compositing yet). Known technique, works.

toBlob on WebGL canvas: renderer.domElement.toBlob(cb) — fine.

Alright — also the "valMass" display: show mass with 1 decimal; slider log: input range 0..100 mapping mass = 0.5 * (400)^t? mass range 0.5..200 log: m = 0.5 * Math.pow(400, t). t=(slider)/100.

Trail slider: value 0..100 → p = 0.90 + t*(0.998-0.90). Display %: (p*100).toFixed(1).

Time slider: 0..100 → 0.1 + t*4.9. Display ×.

Gravity: 0..100 → 0..30. display 1 decimal.

Soft: 0..100 → 0.5..12.

Bloom: 0..100 → 0..2.5.

Now the code. Also add subtle ambient audio? No.

Let me draft the full HTML mentally then write via read_write_file (write mode, full content). Because content is long (~40KB), one write call.

Physics sanity test afterwards in node: replicate G=10, step function, solar preset; simulate 30k steps; check planet count unchanged, positions bounded, no NaN; figure-8: bodies remain within ~300 after 2 periods. Disk: no blowup (max r < 5000). This catches formula errors.

Let me write file now.

Structure of module script:

Write massColor with stops in log space:

Presets:

Wait outer r=415 < WORLD 500 ✔. v at 415 = sqrt(10*2000/415)=6.9 fine.

Hmm — actually retrograde disks are also fine/fun, collisions merge anyway. But prograde is stabler. Use prograde.

Check scaling: solution for G0=m0=1, positions x0(t). Try x(t)=s x0(ωt): accel = s ω² x0'' = s ω² (-G0 m0 x0dir /|x0|²)... need accel = -G m (s x0dir)/(s²|x0|²)·? For equations: x0'' = G0 * m0 * dir/|x0|² (G0=1,m0=1). Then s ω² x0''(ωt) =?= G m s / s² · x0''(ωt)·(1/1)... we need s ω² = G m / s² → ω² = G m / s³ → ω = sqrt(G m/s³). Velocities scale: v = s ω v0 = s sqrt(Gm/s³) v0 = sqrt(G m / s) v0. ✔ So k=sqrt(Gm/s), with G=10,m=350,s=110: k=sqrt(10350/110)=sqrt(31.818)=5.641. v0 values: (0.3471168881, 0.5327289454) and p0 = (±0.97000436, ∓0.24308753)s, third at origin. addBody(-0.97000436s, 0.24308753s, 0.3471168881k, 0.5327289454k, m) addBody( 0.97000436s, -0.24308753s, 0.3471168881k, 0.5327289454k, m) addBody(0,0, -20.3471168881k, -20.5327289454*k, m)

function presetDisk(){ addBody(0,0,0,0,6000); for(i<260){ r = 90 + rnd300; ang; sp = sqrt(G6000/r)(1±0.03); CCW vel (-sinsp, cos*sp); mass 0.5±0.2 } }

function presetCluster(){ for(i<140){ gaussian pos r<220 (use Box-Muller or sum of rands), vel rand ±3, mass 2+rnd*10 } }

let last=performance.now(), simTime=0, fpsEMA=60; function animate(now){ requestAnimationFrame(animate); const dtms = now-last; last=now; frameDt = min(dtms/1000, 0.05); fpsEMA = lerp(fpsEMA, 1/max(frameDt,1e-4), 0.05); // physics if(!params.paused){ acc += frameDt * params.timeScale; let steps=0; while(acc >= SIM_DT && steps < 60){ stepPhysics(SIM_DT); simTime += SIM_DT; acc -= SIM_DT; steps++; } if(steps===60) acc=0; // drop backlog removeEscaped(); compact(); } updateBodyMesh(); updateTrailPoints(); // trail pass fadeMat.color.setScalar(Math.pow(params.trail, frameDt60)); renderer.setRenderTarget(trailRT); renderer.render(trailScene, trailCam); renderer.setRenderTarget(null); // stars time starMat.uniforms.uTime.value = now0.001; controls.update(); composer.render(); if(shotRequested){ shotRequested=false; renderer.domElement.toBlob(saveBlob); } // stats throttle }

const raycaster = new THREE.Raycaster(); const planeY = new THREE.Plane(new THREE.Vector3(0,1,0), 0); function planePoint(e){ ndc from event; raycaster.setFromCamera; ray.ray.intersectPlane(planeY, out); return out (Vector3) or null } canvas.addEventListener('pointerdown', e => { if(e.button!==0) return; const p = planePoint(e); if(!p || Math.max(|p.x|,|p.z|) > WORLD) return; dragging=true; dragStart=p; dragCur=p.clone(); controls.enabled=false; canvas.setPointerCapture(e.pointerId); show aim; hint hide; }); pointermove: if dragging update dragCur; update aim geometry + marker at start (radius from params.mass, color from massColor); pointerup: if dragging: v=(dragCur-dragStart)*VEL_SCALE (x,z), clamp len MAX_SPAWN_V; addBody(start.x,start.z,v.x,v.z,params.mass); hide aim; controls.enabled=true; dragging=false; Escape: cancel. wheel: if dragging { e.preventDefault(); params.mass *= (e.deltaY<0?1.15:1/1.15); clamp 0.5..200; sync slider UI; update marker; }

Hmm — I need to double check exact r160 code. r160 RenderPass.render:

I'm fairly confident r160's RenderPass explicitly calls renderer.clear when this.clear is true (it saves/restores autoClear). Actually let me verify by fetching the file from CDN during validation and grepping. If RenderPass doesn't clear when autoClear=false, I can clear manually before composer.render(): renderer.clear(). To be safe, do that: before composer.render(): renderer.setRenderTarget(null)... composer uses readBuffer RT... Manual clear of default framebuffer wouldn't clear the composer's readBuffer. Safest: fetch RenderPass.js source in validation step and confirm. If unclear, set renderPass.clear = true and rely; also could keep renderer.autoClear=true and set autoClear=false only around trail pass:

This avoids any doubt! RenderPass with autoClear true clears per its own logic anyway. And trail pass needs no clear. This is clean — do that. (RenderPass sets renderer.autoClear=false internally during pass and restores; with clear=true it clears explicitly — either way works.)

Double-check UnrealBloomPass doesn't clear stuff weirdly — it manages its own RTs. OK.

For clearing trail RT manually:

Main clear color: renderer.setClearColor(0x04050c, 1) at init (after any clearTrails call which restores anyway).

Init order: create everything, clearTrails(), loadPreset('solar'), animate.

presetDisk count 261 ✔ under 420. Binary 152 ✔. Solar 9. Cluster 140.

Spawn cap: if count>=MAX_BODIES → toast "Body limit reached" and skip.

Merge color: recompute from new mass — implement in merge: after mass update, [r,g,b]=massColor; write cr/cg/cb.

Now stats: totalMass loop.

Alright, also add small "predicted velocity" numeric readout while dragging? Show in hint? skip.

Write the file now. I'll be meticulous with syntax. After writing, run validations.

One more consideration: import of OutputPass in r160 exists ✔ (examples/jsm/postprocessing/OutputPass.js since r152ish).

GridHelper in XZ plane ✔.

For the aim line colors: LineBasicMaterial vertexColors with geometry 'color' attribute (3 floats per vertex): start cyan (0.2,1.5,1.8) HDR, end magenta (1.8,0.4,1.2). Additive blending.

Marker sphere: MeshBasicMaterial color set from massColor each update; transparent opacity 0.85.

Also add a ring at spawn showing blast radius? enough.

Panel HTML sketch:

Slider row markup: <div class="row"><label>Time scale</label><span class="val" id="valTime">1.0×</span></div><input type="range" id="sldTime" min="0" max="100" value="20"> — compute defaults: time default 1 → t=(1-0.1)/4.9=0.1837 → 18. gravity 10/30 → 33. soft (2-0.5)/11.5 → 13. trail (0.975-0.9)/0.098 → 76. mass: t = ln(8/0.5)/ln(400) = ln16/5.99=2.772/5.991=0.4627 → 46. bloom 1.1/2.5 → 44.

I'll set values in JS on init anyway (single source of truth): define params, then sync UI from params in init. Slider initial HTML values approximate; JS init overrides. Good — avoids mismatch.

Writing time. Keep code commented and tidy.

Actually one more feature for wow: optional "gravity well" grid deformation? skip — enough scope.

Let me write the complete file.