3D solar system · step-5-preview

Three.js r128-ish. Let me check the version and whether Sprite/SpriteMaterial, LineLoop, etc. exist. It's r128 probably. Let me write the app.

Key features:
- Sun + 8 planets with colors, labels (use CSS2D-like overlay? No, only core THREE. Use sprites with canvas textures for labels — that's procedural. Or HTML div labels projected via camera. Both fine. Sprites via canvas are simplest and always readable.)
- Orbital path lines
- Starfield (points)
- Animation with different speeds
- Camera orbit controls (custom, drag to orbit, wheel to zoom)
- Pause/Resume, Reset view buttons

Let me check the version string.

Three.js r128. Good — Sprite, SpriteMaterial, CanvasTexture, Points, LineLoop all available.

Now write index.html.

Design:
- Scene with starfield (Points with procedural random positions, sizes).
- Sun: sphere with MeshBasicMaterial (emissive) + point light + glow sprite.
- Planets: spheres with MeshStandardMaterial or MeshPhongMaterial (procedural color). Add slight banding via vertex colors? Keep simple but distinguishable. Maybe use MeshStandardMaterial with roughness, plus a subtle procedural pattern via canvas texture per planet (rings for Saturn, etc.). Canvas texture generation is procedural — allowed.
- Orbital rings: LineLoop with LineBasicMaterial, faint color.
- Labels: canvas-textured sprites above each planet, scaled with distance so readable. Also render labels only when planet is in front of camera. Sprites always face camera. Use sizeAttenuation false and scale based on aspect... Simpler: sprite with sizeAttenuation false, scale in NDC-ish units. With sizeAttenuation=false, scale is in fraction of viewport height for y... Actually in three, sprites with sizeAttenuation false: scale.x is in... the sprite size in world units, then mapped such that scale of 1 = full viewport? Let me recall: In SpriteMaterial with sizeAttenuation false, the sprite's scale is applied in screen space: matrix makes size in clip space... The shader: `scale` goes into `mvPosition`, and with no attenuation, the final position uses scale directly in NDC roughly: 

```glsl
vec2 scale;
scale.x = length(vec3(modelMatrix[0]...));
...
#ifndef USE_SIZEATTENUATION
  bool isPerspective = isPerspectiveMatrix( projectionMatrix );
  if ( isPerspective ) scale *= - mvPosition.z;
#endif
```
Then `gl_Position = projectionMatrix * mvPosition + vec4(transformed, 0,0)` — with -mvPosition.z, scale effectively in view-space units. So scale of 1 ≈ 1 world unit → that's actual perspective size at that depth. Hmm, so with sizeAttenuation false, the sprite keeps constant size relative to... Actually with `scale *= -mvPosition.z`, a value of 1 world unit at depth 10 becomes projection * (1 unit at that depth) = constant screen fraction. So scale 1 → the projected size of 1 world unit at that depth, which is constant on screen regardless of distance. Good: so constant pixel-size is scale ~ (desiredFrac * distance). That varies with distance. 

Alternative: use HTML labels via DOM divs projected each frame. That's easy and readable, and I control font size. Since it's all in-page, no network. I'll do HTML labels: a div per planet, positioned via projection, hidden when behind camera. That gives crisp text. Plus keep them legible.

Let me do HTML labels with white text and a small dark rounded background, plus leader offset. Also handle overlap a bit — fine.

Camera controls: custom orbit control
- spherical coords: radius, theta (azimuth), phi (polar)
- pointerdown/move/up with pointer capture, drag rotates
- wheel adjusts radius clamped [minR, maxR]
- Also touch support.
- target = (0,0,0)

Initial framing: fit whole system. Radius max for Neptune orbit ~ 60 units. Camera at radius ~140, phi ~ 65° elevation... Actually polar phi from +Y axis. Use phi = 1.1 (about 63° from top), theta = -0.6. Distance 150 gives full view with fov 55: visible height at 150 = 2*150*tan(27.5°) ≈ 156. Hmm need to include labels above. Let's design distances:

Planet orbit radii (schematic):
Mercury 8, Venus 11.5, Earth 15.5, Mars 20, Jupiter 28, Saturn 36, Uranus 45, Neptune 54.
Planet radii: 0.5, 0.9, 1.0, 0.7, 3.0, 2.5, 1.8, 1.7. Sun radius 5.

Camera distance initial 145, fov 50 → half-height at 145 = 145*tan(25)=67.6, height 135. Diameter of Neptune orbit = 108 plus planet radius → fits in 135. Width also fine (aspect ~1.5). Good. With labels offset above planets (~2-3 units), fine.

Orbital speeds: relative periods schematic: base = 2π * k / periodFactor. Use angular speed = w0 / (orbitRadius^0.7)? Requirement: inner planets faster. Use speed = 0.9 / (r^0.85) maybe. Let's use: speed_i = 6 / r_i^1.2? For r=8: 6/12.1=0.49 rad/s; r=54: 6/94=0.064. That's fine and monotonic. Let me use a fixed dict of relative period constants to be more planet-like: Mercury 1.0, Venus 1.6, Earth 2.5, Mars 4.5, Jupiter 14, Saturn 35, Uranus 90, Neptune 160. speed = base/period, base=1.2 → Mercury 1.2 rad/s (too fast? one orbit in 5.2s — fine for demo). Neptune 0.0075 rad/s → orbit in 840s = 14 min, quite slow but that's realistic-ish relative. Maybe compress: use sqrt of period ratio: period_factor = sqrt(relativePeriod) → Neptune 12.6 vs Mercury 1. speed = 1.1/period_factor. Neptune: 0.087 rad/s → orbit in 72s. Good. Mercury: 1.1 rad/s → 5.7s per orbit. Slightly fast but visible motion. Let's use period_factor = pow(rel, 0.6): Mercury 1, Venus 1.33, Earth 1.73, Mars 2.53, Jupiter 4.66, Saturn 6.4, Uranus 7.7, Neptune 9.5. speed = 0.75/period_factor → Mercury 0.75 (8.4s/orbit), Neptune 0.079 (79s/orbit). 

Also add axial rotation of planets and Saturn ring, and maybe moons? Optional — Earth's moon could be nice. Keep it: add Moon around Earth for charm. Small cost.

Pause: freeze simulation time (planets motion) but camera still works. Buttons: Pause/Resume toggle, Reset view.

Also add a small info panel listing planets? Optional. Maybe a legend with planet colors + labels toggle. Keep UI minimal: buttons top-left, hint text. Maybe a "Toggle labels" is extra; skip or include briefly. I'll include label toggle? The requirement says readable labels. Keep always on.

Starfield: 4000 points at random on sphere shell radius 600-900, using PointsMaterial with size 1.2, sizeAttenuation false... For stars, use sizeAttenuation false with round/square points. Add slight color variation via vertexColors.

Also maybe add a faint galaxy band? Skip.

Procedural textures: generate canvas textures for planets (noise-ish bands) to make them distinguishable beyond color. Use a simple hash-based value noise per planet with band shapes. This is nice but adds code; I'll do a compact procedural texture: for terrestrial planets, mottled blobs; for gas giants, horizontal bands with varying colors; Saturn ring texture. Let's implement compactly.

Implement noise: simple value noise 2D with hash, fbm 4 octaves. Per pixel canvas 128x64 (seamless in x? wrap by using angle-based x with cos/sin — makes seamless). Use x → angle mapping so wrapping is seamless. Good.

Texture: for i in 0..w, j in 0..h: u=i/w, v=j/h; sample fbm at (cosT stuff)... Simplest: use 2D noise with u*w0 offset, but wrap issue at seam. Use spherical-ish coordinate: pos = (cos(2πu)*k, sin(2πu)*k, v*k) and sample 3D noise → need 3D value noise. Doable: hash3 based. Let's implement value noise 3D with smoothstep interpolation. Small code, fine.

Actually simpler: use 2D noise on coordinates (u, v) but mirror: sample noise at (u*2 if u>0.5 else...). Meh. Let's just do 3D value noise; ~25 lines.

Rings for Saturn: RingGeometry with a procedural canvas texture (radial alpha bands), transparent, DoubleSide, rotated.

Sun: MeshBasicMaterial with procedural emissive texture + additive glow sprite + PointLight.

Also add a subtle ambient light so dark sides aren't pitch black.

Also handle window resize, devicePixelRatio cap.

Let's also handle: pointer events on renderer canvas with pointer capture, prevent default for wheel (passive false).

Label projection: for each planet compute world position, project to NDC, if z<1 and within bounds, set label left/top with translate(-50%, -100%) offset above. Use a small dot. Also add label for Sun.

Overlap: with 8 planets no big deal.

Add distance-dependent label fade? Not needed.

Now, verification via browser tool: read DOM, check console errors, screenshot.

Let me write the file.

Also note the runner inlines three.min.js. So <script src="three.min.js"></script> then my script. Use defer or place at end of body.

Let's write code.

Custom orbit control implementation details:
state: theta (azimuth), phi (polar, clamp 0.05..π-0.05... but better limit to 0.15..1.6 to avoid flipping under the plane? Allow full but clamp to avoid gimbal weirdness: 0.05..π-0.05). radius: clamp 40..400.
damping: velocity smoothing for nice feel. Use lerp toward target values.

Implement with simple smoothing: current += (target-current)*0.15 each frame.

Drag: on pointermove, targetTheta -= dx*0.005; targetPhi -= dy*0.005.

Wheel: targetRadius *= 1 + delta*0.001 clamp.

Reset view: set initial target values (theta/ph/radius) and animate.

Also touch pinch zoom? skip; single touch drag works.

Also keyboard? optional: space to pause. Add.

Now the animation loop: clock delta, if !paused simTime += dt. Update angles: angle = angle0 + speed*simTime. Planet position x = cos(angle)*r, z = sin(angle)*r. Planet rotation.y += rotSpeed*dt when not paused.

Let me write everything now.

For labels I'll create divs in a container with pointer-events none.

Let me write the HTML.

One concern: with `three.min.js` r128, `THREE.CanvasTexture` exists, `texture.encoding = THREE.sRGBEncoding`. In r128, outputEncoding exists on renderer. Set renderer.outputEncoding = THREE.sRGBEncoding; and map.encoding = sRGBEncoding for color textures. Fine in r128.

Let's produce the code.

Also ensure the pause button text updates.

Write file now.

Wait — placeBody is called with dt for each frame; but if we call it for all bodies with dt, then angle += speed*dt, fine. But placeBody is only called when not paused — good. However, initial positions: bodies[].angle random, but initial position is at (dist,0,0) until first placeBody — fine, since render loop calls placeBody immediately.

Issue: the label offset uses world position + y offset; for Mercury at distance 10, camera might be inside. Fine.

Also potential issue: PolarGridHelper in r128 — material is an array? PolarGridHelper uses LineSegments with LineBasicMaterial (vertexColors? In r128 it's LineBasicMaterial with color). Let me check: PolarGridHelper constructor uses `LineBasicMaterial` with colorParam. It's a single material I think. Actually in r128 PolarGridHelper uses `LineBasicMaterial`? Let me verify quickly. Also check for `g.material` being array.

Let's test in browser.

Single material (tn = LineBasicMaterial). Good. Let's run the browser to check.

The browser tool in this harness — what actions do exist? Let me check the schema of "browser" tool... Actually the available tools listed are read, bash, edit, write, browser. The browser action enum includes inspect, reload, screenshot, click, drag, key, type, scroll. But there's no "open" — maybe the browser is already running a page. Hmm, what page does browser currently show? Perhaps I need to reload with the file path? Let me try inspect first to see current state.

The app is running (browser tool apparently already had the file open — maybe it opens index.html in cwd automatically). Labels are rendering. Everything looks good. No console errors (only driver perf warnings).

Now check orbital motion over time, pause behavior, reset view, and camera drag.

Note the labels seem to be above planets but the Sun label at top-right? Actually "Sun" label near Sun center appears to be at the Sun's position — good.

One issue: the Sun glow sprite is large and covers... fine.

Let's verify motion: take screenshot now and compare after a wait. The browser tool has no "wait" other than actions. I can use inspect/screenshot twice — some time passes between calls.

Let's check Mercury position relative to the Sun: it's to the right of Sun (x positive). Wait screenshot after ~1.5s to see it move.

Test pause: click Pause button at coordinates ~ (58, 105)? The panel is at top-left, 12px padding. Button "Pause" — approx x=60, y=105. Let me click and screenshot.

Also test drag on canvas center-right to orbit the camera.

Let me do these sequentially.

Motion confirmed: Mercury moved from right-of-Sun to left/below, Venus moved to lower-left, Earth moved from top to lower-right, Jupiter moved from top to right. Good.

Now test pause: click Pause button. Coordinates: panel at left 12, top 12. Title row ~ 12+10 padding... The pause button appears around y=105 in image coordinates. Clicking at (x=62, y=105). Then screenshot and screenshot again to verify frozen. Then drag camera and verify still visible. Then Reset view.

Actually the drag will change camera; I can then use Reset view and compare to initial framing.

Let me click Pause first.

Hmm, the button still says "Pause" and status "Orbiting" — but planets moved from previous shot (Venus at top-left, Mercury near Sun, Earth moved up). Wait, the click may have missed the button. Actually planets did move between the two screenshots (this one vs previous): Venus was bottom-left, now top-left; Mercury left → right. So motion is ongoing → the click didn't hit Pause.

The Pause button in the image: panel spans roughly x 12..290, y 12..~135. Buttons row: "Pause" starts around x=22, y=~53? Let's estimate: panel padding 10px; title at ~22-40; row starts ~y=48. Button height ~28. So Pause button center ~ (55, 62). I clicked (62,105) which is likely the status text region. Let me click at (55, 60).

Wait, but in the screenshot, "Pause" text appears at around y=53-62 in the image. Yes, click (55, 58).

Pause works: status "Paused — camera still active". Now, while paused, drag to orbit the camera and confirm the view changes but planets don't move. Drag from (700, 500) to (400, 500) horizontally.

Note: the drag tool probably performs pointerdown/move/up. Let's do it.

Camera orbited while paused — whole system still visible, and planet positions unchanged relative to each other (same as before drag: Earth left of Sun, Mercury near Sun, Venus right of Sun, Saturn bottom, Neptune right edge). Good: camera works while paused.

Now test wheel zoom and Reset view. Let's zoom in with wheel (scroll action with delta). Then reset view button.

Zoom worked (camera closer, planets bigger, Neptune near edge). Planet positions unchanged (paused). Now click Reset view and verify it returns to the original framing.

Hmm — Reset view restores framing but there's a visible issue: planets look oddly positioned. Wait, the Sun label appears to the right of its planet, and labels for Mercury/Venus are offset to the right of their planets. Actually looking closely: the Sun is at center, "Sun" label to the right of it at same height — that's odd; label offset should be above. Hmm, in the first screenshot the Sun label was right of the sun too. The label is placed at y - 12 px... it should be above. The screenshot resolution may just make it look like it's beside. Actually "Sun" appears at the right of the sun glyph — with a leader line, could be that the leader is short and the text box horizontally centered... The leader line points down to the planet, so the label should appear above. In this screenshot "Sun" text appears at the same vertical level as sun center-ish. Hmm, but earlier screenshot also. It may be an offset of ~20px above; hard to tell at this resolution.

More concerning: after Reset view, the camera framing doesn't look exactly like the initial framing (the first screenshot). In the first screenshot: Mercury to the right of Sun, Venus bottom-left-ish, Earth top-left, Jupiter top, Saturn top-right, Uranus far right... Wait, that was AFTER motion had progressed for a while? No — the first screenshot was taken at load, and motion had been running. The planet arrangement here differs because planets have moved since (motion continued before pausing). But camera framing should match the initial camera pose: same theta/phi/radius. Comparing overall composition: first screenshot had Neptune top-left... now Uranus is at right edge cut ("U" visible). Hmm, the reset framing shows Uranus partly off-screen at right edge? That suggests the framing is a bit tighter/different from the initial.

Wait — actually the drag changed theta, and reset restored theta=-0.62, phi=1.02, radius=150. The initial framing was the same. But screenshots differ in which planets are where — that's due to motion, which is expected. The apparent "Uranus at right edge" — in the first screenshot, Uranus was at top-right area and Neptune even further. Now Uranus is right edge, cut off. That's just because the orbital angles differ, not the camera. Since Neptune (further out) is now at bottom-right off screen in this shot... wait no, Neptune isn't visible at all in the last screenshot! Hmm, let me look: labels visible: Sun, Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and "U" (Uranus's label is "U..." partially?). Actually the last label shown is "U" at right edge — that's Uranus's label cut. Neptune is not visible — its label is hidden because it's off-screen (behind/z or outside viewport). So part of Neptune's orbit is off-screen at the current camera azimuth. That's fine — it's the geometry (orbit radius 62 * 2 = 124 diameter plus), camera framing with fov 50 at 150 distance and aspect 1200/800=1.5: horizontal half-angle = atan(tan(25°)*1.5)= atan(0.466*1.5)= atan(0.699)=34.98°, so horizontal extent at 150 = 2*150*tan(35°)=210. Orbit diameter 124 fits. But perspective causes off-center orbits to be near the edges. So a planet at the far side of its orbit can go slightly outside the view. Acceptable — "Initially frame the complete system" mostly holds; at the initial framing, Neptune's orbit diameter fits within view (210 > 124), so the full ring is visible but a planet on the far edge can be near/just outside the top or bottom edge (vertical half-extent: 2*150*tan25=140 > 124, fits).

Hmm, but the reset framing vs initial should look identical in camera terms; they do.

Still, I'd like a slightly wider initial framing so planets never leave the frame. Let me set initial radius to 175 and maybe reduce to phi 1.0. At 175: vertical extent 2*175*tan25 = 163, horizontal 2*175*tan35 = 245. Full orbit fits comfortably. But then the system looks smaller. Let's compromise: 165. Vertical = 154, horizontal = 230. Neptune orbit diameter 124, so margin ~15 units vertically at center depth; near-side planets appear larger. Good enough. Let's use 168.

Actually the concern: at initial load, all planets should be visible. With radius 168 and a planet at orbit radius 62, its distance from camera ranges 106..230. At the far side (depth 230 with the orbit ring tangent... ) the vertical screen extent at that depth: fine. Planets at far side are farther away → project smaller. So a planet at the "back" of Neptune's orbit is at depth 168+62=230 from camera, screen extent 2*230*tan(25) vertically — but that's the frustum extent, and the planet's y offset is 0, so it's fine. Planets can only be off-screen if their projected position exceeds the frustum, which for a point in the plane y=0 at radius up to 62 with camera at 168... The half-height of the frustum at the center depth is 78; at depth 230 it's 106. So a Neptune planet at the far point is well within. The tightest case is the point where the orbit is tangent to the vertical frustum boundary: roughly x=±62 at z = ±sqrt(168²-62²)? Not exactly — the orbit is a circle of radius 62 in the plane, camera at 168 (elevated). Let me just test empirically: set radius 168 and check screenshots at a few times.

Actually risky and time-consuming. A safer approach: keep initial radius at 150 but the previous screenshots showed all 8 labels visible at initial load (all 8 planet labels + Sun were in the DOM, but that doesn't equal on-screen). In the first screenshot, I saw Neptune, Uranus, Saturn, Jupiter, Mars, Earth, Venus, Mercury labels — all 8 visible plus Sun. That's at whatever angles they had. At t=0 with random initial angles, it's possible some planet is off-screen briefly.

Let me compute the worst case for the current framing with radius=150, phi=1.02, theta=-0.62. Camera at height = 150*cos(1.02)=78.6, horizontal distance = 150*sin(1.02)=124.7. Consider a planet at orbital position p=(62cos a, 0, 62 sin a). Project into camera space. Let's just do a quick numeric script in node? Node is available. Let me write a small script to compute max |x_ndc| and y_ndc over a in [0,2π) for radius 62 and check within ±1. Use the projection: camera looks at origin from position C, up+Y. Compute view coordinates.

Let me do it quickly with a small JS snippet using THREE from file in node? Easier: compute manually with the view basis.

Actually let me just do it via node with three.min.js loaded as CommonJS... it's UMD, works in node (exports). Let's try.

Given time budget (15 min total, we've used maybe 8), let me do this quick numeric check, then adjust radius so that all planets across all angles stay within NDC ±0.92 (safety margin for labels).

At radius 150, worst NDC = 0.716 → all planets are within 72% of half-height/width for every angle. So all 8 are always visible at the initial framing (with labels offset ~12px + text height above the planet; NDC 0.716 = 0.716*400 = 286px from center vertically, and half-height is 400px, so 114px of room above — plenty for labels).

So why was Neptune's label missing in the last screenshot? Because the camera phi/theta was different at that time (the reset animation was in progress — the camera was still lerping toward the initial pose!). Indeed the reset uses smoothing: camTarget set to initial, and cam lerps at 0.18/frame. The screenshot was taken right after clicking, so camera was still mid-transition. Also "U" cut label = Uranus label partially visible.

So reset works, just animated. Let's confirm by waiting a couple seconds and screenshotting.

Reset view completed: the whole system is framed, all 8 planets + Sun visible, paused and frozen. 

One nit: the Sun label appears to the right of the Sun at the same height, while planet labels appear above their planets. Looking at the screenshot: "Sun" is at ~ (right of the sun), and "Earth" above Earth. Hmm actually the Sun label appears offset to the right — that's likely because the leader line goes up-left/right? The Sun's label position: world (0, SUN_RADIUS+1.2, 0) = (0, 6.2, 0), 12px above the sun's top. In the screenshot the Sun disc spans ~ y 395-505 in the image, center ~450; the Sun label at ~452-470? It looks nearly level, maybe 12-20px above the center top of the sun. It's fine — actually the label box top is at (y - 12) and the box bottom has the leader line, so the label's bottom edge is 12px above the sun's top surface, i.e., about 30px above center. In the screenshot the Sun's glow extends further. It reads fine.

Also I notice "Venus" and "Sun" labels overlap slightly? Venus label at (x~640, y~385) and Sun at (x~666,y~380). They are adjacent but distinct. Fine.

One more thing: the label for the Sun is at the same x as the sun (center). Yes.

Also let me verify Resume works after pause (click Resume) and check the console for errors — already no errors.

One more consideration: the label "Mercury" appears at the same spot as earlier... fine.

Let me resume and do a final check of the console + a longer motion sample to confirm inner planets are faster (Mercury moved much more than Neptune between screenshots — verified earlier: Mercury went from right to left across the sun while Neptune moved slightly).

Let me click Resume (the first button) and take a final screenshot, verifying motion resumes.

Also, potential issue: label overlap when paused/resumed — not important.

One improvement: since pause leaves camera active (verified) — done.

Final: resume.

Everything works. Final file is saved at /tmp/job-kiNXuG/index.html. Let me do a final syntax sanity check (the file is what's running, no console errors).

One last thing: kill the http server? Not necessary, but let me leave it. Actually let me clean up the background server to be tidy — it may keep running in the environment. I'll kill it.

Also the browser tab still runs the app; fine.

Let me stop the server.