3D solar system · mimo-v2.6-pro

Let me start by checking the working directory and the three.min.js file.

Three.js r128-ish (2021). Let me check if it's the UMD build (global THREE) — yes, "object"==typeof exports... else define... else (t.THREE = ...). Let me confirm features: SphereGeometry available (r128 has SphereGeometry as alias of SphereBufferGeometry). Let me check quickly.

REVISION=e — minified differently. Let me find the revision value.

Three.js r128. Global THREE. No OrbitControls — I'll implement my own camera orbit controls.

Now let me build the app. Key features:

1. Sun + 8 planets with distinguishable colors, labels (CSS2D-like via HTML overlay divs projected manually — since CSS2DRenderer isn't available in core; I'll project 3D positions to screen with `project()` and position absolutely-positioned divs).
2. Orbital paths (LineLoop / RingGeometry lines using EllipseCurve or BufferGeometry from circle points).
3. Procedural starfield: Points with random positions, plus a large inverted sphere with procedural gradient maybe. Keep it simple: Points with sizeAttenuation, plus maybe some colored stars.
4. Animate planets orbiting with different speeds (angular velocities inverse-ish to distance).
5. Camera: initial framing of complete system; drag to orbit around sun (spherical coords theta/phi); wheel zoom within bounds (e.g., 30 to 400).
6. Pause/Resume and Reset View buttons. Pause freezes planet motion but camera still works.
7. Procedural materials/geometry: e.g., canvas-generated textures for planet surface (noise-based bands), sun with emissive glow (sprite with radial gradient canvas texture), starfield points.

Also nice extras: planet rotation, sun glow via sprite, orbit lines slightly tilted to be visible, saturn rings maybe (procedural). Keep it robust.

Labels: HTML divs in an overlay layer, updated each frame via projection. Hide labels behind? Not needed. Fade when too far? Keep readable with screen-space size.

Let me also add: hover highlight maybe not needed. Keep scope tight but polished.

Camera drag: mousedown/mousemove/mouseup on the renderer canvas, also touch support optional. Wheel with preventDefault.

Controls bounds: distance from 25 to 500. Initial distance: must frame the complete system — outermost orbit radius e.g. Neptune at 155 units. So camera distance ~ 300 with fov 50, looking at the sun. Ensure the outer orbit fits in view: with fov 50 vertical, at distance d the half-height visible = d*tan(25°)=0.466d. Need >= 160 → d >= 343 if camera looks edge-on at the ecliptic plane... Hmm, but the camera is slightly above the ecliptic so the orbit projects as an ellipse; the outer orbit fits if radius fits in the horizontal/vertical extent. Simplest: set initial distance so that the outer orbit radius fits comfortably: d ≈ 380, camera slightly above. Or reduce fov... Actually a wide-ish framing: set outer orbit radius ~ 150, initial camera distance 380, elevation angle ~ 62° from vertical (i.e., phi ~ 62°). Let's compute: camera at spherical (r=380, theta=0, phi=62° from Y axis). Looking at origin. Vertical half-angle = 25°, tan = 0.466 → half-height at origin plane = 177 units. The orbit of radius 150 in a tilted plane: the farthest point's projection... it's roughly fine. I'll verify visually with screenshots.

Also aspect: horizontal fov larger at 1200x800 (aspect 1.5), so half-width = 177*1.5 = 265. Fine.

Planet data (schematic):
- Mercury: color 0x9c8e7e (grayish), orbit radius 26, size 1.4, speed high
- Venus: 0xd9a066 / 0xe6c17a, radius 38, size 2.6
- Earth: 0x3b78d0 blue with green continents, radius 52, size 2.8
- Mars: 0xc1543c, radius 68, size 2.1
- Jupiter: 0xd8a26a banded, radius 92, size 7.5
- Saturn: 0xe0c68c, radius 116, size 6.4, ring
- Uranus: 0x8fd6d9, radius 138, size 4.4
- Neptune: 0x4a6fd9, radius 158, size 4.2

Speeds: omega = base / (radius^1.0)? Kepler-ish: omega ∝ r^-1.5 gives inner much faster. Use periods: mercury fast. Let's define angularSpeed = 0.6 * Math.pow(1/radius, 1.5) * something... Let's just use: angularSpeed = 26/radius^1.5 scaled. For radius 26: 26/132 = 0.197 rad/s → period ~32s. Neptune radius 158: 26/1981 = 0.0131 rad/s → period 480s (~8 min). Hmm maybe speed up outer a bit: use exponent 1.2: 26/r^1.2: 26 → 26/47=0.55 (period 11s too fast). Let's define base speed such that Mercury period ~ 20 s and Neptune ~ 120 s: use omega = k / r^p with p chosen: ratio of periods Neptune/Mercury = (158/26)^p = 6 = ... we want 120/20 = 6 → 6.08^p = 6 → p ≈ 0.98. So omega ∝ 1/r roughly. That keeps inner faster and both readable. Actually a bit of curve: p = 1.1 gives ratio 8 → Neptune 160s if Mercury 20s. Fine — use p = 1.05, k such that Mercury = 0.30 rad/s → period 21s, Neptune omega = 0.30*(26/158)^1.05 = 0.30*0.156 = 0.0468 → period 134 s. Good.

Also planets revolve around sun at center; add slight orbital inclination (few degrees) for visual interest — but labels and paths then tilted; keep inclinations small (0-3 degrees) or skip. I'll add tiny inclinations for realism but keep near-flat.

Sun: emissive material MeshBasicMaterial with procedural canvas texture (radial noise gradient), plus sprite glow with additive blending.

Textures procedurally generated with canvas: function makePlanetTexture(baseColor, opts) — draws noise bands/patches. Implement simple value noise with random blobs; use canvas 256x128 equirectangular with horizontal bands + speckles. For Earth add continents blobs. Keep it generic: bands parameter and blob parameter.

Starfield: 
- Background: large sphere with dark gradient? Just scene.background = black (or very dark blue) plus Points stars: 3000 stars in a shell radius 800-1500, colors varying white/blue/yellow, sizes random via vertexColors and sizeAttenuation... PointsMaterial has single size; use two Points objects with different sizes, or use ShaderMaterial (allowed, it's core). Simpler: 3 Points groups with different sizes/colors. Plus a faint Milky Way band? Skip.

Let me use custom ShaderMaterial for stars to vary size per vertex — that's fine, core THREE. But simpler is safer. I'll do 2-3 Points layers.

Labels: overlay div with pointer-events none; each planet label positioned via project(). Include name labels for Sun and planets. Also maybe a HUD title and instructions.

Buttons: Pause/Resume toggle, Reset view. Also maybe a "speed" slider — not required; skip or add small speed control? Requirements say only Pause/Resume and Reset view. I could add speed slider as bonus but keep simple. I'll skip extra to reduce risk. Actually a subtle "info" line showing sim time is nice. Keep minimal.

Reduced motion? Not required.

Now write the file. Careful with r128 API:
- THREE.SphereGeometry exists (r128 has SphereGeometry which is BufferGeometry-based). Yes.
- THREE.PointsMaterial with vertexColors: true (r128 uses `vertexColors: true`, not THREE.VertexColors — both work in r128; `vertexColors` boolean is preferred in r125+).
- THREE.LineLoop, THREE.BufferGeometry with setAttribute('position', new THREE.Float32BufferAttribute(...)).
- THREE.CanvasTexture.
- sRGB: renderer.outputEncoding = THREE.sRGBEncoding; texture.encoding = THREE.sRGBEncoding.
- Sprite with SpriteMaterial map + blending: THREE.AdditiveBlending.
- TorusGeometry for Saturn's ring? Better: RingGeometry with a canvas texture and alpha, side: DoubleSide. RingGeometry UVs are a bit odd (uv maps to square). I'll just use two rings with MeshBasicMaterial colors and varying opacity, or use RingGeometry with vertex colors radial gradient — that's doable: build ring geometry manually with vertex colors based on radius. Let's do: ring texture generated on canvas as a 1D-ish gradient strip and map to RingGeometry... RingGeometry's UV: u along theta? Actually in three, RingGeometry uv = (x/radius+1)/2, (y/radius+1)/2 — planar mapping. So a canvas texture with radial gradient centered works! Create canvas 256x256 with radial gradient bands (alpha rings), center transparent, and map with RingGeometry(outer*0.55? ) Hmm, RingGeometry(inner, outer) with planar UV where uv is in [0,1] over the bounding square of size 2*outer. So radial gradient from center: distance in texture corresponds to radius/outer. So I can draw alpha bands as function of radius fraction. 

Let me write the texture: for each pixel compute r = dist/128 (0..~1.41); alpha = band pattern for r in [inner/outer, 1]. Use canvas loop 256x256 = 65k pixels, fine.

Camera controls implementation:
- state: theta (azimuth), phi (polar), dist, target = (0,0,0).
- updateCamera(): position = target + spherical.
- drag: dx → theta -= dx*0.005; dy → phi -= dy*0.005, clamp phi to [0.15, Math.PI-0.15]... Actually clamp to [0.12, 1.45]? Allow going a bit below? Keep phi in [0.15, Math.PI - 0.15] to allow seeing from both sides, but limit near-poles to avoid gimbal weirdness. Standard OrbitControls: phi in [0, π]. Fine.
- wheel: dist *= Math.pow(0.95, deltaSign) clamp [30, 700]. Use e.deltaY.

Reset: tween camera to initial over ~1s using easing (nice). Implement smooth reset with lerp over 60 frames.

Also handle keyboard? Not needed.

Resize handler.

Label projection: for each body, world position (mesh.position), project with camera; if behind camera (z > 1) hide; else set left/top with translate(-50%,-100%) offset above body. Also scale opacity by distance maybe.

Edge: labels overlapping at initial framing for inner planets — acceptable; small font, readable.

Let me also show orbital paths as LineLoop with slightly transparent color per planet.

Pause: simTime not advancing; camera still updated each frame.

Now write the code carefully.

Noise texture generation function:

function makeTexture({base, bands, blobs, seed}) {
  const c = document.createElement('canvas'); c.width=256; c.height=128; const ctx=c.getContext('2d');
  // base fill
  ctx.fillStyle = base; fillRect;
  // horizontal bands with varying lightness
  for bands: draw horizontal stripes with rgba variations.
  // blobs: random ellipses with soft alpha (use radial gradients)
  // speckle noise: small dots
  return new THREE.CanvasTexture(c);
}

Need color helpers: use hsl strings, e.g. base as hsl. I'll pass hue/sat/light and generate variations.

Let me write a deterministic RNG (mulberry32) so results are stable.

Sun texture: radial gradient from yellow-white center to orange edges + some granulation dots; used on sphere with MeshBasicMaterial; plus sprite glow.

Alright, also add subtle sun light: THREE.PointLight(0xffffff, 2, 0, 1) at origin + ambient 0.25 so planets are lit on the sun-facing side. With MeshStandardMaterial? Use MeshLambertMaterial or MeshPhongMaterial for planets (cheap, r128 fine). MeshPhongMaterial with shininess 5.

Note: with outputEncoding sRGB and lights, textures need encoding sRGB. OK.

Star points: use PointsMaterial({size: 2.2, sizeAttenuation: true, vertexColors: true, transparent, opacity .95, map: circle texture, alphaTest? }). Use a soft dot texture to avoid squares. Fine.

Let me now write index.html.

Details on frame loop:
```
let simTime = 0; let last = performance.now();
function animate() {
  requestAnimationFrame(animate);
  const now = performance.now();
  let dt = Math.min((now-last)/1000, 0.1); last = now;
  if (!paused) simTime += dt * speedScale;
  for each planet: angle = phase + omega*simTime; x = cos(angle)*r; z = -sin(angle)*r (with inclination); also planet.rotation.y += ...
  updateCamera(); updateLabels(); renderer.render(scene,camera);
}
```

Inclination: rotate the orbit plane by small angle around X: position = rotateX(incl) applied to (cos*r, 0, sin*r). And orbit line geometry likewise rotated via mesh rotation.x = incl. Simple: put orbit line and planet position in a group with rotation.x = inclination. Then label projection uses mesh.getWorldPosition.

I'll do: each planet has a THREE.Group 'orbitGroup' with rotation.x = incl, rotation.y = node (ascending node offset) — adds visual variety. Planet mesh added to orbitGroup at computed position. Orbit line also in orbitGroup.

Camera bounds and initial: dist0 = 380, theta0 = 0.6, phi0 = 1.15 (about 66° from +Y → camera elevation ~24° above plane). Let's compute framing: fov 45. half-height at distance 380 = 380*tan(22.5°) = 157.5. Outer orbit radius 158. Slightly too tight vertically. Use fov 50 → 380*tan(25)=177. And camera slightly above so the far side of the orbit rises... Actually with camera above the plane looking down at origin, the orbit ellipse's vertical extent in screen space ≈ 2*R*sin(elevation) for the plane direction and 2R horizontally. Horizontal half-width = 177*1.5 = 266 > 158. Vertical: orbit's projected minor axis = R*sin(elev) where elev = 90-66 = 24° → 158*0.4 = 64 < 177. But the far edge of orbit at distance further from camera appears smaller; and nearest edge bigger: near edge distance = 380 - 158*cos(elev)... ≈ 380-144 = 236, half-height there = 110 < ... the near orbit edge appears at y offset... it's fine. To be safe use initial dist 420 and fov 50. Max zoom out 800, min 40.

Let me set: DIST_MIN = 40, DIST_MAX = 800, initial dist 420.

Let's write it.

Also the requirement "Initially frame the complete system" — verify via screenshot.

Now, labels for readability: white text with dark shadow/outline, small rounded background chip with planet color dot. Nice.

HTML structure:
```
<div id="app">
  <canvas id="scene"></canvas>
  <div id="labels"></div>
  <header id="hud"> title + subtitle </header>
  <div id="controls"> buttons </div>
  <div id="hint">Drag to orbit • Scroll to zoom</div>
</div>
```

Also planet legend? Maybe skip.

Write the file now.

For the ring texture with planar UV on RingGeometry: RingGeometry(inner, outer, thetaSegments=96, phiSegments=4). UVs: in three r128, RingGeometry uv = (vertex.x/outer + 1)/2 etc? Let me recall: RingGeometry code sets uv based on position/radius: 
```
vertex.x = radius * Math.cos(theta); vertex.y = radius*sin(theta);
uv.x = (vertex.x / radius + 1)/2  -- actually uses (x/outerRadius?) 
```
In three's RingGeometry:
```
uvs.push( ( vertex.x / radius + 1 ) / 2, ( vertex.y / radius + 1 ) / 2 );
```
where radius is outer radius. Hmm, actually it's `( vertex.x / radius + 1 ) / 2` with radius = outerRadius. So uv is planar over [-outer, outer] mapped to [0,1]. So a texture with radial gradient centered maps correctly. Good.

I'll draw the ring texture: for each pixel, r = dist/(size/2) (0..~1.41 at corners). Bands: define alpha profile for r in [0.55, 1.0] where 0.55 = inner/outer. e.g. alpha = base 0.55 with gaps (Cassini division) at r≈0.72-0.76. Colors: pale gold with slight variations.

Ring geometry: inner = 1.35*planetRadius? Saturn radius 6.4 → ring inner 8.2, outer 13.5. So inner/outer = 0.6.

Fine.

Also add a subtle ecliptic grid? Skip.

Let me write the whole file.

Sun glow sprite: canvas 256 radial gradient white→transparent, SpriteMaterial blending additive, depthWrite false, scale ~ 40.

Starfield: 2 layers:
- layer A: 1800 stars, size 1.6, colors whitish/blue-ish
- layer B: 400 stars, size 3.2, brighter with warm/cool colors

Positions in shell radius 600..1600.

Also add faint nebula? skip.

Now code writing. I'll be careful with three r128 deprecations: `THREE.sRGBEncoding` exists. `renderer.outputEncoding` exists in r128. `texture.encoding = THREE.sRGBEncoding` — for canvas textures on MeshPhongMaterial. Yes.

One caution: `renderer.physicallyCorrectLights` not needed.

Write now.

For text labels projection each frame:
```
const v = new THREE.Vector3();
bodies.forEach(b => {
  b.mesh.getWorldPosition(v);
  v.project(camera);
  const x = (v.x*0.5+0.5)*width; const y = (-v.y*0.5+0.5)*height;
  if (v.z > 1) el.style.display='none'; else {...}
});
```
Note `v.project` mutates. Fine.

Offset label above: y - 22 px (or scale by distance: offset = clamp(14, 34, 2000/dist*?)). Keep simple: offset by radius-based size.

Fade labels for distant bodies: opacity = clamp(1 - dist/1200...) skip.

Time to write.

Also handle pointer events for both mouse and touch: use pointer events (pointerdown/move/up) — supported.

Wheel: `canvas.addEventListener('wheel', e => { e.preventDefault(); ...}, {passive:false})`.

Reset tween: set resetAnim = {from:{theta,phi,dist}, to:{...}, t:0}. In updateCamera, if resetAnim active, ease over 0.8s and also lerp theta shortest path.

Simpler: on reset, set target values and lerp each frame: camera.angles lerp toward target with factor 1-exp(-dt*5). And user drag sets target too. Actually simplest robust: keep `theta, phi, dist` as the actual values, and on reset set `resetT = 1.0` and store start values; each frame advance. I'll implement easing.

Let me now write out the file content.

Planet data array:

```js
const PLANETS = [
  { name:'Mercury', color:0x9a8e82, radius:26, size:1.5, speed:..., incl:0.10, phase:0.6, tex:{hue:35,sat:8,light:52,bands:10,blobs:26} },
  ...
];
```

I'll compute speed = 0.30 * Math.pow(26/radius, 1.05).

Mercury: radius 26 → 0.30 rad/s (period 21s)
Venus 38 → 0.30*(26/38)^1.05 = 0.30*0.676 = 0.203 (31s)
Earth 52 → 0.30*0.489 = 0.147 (43s)
Mars 68 → 0.30*0.373 = 0.112 (56s)
Jupiter 92 → 0.30*0.272 = 0.0816 (77s)
Saturn 116 → 0.30*0.216 = 0.065 (97s)
Uranus 138 → 0.30*0.182 = 0.0546 (115s)
Neptune 158 → 0.30*0.158 = 0.0474 (132s)

Good: inner faster.

Sizes: Mercury 1.5, Venus 2.7, Earth 2.9, Mars 2.1, Jupiter 7.6, Saturn 6.6, Uranus 4.4, Neptune 4.2, Sun 12.

Check spacing: Saturn ring outer 13.5 at radius 116 vs Uranus 138 — 22 units gap, ok.

Now the texture generator:

```js
function mulberry32(a){return function(){a|=0;a=a+0x6D2B79F5|0;var t=Math.imul(a^a>>>15,1|a);t=t+Math.imul(t^t>>>7,61|t)^t;return((t^t>>>14)>>>0)/4294967296;};}

function planetTexture(opts){
  const {hue=20, sat=30, light=50, bands=8, blobs=20, seed=1, ice=false} = opts;
  const rnd = mulberry32(seed*7919+13);
  const c = document.createElement('canvas'); c.width=256; c.height=128;
  const ctx = c.getContext('2d');
  // base vertical gradient
  const g = ctx.createLinearGradient(0,0,0,128);
  g.addColorStop(0, `hsl(${hue},${sat}%,${Math.max(5,light-18)}%)`);
  g.addColorStop(0.5, `hsl(${hue},${sat}%,${light}%)`);
  g.addColorStop(1, `hsl(${hue},${sat}%,${Math.max(5,light-18)}%)`);
  ctx.fillStyle=g; ctx.fillRect(0,0,256,128);
  // bands
  for(let i=0;i<bands;i++){
    const y = rnd()*128; const h = 3+rnd()*14;
    const l = light + (rnd()*2-1)*14;
    ctx.fillStyle = `hsla(${hue + (rnd()*2-1)*10},${sat+ (rnd()*2-1)*12}%,${clamp(l,5,92)}%,${0.25+rnd()*0.35})`;
    ctx.fillRect(0, y, 256, h);
  }
  // blobs (continents / storms)
  for(...){
    const x=rnd()*256, y=rnd()*128, r=6+rnd()*26;
    const rg = ctx.createRadialGradient(x,y,0,x,y,r);
    const l = light + (rnd()*2-1)*18;
    rg.addColorStop(0, `hsla(${hue2},${sat2}%,${l}%,${0.5+rnd()*0.4})`);
    rg.addColorStop(1, 'hsla(0,0%,0%,0)');
    ctx.fillStyle = rg; ctx.beginPath(); ctx.arc(x,y,r,0,Math.PI*2); ctx.fill();
  }
  // speckles
  ...
  const tex = new THREE.CanvasTexture(c); tex.encoding = THREE.sRGBEncoding; tex.anisotropy=...; return tex;
}
```

Earth special: hue 210 sat 55 light 45 with green blobs hue 120. I'll add `blobHue` option.

Wrap-around seams: blobs near x edges won't wrap, minor. Could draw blobs 3 times at x-256, x, x+256 to wrap. Cheap fix — do it.

Sun texture: radial-ish: just draw base orange-yellow with granulation: many soft radial blobs in warm colors + darker spots. Fine.

Now write.

I'll write the file in one go.

Regarding `THREE.LineLoop` with `LineBasicMaterial({color, transparent:true, opacity:0.28})`.

Also need `scene.fog`? No — would fade stars. Skip.

Camera: PerspectiveCamera(50, aspect, 0.5, 5000).

Let me write.

updateCamera with reset animation:
```js
const cam = { theta: 0.62, phi: 1.12, dist: 420 };
const camInit = {...cam};
let resetAnim = null;
function applyCamera(){
  const sinPhi = Math.sin(cam.phi);
  camera.position.set(
    cam.dist * sinPhi * Math.sin(cam.theta),
    cam.dist * Math.cos(cam.phi),
    cam.dist * sinPhi * Math.cos(cam.theta)
  );
  camera.lookAt(0,0,0);
}
```

Reset:
```js
function resetView(){
  resetAnim = { t:0, from:{...cam} };
}
// in animate: if resetAnim: t += dt/0.9; e = easeInOutCubic(min(t,1)); cam.theta = lerpAngle(from.theta, camInit.theta, e) ... if t>=1 resetAnim=null;
```
lerpAngle: handle wrap by shortest path:
```js
function lerpAngle(a,b,t){ let d = ((b-a+Math.PI)%(Math.PI*2)+Math.PI*2)%(Math.PI*2)-Math.PI; return a + d*t; }
```

User drag cancels resetAnim.

Now writing the file for real.

The file is written. Let me quickly run it in the browser and check for errors and label/framing issues. Time is short — do a quick check.

One potential issue: `zoomText` is used inside `applyCamera()` but `zoomText` const is declared later (after applyCamera defined but before applyCamera is called? applyCamera is first called at boot which is after the UI section, so `zoomText` is defined by then — const TDZ only matters at call time). applyCamera is called in `onResize()` and `resetView`... but onPointerDown doesn't call it. Wheel handler calls applyCamera — after boot. Fine since all calls happen after declarations execute. Actually `onResize` is called at boot, after zoomText declaration. OK.

But wait — the wheel handler is registered before zoomText is defined, but only invoked later. Fine.

Let me quickly verify in browser.

One TDZ risk: `applyCamera` references `zoomText` — called first at boot (after declaration). Safe.

Now run browser check quickly.

Good overall. Issues:
1. The system doesn't fully fit: Neptune's orbit bottom is cut slightly? Actually the outer orbit bottom edge is around y=650 and left/right ~260/950 — it fits horizontally but the top of the outermost orbit is hidden behind? Actually the outer ellipse appears to fit. But the framing is a bit low/right — the sun is at ~(600, 400) center. It looks fine.

Actually looking closer: the outermost orbit (Neptune, radius 159) — visible ellipse spans x from ~258 to ~945 and y from ~285 to ~648. It fits within viewport. Good.

2. Labels overlap near the sun: Mercury/Venus/Sun overlap. Inner planets crowded. Could reduce label lift and hide labels of inner planets when too close? Simplest improvement: offset labels so they don't collide — alternate lift heights per planet. Or scale label offset by planet size (already) but inner planets are all near center at this zoom. This is inherent. Could hide labels when body is very close to sun in screen space... but then labels missing. Alternatively stagger label vertical lift by index (e.g. lift = size + 16 + (idx%3)*12). Quick fix worth doing.

3. Starfield looks sparse — stars are quite dim. Could raise star brightness/size a bit. Optional.

Let me do quick fixes: stagger label lift, increase star visibility slightly. Then test pause/reset via browser clicks.

Actually the screenshot shows stars faintly — acceptable "procedural starfield", but let's boost opacity/size a bit.

Let me apply small edits then test interactions.

Now test: reload, screenshot, then test drag orbit, pause + camera move, reset view.

Better; starfield is more visible, labels staggered. Neptune's label is now far from its planet (lift staggered by index — Neptune index 7 → 7%4=3 → lift 14+51=65+size). That's a bit disconnected but acceptable. Hmm, Neptune label at y=550 vs planet at y=630 — 80px gap looks disconnected. Better: stagger should be small (e.g. (i%2)*14). Let me reduce stagger to (i % 3) * 12 and instead keep it tight. Actually collisions: Mercury/Venus near sun. Small stagger (i%2)*16 would still separate adjacent ones... but Mercury & Venus are index 0 and 1 → lifts 14 and 30 — different. Fine and closer.

Let me change to `b.def.size + 12 + (i % 2) * 18`. Mercury: 1.55+12=13.5 lift; Venus: 2.7+30=33. That separates them somewhat. Also the Sun label lift 42.

Let me do that quickly and then test interactions (pause, drag, reset).

Now test: reload, sample motion (two screenshots to compare planet positions), pause, drag camera, reset.

Let me use browser drag to orbit, then click pause, then drag, then check simTime frozen, then reset.

Steps:
1. reload + screenshot (initial framing).
2. inspect __orrery simTime via... `browser` has no console eval tool exposed except "inspect" (DOM/console). Hmm, no eval. I'll rely on the status text "T+ x s" in DOM shown in screenshot/inspect output.

Plan: reload → note T+ value; wait; screenshot → T+ increases (motion). Then drag camera → check system still visible. Then click Pause → note T+ twice (should stop) while dragging. Then click Reset view → compare framing with initial.

Do it efficiently.

Initial framing good: full system visible, labels readable (minor overlap in crowded center is inherent). Now test pause + drag + reset.

1. Click Pause.
2. Inspect DOM (T+ value) twice to confirm freeze.
3. Drag camera while paused.
4. Click Reset view, screenshot, compare framing.

Paused works: T+ frozen at 5.1 s, button now "Resume", status shows PAUSED. Planets visibly advanced compared to frame 1 (orbit motion confirmed between T+0.6 and T+5.1 — e.g. Earth moved, Mercury/Venus moved).

Now while paused, drag the camera and check the system stays visible; also verify T+ stays frozen.

Camera orbited (view rotated), system stays fully visible, and T+ still frozen at 5.1 s → pause keeps camera usable. 

Now zoom in with wheel to test bounds, then click Reset view and compare framing.

Let me do a wheel zoom test + reset in fewer steps: scroll to zoom in, screenshot, then click Reset view and screenshot.

Zoom works (420 → 375). Now click Reset view and screenshot to compare framing with initial.