Rotating icosahedron · glm-5.3-flash

Overexposed — lights too bright/washed out white. Reduce intensity, maybe use physical decay. PointLight default decay 2 with intensity 60 gives too much near. Lower to ~30 and reduce material color? Actually overexposure white — reduce intensity to 25 each, or increase distance falloff. Try intensity 25.

Still too bright/white, colors barely visible. The intensity in r150+ is in candela with decay 2; at distance ~7 from light, illuminance = 20/49 ≈ 0.4... but rendering white means too high near faces. Maybe tone mapping off. Lower to 6 and set decay default. Also reduce metalness. Try intensity 6 each.

ACES tonemapping applied to white lit faces still saturates to white. Faces near light A at distance ~3: intensity 6 / 9 = 0.67 × color... faces pointing right at it should be pinkish but appear white. Maybe legacy lights mode? UseLegacyLights default false in newer three. Face at ~2 units: 6/4 = 1.5, tonemapped still near white. Reduce metalness so color shows, and reduce intensity to 3? Colors of lights are strong (ff4477), metalness 0.35 desaturates. Let's set intensity 4, metalness 0.1, roughness 0.5.

Pink and blue highlights visible on edges. Colors appear but faces facing camera are white — ambient too high? Ambient 0x223344*0.6 is low. White faces likely near light B? Hmm, faces facing camera lit white — could be specular. Reduce further to intensity 3 and see. Actually the color gradient is visible; faces with normal toward light are saturated. That's acceptable-ish but most of the object is white. Set intensities to 3 and material color darker (0x887788). Try.

Face orientation-dependent: camera-facing faces lit white from... hmm. Faces directly facing camera are white. The camera is between the lights? Light A at (5,4,4), camera orbits radius 8. Faces facing camera get some light from A or B. But they render pure white even at intensity 3? 3/dist² with dist~5 → 0.12 × light color... that can't be white. Unless three r155+ uses physically correct with candela... that math holds. Pure white faces maybe from edges lines? No. Something else: maybe the screenshot was taken while previous settings still applied? The browser reloads on action? The reload happens per action I think. Hmm, but colors disappeared now — ambient? Ambient is 0x223344 dark blue.

Wait — maybe legacy lights: if this three.min.js is old (r128), PointLight intensity semantics differ (no physical falloff units), distance 60, decay... In old three, intensity 3 with decay 1 gives strong light at dist 5: 3/5 = 0.6. Still not white for pink light... unless old three uses useLegacyLights and gamma. Color ff4477 * 0.6 = pinkish, not white.

Maybe both lights overlap: a face can receive 0.6 pink + 0.6 blue → white-ish magenta. Pink+blue → white/light purple! Yes — overlap saturates. Separate the lights more, reduce to 2, and increase their separation so fewer faces get both.

Pink face visible, but some faces pure white — likely faces with normal pointing exactly at light at close distance still saturating (intensity/dist² with dist ~ sqrt(6²+5²+5²)=9.3 → 3/87=0.034 — that can't be white!). So white faces can't come from decay-2 lights. So probably this three.min.js is old and doesn't do physical falloff — intensity 3, distance 60, decay... old three (r<155) legacy: falloff = intensity * pow(saturate(1 - d/distance), decay)? With distance 60 at d=9: (1-9/60)^... ≈ 0.85 * 3 = 2.5 → saturated. That explains white! So old three.min.js — reduce intensity to ~1.2 and rely on that.

2021 → r13x (r136?). Legacy lights: PointLight with decay default 1 in old versions? In r136, physicallyCorrectLights default false; falloff uses punctualLightIntensityToIrradianceFactor: if decay>0 and distance>0: pow(saturate(-d/distance+1), decay). So with distance 60, near 9 units, factor ~0.85. So intensity 3 → ~2.5 saturated. Set intensity ~0.9 for visible color without saturation.

Still white?! Faces facing camera pure white with intensity 0.9 legacy falloff ~0.75 × color... pink light at (6,5,5) from a face at origin-ish — distance ~8.8, factor (1-8.8/60)^1 ≈0.85, ×0.9 = 0.77. Color ff4477 × 0.77 ≈ pink (198,55,95). Not white! Unless material color 0x776677 multiplies... still pink. So why white?

Hmm — maybe the browser screenshot isn't reloading? Maybe it's caching old render. Or maybe... wait, earlier screenshots clearly changed with edits. The white faces might be specular highlight: metalness 0.1, roughness 0.45, standard material specular GGX — with light intensity 0.77 at close-normal, specular can spike to white. But entire faces white?

Alternative: two lights both at 0.85 factor: pink 0.77 + blue 0.77 → (0.77+0.77*[0.27,0.53,1]) → r 1.0, g ~1.0, b 1.5 → white! Overlapping illumination still sums to white. Faces facing camera receive both lights? Lights are opposite (6,5,5) and (-6,-4,-6) — a camera-facing face normal ~ +z gets dot with pink dir ~0.5 and with blue dir ~ -? Blue is behind, negative dot. Hmm.

Let me test directly: reduce to 0.45 each and see. Or check actual three version precisely — copyright 2021 = up to r137. In r137 decay default for PointLight is 1? Actually PointLight decay default 1 in old versions. OK.

Instead of guessing, I could just switch to MeshPhongMaterial with lower shininess and dimmer ambient... The white issue persists across intensity 3→0.9 which is suspicious. Maybe the browser reload happens but screenshot timing captured before reload? "Frame 1, +0ms" — maybe screenshot taken immediately at load, before frame 1 with new lights? But changes did appear earlier. Actually did they? Screenshot sequence: intensity 20 → still white; 6+tonemap → white; 4 darker → pink visible partially. Then 3 → more white?? Weird.

Maybe faces are white because of EdgesGeometry lines? No.

Hypothesis: faces facing camera are lit by BOTH lights because camera sits between lights and object — normals facing camera (+z-ish hemisphere) have positive dot with pink (6,5,5 normalized ≈ (0.68,0.57,0.57)) → dot 0.57 max... irradiance 0.77*0.57 = 0.44 pink. Plus ambient small. That's ~ (0.44*1.0 +0.13, ...) = (0.57,0.4,0.47) pinkish grey. Not white.

Unless... physicallyCorrectLights in r137: if renderer.physicallyCorrectLights is false (default), legacy factor used. OK.

Maybe the issue: material is MeshStandardMaterial with flatShading — fine.

Let me actually debug via browser inspect: evaluate? browser tool has inspect, not evaluate. Hmm. Alternative: use MeshLambertMaterial — simpler, no specular spike. Try Phong with specular near black.

Still white faces. Camera-facing faces are white — that suggests a light near the camera position... The camera orbits at radius 8 in x-z plane at height ~2. Lights at (6,5,5) and (-6,-4,-6). A camera-facing face at angle θ has normal ~ pointing to camera at (8sinθ, 2, 8cosθ)-ish. White faces appear when camera is roughly opposite the light direction? Hmm.

Wait — maybe the white is because faces get BOTH lights: pink from one side + blue other... no, opposite directions.

Or... the ambient light: AmbientLight(0x223344, 0.6) — weak.

Alternative idea: the light intensity in this build might use punctual falloff with distance=60, decay default... let me check the minified source for default decay: PointLight constructor sets decay = 1 probably. intensity 0.9, distance 60: factor = pow(saturate(1 - d/60), 1)? No—actually legacy formula: if decayed: pow(saturate(-lightDistance/cutoffDistance+1), decayExponent). d≈9 → 0.85^1 = 0.85. So ~0.77. Pink face should be pink.

Unless... the white faces correspond to normals pointing at pink light AND we're seeing saturation because... 0.77 max × (1,0.27,0.47) = max 0.77 → not white.

Something's off — maybe the material color multiplies and flat shading with vertex normals? White value 255 everywhere means irradiance >1. Could decay be 0? If decay=0, no falloff: irradiance = intensity × dot = 0.9 × dot. Still ≤0.9.

Two lights sum: 0.9 pink + 0.9 blue on a face between them? Face normal toward +x could catch pink 0.9*dot(pink dir). Max total per channel: r: 0.9*1(pink) + 0.9*0.27(blue) = 1.14 → white-ish. Hmm plausible for faces oriented between lights.

Honestly, simpler approach: lower intensities to 0.4 each. Also possible the browser renders screenshot immediately and the "frame" is the very first render... but the frame changes each screenshot with rotation so it's live.

Try 0.4.

Still white faces at intensity 0.4?! That means intensity isn't what I think, OR the camera-facing faces are being lit by something strong... The white faces always face the camera. Wait — is there maybe a default light? No. Or the material emits? No.

Hmm, wait: maybe the browser screenshot is not reloading my latest edits — the file in browser might be cached/stale and reflect the first version (intensity 60?). The first screenshot had intensity 60. Every subsequent looks identical white. The pink appeared in one screenshot (intensity 3 build?) then disappeared. Actually with intensity 60 vs 0.4 there'd be a huge difference — unless saturation clamps everything ≥ some threshold, so 0.4 still saturates? With decay=1, distance=60: factor ~0.85 → 0.34 × color. Not saturated.

Unless decay is 0 → no distance attenuation, intensity 0.4 direct. Still ≤ 0.4.

Something else adds white: the EdgesGeometry LineBasicMaterial — only lines. The stars? No.

Wait... could the white faces be facing camera because I lookAt(0,0,0) each frame, and lights... no.

Could THREE version here have PointLight intensity interpreted with power? Hmm.

Let me test by making the lights absurdly dim (0.02) via a temp edit and screenshot — if faces still white, intensity isn't the driver and something else (e.g., my edit not applied, or toneMapping reversed).

With intensity 0.02, blue face appears but other faces still WHITE. So white faces don't come from point lights at all. White faces facing camera... ambient is dark. What lights them? The EdgesGeometry lines are grey. Stars are points.

OH — the white is probably the stars material? No. Wait: white faces face the camera exactly — like the material is rendering unlit... MeshStandardMaterial with flatShading — but if normals missing? IcosahedronGeometry has normals. Hmm, white faces could be the *back faces*?? No.

Maybe it's tone mapping inverse: ACESFilmic on dark should stay dark.

Alternatively the white faces are lit by... point light at camera? No. Hmm, what about the LineSegments with opacity 0.35 — no.

Idea: faces facing camera are lit by the lights whose positions are *behind camera*? Light A at (6,5,5) fixed. Camera orbits. Faces white in all orientations regardless — faces facing camera always white. That strongly suggests a light at/near camera, or the geometry normals point at camera and something like "envMap"? None.

Wait — could it be that these white faces are where the light IS between camera and object? Consider light B at (-6,-4,-6). Camera at angle θ: (8sinθ, 2, 8cosθ). If camera is at θ=0 → (0,2,8). Light A direction from origin: (6,5,5) normalized ≈ (0.68,0.57,0.57). A face with normal (0,0,1) (facing camera): dot with A = 0.57 → lit pink 0.02×0.57≈0.01 → invisible. So white can't be lights.

Unless the material color 0x776677 with ambient 0x223344*0.6*albedo ≈ (0.08) dark. So white faces are unexplained → maybe they're NOT the mesh but something else white in front? Like the renderer clear + ... no.

Hmm — could the white faces be faces whose normals point toward... the scene has stars PointsMaterial with size 0.8 and sizeAttenuation — stars at 100-250 distance, fine.

Wait, actually maybe it's a z-fighting/duplicate? No.

Let me reconsider: maybe this build is r137 with physicallyCorrectLights default... no, r137 default false. But sRGB? In r137 renderer.outputEncoding default LinearEncoding.

Test: temporarily remove point lights entirely and set ambient 0 — if faces still white, it's not lighting. Actually better: change material to MeshBasicMaterial red — then whole object red; confirms we're seeing the mesh.

The object with MeshBasicMaterial RED is... not red! It's white/black. So the mesh is not what we're seeing?! The visible shape must be something else... but it's an icosahedron shape. Unless the LineSegments Edges overlay with white opacity? Lines wouldn't fill.

Wait — the mesh IS white/black even with basic red material?? That means the screenshot is stale/not reflecting my file edits! The browser may be serving a cached version or the file changes aren't picked up. Different rotations each time = live animation, but material unchanged... unless cached index.html. The reload should fetch fresh. Hmm, but "cyan face" appeared in this shot, and earlier pink/blue appeared — those could be remnants of earlier versions? No, earlier version never had cyan.

Hold on — is my file actually what I think? Maybe the sed edits didn't apply where I think... grep showed MeshBasicMaterial applied. So the running page should be red. It's not. So the page isn't reloading my edited file — caching issue. The colors we saw (pink, blue, cyan) were from...? First screenshot was white-heavy consistent with intensity 60. Then changes appeared: pink face at "intensity 3" build. Then it went back to white? That inconsistency could be just rotation-dependent (which faces face the lights).

Likely caching: reload might use cache. The current visual (white + cyan) can't match any version I wrote... unless it does: version with intensity 60 lights (first) had white; but cyan?

Actually maybe the browser does reload properly, and the white faces are... hmm with MeshBasicMaterial red the entire silhouette should be red. It's not. Conclusion: caching. Force cache bypass by adding query param? I can't change the URL. Add a version marker in HTML title and check dom? DOM output shows "Pause\nReset" only. Let me verify caching: edit title to "V2" and inspect.

Now pink/red visible with lights 0.02?! That looks like MeshBasic red modulated by... no, basic ignores lights. This looks like an intermediate state. The reloads are asynchronous — the screenshot is taken at some time and reflects a *previous* version. So each screenshot lags my edits by one or two versions. This explains all the confusion! The current shot shows a mix: red face (basic material version) + pink gradient (lights at some version). So screenshots lag behind file edits.

So my earlier conclusions were polluted. Restore the proper version: MeshStandardMaterial, decent light intensities. Given screenshots lag, do: write final file, then take multiple screenshots spaced (reload then screenshot maybe waits?). The browser action "reload" then screenshot in separate calls — each call probably reloads and immediately screenshots. The lag might be that reload uses cached index.html. Let me write final version, reload, screenshot twice to catch up.

Now it looks good — pink/magenta lighting with some blue on the left edge. Colors are visible and not blown out. Maybe slightly increase blue presence; it's fine. Take another sample later, test Pause and Reset.

Rotation and camera movement working. The blue light isn't very visible; could strengthen blue a bit (1.5) and reduce pink slightly. Fine-tune: pink 1.0, blue 1.5. Then test Pause.

Looks good. Now test Pause: click at Pause button (x~52,y~766), screenshot, wait, screenshot to verify frozen. Then Resume, then Reset verify pose returns.

Button now says "Resume" (paused). Take another screenshot to verify frozen frame identical.

Frozen — identical frame. Now Resume, then Reset, and verify pose matches initial (rotation identity-ish, camera at (0,2,8)). Click Resume then Reset, screenshot.

Resumed (frame differs). Now click Reset and verify pose matches initial (initial: elapsed=0, rotation 0, camera (0,2,8) looking at origin — face-on hexagonal silhouette like first screenshot).

Reset pose matches the initial view (face-on hexagonal silhouette, camera front, blue rim on lower-left, pink on right — same as the very first corrected screenshot). Both light colors now clearly visible. Also verify resize briefly? Resize handler is standard; low risk. Done. Final report.