Black Hole Lensing Demo Creation

Let me check the current state of the demos folder to see what's there, and continue from where the previous turn left off. The last execution was about creating a gravity sandbox demo. The summary says the next steps involve validating the JS/GLSL code, checking CDN URLs, performing a physics sanity test, and updating the main index.html to include the new demo.

This new turn says "Wake up and do as you please." So I have freedom. Let me first check the state of the demos folder, verify the gravity sandbox demo exists and is complete, update the index page if needed, and then perhaps do more work.

Let me install shell tools first.

Let me check the current state of the demos folder.

The previous turn created /space/demos/005-gravity-sandbox/index.html. The main index.html was last modified Jul 18, so it likely doesn't include the 005 demo yet. Let me check both files: the main index and the 005 demo to validate them.

Let me first check the main index.html.

******************************************************************************************************************************************************************************st.

*************************************************************************************************************************************************ag.

*******************************************************************************************************************************s).

All CDN URLs resolve. Now let me do a quick physics sanity check on the demo's integrator. Let me look at the physics code in the module to verify it makes sense — let me view the full module to check for logical issues, particularly the physics and rendering. Let me view the extracted module file.

The code looks complete and well-structured. Let me check a few potential issues:

1. The restartStep function — recursion potential issue. In stepPhysics, when b === i (the lighter body at index i is absorbed), it calls restartStep(dt) and returns. That's fine.

2. The updateAim function uses $('hint') — need to verify the DOM has all those IDs. Let me check the HTML body has all required IDs: toast, app, hint, panel, panelToggle, sldTime, valTime, sldGravity, valGravity, sldSoft, valSoft, sldTrail, valTrail, sldMass, valMass, sldBloom, valBloom, chkMerge, btnPause, btnClear, btnShot, presetSolar, presetBinary, presetEight, presetDisk, presetCluster, statFps, statBodies, statTime, statMass.

Let me grep the HTML for these IDs to verify they all exist.

All DOM IDs exist. Now let me do a headless physics sanity test — I'll extract the physics code and run it in node to verify orbits behave (e.g., a circular orbit stays roughly at constant radius). Let me write a small node test that replicates the stepPhysics logic (symplectic Euler with softened gravity) with a central mass and one planet in circular orbit, and check energy/radius conservation over time.

Actually, I can extract the actual physics functions from the module. But they reference params, mass, etc. Simpler: replicate the algorithm exactly in a test harness. Let me do that.

Physics is solid — circular orbit holds within 0.45% over ~2000 time units, and the figure-8 three-body solution stays bounded.

Now let me also do a quick check of the merge/collision path to make sure the restartStep logic doesn't infinitely recurse or crash. Let me test a head-on collision scenario.

***********************************************************************************************************************************xt.

************************************************************************************************************************************************************es.

The lines look exactly like what I searched for. Maybe the replace tool has issues with the S3FS filesystem or with multi-line strings. Let me try using sed/awk via shell command instead, or a python script.

Actually, wait — the file uses LF endings ($ at end). My search string uses \n. That should match. Perhaps the tool does something weird. Let me just use python to do the insertion — it's more reliable.

******************************************************************************************************************************************************************************************************************************************-A.

*************************************************************************************************************************************************************************************************************************************************************it.

The index page is now rewritten cleanly with all 5 demos. Now, per my purpose, I could go beyond and create another demo — the task says "Wake up and do as you please." I've completed the leftover work from the previous turn (validating demo 005 and updating the index).

Should I create a new demo? The instructions say "do as you please" and my purpose is to create cool Three.js demos. The previous demo 005 was just finished. Creating another impressive demo would be a good use of this turn. Let me think about what would be a great addition:

Ideas for demo 006:

1. Ray-marched volumetric clouds / nebula — volumetric ray marching in a fragment shader
2. Audio-reactive visualizer — needs microphone/audio file, may be tricky without user interaction but can include a built-in synthesized soundtrack via WebAudio
3. Asteroids 3D game — playable mini-game
4. Tessellated terrain with erosion / procedural planet
5. Cloth/soft-body simulation
6. Particle life (primordial soup) — artificial life particles
7. Wormhole / hyperspace tunnel with shaders
8. L-system fractal trees / generative
9. Wave function collapse
10. Interactive fluid + particles — already did fluid
11. Black hole gravitational lensing shader — ray-bent accretion disk, GLSL
12. 3D snake game
13. Orbital mechanics done
14. Procedural city / cyberpunk flythrough
15. GPU compute flocking (boids) with GPGPU — 100k boids via texture-based computation

A GPGPU boids flocking simulation with 100k+ instances would be impressive and complements the gravity demo (which is CPU-based O(n²)). Or a black hole lensing ray-marcher would be very "wow" — photon bending around a Schwarzschild black hole with an accretion disk, animated, with doppler beaming colors. That pairs nicely with the gravity sandbox theme but is shader-based.

Actually, let me do the black hole gravitational lensing demo — it's extremely impressive visually (Interstellar-style), fully in a fragment shader (ray marching with geodesic bending), interactive camera orbit, adjustable spin/mass/lensing quality, bloom. That's advanced and visually stunning.

Alternatively GPGPU boids — also very cool. But black hole lensing is more "wow".

Let me plan the black hole demo:

Demo 006: Event Horizon — Black Hole Lensing

• Fullscreen quad ray-marching shader
• Camera orbits a Schwarzschild black hole at origin
• Each pixel: cast a ray from camera, integrate geodesic bending (simple numerical integration of light deflection in Schwarzschild metric using the weak-field approximation or full geodesic with adaptive step)
• Accretion disk: thin disk in equatorial plane with procedural texture (noise-based swirl), temperature color gradient (blackbody: inner hot blue-white, outer orange-red), doppler beaming (one side brighter)
• Background: procedural starfield / nebula cubemap-ish (can use procedural noise stars)
• Photon sphere glow, event horizon shadow
• Bloom post-processing
• Controls: distance, inclination, disk temperature, rotation speed, lensing quality/steps, bloom, exposure
• HUD with info
• Auto-rotate, orbit controls (custom since camera feeds shader uniforms — use OrbitControls on a dummy camera and pass its position matrix to shader)

Implementation details for the shader:

• Standard approach: for each pixel, ray direction from camera. Then integrate the null geodesic approximately: use the "bending" iterative approach: step along ray, at each step apply gravitational acceleration to the ray direction perpendicular component:
  • A common cheap method: treat photon as particle with velocity c, apply acceleration a = -1.5 * h² * r̂ / r⁵ (in geometric units, from the Schwarzschild null geodesic equation in terms of impact parameter). Actually the standard pseudo-Newtonian light bending: d²r/dλ² = -1.5 h² r / r⁵ where h is angular momentum. Implementation: keep velocity vector v (|v|=1), position p; each step: h = |p × v|; accel = -1.5 * h² * p / |p|^5 * rs... Let me use units where rs = 1 (Schwarzschild radius).
  • Step: v += a * dt; v = normalize(v); p += v * dt. With adaptive dt based on distance to hole.
• Check disk crossings: when crossing y=0 plane within disk radii [r_in, r_out], accumulate disk color with alpha; apply doppler shift based on disk velocity direction vs ray direction.
• If ray gets inside rs → black (event horizon shadow).
• If ray escapes to large radius → sample background (procedural stars + nebula gradient).
• Disk texture: procedural fbm noise, rotation animated with time, Keplerian differential rotation.

This is a well-known shader (like the famous Shadertoy black hole shaders). I can write a robust one.

Performance: 64-128 steps per pixel at full res might be heavy; render at reduced resolution scale (e.g., 0.75× or adjustable quality) and upscale, plus bloom. Adaptive stepping helps.

Let me write this demo carefully. Key parts:

1. HTML shell with UI panel similar style to demo 005 (consistent).
2. Import map with three@0.160.0, EffectComposer, RenderPass? Actually for a fullscreen shader, simpler: use a Scene with an OrthographicCamera and a fullscreen quad with ShaderMaterial, render through EffectComposer with UnrealBloomPass and OutputPass.
3. Camera rig: a PerspectiveCamera that OrbitControls moves; the shader needs camera position + orientation matrix. I can pass camera.matrixWorld (or compute basis vectors: right, up, forward from camera quaternion) as uniforms, plus tan(fov/2) and aspect.
4. Shader: the lensing ray-marcher.

Shader outline (GLSL):

Wait — light bending for photon: with |v| = 1 and accel = -1.5 h² r/r⁵. But normalizing v each step changes the dynamics slightly; the standard approach used in many shaders: don't normalize, keep v as "velocity" with initial magnitude 1 (c=1), and integrate p' = v, v' = -1.5 h² r / r⁵. The magnitude stays ~1. Normalizing each step is a stabilizer that some use; it slightly alters but looks fine. I'll not normalize for correctness, or optionally clamp.

Actually the well-known "starless" approach in the famous Shadertoy "Black Hole" by various authors: they use exactly this pseudo-Newtonian form. E.g.:

Good.

Disk color:

• radius-based temperature: T ∝ (r_in/r)^0.75, color from blackbody-ish gradient (white-blue hot inner → orange outer).
• Keplerian velocity direction: perpendicular to radius in disk plane: omega direction; v_disk = sqrt(M/r) tangential. Doppler factor: boost brightness on approaching side: factor = (1 + beta * dot(tangent, -rayDir))^3 approx; also redshift the dim side.
• Texture: fbm(uv based on angle + radius, with differential rotation: angle -= time * r^-1.5 * speed).
• Alpha: density falls off with radius, and vertical thin → treat as infinitesimally thin, accumulate with some opacity ~0.6.
• Inner edge glow (ISCO) bright.

Background: procedural: direction → stars via 3D grid hash (cell-based star points): for ray direction v, compute color = sum of star contributions using hash on octahedral mapping or 3D cell noise: stars = pow(hash, high) etc. Plus subtle nebula fbm tinted. Add Milky-Way band: brightness along galactic plane of the background.

Also "photon sphere" ring glow naturally emerges from bending (rays passing close get bent strongly, sampling bright disk multiple times / Einstein ring from background).

MAX_STEPS as compile-time constant (e.g., 160) with early escapes; quality uniform controls dt scale — more quality = smaller dt = more steps effectively. Use dynamic loop bound via uniform float and break when i > uSteps.

Also add a rotating black hole? Kerr is much harder; skip — Schwarzschild with a nice disk is already stunning. Maybe add "spin" parameter that just drags disk slightly (fake frame dragging for visuals)? Keep honest: Schwarzschild.

Post: UnrealBloomPass + OutputPass, plus vignette via CSS.

UI: consistent with demo 005 style: panel with sliders:

• Distance (camera radius) — via OrbitControls zoom actually; sliders for:
• Quality (steps): 40–220
• Disk temp: color shift
• Disk brightness
• Rotation speed (disk animation)
• Doppler beaming on/off + strength
• Background stars density
• Bloom strength
• Exposure
• Resolution scale (performance) Buttons: Pause rotation? Snapshot (P). Keyboard: P snapshot, Space pause disk animation, H toggle panel? Keep consistent.

HUD: FPS, steps, etc.

Camera: OrbitControls targeting origin, autoRotate optional, damping. FOV 55. Pass camera basis vectors to shader each frame.

Edge cases: when camera is inside disk plane region? Clamp camera min distance outside horizon (e.g., min 3.5 rs). OrbitControls minDistance handles it.

Resolution scale: render composer at size * scale. Implement by setting renderer.setSize(wscale, yscale, false) with CSS upscaling? Simpler: renderer.setPixelRatio(scale * devicePixelRatio). I'll use a "render scale" select: 100%/75%/50% mapped to setPixelRatio.

Let me now write the shader carefully.

Details:

Constants:

• RS = 1.0 (in shader units). World: camera orbit radius in "rs units" — set camera positions in rs units directly (e.g., camera at distance 6–30). OrbitControls distances: min 3.0, max 60.

Disk: inner 1.6 rs (ISCO-ish 3.0? For Schwarzschild ISCO = 3 rs = 6M... wait rs = 2M, ISCO = 6M = 3 rs. Photon sphere at 1.5 rs. For looks, inner edge ~2.2–3.0; I'll use 2.6 default with slider 1.8–4.5), outer ~12 rs default slider 6–20.

The bending: accel = -1.5 * h2 * p / r^5. Note h2 = |p × v|² with |v|=1 → h2 = r² sin²θ. Near photon sphere, unstable orbit — needs small dt. Adaptive dt: dt = clamp(0.02 * r * (r-1)... hmm. Common: dt = 0.02 + 0.08 * r? Let me use dt = max(0.015, 0.04 * (r - 1.0)) * qualityFactor, capped at 0.35. Also finer when close to disk plane? It's fine.

MAX_STEPS 256 constant; uSteps slider 60–256 controls loop break.

Escape: r > 40 → sample background. Also total path length guard: if accumulated dt > 200 → background.

Disk crossing: p.y sign change. Since disk at y=0. Multiple crossings accumulate (front image + back image bent around — the classic look where you see disk above and below the hole). transmittance multiplicative; alpha per crossing ~ density * something. To get bright disk, emissive: col += transmittance * diskEmission; then transmittance *= (1 - alpha).

Doppler: disk rotates around y axis. Angular velocity ω ∝ r^-1.5 (Keplerian). Velocity vector = ω × r_vec: for counterclockwise seen from +y: vel = normalize(cross(vec3(0,1,0), hitPos)) * beta(r), beta = min(0.55, 0.35 * sqrt(3.0/hr))? For visual: beta = uBeamVel * sqrt(uDiskInner / hr) clamp 0..0.6. Doppler factor d = 1 + dot(vDisk, -v) where v is photon direction... Careful: observed brightness boosted where disk material moves toward observer: dot(vDisk, dirToObserver). dirToObserver = -v (photon travels along v toward camera... photon direction v points from emission toward camera? Our ray marches backward from camera. The photon at the end travels along v; observer receives photons coming along -v at camera... For beaming: brightness *= pow(1 + dot(vDisk, (-v)), 3) — approximate; sign determined empirically: approaching side brighter. dot(vDisk, -v): if disk material velocity points toward camera (same direction as photon travel direction v toward camera... hmm photons reaching camera travel toward camera = direction from hit point to camera ≈ v (the marching direction at the end). Material moving toward camera has vDisk · (cameraDir) > 0 where cameraDir ≈ v_final-ish... I'll just compute boost = 1 + dot(vDisk, v) and if the visual looks wrong I can't test visually — so make the sign controllable? Standard known-good: in many shadertoys: float dop = dot(normalize(cross(vec3(0,1,0), hitPos)), -rayDir); col *= pow(1.0 + beamStrength * dop, 3.0). I'll use that; magnitude controlled by slider; if sign flipped it just brightens the other side — visually plausible either way (rotation direction also selectable via a "direction" toggle maybe). Keep it simple.

Disk texture via fbm:

• coords: angle θ = atan(hit.z, hit.x); rotation: θ_rot = θ - uTime * uRotSpeed * pow(uDiskInner / hr, 1.5) (differential).
• radial coordinate: s = (hr - uDiskInner) / (uDiskOuter - uDiskInner).
• uv = vec2(θ_rot * (some wraps, e.g., * 2.0/π scaled by 3), s * 6.0) then fbm → streaks. Multiply emissive by (0.4 + 0.6 * fbm). Also spiral modulation: sin(θ_rot2 + s12).
• Temperature color: t = pow(uDiskInner / hr, 0.75); color ramp: mix(outer orange (1.0,0.45,0.15), inner white-blue (0.8,0.9,1.2)... better ramp through stops: blue-white → yellow → orange-red, using t. Multiply overall by uDiskTemp tint? uDiskTemp slider shifts ramp power.

Emission intensity: peak near inner edge: I = smoothstep falloff * (1-s)^1.5 * 3.0. HDR values up to ~4 for bloom.

Background:

• Stars: 3D cell hash: dir → p = v * 60; cell = floor(p); star if hash(cell) > 0.97; brightness pow; position within cell via hash3; point-like: d = length(frac(p)-starPos); intensity = smoothstep(0.1,0,d)b. Add slight color variation. Density via uStarDensity scaling threshold... simpler: star = pow(max(0, 1-d8),2) * step(threshold, h). Use density slider to scale count: threshold = 1 - uStarDensity*0.03.
• Nebula: fbm(v*3 + seed) tinted magenta/blue, times band along y (galactic plane): band = exp(-abs(v.y)*3). Plus faint overall gradient.

Tonemapping: renderer ACES via OutputPass handles.

Also faint "jet" or glow around horizon? Skip jets (polar jets are a nice touch: two cones) — maybe subtle: skip.

UI panel consistent with demo005 style (same CSS patterns: glass panel, sliders grid, buttons). I'll write fresh CSS modeled on 005 (I know its structure: #hud, #stats, #panel with .closed, #panelToggle, .grid2 buttons, sliders). I'll craft similar but self-contained.

Extra feature: "Cinematic mode" button — slow auto camera orbit + panel auto-hide. Nice.

Snapshot: P key / button — composer renders then canvas.toBlob.

Keyboard: Space = pause disk/camera animation; P = snapshot; H = hide UI; Esc nothing.

HUD: FPS, steps, ray steps count static.

Let me also double check three@0.160.0 has OutputPass (yes, used in 005).

One risk: shader compile errors. I can validate GLSL by compiling with a headless GLSL validator? Not available likely. I'll be very careful with syntax. Alternative: use glslangValidator? Probably not installed. I could npm install glslang? Might not have network for npm... Let me check quickly if glslangValidator exists; if not, I'll write extremely carefully and maybe test compile via node + headless-gl? headless-gl needs native build — unlikely. I'll self-review carefully.

Actually, I can write a small GLSL syntax sanity checker? Too complex. Careful authoring + maybe a regex for balanced braces. Let me just be careful. Common pitfalls:

• loop indices must be constant-comparable in WebGL2? In WebGL2 (Three r160 uses WebGL2), dynamic loop bounds are allowed. MAX_STEPS as #define constant, break on uniform condition — allowed in WebGL2.
• Integer/float mixing: use floats.
• Declare all functions before use.
• gl_FragCoord / gl_FragColor fine in WebGL2 via three's shader chunks (three compiles ShaderMaterial as GLSL3? No — ShaderMaterial defaults to GLSL1 (auto-converted: three adds #version 300 es only for RawShaderMaterial with glslVersion set or if needed... Actually Three r160: WebGL2 always; for ShaderMaterial, three prepends compatibility defines: gl_FragColor is auto-defined? In WebGL2 with three, custom ShaderMaterial fragment shaders still use gl_FragColor because three includes "#define gl_FragColor pc_fragColor" compatibility when GLSL1 shaders run on WebGL2. Yes — three handles that: it prepends a compatibility header mapping texture2D→texture etc. gl_FragCoord works. OK.

For the fullscreen pass approach, I could use EffectComposer with a custom ShaderPass-like. Simplest robust: create my own fullscreen triangle scene:

• const fsScene = new THREE.Scene(); const fsCam = new THREE.OrthographicCamera(-1,1,1,-1,0,1);
• quad = new THREE.Mesh(new THREE.PlaneGeometry(2,2), lensMaterial); fsScene.add(quad);
• composer = new EffectComposer(renderer); composer.addPass(new RenderPass(fsScene, fsCam)); bloom; output.

RenderPass with ortho cam and fullscreen quad — standard.

Uniforms needed each frame: uCamPos, uCamRight/uCamUp/uCamFwd (from the orbit camera), uTanFov, uAspect, uTime, plus params. uResolution for gl_FragCoord normalization (renderer size with pixel ratio — composer passes drawing buffer size? gl_FragCoord in pixels of drawing buffer; set uResolution = renderer.getDrawingBufferSize()).

Camera basis: camFwd = camera.getWorldDirection(); camRight = cross(fwd, camera.up).normalize() — better from matrix: right = (m.elements[0], [1], [2]) normalized; up = (elements[4..6]); fwd = -(elements[8..10]). I'll extract from matrixWorld.

FOV: tan(fov*0.5 in rad). aspect = w/h.

Now disk plane orientation: disk on XZ plane (y=0). Camera orbits target 0. Good; inclination = camera polar angle — user can orbit freely; auto-rotate for cinematic.

Grid/axes helpers: none (shader only). Maybe add subtle 3D reference ring? Not needed.

HUD stats: FPS EMA, sim "photons marched" = steps*pixels (fun stat), camera distance in rs.

UI sliders:

1. Quality (steps 60–256, default 160)
2. Render scale (0.5–1.0, default 0.8)
3. Disk inner radius (1.8–4.5, default 2.6)
4. Disk outer radius (6–20, default 12)
5. Disk temp (0.5–2.0, default 1.0)
6. Disk speed (0–3, default 1.0)
7. Beaming strength (0–2, default 1.0)
8. Star density (0–1.5, default 1.0)
9. Bloom (0–2.5, default 0.9)
10. Exposure (0.3–2.0, default 1.0) Buttons: Snapshot, Pause/Resume anim, Cinematic toggle (auto-orbit), Reset camera. Presets? Maybe: "Classic", "Hot ISCO", "Wide disk", "Minimal". Could add 2-3 presets adjusting disk params. Nice touch: preset buttons row: Interstellar (default), Inferno (hot fast), Faint (dim wide). Keep 3 presets.

Time: uTime accumulates frameDt * animSpeed when not paused.

Now the GLSL code. Let me write it fully, carefully.

Star background:

Hmm wait — 3D cell star on ray direction: dir*scale — each pixel samples one cell; a star is a point within cell; since neighboring pixels in same cell compute same d → star appears as blob of several pixels. Fine. Size: scale 40 → cell angular ~1/40 rad ≈ 1.4°, star smoothstep 0.45 cell → ~0.6° wide — a bit big. Scale 60/120 better. Brightness values: make stars HDR ~ up to 2-3 for bloom sparkle.

Disk:

Hmm, building fbm coords for streaky disk: use vec3(cos(a2)k, sscaleR, sin(a2)*k) with k ~ 3 → circular symmetry preserved, streaks along angle. fbm(q) in [0,1].

Hmm: dot(tang, -rayDir): tang is disk velocity direction; -rayDir points from hit toward camera roughly (rayDir is the direction photon travels at end...). Photon arrives at camera along rayDir; so direction toward observer = -rayDir? No wait — we march FROM camera along rayDir; at the end, rayDir points away from camera. The photon that reaches the camera travels TOWARD the camera, i.e., along -rayDir... no! The photon travels along the same path but opposite direction? In lensing we trace backward: from camera into scene. A photon emitted by disk travels along +rayDir direction? The photon's final velocity at camera equals rayDir (pointing away from camera position along the path we marched... we marched from camera outward, so the path direction we follow is the reverse of photon travel. Photon travel direction at emission ≈ -v_at_emission? Ugh.

Simplest: brightness boost where disk surface moves toward the camera. Vector toward camera from hit = normalize(uCamPos - hit). boost = 1 + beam * dot(tang, normalize(uCamPos - hit)). dot>0 when tangential velocity points toward camera → approaching → brighter. That's clean and correct visually. Use that instead of rayDir:

Wait — uBeam multiplies twice (beta includes uBeam and boost includes uBeam). Put uBeam only in boost: beta pure physics-ish. Fix: beta = clamp(0.42sqrt(uDiskIn/r), 0, 0.6); boost = pow(clamp(1+uBeamdopbeta2.2,...),3).

Main march:

Note: v magnitude drifts slightly; normalize(v) for background sampling. Also for dt I used distance-based adaptivity; near horizon dt tiny → photon sphere needs many steps; MAX 256 might still not fully resolve extremely bent rays — acceptable visually (they'll terminate inside horizon mostly). Add "if r < 1.12 && dot(v,p) < 0" fast-capture: once plunging inside photon sphere heading inward, capture to save steps:

Hmm, photons can orbit at 1.5 and escape; below 1.5 unstable; capturing at r<1.2 heading inward is safe-ish. Also to avoid infinite orbiting near 1.5: step count guard handles.

Also multiple disk crossings: after first crossing trans reduces; subsequent crossings add dimmer backside image — that's the classic look (disk seen behind hole top/bottom). But careful: rays crossing disk plane behind the hole when disk is opaque-ish get absorbed → correct shadowing.

One issue: when trans becomes very small we break before background → areas behind disk show dark — correct.

Camera inside disk radius region: if camera y=0 exactly and within disk radii... OrbitControls polar angle limits: set minPolarAngle 0.08, maxPolarAngle π-0.08 to avoid exactly 0? Edge-on views are gorgeous; keep allowed. If camera within disk annulus at y=0, first step crosses immediately with weird hit — acceptable.

Disk plane thickness: zero-thickness might alias (missed crossings when dt large across plane? we detect sign change of y — no miss). Moiré on grazing angles possible; add slight mip-ish fade when |v.y| small? The streak texture fbm is 3D; grazing rays see stretched pattern — fine.

uSteps default 170, slider 60–256.

Performance: 256 steps * (fbm only on crossings) — most steps cheap (cross/pow). background fbm once. Should run OK at 0.75 scale on decent GPU. Bloom at full res might cost; fine.

Extra wow: subtle chromatic-ish "Einstein ring" emerges automatically.

Presets:

• "Gargantua" (default): diskIn 2.6, out 12, temp 1.0, speed 1.0, beam 1.0, stars 1.0
• "Inferno": diskIn 2.0, out 8, temp 1.6, speed 1.8, beam 1.4
• "Whisper": diskIn 3.6, out 18, temp 0.7, speed 0.5, beam 0.6, stars 1.3

Preset applies sliders via the same bindSlider.set mechanism (t normalized 0..1 per slider).

Panel buttons: Snapshot(P), Pause(Space), Cinematic(auto-orbit toggle, C), Reset Cam(R)? R might conflict nothing. Fine.

Keyboard: Space pause anim; P snapshot; C cinematic; H toggle panel; 1/2/3 presets.

Cinematic: controls.autoRotate = true, speed 0.6; panel fades (add class), toast.

Snapshot: same as 005.

Also hint element bottom ("Drag to orbit · Scroll to zoom").

Now the JS structure. Camera: PerspectiveCamera(55, aspect, 0.1, 500); position spherical default: (0, 3.2, 8.5) looking at origin. OrbitControls: target 0, enableDamping, minDistance 2.2 (outside horizon=1... but camera between 1 and diskIn fine, even inside disk region gives inside-disk view — dt adaptivity handles; min 1.6 to stay outside photon sphere-ish), maxDistance 45, autoRotate optional.

Uniform updates per frame:

These are normalized already (rotation matrix columns orthonormal).

uTanFov = Math.tan(THREE.MathUtils.degToRad(camera.fov*0.5)); uAspect = w/h (drawing buffer aspect — same as screen aspect). uResolution = renderer.getDrawingBufferSize(v2) — pass as Vector2 uniform, update on resize and render-scale change.

Render scale: renderer.setPixelRatio(dpr * scale); composer.setSize(w,h); Also bloom pass resolution auto.

Hmm — EffectComposer with setPixelRatio: composer.setSize uses renderer size * pixelRatio internally for render targets. getDrawingBufferSize returns actual pixels — gl_FragCoord ranges over that. Good.

HTML/CSS: reuse style language from 005: gradient title, glass panel top-right with sliders, HUD top-left, hint bottom, toast. I'll write consistent CSS (copy patterns: .panel glass, range inputs styled, .btn grid2, kbd). Since I can't see 005's full CSS now (only first 2000 chars), I'll write my own consistent dark glass style — it doesn't need to be identical to 005, just clean and consistent.

Layout:

• #hud top-left: title "Event Horizon", subtitle, stats (FPS, cam dist rs, steps).
• #panel top-right: sections: Render (quality, scale), Disk (inner, outer, temp, speed), Optics (beaming, stars, bloom, exposure), Presets (3 buttons grid), Actions (Snapshot, Pause, Cinematic, Reset Cam), panelToggle "×".
• #hint bottom-center.
• #toast top-center.
• #vignette overlay.

Slider rows: label + value span, input range. I'll generate rows in HTML directly.

bindSlider same pattern as 005: (id, valId, toParam, toText) with t 0..1, .set(t).

Presets set via sliders' set functions — need references to all slider objects: store in array/object.

Now — GLSL validation. Let me check if glslangValidator is available, or install via apt (probably no sudo/network?). We had network for curl. Try which glslangValidator and apt list --installed? Simpler: try npm i -g? Actually there's a pure-JS GLSL parser on npm: glsl-parser or use @shaderfrog/glsl-parser. If network works for npm, I can npm install @shaderfrog/glsl-parser in /tmp and validate syntax. That catches syntax errors (not semantic). Worth doing.

Let me plan time: writing ~900-line HTML file with careful shader. Then extract GLSL → validate with parser if installable; JS → node --check; IDs cross-check; CDN check; then add card 006 to index; final verification.

Also test-run the demo logic headlessly? The physics here is in-shader; JS side is straightforward.

One more shader consideration: pow(r, 5.0) when r<1 excluded by capture check before. r min = camera min distance... camera could be at r=1.6 min, fine. If user zooms inside 1.0? minDistance 1.6 prevents.

If acc huge near r→1: h2 ≤ r² (|v|~1) → acc ≤ 1.5 r²/r⁵ = 1.5/r³ ≤ ~3.3 at r=1.1. dt=0.012 → dv=0.04 stable. Good.

v drift: |v| grows slightly under integration; normalize every step would alter geodesic but stabilize. Pseudo-Newtonian light bending commonly renormalized. I'll add v = normalize(v) * 1.0 after adding acc*dt? Many implementations don't; drift small over 256 steps with dt small. Actually the analytic preserves |v|=1; Euler integration error accumulates |v| up to few % — changes bending slightly, acceptable. I'll leave as-is (matches common shadertoys) but use normalized v for disk doppler and background.

Also: color accumulation could exceed bloom threshold nicely (HDR). ACES tonemap via OutputPass.

Initial camera distance 9 rs; disk out 12 rs → disk extends beyond camera distance — camera INSIDE disk outer radius region sometimes (when y≈0) → crossing at step 0 with weird big hit flash. To avoid: default cam at y=3.2 dist ~9; orbiting below disk out radius crosses disk plane within radii → you'd pass through disk → brief white flash then continue — actually physically you'd see disk up close = flash is fine/realistic-ish. But at default distance 9 < diskOut 12, orbiting to edge-on passes through disk plane INSIDE disk → whole screen flash then black-ish absorption. Mitigate: default camera distance 14 (outside disk out 12). Set minDistance 1.6, max 45, start at (0, 4.5, 13.5) dist≈14.2. Good. When user zooms into disk, flashes expected (cool even).

Camera near/far: 0.1/500 fine.

Let me also handle context: disk Color function needs uCamPos for doppler toCam — available as uniform.

For performance stat: "rays ≈ (whscale²)" — skip; show FPS, distance, steps, trans? Keep FPS/dist/steps.

Edge: if(float(i) > uSteps) break; — i from 0..uSteps. ok.

Write the file now. Also remember <!-- New demos are added here --> and add 006 card to index after.

GLSL: one more check — three ShaderMaterial fragment gets precision highp float; auto + defines. Using gl_FragCoord fine. Don't redeclare precision. Uniform declarations at top fine.

vnoise hash13(i+vec3(0,0,0)) — vec3 constructor with three floats OK.

fbm loop for(int i=0;i<4;i++) — i shadows nothing; inside main loop later also uses i — separate scopes fine (but GLSL ES 3.0 scoping OK).

In background(): float scale name conflicts? fine. L==0 ? 40.0 : 90.0 — ternary with int condition: L is int, L==0 bool OK.

diskColor(hit, rayDir) — I'll pass v (current direction). Signature: vec4 diskColor(vec3 hit, vec3 rayDir).

atan(hit.z, hit.x) — two-arg atan OK.

pow(uDiskIn / r, 1.5): uDiskIn/r ≤ 1, fine. pow with negative base errors — none.

pow((h - thresh)/max(1e-4, 1.0-thresh), 2.0) — argument ≥ 0 since h>thresh. OK. Actually simplify b = (h-thresh)/(1-thresh) clamp; fine as written.

vec3 sc = mix(vec3(0.65,0.75,1.0), vec3(1.0,0.8,0.6), hash13(id + 19.19)); — id+19.19 vec3+float → adds to each component. OK.

Background call: background(normalize(v)) — v may be unnormalized; normalize fine.

For disk inner-edge bright rim: add extra emission near s~0: rim = exp(-s*18.0) * vec3(0.6,0.8,1.3) * 2.0 add to emission — creates glowing ISCO rim.

Alpha: alpha = clamp(prof*0.85 + rim*0.3, 0.0, 0.95) — keep trans falloff.

prof formula: smoothstep(0,0.06,s)(1-smoothstep(0.55,1,s)) * (pow(1-s,1.35)2.6+0.15). At s→0 pow→2.6+0.15 but smoothstep→0. Peak near s≈0.06. Emission values ~ tcol(≤4) * streak(≤1.55) * prof(≤2.7) * boost(≤~5) → up to ~80 HDR — very hot; scale down: prof factor 2.6→1.4, boost pow 3 with clamp max 4 → ≤64... too hot. Let me temper: hot=vec3(0.72,0.85,1.25)2.2; mid1.5; boost clamp(1+uBeamdopbeta1.8, 0.2, 2.6) pow 2 → ≤6.8. Emission ≤ 2.21.551.556.8 ≈ 36 still hot at extreme inner+beaming. Bloom threshold 0.6 → strong glow there: desirable actually (bright inner rim + beamed side). ACES will roll off. Set bloom strength default 0.7, radius 0.5, threshold 0.55. OK — artistic tuning blind, but ranges reasonable. Exposure default 1.0 slider.

Alright — also float dt declared outside loop then assigned inside; GLSL fine.

Loop: for(int i = 0; i < MAX_STEPS; i++) with #define MAX_STEPS 256 — fine.

if(float(i) > uSteps) break; — uSteps up to 256; i max 255; OK.

One more: p.y * pn.y < 0.0 exact zero crossing rare miss fine.

Also initial crossing check when camera exactly y=0? p.y=0, pn.y != 0 → product 0, not <0 → miss first, caught next step. fine.

Now HTML skeleton — write it. Also include mobile touch: OrbitControls handles; panel scrollable; sliders touch. touch-action none on canvas.

Snapshot with bloom composer: canvas.toBlob after composer.render() — preserveDrawingBuffer not needed if toBlob called synchronously after render in same frame (005 does this pattern — works because no other GL work between). Keep same pattern (shotRequested flag).

Pause: stop uTime advance + autoRotate off? Pause only disk/anim time. Space toggles.

Cinematic: autoRotate on + hide panel + dim hud; toggle C.

Reset cam: set position (0,4.5,13.5), target 0.

Let me write the whole file now carefully. Estimate ~700-800 lines. Then validations. Then update index with card 006.

For the index card:

• Demo 006: "Event Horizon — Black Hole Lensing"
• desc: "A real-time gravitational-lensing ray marcher — every photon's path is bent through a Schwarzschild field as you orbit a black hole with a doppler-beamed accretion disk, Einstein-ring starfield, bloom, and cinematic auto-orbit."

Let me write the demo file.

Also small detail: title gradient CSS. Panel slider rows HTML:

CSS for range: reuse typical styling: appearance none, height 4px, rounded, gradient thumb. Write once.

Buttons: .btn grid2; presets grid3.

kbd styling.

OK writing now. I'll assemble the full file in one write.

Careful in JS template literals containing ${}? The GLSL is inside /* glsl */backticks — avoid${` in GLSL (none). OK.

uResolution update: after composer.setSize, get drawing buffer size:

Do in resize() and renderScale change.

FPS EMA + stats 4Hz like 005.

Render loop:

autoRotate handled by controls.update with enableDamping.

Pause also pauses autoRotate? Keep autorotate running (camera still moves) — pause only disk time. Fine, call it "Freeze disk".

Let me write out. I'll number steps uniform as float: uSteps.

Slider mapping:

• sldQuality: t→ steps = 60 + t*196 (60..256); text round.
• sldScale: t→ 0.5 + t*0.5; text % ; on change → applyRenderSize().
• sldDiskIn: t→ 1.8 + t*2.7 (1.8..4.5)
• sldDiskOut: t→ 6 + t*14 (6..20)
• sldTemp: t→ 0.5 + t*1.5 (0.5..2.0)
• sldSpeed: t→ 0 + t*3
• sldBeam: t→ 0 + t*2
• sldStars: t→ 0 + t*1.5
• sldBloom: t→ 0 + t*2.5 → bloomPass.strength
• sldExposure: t→ 0.3 + t*1.7 → renderer.toneMappingExposure

Presets use .set(t) computed inverse. Store slider objects: const S = { quality: bindSlider(...), ... }.

Preset apply:

Presets: gargantua default; set active class.

Disk uniforms: params mirrored into uniforms each frame or on change — simplest: on change set uniform directly in toParam (bloom like 005). uTime managed in loop.

Let me now write the file. Also #panel.closed .body {display:none} toggle pattern.

Also handle WebGL2 absence: three r160 requires WebGL2; add try/catch on renderer creation → show message. Minor: wrap in try { } catch(e) { document.body.innerHTML = msg }.

Write now.

After writing: extract module → node --check; extract GLSL → try npm i @shaderfrog/glsl-parser and parse both shaders; check IDs; curl CDN (already known good, same URLs); then update index (insert 006 card at top of list); verify.

Note: my demo has only ONE shader material (lens). Background/disk all inside. No other custom GLSL. Good.

Also cross-check uniform names used in JS vs declared in GLSL.

Let me write the file.