3D solar system · particle-1

Three r13x probably. Let me check revision quickly.

Three r128. Need to build the app. Key features:

- Sun + 8 planets, colors, labels, orbital paths, procedural starfield.
- Animation with different speeds (inner faster).
- Initial camera framing complete system.
- Drag orbit around Sun, wheel changes camera distance with bounds.
- Pause/Resume, Reset view.
- Procedural materials/geometry, only core THREE (no OrbitControls).

I'll implement my own spherical orbit camera. Labels: use CSS2D-like HTML overlay divs projected via camera each frame, or canvas sprites. Requirement "readable labels" — HTML labels overlaid using projection is crisp and easy. Need to avoid labels appearing when behind camera or occluded? Just project positions, hide if behind camera. Could add toggle? Not required.

I'll create a renderer with antialias, scene, starfield using Points with random positions in sphere, procedural star colors/sizes perhaps using a circular sprite texture generated from canvas (procedural allowed). Sun: emissive sphere with glow sprite (canvas radial gradient) plus point light. Planets: SphereGeometry with MeshStandardMaterial colors, small axial tilt, maybe rings for Saturn (procedural Torus or RingGeometry). Orbital paths: circles using LineLoop, slight color.

Schematic distances: Mercury 8, Venus 11.5, Earth 15, Mars 19, Jupiter 27, Saturn 35, Uranus 43, Neptune 51. Sizes: Mercury .55, Venus .9, Earth 1, Mars .7, Jupiter 2.6, Saturn 2.2, Uranus 1.5, Neptune 1.45. Sun radius 3.2.

Speeds: period values, angular speed = base/(distance factor?) Use orbital speed inversely proportional to sqrt(distance) or specified. base speed maybe 0.35 rad/s? Too fast. For visible motion: Earth angular speed 0.22 rad/s (~28s per orbit), Mercury 0.55 (11s), Neptune 0.05 (125s). Good.

Labels overlay: absolute-positioned divs in #labels container with white text, subtle background, maybe small line? Simply position at planet screen pos offset. Need labels not overlap badly. Label follows planet. For sun too.

Camera initial framing: full system radius 51 + planet? Neptune at 51, orbit ring to 51. Camera distance ~120, elevation 35 degrees, looking at origin. FOV 50. Compute distance so 51 fits: vertical extent considering aspect ratio. At distance d, visible half-height = d * tan(25°) = 0.466d. Need 51 at maybe 90% → d ~120. Looking tilted, projected vertical extent of disk radius 51 is 51 (the disk is tilted). Set camera (0, 65, 105) distance 123. Screen fit horizontally at aspect 1.5: horizontal half = 0.466d*1.5 = 86. Fine. But tool viewport 1200x800 aspect 1.5. Also resize.

Orbit camera: spherical coords radius, theta azimuth, phi polar. Initial theta= maybe 0, phi such that camera elev 32° (phi from y-axis = 58°). Distance 125. Drag changes theta/phi. Clamp phi [0.12, Math.PI/2 - 0.03] maybe allow near horizon but not below? "within usable bounds" — clamp phi 0.15..1.45 (elev up to ~81°, min ~8°). Wheel distance clamp [12, 260]. Fit complete system initially.

Pause: set paused flag; animation loop still renders and camera responds. Reset view: resets camera spherical to initial values and target, also maybe keep paused state? Requirement "Reset view restores the initial camera framing." Should not necessarily resume. Keep pause state as-is. Reset button label unchanged.

Labels must show planet names. Use divs and update each frame. Hide when behind camera (vector.z in NDC) or if projected outside? Keep if on-screen maybe clamp? Hide offscreen.

Need ensure label positions correct under renderer size. Use renderer.domElement bounding rect? Canvas fills window; use camera projection with container size.

Also add title overlay/info and controls buttons styled.

Additional visual polish: sun glow via additive sprite radial gradient; starfield with ~4000 points, colors slight variance; maybe background gradient? Scene background black. Procedural star texture canvas.

Planet material: MeshStandardMaterial with roughness 0.9. Could add procedural texture for Earth? Not necessary, but "Generate materials and geometry procedurally" satisfied. Maybe add subtle noise via canvas textures to planets? Requirement is okay with colors. But "procedural" only materials and geometry, no texture files—canvas-generated textures are fine. I could add a simple banding texture for Jupiter/Saturn, Earth continents-ish noise. Adds nice look. But time limit 15 min; keep manageable. I'll implement canvas texture generator for gas giant bands and rocky noise to make distinguishable. Use seeded deterministic simple noise. But labels/colors enough. I'll do subtle canvas textures for all planets with color base and spots—simple.

Actually to reduce risk, use colors + slight emissive; Saturn ring; Earth maybe. Let's add canvas textures function for gas giant bands (Jupiter, Saturn, Uranus, Neptune) and rocky (Mercury, Venus, Mars) using random speckles. Earth with blue base and green blobs. Deterministic random via seeded LCG for consistent look.

Sun texture: canvas with noise orange/yellow; emissive map or MeshBasicMaterial with texture. Use MeshBasicMaterial for sun with sun texture + glow sprite. PointLight at origin, intensity maybe 1.6 with distance 0. Ambient light 0.35.

Orbit paths: LineLoop with 128 segments, MeshBasicMaterial transparent opacity 0.28; assign planet color maybe. Each orbit ring at y=0. Slight tilt? Keep ecliptic flat for clarity, maybe tiny inclinations per planet? "Distinguishable orbital paths" visible. Keep flat; camera tilted. Add inner glow? fine.

Planet labels updated each frame using world position. Also label maybe hidden behind Sun? not important.

Animation: simulate with elapsed time accumulator only when not paused; planets angle = phase0 + elapsed * speed. Use requestAnimationFrame with dt clamp. Planet mesh positions via group pivot? Set mesh.position directly. Saturn rings and labels follow planet world position. Labels use planet.mesh.getWorldPosition. Moons? Not required. Could add Earth moon for flair but skip.

Initial framing should show complete system including orbit paths. Let's compute camera start with fov 50, aspect 1.5, distance 130, position (0, 72, 108) gives distance 130. phi from y: cos(phi)=72/130 => phi=0.985 rad (56.4° from y, elevation 33.6°). theta = 0 gives x=0,z=108. Rotate around y. Maybe initial theta=0.35 to avoid label overlap? Keep 0.2.

Need full coverage of Neptune at 51 on screen. Projection at dist 130: half-height 130*tan25=60.6, Neptune vertical projection depends on tilt, radius 51 * cos? It's near screen center. Good. On 1200x800, okay.

Wheel zoom: radius clamp [8, 300]. At min 8 camera inside sun? Sun radius 3.2; min 15 maybe. But user might want zoom to inner planets. min 12, max 260. With FOV 50, at 12 the sun radius 3.2 and Mercury orbit 8 partially visible. Set min 10. Requirement "usable bounds". Fine.

Touch support? Add pointer events for drag, wheel, maybe pinch. Browser tests use mouse. Implement pointerdown/move/up.

Reset view: smooth animate back to initial? Could instantly reset. Better smooth tween over 0.6s but test may screenshot after click; instant or fast. Implement target spherical and lerp each frame? For simplicity, set values and mark. But comparing initial framing after reset should match exactly. Use exact assignment. Good.

Pause button text toggles "Pause"/"Resume" and simulation freezes. Time accumulator approach ensures no jump when resuming. Use clock delta only when not paused.

Need labels visible readable: text-shadow, background semi-transparent, font 12px. Label data-name. At initial camera, labels projected. Also maybe hide sun label? Show "Sun".

Ensure starfield procedural: random spherical distribution radius 200-500, PointsMaterial size 1.2, sizeAttenuation maybe true, vertexColors. Use procedural circular sprite texture for round stars. Points with map and transparent. Render behind everything. Size attenuation gives depth; use sizes random via per-vertex? PointsMaterial single size; could use two point clouds with sizes 0.8 & 1.6. Or shader—too much. Use one cloud size 1.5, map round. Stars colored bluish/white/yellow. Add a few brighter via second cloud size 2.4 count 250. Keep rotation slowly maybe.

Sun glow sprite: canvas radial gradient with transparent edge, AdditiveBlending, depthWrite false. Sprite scale 18. Also a second halo. The glow will appear as billboard.

Also maybe orbit path transparency and subtle. For labels, add connector? no.

UI: top-left title, bottom-center controls with buttons Pause/Resume, Reset view, maybe speed toggle? Required only two. Add hint "Drag to orbit · Scroll to zoom". Include legend? Labels cover.

Accessibility/test: Buttons with ids pauseButton, resetButton, and data attributes. Simulation state exposed? Tests may inspect DOM labels, look for text. Ensure labels are actual DOM text in #labels. Planet names might be in labels visible. The test says "Inspect the initial planet labels" — DOM labels good.

Could also expose window.solarSystem with getState maybe helpful. Not required but nice: window.__solar = {paused, camera...}. Keep.

Implementation concerns:
- THREE r128 `SpriteMaterial`, `AdditiveBlending`, etc.
- CanvasTexture.
- labels positions use camera.updateMatrixWorld etc.

Let me write index.html. Need inline CSS/JS and script src="three.min.js". Since runner inlines three.min.js, plain script tag as required. Place `<script src="three.min.js"></script>` then inline script after.

Let me craft code carefully.

HTML:
```
<div id="app">
 <canvas? renderer appended to #stage>
 <div id="labels"></div>
 <header>...
 <div id="controls">...
</div>
```
Renderer appends canvas to #app; labels overlay pointer-events none.

CSS: body margin 0 overflow hidden background #000; font-family system.

Title panel top-left maybe compact. Buttons bottom center.

JS:

```
const container = document.getElementById('stage');
const renderer = new THREE.WebGLRenderer({antialias:true, alpha:false});
renderer.setPixelRatio(Math.min(window.devicePixelRatio,2));
renderer.setSize(innerWidth, innerHeight);
container.appendChild(renderer.domElement);
const scene = new THREE.Scene();
scene.background = new THREE.Color(0x02030a);
const camera = new THREE.PerspectiveCamera(50, innerWidth/innerHeight, 0.1, 2000);
```

Star generation:
```
function makeStarTexture(){
 const c=document.createElement('canvas'); c.width=c.height=64;
 const ctx=c.getContext('2d');
 const g=ctx.createRadialGradient(32,32,0,32,32,32);
 g.addColorStop(0,'rgba(255,255,255,1)');
 g.addColorStop(0.25,'rgba(255,255,255,0.9)');
 g.addColorStop(0.5,'rgba(255,255,255,0.25)');
 g.addColorStop(1,'rgba(255,255,255,0)');
 ctx.fillStyle=g; ctx.fillRect(0,0,64,64);
 return new THREE.CanvasTexture(c);
}
```
Points positions random in shell radius 380-900 maybe, avoid too far. Camera far 2000. Colors.

Stars count 4500. Use Float32Array. random inside sphere with radius between 300,900 and ensure not concentrated? For all directions including behind camera. Fine. Also second bright stars.

Maybe add faint nebula? procedural gradient background? Use transparent sprites? Keep simple.

Procedural planet textures:
seed function:
```
let seed=12345;
function rnd(){ seed=(seed*1664525+1013904223)%4294967296; return seed/4294967296; }
```
makeRockyTexture(baseColor, accentColor, spots):
canvas 256x128; fill base; draw random blobs with alpha; add horizontal subtle noise. For Earth: base ocean, continents green/brown blobs, poles whitish. For gas: horizontal bands with varying lightness plus swirl ellipses.

Could map textures with sphere.

Define planet data:

```
const PLANETS = [
 {name:'Mercury', radius:0.55, distance:8, color:0xa8a29a, speed:0.62, phase:0.3, type:'rocky', texture...},
...
];
```

Schematic: Mercury 8, Venus 11.5, Earth 15, Mars 19, Jupiter 27, Saturn 35, Uranus 43.5, Neptune 51.5. Sun radius 3.3. Sizes Mercury .55, Venus .95, Earth 1.0, Mars .7, Jupiter 2.7, Saturn 2.3, Uranus 1.5, Neptune 1.45. Orbit speeds: 0.55,0.4,0.3,0.23,0.13,0.095,0.068,0.052. That's fast but visually good: Neptune 120s. Earth 21s. Test sample orbital motion within a few seconds requires measurable movement. 0.3 rad/s gives 17° in 1s. Good.

Actually to make inner generally faster clearly. Yes.

Tilt: Saturn axial tilt 0.47 rad, ring geometry rotated x = PI/2 + tilt? Use ring in group with rotation. Orbit all flat.

Create orbit:
```
for i 0..255 angle; points at distance cos/sin, y=0, line loop.
```
Use LineBasicMaterial color 0x4a6a8a opacity 0.35 transparent. Maybe per-planet color with opacity .3.

Sun:
- SphereGeometry(3.3, 64, 48), texture from canvas with yellow-orange noise, MeshBasicMaterial map.
- glow sprite (radial gradient orange) scale 16.
- core light pointLight(0xffffff, 1.6, 0, 1) maybe distance 0 infinite. In r128 intensity. Ambient 0.45 maybe planets visible on dark side? Realistic but visibility; use ambient 0.55 + point intensity 1.4. Standard material colors bright.

Orbit path for each planet also add tiny dot marker? no.

Planet creation:
```
const pivot = new THREE.Object3D(); scene.add(pivot);
mesh...
```
Since orbit around origin, just position set each frame. store `mesh`, `angle`.

Saturn ring: RingGeometry(inner 2.9, outer 4.3, 96) MeshBasicMaterial? Standard with color 0xd9c39b, transparent opacity 0.8, side DoubleSide, roughly. Mesh rotation.x = Math.PI/2 - 0.35? Put ring as child of planet mesh; since planet sphere rotated for texture, rotate ring independently. mesh.rotation? ring.rotation.x = Math.PI/2 (ring default in XY plane, rotate to XZ). Add tilt around z maybe. Ring child of planet mesh's group: create planet group at orbit position, sphere at origin. Ring child rotation.x=Math.PI/2; then group.rotation.z=0.3 tilt. Simpler: planet mesh with texture, add ring to separate group at same position with rotation.x=PI/2, rotation.z=0.35? Euler order. Use ringGroup.rotation.set(Math.PI/2 + 0.2, 0, 0.3)? A ring lying nearly in orbital plane but tilted slightly looks fine.

Actually each planet group: `const holder = new THREE.Group(); scene.add(holder); sphere ...; holder.position` updated. ring added to holder with rotation x = Math.PI/2, and holder.rotation.z = 0.35 etc. Sphere rotates itself for texture animation? Could rotate slowly, but not global holder. Keep sphere rotation.y over time for subtle spin while paused freeze. Do same accumulator.

Labels:
```
const label = document.createElement('div');
label.className='label';
label.textContent = name;
labels.appendChild(label);
```
Planet label position: world pos + offset (0, radius+0.8, 0). Project. At initial camera look at origin.

For labels visibility: compute `v = worldPos.clone().project(camera)`; if v.z > 1 or v.z < -1? For points behind camera, project yields weird; use camera-space z: transform world position by camera.matrixWorldInverse, if z > -near? Use `worldPos.clone().applyMatrix4(camera.matrixWorldInverse)` z should be negative in front. If z >= -0.1 hide. Also hide if x/y outside [-1.05,1.05]. Position = ((x+1)/2*width, (1-y)/2*height). Label CSS transform translate(-50%,-50%). Also avoid label offscreen? Hide offscreen.

Sun label offset.

Update labels each frame.

Camera orbit implementation:
state:
```
const view = {
 radius: 132,
 theta: 0.28,
 phi: 1.00,
 target: new THREE.Vector3(0,0,0)
};
const INITIAL = {...};
const PHI_MIN=0.12, PHI_MAX=1.5
const RADIUS_MIN=11, RADIUS_MAX=300
```
Position:
```
camera.position.x = target.x + r*sin(phi)*sin(theta)
camera.position.y = target.y + r*cos(phi)
camera.position.z = target.z + r*sin(phi)*cos(theta)
camera.lookAt(target)
```
With phi=1.02, y = r*0.523. r=132 => y=69; horizontal = 112.5. Good.

Initial framing check: Neptune orbit radius 51.5 projected maybe. At distance 132, vertical half extent=132*tan(25°)=61.6. The ecliptic disk tilted relative to view, vertical projected extent of a circle radius R viewed at elevation e: max vertical screen approx R*sqrt(sin? let's think). Camera looking down at 30°, ecliptic plane appears ellipse with minor axis R*sin(elevation) = R*sin(30°)=25.7 vertical, major axis 51.5 horizontal. So vertical half 51.5 horizontal depends aspect: horizontal half extent = 61.6*1.5=92.4. So all fits with margin. At initial screenshot, plenty margin. Could reduce distance to 105 to frame bigger? Need full system visible; distance 110: half-height 51, horizontal 77. disk horizontal radius 51.5 leaves margin. vertical disk 26. Distance 115 good, bigger planets. Initial distance 118, phi=0.98. Max horizontal extent 51.5*? orbit circle on screen has horizontal radius r; fits. 51.5/ (118*tan25*1.5=82.6) = 62% width. Nice. Use 118. Cam y=65.5,z~? horizontal 98.6. Outer orbit full visible. On narrower screens aspect < 1, horizontal half extent might be insufficient: at aspect 0.75, half-width = 41.3, outer orbit clipped. User runner viewport 1200x800 = 1.5. But robust initial framing could compute distance based on aspect. Good idea: compute initial camera distance from aspect:
```
function idealDistance(aspect){
 const R=55; // includes label margin
 const vFov=THREE.MathUtils.degToRad(50);
 const halfV=Math.tan(vFov/2);
 // horizontal half = d*halfV*aspect; need >= R*1.06
 const dH = (R*1.06)/(halfV*aspect);
 const dV = (R*1.06)/halfV;
 return Math.min(Math.max(dH, dV?), ...)
}
```
Wait disk's vertical extent is less due tilt, but safe use dV=R*1.10/halfV ≈ 55.6*1.1/.466=131. That's same as before. Using dH for aspect 1.5 = 83.9. Since horizontal is limiting for wide screen and vertical for narrow. To fully frame disk with safe margin: required d = max(R*1.12/halfV, R*1.12/(halfV*aspect)). For aspect 1.5 vertical governs d=132. Hmm vertical safe assumes disk vertical extent R, but actual ~R*sin(elev). But labels/planets at edge may go up/down somewhat. Simpler static 118 works. Let's compute with margin: R=54, aspect 1.5, halfV .4663, dH=77, dV=116. Initial distance 122 gives vertical half 56.9 vs disk vertical extent ~26. Fine. Choose 120 and ensure does not clip. Use initialDistance = 120 maybe adjust for aspect <1.15: `Math.max(120, 54/(tan25*aspect)*1.05)`. For aspect 1.5 => 81, so 120. For 1.0 => 121.6. Good.

Actually initial camera distance should perhaps 122. Use computed.

Reset view restores initial framing including recomputed on resize? "compare initial framing" likely screenshot before/after. Keep initial radius constant. On resize only aspect updates. Reset exact initial values. Good.

Camera drag sensitivity: theta -= dx*0.005; phi -= dy*0.005; clamp. Use pointer events on renderer canvas and prevent default. On pointerdown set dragging. Use pointer capture. Wheel: radius *= exp(deltaY*0.001); clamp; prevent default.

Buttons: Pause toggles paused, text. Reset view resets theta/phi/radius to initial and maybe save. Also `aria-live`. Keyboard shortcuts maybe space to pause, R reset. Ensure not if focus on button? Fine.

Simulation:
```
let simTime=0;
const clock=new THREE.Clock();
function animate(){
 requestAnimationFrame(animate);
 const dt=Math.min(clock.getDelta(),0.05);
 if(!paused) simTime += dt;
 planets.forEach((p,i)=> {
   const a = p.phase + simTime*p.speed;
   p.holder.position.set(Math.cos(a)*p.distance, 0, Math.sin(a)*p.distance);
   p.sphere.rotation.y = (p.phase + simTime*p.spin);
   // label positions later
 });
 updateCamera();
 renderer.render(scene,camera);
 updateLabels();
}
```
Important label placement after camera position update and renderer; camera matrices updated before project. Call camera.updateMatrixWorld() prior.

updateCamera sets position/lookAt every frame. Should call before render. Fine.

Sun rotation.

Planet holder perhaps tiny orbital inclination? No.

To make orbital paths distinguishable, maybe each planet's path has color near planet. Distinct enough.

Procedural textures:
- generatePlanetTexture(base, accent, type, seed). Need color manipulation helpers. Use THREE.Color(base) to get CSS? `#` + hex pad. Since planet color numbers. Use predefined canvas drawing colors maybe.

Simplest: create canvas textures using gradients/bands. Let's implement:

```
function makePlanetTexture(opts){
 const w=512,h=256; canvas...
 const ctx...
 function col(hex){return '#'+hex.toString(16).padStart(6,'0');}
 ctx.fillStyle=col(opts.base); fillRect
 // large soft blobs
 for(i=0;i<opts.blobs;i++){
   const x=rand()*w,y=rand()*h,r=10+rand()*50;
   const g=ctx.createRadialGradient(x,y,0,x,y,r);
   g.addColorStop(0, rgba(accent, .18-.45));
   g.addColorStop(1, rgba(accent,0));
   ctx.fillStyle=g; ctx.beginPath(); ctx.arc(x,y,r,0,TAU); ctx.fill();
 }
 if gas: draw bands:
   for (y=0;y<h;y+=...) with sin variation and random alpha; use rects across width with gradient? 
```
Actually draw bands first, then blobs. Gas texture using horizontal stripes of accent colors with varying opacity, plus ellipse swirls. For Saturn subtle. Earth: ocean base + continents.

Could simplify per planet with type:
- rocky: speckles and craters (darker/lighter circles)
- earth: base 0x1f5f9e, land blobs green, polar caps.
- gas: bands.

No external assets.

Earth addition: atmosphere glow? Could add sprite or a slightly larger transparent sphere with additive material. Nice but time. Maybe emissive color. Also Moon? skip.

Add per-planet subtle emissive = color * 0.08 so dark side visible. `new THREE.MeshStandardMaterial({map, roughness:0.95, metalness:0.0, emissive: new THREE.Color(color).multiplyScalar(0.12)})`. For visibility.

Lighting from sun plus ambient 0.35. Planets around 15 units get intensity = 1/(distance^2)? Three.js physicallyCorrectLights false by default in r128, point light intensity constant with distance decay=1? Use PointLight(0xfff3d6, 1.4) with distance 0 and decay 1; intensity doesn't attenuate much? In r128 default decay=1 physically? PointLight intensity / distance maybe. Set decay=0? Hmm r128 point light supports decay. If decay=2 with intensity high? Simpler ambient 0.55 + point 1.6 decay 0 distance 0 = constant-ish? Historically without physicallyCorrectLights, distance=0 no attenuation. Set PointLight(0xffffff, 1.5, 0). Good. Add ambient 0.5.

Sun MeshBasic unaffected.

Glow sprite textures radial: sunTexture? glow separate canvas 256 gradient from rgba(255,220,150,1) at 0 to 0 at 1; sprite scale 20. Also core glow additive.

Could add lens-ish second sprite scale 34 low alpha. Fine.

Background star twinkle? no.

UI:
```
<header id="hud">
 <h1>Solar System</h1>
 <p>Drag to orbit · Scroll to zoom · Space to pause</p>
</header>
<div id="controls">
 <button id="pause">Pause</button>
 <button id="reset">Reset view</button>
</div>
```
style glass panels, buttons nice.

Need labels: avoid clipping: labels container fixed inset 0, pointer-events none. each label absolute; transform translate(-50%,-50%); white-space nowrap; color #dfe9ff; font-size 12px; letter-spacing .04em; background rgba(4,10,24,.55); border 1px solid rgba(120,170,255,.22); padding 2px 7px; border-radius 999px; transform translate(-50%,-50%); will-change transform. But labels over planet should offset upward; use offset world y = radius + 0.9. For sun label maybe top. All labels as dots? We can add colored dot before label via border-left? Use inline span with color styling. Simple label with text and subtle colored dot:
```
label.innerHTML = `<i style="background:#..."></i>${name}`
```
CSS .label i {width:6px;height:6px;border-radius:50%;display:inline-block;margin-right:5px;vertical-align:...}
```
Need avoid injection; names static. Good.

Label visibility: hide if offscreen. Also fade labels when sqrt? Keep.

Test sample orbital motion via screenshot: Pause/Resume. Expose `window.solarSystem = { get simTime(){...}, pause ... }` perhaps. Tests can inspect UI. We'll include `window.__solar = {state:..., camera...}` for debugging. Not harmful.

Initial labels: Because camera frames whole system, labels may cluster near center for inner planets. Use label offsets outward? Could position labels radially outward from sun in screen space? Standard top offset. Cluster maybe but readable. At initial framing, planet screen positions at different orbital angles, phases chosen to spread. Choose phases: Mercury 0.4, Venus 2.2, Earth 4.0, Mars 5.4, Jupiter 1.0, Saturn 3.0, Uranus 4.9, Neptune 0.1. This spreads. Screen projection may still cluster. But labels small. Could use collision avoidance labels: adjust y offset stack if overlapping. Fancy but not needed; maybe implement simple screen-space vertical stagger only for labels within 24px of each other? Complexity. Initial camera pushed far; planets are near center with radii (orbits) projected, but spread around ellipse. Inner labels might overlap. It's okay "readable labels" means legible, each visible. Could implement collision displacement: assign labels sorted by screen y, if overlap with previous moved labels shift left/right? Let's not overcomplicate. Alternatively use CSS labels with smaller font 11 and slight offsets based on planet, labels at exact world positions. Hmm.

Potential issue labels get hidden behind Sun? We hide only behind camera; labels will show through sun, but fine.

Add label distance-based opacity? no.

Rings for Saturn: RingGeometry r128 available. Material transparent with opacity .7, side DoubleSide, map procedural ring texture? Could generate radial stripe texture with canvas and set UV mapping. RingGeometry UVs map x/y not radial; a simple color works. Use MeshBasicMaterial color 0xd8c49a, transparent opacity 0.55, side DoubleSide. It will look like flat ring, lit? Basic material bright both sides. Good. Add second inner ring darker? maybe one.

Add asteroid belt between Mars and Jupiter? nice procedural: 800 small points at radius 21-24 with slight y scatter, colors gray. Optional visual. Could add using Points with size 0.25. Not required but adds detail. Keep minimal (maybe time). Maybe skip to ensure correctness.

Procedural starfield should be visible. Set renderer.setClearColor(0x02030a).

Sun's position light at origin.

Resize handler updates camera.aspect, renderer size, maybe recompute initial distance? No reset initial distance only on load based aspect. On resize, framing could clip but acceptable. Could reset camera radius if at initial? Keep.

Implement pointer interactions:
```
let dragging=false, lastX, lastY;
canvas.addEventListener('pointerdown', e=>{dragging=true; ...; canvas.setPointerCapture(e.pointerId); canvas.style.cursor='grabbing';});
canvas.addEventListener('pointermove', e=>{ if(!dragging)return; const dx=e.clientX-lastX ...; view.theta -= dx*0.006; view.phi -= dy*0.006; clamp; last=...;});
canvas.addEventListener('pointerup', ...);
canvas.addEventListener('pointercancel', ...);
canvas.addEventListener('wheel', e=>{e.preventDefault(); view.radius *= Math.exp(e.deltaY*0.0012); clamp;}, {passive:false});
```
Note wheel direction: deltaY positive zoom out (increase radius). `Math.exp(deltaY*0.0012)` yes.

Clamp phi min 0.15, max 1.52 (~87°). theta wraps.

Reset view: view.theta=INITIAL.theta; view.phi=INITIAL.phi; view.radius=initialRadius; maybe update camera immediately. No transition.

Pause: if paused, animation time stops; camera still updates every frame, wheel works. Buttons are HTML above canvas.

Maybe add visibility pause to avoid clock spike after tab hidden: clock.getDelta clamp 0.05 enough.

Space toggles pause, R resets.

Labels update each frame; when paused camera moved labels update.

RA/dec? no.

Let's write file. Also testing with browser tool. Let's generate.

One concern: color and color conversion from number. Use `'#'+c.toString(16).padStart(6,'0')`.

Texture generation function:

```
function makeTexture(kind, base, accent, seed){
 const c=document.createElement('canvas'); c.width=512; c.height=256;
 const ctx=c.getContext('2d');
 const rand=mulberry32(seed);
 ctx.fillStyle=css(base); ...
 const grad = ctx.createLinearGradient(0,0,0,256);
 ...
 function blob...
 if(kind==='gas'){
   for(let y=0;y<256;y++){
      const t = y/256;
      const band = Math.sin(t*Math.PI*14 + ...)*...;
      ctx.fillStyle = rgba(accent, .06+.12*...);
      ctx.fillRect(0,y,512,1+...)
   }
   // swirl ellipses
   for (i=0;i<70;i++){ ellipse ... }
 } else if(kind==='earth'){ ... continents ...}
 else { speckles + craters}
 // subtle shading maybe
 const tex = new THREE.CanvasTexture(c); tex.anisotropy = renderer.capabilities.getMaxAnisotropy(); tex.wrapS=REPEAT; ...
 return tex;
}
```
Note renderer must exist before textures to use capabilities. yes.

Rocky: base and accents via radial gradients.

For sun texture: bright noise with orange spots.

Need texture seam? wrapS repeat with canvas edges not matching—subtle, okay. Set repeat x maybe 1.

Saturn ring maybe use ring texture: generate 256x8 canvas with alternating alpha stripes and map to RingGeometry; RingGeometry UVs: u along radial? In three RingGeometry uvs are (vertex.x/radius+1)/2 etc not radial; likely weird. Skip texture, plain translucent ring with slight opacity.

Add glow rim around planets? no.

Let's write code.

Now run browser inspect.

Initial view looks good. Labels all visible and spread. However planet sizes: Saturn's ring looks oddly intersecting? It's fine. The starfield is very sparse/dim—maybe visible barely. Could brighten a bit. Also Jupiter appears grayish due to lighting? Jupiter at position bottom-right, texture somewhat gray-brown. Fine. Sun glow decent.

Concerns:
1. Sun label "Sun" directly over sun; good.
2. Stars barely visible. Increase brightness/size or exposure. Space background mostly black with faint stars. Requirement "against a procedural starfield" — visible. Could bump star size/opacity and count. They are visible in screenshot faintly (dots at top-left). Let's improve by increasing sizes to maybe 2.6/5.2 and opacity. Colors brighter. Also could add background subtle gradient? Scene background black. Fine.

3. Planet labels appear with dots; good.

4. Initial framing: all outer orbit fully visible at bottom. Good. But top half has a lot of empty space (system appears low-ish? center is around y=460, viewport center 400). The camera lookAt origin; why center lower? Because disk tilted; sun at screen y=400? Sun label around 371, so sun center ~384; roughly center. Outer orbit extends to y~575. fine.

5. Test motion: sample positions by canvas? We can use window.solarSystem to compute? Planet holder not exposed. But simTime changes. Screenshot comparison. Let's check orbit drag, pause, reset.

Potential issue: UI label count and find label positions. Good.

Let's brighten stars and maybe tweak Jupiter color less gray. Let me first test drag and pause/reset. Use browser actions: pause click, drag, screenshot, reset. Also inspect before/after camera.

Let's sample DOM positions and simTime via... browser inspect gives DOM, not JS eval. The browser tool doesn't have eval. Could use screenshot. Use click Pause coordinates (541,752), screenshot two seconds apart? Motion tool frames maybe. We can screenshot before pause and after; while paused motion screenshot differences should show camera only. Test drag.

First check console no errors. Good.

Let's test pause by clicking then dragging, then reset.

The pause occurred and button says Resume. Positions have advanced from first screenshot (expected). Need verify planets frozen while camera can move. Drag.

Drag works; camera went near edge-on, system still visible. Labels overlap badly at edge-on. Requirement "readable labels" initial framing is okay. Could add label collision avoidance to make labels readable in any view. Maybe worth implementing a simple stagger vertical offset when labels overlap. Since labels overlap at edge-on; tests may orbit and check labels? Requirement verify orbit camera system stays visible; labels requirement likely initial. Still, improve labels with collision avoidance to be robust.

Also note Saturn's ring disappeared/overlap? At edge-on, labels overlap. Fine.

Test wheel zoom and reset.

Zoom works; some labels hidden offscreen (Uranus, Neptune) because zoomed in. That's appropriate. Outer orbits clip due to zoom, expected. Labels crowded center though still mostly legible.

Now reset view should restore exact initial framing (with paused planets frozen). Click reset.

Reset restores initial framing exactly, with planets frozen where they were (same as previous paused screenshot). Good.

Now resume test: click Resume and confirm motion proceeds. Also check labels hidden? After resume no DOM change except text. Could screenshot after delay. The click tool gives screenshot immediately; take screenshot after maybe motion action. Use motion maybe shows frames? Let's click resume then screenshot to see planet positions changed.

Also consider improvements:
- Starfield very faint. Increase visibility modestly.
- Label collisions when edge-on. Could add simple avoidance to ensure all labels readable when clustered. It's an extra but "readable labels" and orbit camera; nice.

Implement label collision avoidance:
- After computing desired positions for all labels (9), sort by y then x. Check bounding boxes? Need label width unknown; approximate 60px. We can use el.offsetWidth (available). offset positions: place each; after placement, for each label compare with already placed; if rect overlap, shift current vertically up by step (e.g., 18px) until no overlap, potentially up to screen boundary. But labels could overlap target planet; slight offset acceptable. Better shift along y by increments alternating up. Simple algorithm: for each label sorted by y, set positions, then compare and move current up 18px until no overlap with placed. This can push labels far but max 8*18=144. At edge-on labels around same y may stack upward; readable. Need ensure hidden labels excluded. Use el.offsetWidth/offsetHeight after display. Element display: inline-flex; offsetWidth works after class removal.

Position sequence: compute base x,y for each; set hidden states; collect visible. Sort by y. For each, while overlaps any placed rect, y -= (h+4); clamp to top 22? If too high maybe offscreen. Could instead stagger left/right? At edge-on, labels around x 470-700,y380-400; stacking upward 8 labels ~160px fine.

But initial framing labels not overlapping; unchanged.

Need not overdo. Also hidden labels excluded. When paused and camera changed, updateLabels() runs each frame anyway.

Implement in updateLabels:
```
const items=[];
function placeLabel returns maybe {x,y,el} ...
```
Refactor placeLabel to return position or null and set visibility; current writes style. I'll modify:
- placeLabel(el, worldPos) computes and sets class, returns {x,y} or null.
- updateLabels collects sun + bodies, then apply avoidance.
Need be careful not to add hidden. Use getBoundingClientRect? offsetWidth.
Algorithm:
```
const placed=[];
items.sort((a,b)=>a.y-b.y);
for each item:
  let {x,y,el}=item;
  el.classList.remove('hidden') already;
  el.style.left=x+'px'; el.style.top=y+'px';
  let w=el.offsetWidth, h=el.offsetHeight;
  let tries=0;
  while(tries<20){
    let overlap = placed.some(r => Math.abs((x)-(r.x+r.w/2)) < (w+r.w)/2+4 && Math.abs(y-(r.y+r.h/2)) < (h+r.h)/2+4);
    if(!overlap) break;
    y -= h + 4;
    tries++;
  }
  // Avoid going above header? clamp y to h/2+8
  el.style.top = y...
  placed.push({x:x - w/2, y:y-h/2, w,h});
```
But labels can overlap when one rect compare uses center coords. Fine. Since each el transform -50%, top/left is center. Store center and compare.

Sort order top to bottom. For overlapping cluster, later labels move above earlier ones; e.g. labels might overlap sun label. Fine.

However, labels stacked upward could overlap with header if near top; clamp: if y - h/2 < 8 then move below instead? rare. Keep clamp after loop: y=Math.max(y, h/2+8). But clamping could re-overlap. Not critical in typical views.

Actually collisions in initial screenshot: Mercury label at y~423 close to Sun at 373, no overlap. Good.

Starfield brighten: increase sizes 2.6 and 5.0 maybe, opacity 1, add third mid layer? Screenshot shows stars faint, but still visible on a good monitor. Add a soft background gradient to scene? Could add a huge inverted sphere with vertex colors gradient dark blue — but starfield requirement, keep black. Increase brightness by using brighter colors and larger count. Let's set first layer size 2.8 count 4200, opacity 1; bright 430 size 5.2. In screenshot the faint stars are visible but small. Use size 1.8? Points size in world units and sizeAttenuation true; at distance ~600, size 2.1 projects small. Point size on screen = size * (height/2) / distance? ~2.1*400/600 = 1.4px. Bigger size 4 => 2.7px. Set 3.6 for base and 7 for bright? That may look like chunky stars. Do 3.2 base, 6.2 bright. Also colors still dim due blending; additive. Should look better.

Also Jupiter texture appears grayish because accent light; could boost saturation with color. Fine.

Saturn ring orientation: screenshot shows ring around Saturn prominent. Nice.

Let's implement label avoidance + star tweak. Then recheck.

Now recheck initial and edge-on labels. Reload (resets pause to unpaused). Take screenshot.

Stars are visible now (though subtle). Initial labels nicely spread. Sun label now above Sun? fine.

Test edge-on drag again to see label avoidance.

Labels no longer overlap, though Jupiter label is detached from its planet because it was pushed up (label near Neptune's planet, shared cluster). But readable. Slight issue: Jupiter's label at 368,130 while Jupiter planet at ~400,400; it got collided and shoved upward via repeated collision with Neptune etc. Actually it moved 130px up? Because item sorted by y and clusters. Since Jupiter label originally y=~554? Wait Jupiter planet likely left at 399,400; label maybe originally at x=400,y=380? It got pushed by overlapping labels. The label at 368,130 is far from planet. That's ugly but readable and only on edge-on view. Requirement only readable labels; still I'd prefer better collision resolution that offsets horizontally rather than stacking far vertically.

Improve: instead of moving upward by 22 repeatedly for overlaps, nudge alternating above/below by smaller steps? Could place near but stacked. At edge-on labels naturally cluster, any avoidance shifts. A better approach: when overlap, shift outward horizontally from screen center? Or push label radially away from sun in screen space. But simpler: limit upward displacement and alternate to minimize far detach. Our current algorithm yields Jupiter 250px above its planet because many labels cluster. Let's count cluster: Jupiter, Neptune, Sun, Mars, Earth all around x=400-700,y=387-399. The placed order sorted by y: Sun(y=383), Mars(390), Earth(399), Jupiter(?), Neptune(?) etc. Jupiter at x=400 clearly got pushed up to 130 because it collided with all. Hmm that's too much. Why would it need 12 tries? Overlaps were likely Neptune at x=447,y=398 and Mars at x=606... Jupiter original x maybe 400, y=396, width 75. It overlaps Neptune (x447, widths ~70, sum 72+4? center dx 47 < 72 yes), Mars far no. Shift up 22 -> y 374; may overlap Sun at x598? dx 198 no. Hmm not 250. Wait screenshot label Jupiter at x=368,y=130! That suggests initial y ~130? No planet Jupiter is at left ~399,400. Label maybe x=368 y~386. It ended up 130. Weird. Perhaps labels offset via holder localToWorld with labelOffset and holder at planet pos; yes top offset ~32 pixels.

Wait why did Jupiter go so high? The placed labels sorted by y; Venus at y=283, Saturn 326, Mercury 340, then Jupiter maybe 386? It could collide with Neptune & Mars etc. But only ~3 shifts. 130 seems like a measurement issue: offsetWidth read while previous hidden could be 0? no fallback 72. 16 tries max => 16*~24=384 possible. Could it have collided repeatedly with itself? No.

Actually likely label stacking: labels are set and offsetHeight maybe 0 when hidden? We call measureLabel removes hidden and returns. offsetWidth should be measured. For labels hidden from previous view maybe display none changed; okay.

Regardless, too aggressive. Better approach: Only avoid collisions among labels by shifting vertically in smaller increments while also shifting x outward from screen center? Or allow only max 3 nudges then horizontal. Another better label style at edge-on: offset labels radially outward from the Sun in screen space so planets near center get labels toward outside. But when edge-on, planets on left/right; can shift outward horizontally. Labels clustered center around x 470-670; screen center 600. Push labels towards their planet's side? Hmm.

Maybe keep collision avoidance but cap vertical shift to ~70px total and if still overlap, shift horizontally away from screen center by 80px. That keeps labels near. Implement:
```
let dx=0;
for tries 0..12:
  check; if hit:
    if tries<3 y -= h+4;
    else { dx = (it.x < window.innerWidth/2 ? -1 : 1) * (w/2 + 30) * Math.ceil((tries-2)/2); x = it.x+dx; y=initial y; }
```
Still could detach. Alternatively skip collision avoidance entirely; labels overlap at exact edge-on but remain partly readable. The task doesn't require labels at all angles. The prior screenshot overlapped labels but still readable-ish (Venus under Sun, Saturn). Hmm.

Better algorithm: sort labels and push them apart vertically only within local cluster; using greedy that uses original y; each label shift up by 20 until fits — that's what we did, but the weird 250 offset suggests bug. Let me debug quickly via console eval? Browser tool has no eval, but can add temporary inspect? Could use `browser inspect` only DOM. Could use puppeteer? no. Could read screenshot pixel. Not worth.

I can instead implement a simpler, bounded algorithm: for each label, try candidates: original, up 18, down 18, up 36, down 36, up 54, down 54, left/right 40. Choose first non-overlapping candidate within screen; keeps near planet. Max 6 tries. This is better. Use offsets list [(0,0),(0,-20),(0,20),(0,-40),(0,40),(-45,0),(45,0),(-45,-20),(45,-20)]. Check overlap with placed; clamp within screen. This limits detachment.

Also need label positions relative to planets; at edge-on cluster, labels will scatter within ~45 px, may still overlap slightly but clustered labels can be staggered. Good.

Let me rewrite collision loop with candidate offsets. Also note the initial layout is great, so no impact.

Also there are only 8 labels for 9 items. Jupiter at 130 is clearly wrong; candidate method better.

Then test edge-on again.

Reload and test edge-on plus motion and pause. Also note the screenshots show planets moving and label positions follow. Need verify pause freezes planet motion. I can take two screenshots of paused state after a few seconds; browser tool maybe each action takes snapshot, but no timing. Use `motion` action? Let's check tool: action "motion" maybe returns animation frames. Let's use after pause to see frames.

Initial good. Now drag edge-on and see labels.

Labels now all near their planets: Jupiter at left planet, Neptune, Mercury near small planet and Mars above. Sun label slightly offset. Some overlap possible but readable. Good.

Note at edge-on the vertical drag only changed phi from .99 to .99-.15=.84? Wait drag dy=-150 * .0052 = +0.78 → phi=1.77 clamped to 1.52 (near edge-on). Good.

Now pause and check frozen motion. We can use pause + screenshot twice. The browser tool screenshots at action time; maybe use motion to get frames after 1s. Let's pause, then motion.

Now paused. Let's use motion action to see frames over time while paused; positions should not move.

Frames identical while paused — positions frozen (except stars rotate very slowly? brightStars rotation continues even paused; okay). Good.

Now reset while paused and confirm initial framing. Then resume and compare motion. Click Reset view.

Reset restored initial framing. However note initial framing compared to first screenshot: first screenshot had Saturn at top center and Neptune bottom-right etc. Now paused planets positions are different (planets continued moving before pause), but camera framing is exact. That's expected. The requirement "compare the initial framing" means camera; good. Maybe reset should also reset simulation? It says Reset view, so no.

One issue: at 1200x800, labels on reset all readable. Fine.

Test resume motion. Click Resume and use motion or screenshot.

The screenshot after resume shows planet positions slightly advanced (Venus at different place, Saturn etc.) relative reset. Hard to tell but sim time runs. Use motion to confirm movement.

Motion frames confirm planets move (Mercury/Venus/Earth positions changing and labels follow). However, one glaring issue: labels for Mercury and Venus overlap planets/sun? In frame 4: Sun label at (599,367) near Sun; Mercury label at (660,397) overlaps Earth? Some labels drift and overlap due to collision handling? Frame 4 shows Sun and Venus labels near each other but not overlapping.

More important: Sun's label is not always attached to Sun because collision offsets use left/right, but okay.

Saturn's rings visible. Distinguishable planet textures/colors.

Now the starfield is still quite sparse but visible. Could add more stars to make it richer. 4200 stars over the whole sphere; visible in front half ~2100 across 1200x800; screenshot shows maybe hundreds. Fine but "procedural starfield" present. Could increase count to 7000. Not necessary.

One potential issue: frame 2 vs 4 labels reposition due to planets moving; collision offsets can make labels jump. Acceptable.

Initial complete system framing: Neptune orbit fully visible with margin. yes.

Check smaller viewport? Runner likely fixed 1200x800. Responsive enough.

Do labels have readable colors? Yes.

Could add asteroid belt? Not required.

One bug: `window.solarSystem` is defined and `labels()` returns trimmed. Fine.

One subtle issue: the planet orbit path lines are very dim; visible enough. Colors per planet.

Another: `PointLight` intensity 1.85 with ambient 0.55, planets lit from center. Planets' textures look washed out on the sun-facing side, especially Saturn's rings. Fine.

Custom camera: dragging works. Wheel zoom tested. Reset view tested. Pause camera usable tested. Initial framing restored.

Potential issue with the wheel: mouse wheel over buttons? Buttons overlay, canvas wheel only. Fine.

Potential issue: user drags starting on labels? labels pointer-events none, so canvas receives. Good. HUD pointer events none. Buttons work.

Pause state and Reset: Reset doesn't resume simulation. That's arguably desired.

Could set aria-live to button text? no.

Need final check of source for anything broken. Use read or grep. We already tested. Maybe there is a bug in computeInitialRadius: `Math.max(neededV, neededH)` where neededV=54/0.466=115.8, *1.03=119.3 -> 119.3. initial radius 119.3. Fine.

Requirement "Initially frame the complete system." At viewport 1200x800 screenshot: yes outer ring fully visible with margin.

Now "sample orbital motion": verified.

Could improve pause freeze stars? Requirement says "Pause freezes planetary motion while leaving camera controls usable." We still rotate stars slow; planets frozen. Sun rotation frozen due condition; brightStars rotation continues. Starfield rotation is background, not planetary motion. Fine, but some might consider pause should freeze everything except camera. Better to freeze sun/stars too when paused (it is under !paused for sun; brightStars not). Move brightStars rotation inside !paused. Minor. Do it for consistency. Also textures rotate only if not paused (mesh.rotation uses simTime, so frozen). Good.

Also starfield should maybe be static anyway. Let's fix brightStars rotation only when !paused.

Another thought: labels collision offset makes Sun label shift from sun when inner labels cluster. Fine.

Let's make starfield slightly denser and fix pause stars. Also perhaps add a tiny Moon for Earth? Not required and time.

One issue observed: Sun label in frame 4 is right next to Sun but Sun itself at 599,384, good.

The visual could use a bit more star density at wide view. Add a third layer of 1000 tiny faint stars? Already 4200. In screenshot many faint dots. Good.

Let me apply brightStars pause tweak and final test quickly.

We need final reload quick inspect errors and initial screenshot, verify all labels. Then done. Also perhaps verify file has no external URLs. grep http.

Let's run reload + grep in parallel? Browser reload and bash grep independent; can parallel.

Everything looks correct. Final state initial view has all labels and orbital paths, complete system.

Reported checks:
- Initial output + console: no JS errors, only WebGL perf warnings.
- all labels.
- orbital motion sampled.
- drag orbit near edge-on, system remains visible; improved label collisions.
- wheel zoom in/out (only zoom in tested; out implied). We tested -600 (zoom in). Could test zoom out? Not necessary but could quickly. Reset tested.
- Pause freezes motion while drag/zoom usable; verified via motion frames.
- Reset restores initial framing.
- Unverified: touch pinch (not implemented; only single-finger drag), keyboard Space/R works by code; extreme zoom bounds effectively clamped. Responsive small screens not tested.

Need final answer concise. Mention file path.