Lorenz attractor · ling-3.0-flash

Let me break down this task:

1. Create a 3D Lorenz attractor visualization using Three.js
2. Single HTML file with inline CSS and JS
3. Use local three.min.js via script tag
4. Implement the Lorenz system with specific parameters
5. Draw a colored trajectory that grows over time
6. Camera controls: orbit on drag, zoom on scroll
7. Pause/Resume and Reset buttons
8. No external resources or CDNs

Let me start by checking what's in the current directory and if three.min.js exists.

Good, three.min.js is present. Now let me check its size and make sure it's a valid Three.js library. It's about 603KB which seems reasonable for three.min.js.

Now let me build the index.html file. I need to:

1. Implement the Lorenz system with sigma=10, rho=28, beta=8/3, initial state (0.1, 0, 0)
2. Use a stable numerical time step (I'll use RK4 or a small Euler step)
3. Draw a luminous colored trajectory using THREE.Line or BufferGeometry
4. Orbit camera controls (drag to orbit, scroll to zoom)
5. Pause/Resume and Reset buttons
6. Frame the full attractor initially
7. Keep trajectory storage bounded

Let me think about the implementation:

**Lorenz System:**
- dx/dt = sigma * (y - x)
- dy/dt = x * (rho - z) - y
- dz/dt = x * y - beta * z

Parameters: sigma=10, rho=28, beta=8/3
Initial: (0.1, 0, 0)

**Numerical Integration:**
I'll use RK4 for stability with a small time step (dt=0.005 or so).

**Trajectory Visualization:**
- Use BufferGeometry with a line
- Color the vertices based on their position or time
- Keep a maximum number of points (e.g., 10000) to bound memory
- Use a LineBasicMaterial or Line material with vertex colors

**Camera Controls:**
- Implement custom orbit controls:
  - Mouse drag: rotate camera around target
  - Mouse wheel: zoom (change distance)
  - Need to prevent default on wheel to avoid page scroll

**UI:**
- Pause/Resume button
- Reset button
- Maybe a small info panel

**Initial Framing:**
- The Lorenz attractor typically spans roughly x: [-20, 20], y: [-30, 30], z: [0, 50]
- I'll compute the bounding box from the initial points and position the camera accordingly

Let me think about the color scheme. I want a luminous-looking trajectory. I can use a gradient from one color to another along the trajectory, or use a single bright color with emissive-like appearance.

For the "luminous" look, I can:
- Use a bright color (cyan, magenta, etc.)
- Add a slight glow effect by using a larger line width (though WebGL line width is limited)
- Use vertex colors that change along the trajectory

Actually, for a really luminous look, I could use a tube geometry or a series of spheres, but that might be heavy. A simpler approach is to use a Line with vertex colors and maybe a custom shader. But let me keep it simple and effective.

Let me use a BufferGeometry line with vertex colors. I'll color the trajectory based on the z-coordinate or the progress along the path, using a gradient from one hue to another.

For the bloom effect, I could use a simple approach: render the line with a bright color and maybe add a second slightly wider, semi-transparent line behind it for a glow effect. Or I could use an UnrealBloomPass... but that requires postprocessing addons which aren't available.

Let me just use a bright, saturated color with vertex colors that shift along the path. I'll use a cyan-to-magenta or similar gradient.

**Camera Orbit Implementation:**
I need to implement this from scratch since I can't use OrbitControls.

```javascript
let cameraDistance = 60;
let cameraTheta = 0; // azimuthal angle
let cameraPhi = Math.PI / 3; // polar angle
let isDragging = false;
let prevMouse = { x: 0, y: 0 };

// On mouse down: start dragging, record position
// On mouse move: update theta and phi based on mouse movement
// On mouse up: stop dragging
// On wheel: adjust cameraDistance

// Camera position:
// x = targetX + cameraDistance * sin(cameraPhi) * cos(cameraTheta)
// y = targetY + cameraDistance * cos(cameraPhi)
// z = targetZ + cameraDistance * sin(cameraPhi) * sin(cameraTheta)
```

Wait, I need to be careful with the coordinate system. Let me use:
- theta = azimuthal angle (horizontal rotation)
- phi = polar angle from top (vertical rotation)

Camera position:
```
x = target.x + cameraDistance * sin(phi) * sin(theta)
y = target.y + cameraDistance * cos(phi)
z = target.z + cameraDistance * sin(phi) * cos(theta)
```

Actually, let me use the standard spherical coordinates:
```
x = target.x + cameraDistance * sin(phi) * cos(theta)
y = target.y + cameraDistance * cos(phi)
z = target.z + cameraDistance * sin(phi) * sin(theta)
```

And camera.lookAt(target).

Let me now write the full HTML file.

For the line, I'll use a BufferGeometry with position and color attributes. As new points are added, I'll update the geometry. When the buffer is full, I'll shift old points out or use a circular buffer approach.

Actually, a simpler approach: maintain an array of points, and when it exceeds the max, remove the oldest points. Then rebuild the geometry each frame or periodically.

For performance, I should use a dynamic BufferGeometry and update the draw range rather than recreating the geometry.

Let me think about the max points. If I add points every frame at dt=0.005, and run at 60fps, that's 12 points per frame. Over 10 seconds, that's 120 points. Over 100 seconds, 1200 points. So even with 10000 max points, we'd have plenty of history.

Actually, let me think about the time step more carefully. The Lorenz system is stiff in some regions. A dt of 0.005 with RK4 should be stable enough. But I might want to sub-step - take multiple small steps per frame for smoother trajectories.

Let me use dt=0.005 and take 4 steps per frame (so effectively dt=0.02 per frame). That should give a smooth trajectory.

Wait, actually for the Lorenz attractor, dt=0.01 with RK4 is usually fine. Let me use that and add one point every few frames to keep the line from being too dense.

Actually, let me just add a point every frame with dt=0.01. That should be fine for visualization purposes.

Let me think about the line rendering. For a "luminous" look, I could:
1. Use a bright color scheme
2. Use lineWidth (but WebGL has limited support for lineWidth > 1)
3. Use a custom shader with glow

For simplicity and effectiveness, I'll use a Line with vertex colors. The colors will shift along the trajectory from one hue to another, creating a rainbow-like effect that gives a luminous appearance.

Actually, let me use a simpler but effective approach: use a single bright color (like cyan or white) for the line, and add a second slightly offset, wider line with lower opacity behind it for a simple glow effect. But WebGL line width is limited...

Let me just go with a beautiful vertex-colored line. I'll use a gradient from cyan to magenta or similar.

Let me also think about the initial framing. The Lorenz attractor with these parameters typically has:
- x range: roughly -20 to 20
- y range: roughly -30 to 30  
- z range: roughly 0 to 50

So the center is roughly at (0, 0, 25) and the bounding sphere radius is about 30-40.

I'll compute the actual bounding box from the first portion of the trajectory and set the camera distance accordingly.

Actually, for simplicity, I'll just set the camera at a reasonable distance and let the user adjust. But the task says "Frame the full attractor initially" so I should compute this.

Let me pre-compute a chunk of the trajectory to find the bounds, then position the camera.

Or I can just use a known good camera position. The Lorenz attractor fits well in a sphere of radius ~50 centered around (0, 0, 25). So camera at distance ~80 looking at (0, 0, 25) should frame it well.

Let me write the code now.

Here's my plan for the HTML structure:

```html
<!DOCTYPE html>
<html>
<head>
  <style>/* CSS */</style>
</head>
<body>
  <div id="ui">
    <button id="pauseBtn">Pause</button>
    <button id="resetBtn">Reset</button>
  </div>
  <script src="three.min.js"></script>
  <script>/* JS */</script>
</body>
</html>
```

Let me write the full implementation now.

For the trajectory line, I'll use a dynamic approach:
- Maintain a Float32Array for positions and colors
- Update the BufferGeometry each frame
- Use a maximum buffer size, and when full, shift data

Actually, for simplicity and performance, let me use a different approach:
- Store points in a regular array
- When the array exceeds MAX_POINTS, remove the oldest points
- Rebuild the BufferGeometry from the array each frame

This is simpler but might be slow for very large point counts. Let me use a more efficient approach with a circular buffer.

Actually, let me just use a simple approach: maintain arrays for positions and colors, and when they exceed the max, splice off old points. Then update the BufferGeometry attributes.

Let me write the code:

```javascript
const MAX_POINTS = 20000;
const positions = new Float32Array(MAX_POINTS * 3);
const colors = new Float32Array(MAX_POINTS * 3);
let pointCount = 0;

// Create geometry
const geometry = new THREE.BufferGeometry();
geometry.setAttribute('position', new THREE.BufferAttribute(positions, 3));
geometry.setAttribute('color', new THREE.BufferAttribute(colors, 3));
geometry.setDrawRange(0, 0);

const material = new THREE.LineBasicMaterial({ vertexColors: true });
const line = new THREE.Line(geometry, material);
scene.add(line);

function addPoint(x, y, z, r, g, b) {
  if (pointCount >= MAX_POINTS) {
    // Shift data left
    positions.copyWithin(0, 3, MAX_POINTS * 3);
    colors.copyWithin(0, 3, MAX_POINTS * 3);
    pointCount = MAX_POINTS - 1;
  }
  const idx = pointCount * 3;
  positions[idx] = x;
  positions[idx + 1] = y;
  positions[idx + 2] = z;
  colors[idx] = r;
  colors[idx + 1] = g;
  colors[idx + 2] = b;
  pointCount++;
  geometry.attributes.position.needsUpdate = true;
  geometry.attributes.color.needsUpdate = true;
  geometry.setDrawRange(0, pointCount);
}
```

Hmm, copyWithin on Float32Array should work. But this shifting approach is O(n) each time. For 20000 points, it's fine.

Actually, let me think about this differently. Instead of shifting, I can use a circular buffer with a start index and count. But that makes the draw range trickier with BufferGeometry.

Let me just use the shift approach - it's simple and 20000 points is small enough that performance isn't an issue.

Wait, actually a better approach: use a fixed-size buffer and just update the draw range. When we reach the max, we stop adding new points (or we can shift). But the task says "Keep trajectory storage bounded" so we need to remove old points.

Let me use the shift approach but only shift when we hit the max. Since we're adding points every frame, and the max is 20000, we'd only shift every 20000 frames or so. That's fine.

Actually, let me reconsider. Instead of shifting the entire array, I can keep track of a "start" offset and just update the draw range. But BufferGeometry doesn't support drawing from an offset easily... actually it does with `geometry.setDrawRange(start, count)`.

Wait, `setDrawRange(start, count)` sets the starting index and the number of vertices to draw. So if I have a circular buffer:
- When I add a point, I write it at position `nextIndex % MAX_POINTS`
- I increment `nextIndex`
- The draw range starts at `max(0, nextIndex - MAX_POINTS)` and has count `min(nextIndex, MAX_POINTS)`

But the issue is that the positions wrap around, so the line would have a discontinuity when it wraps. The line would go from the end of the buffer back to the beginning, which is wrong.

So I need to either:
1. Shift the data (O(n) but infrequent)
2. Use two draw ranges (not supported by Line)
3. Accept the discontinuity (looks bad)

Option 1 is the simplest and works fine for our purposes. Let me go with that.

Actually, let me think about this more carefully. When we hit MAX_POINTS and need to add a new point, we can:
1. Remove the oldest point (shift the array)
2. Add the new point at the end

This keeps the line connected and the trajectory bounded. The shifting is O(n) but happens only once every MAX_POINTS additions, so amortized it's fine.

Let me implement this.

For the color scheme, I want a luminous look. Let me use a gradient that shifts based on the z-coordinate (height), going from warm colors at the bottom to cool colors at the top. Or I can use a time-based gradient.

Let me use a hue-based gradient where the color cycles through the spectrum as the trajectory progresses. This gives a nice rainbow effect that looks luminous.

```javascript
function getColor(t) {
  // t is a value from 0 to 1 representing progress along the trajectory
  const hue = (t * 0.8) % 1.0; // cycle through hues
  const c = new THREE.Color().setHSL(hue, 1.0, 0.6);
  return c;
}
```

Actually, for a more luminous look, I'll use a gradient from cyan to magenta with some white in between. Or I can use HSL with high saturation and lightness.

Let me use a simpler approach: color based on the z-coordinate, mapping it to a blue-to-red gradient. This gives a nice visual indication of height.

```javascript
function getColor(z) {
  // Map z from 0 to 50 to a color gradient
  const t = Math.max(0, Math.min(1, z / 50));
  // Blue at bottom, red at top
  const r = t;
  const g = 0.2 * (1 - t);
  const b = 1 - t;
  return { r, g, b };
}
```

Hmm, let me think about what looks best. For a "luminous" look, I want bright, saturated colors. Let me use a gradient from cyan (low z) to yellow (high z), with white in between.

Actually, let me just use a rainbow effect based on the point index. This is visually striking and gives the "luminous" feel.

```javascript
function getColor(index, totalPoints) {
  const t = index / totalPoints;
  const hue = t * 0.75; // 0 to 0.75 (red to violet)
  const c = new THREE.Color().setHSL(hue, 1.0, 0.55);
  return c;
}
```

Wait, but I need to update colors as new points are added, which means I need to update the entire color buffer each time. That's expensive.

Alternative: color each point based on its z-coordinate, which doesn't change over time. So I only need to set the color once when I add the point.

```javascript
function getColor(z) {
  const t = (z + 20) / 70; // normalize z from -20 to 50
  const hue = 0.6 - t * 0.4; // blue to red
  const c = new THREE.Color().setHSL(hue, 1.0, 0.5);
  return c;
}
```

This is better. Let me use this approach.

Actually, let me reconsider the whole color approach. For a "luminous-looking" trajectory, I think a single bright color with a subtle variation works well. Or I can use a gradient from one bright color to another.

Let me go with a gradient that goes from cyan (#00ffff) at the start to magenta (#ff00ff) at the end, based on the progress along the trajectory. But since I need to update colors when points are removed (shifted), this gets complicated.

Simplest approach that looks good: color each point based on its z-coordinate. This is static and doesn't need updating.

Let me finalize my approach and write the code.

For the orbit controls, I need to handle:
1. Mouse drag → rotate camera around target
2. Mouse wheel → zoom in/out
3. Touch support would be nice but not required

Let me implement this:

```javascript
let isDragging = false;
let prevX = 0, prevY = 0;
let theta = 0, phi = Math.PI / 4;
let cameraDistance = 70;
const target = new THREE.Vector3(0, 0, 25);

canvas.addEventListener('mousedown', (e) => {
  isDragging = true;
  prevX = e.clientX;
  prevY = e.clientY;
});

canvas.addEventListener('mousemove', (e) => {
  if (!isDragging) return;
  const dx = e.clientX - prevX;
  const dy = e.clientY - prevY;
  theta -= dx * 0.005;
  phi -= dy * 0.005;
  phi = Math.max(0.1, Math.min(Math.PI - 0.1, phi));
  prevX = e.clientX;
  prevY = e.clientY;
});

canvas.addEventListener('mouseup', () => { isDragging = false; });
canvas.addEventListener('mouseleave', () => { isDragging = false; });

canvas.addEventListener('wheel', (e) => {
  e.preventDefault();
  cameraDistance *= (1 + e.deltaY * 0.001);
  cameraDistance = Math.max(10, Math.min(200, cameraDistance));
}, { passive: false });

function updateCamera() {
  camera.position.x = target.x + cameraDistance * Math.sin(phi) * Math.cos(theta);
  camera.position.y = target.y + cameraDistance * Math.cos(phi);
  camera.position.z = target.z + cameraDistance * Math.sin(phi) * Math.sin(theta);
  camera.lookAt(target);
}
```

Wait, I need to think about the coordinate system. In Three.js, y is up. The Lorenz attractor has z as the vertical axis typically. Let me make sure the camera looks at the attractor properly.

Actually, in the Lorenz system, the two lobes are along the x-axis, and z is the vertical axis. So the attractor looks like a butterfly with wings spread along x, and z going up.

Let me set the camera target at the center of the attractor, which is roughly (0, 0, 25).

For the initial framing, I need to compute the bounding box of the attractor. Let me pre-compute a short trajectory to find the bounds.

Actually, I can just use a known camera position. The Lorenz attractor with these parameters spans roughly:
- x: -20 to 20
- y: -30 to 30
- z: 0 to 50

So the bounding sphere has center (0, 0, 25) and radius ~35. A camera at distance 80 from center should frame it well.

Let me also add a subtle grid or background to help with depth perception.

Now let me write the complete code. I'll also add some CSS styling for the UI buttons.

Let me think about the overall structure:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Lorenz Attractor</title>
<style>
  * { margin: 0; padding: 0; box-sizing: border-box; }
  body { overflow: hidden; background: #000; font-family: sans-serif; }
  canvas { display: block; }
  #ui { position: absolute; top: 20px; left: 20px; display: flex; gap: 10px; }
  button { /* styling */ }
</style>
</head>
<body>
  <div id="ui">
    <button id="pauseBtn">Pause</button>
    <button id="resetBtn">Reset</button>
  </div>
  <script src="three.min.js"></script>
  <script>
    // All JS here
  </script>
</body>
</html>
```

Let me now write the complete JavaScript implementation.

One more thing - for the "luminous" look, I should consider using a Line material with a custom shader or at least a bright, saturated color. Since I can't use postprocessing bloom, I'll simulate luminosity with:
1. Bright, saturated colors
2. A slight glow by rendering a second, wider, semi-transparent line behind the main line

Wait, WebGL line width is limited to 1px on most platforms. So I can't make the line wider.

Alternative: I can use a TubeGeometry for the trajectory, which would give a 3D tube that looks more substantial. But that's expensive to update every frame.

Another option: Use a series of small spheres or points along the trajectory. Points with a large size can look luminous.

Actually, let me use a combination:
1. A Line for the main trajectory (thin, bright)
2. A Points geometry with larger point size for a glow effect

Or even simpler: just use a bright LineBasicMaterial with vertex colors. The colors themselves will create the luminous appearance.

Let me also add a subtle background gradient or some ambient particles for atmosphere.

OK, let me just write the code now. I'll keep it clean and functional.

Let me also think about the reset behavior. When reset is pressed:
1. Clear the trajectory
2. Reset the Lorenz state to (0.1, 0, 0)
3. Reset the simulation time
4. Start growing the trajectory again

For pause/resume:
1. Pause: stop adding new points to the trajectory, but keep the camera controls active
2. Resume: continue adding points

Let me also add a small trail of points at the current position of the Lorenz system, like a "head" that follows the trajectory. This makes it easier to see where the system is.

Actually, let me add a small glowing sphere at the current position of the Lorenz system. This serves as the "head" of the trajectory.

Let me now write the complete code:

```javascript
// Lorenz system parameters
const sigma = 10;
const rho = 28;
const beta = 8 / 3;
const dt = 0.005;
const stepsPerFrame = 4; // sub-steps per frame for smoothness

// Initial state
let x = 0.1, y = 0, z = 0;

// State
let paused = false;
let pointCount = 0;
const MAX_POINTS = 30000;

// Arrays for trajectory
const positions = new Float32Array(MAX_POINTS * 3);
const colors = new Float32Array(MAX_POINTS * 3);

// Three.js setup
const scene = new THREE.Scene();
scene.background = new THREE.Color(0x000011);

const camera = new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 1000);
const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(window.innerWidth, window.innerHeight);
renderer.setPixelRatio(window.devicePixelRatio);
document.body.appendChild(renderer.domElement);

// Create trajectory line
const geometry = new THREE.BufferGeometry();
geometry.setAttribute('position', new THREE.BufferAttribute(positions, 3));
geometry.setAttribute('color', new THREE.BufferAttribute(colors, 3));
geometry.setDrawRange(0, 0);

const material = new THREE.LineBasicMaterial({ vertexColors: true, linewidth: 1 });
const line = new THREE.Line(geometry, material);
scene.add(line);

// Create head sphere
const headGeometry = new THREE.SphereGeometry(0.5, 16, 16);
const headMaterial = new THREE.MeshBasicMaterial({ color: 0xffffff });
const head = new THREE.Mesh(headGeometry, headMaterial);
scene.add(head);

// Lighting
const ambientLight = new THREE.AmbientLight(0x404040);
scene.add(ambientLight);

// Camera setup
const target = new THREE.Vector3(0, 0, 25);
let cameraDistance = 70;
let theta = 0;
let phi = Math.PI / 4;

function updateCamera() {
  camera.position.x = target.x + cameraDistance * Math.sin(phi) * Math.cos(theta);
  camera.position.y = target.y + cameraDistance * Math.cos(phi);
  camera.position.z = target.z + cameraDistance * Math.sin(phi) * Math.sin(theta);
  camera.lookAt(target);
}

updateCamera();

// Mouse controls
let isDragging = false;
let prevX = 0, prevY = 0;

const canvas = renderer.domElement;

canvas.addEventListener('mousedown', (e) => {
  isDragging = true;
  prevX = e.clientX;
  prevY = e.clientY;
});

canvas.addEventListener('mousemove', (e) => {
  if (!isDragging) return;
  const dx = e.clientX - prevX;
  const dy = e.clientY - prevY;
  theta -= dx * 0.005;
  phi -= dy * 0.005;
  phi = Math.max(0.05, Math.min(Math.PI - 0.05, phi));
  prevX = e.clientX;
  prevY = e.clientY;
});

canvas.addEventListener('mouseup', () => { isDragging = false; });
canvas.addEventListener('mouseleave', () => { isDragging = false; });

canvas.addEventListener('wheel', (e) => {
  e.preventDefault();
  cameraDistance *= (1 + e.deltaY * 0.001);
  cameraDistance = Math.max(15, Math.min(200, cameraDistance));
}, { passive: false });

// Lorenz system
function lorenzStep(x, y, z, dt) {
  const dx = sigma * (y - x);
  const dy = x * (rho - z) - y;
  const dz = x * y - beta * z;
  return {
    x: x + dx * dt,
    y: y + dy * dt,
    z: z + dz * dt
  };
}

function addPoint(x, y, z) {
  if (pointCount >= MAX_POINTS) {
    // Shift data to remove oldest point
    positions.copyWithin(0, 3, MAX_POINTS * 3);
    colors.copyWithin(0, 3, MAX_POINTS * 3);
    pointCount = MAX_POINTS - 1;
  }
  
  const idx = pointCount * 3;
  positions[idx] = x;
  positions[idx + 1] = y;
  positions[idx + 2] = z;
  
  // Color based on z-coordinate
  const t = Math.max(0, Math.min(1, z / 50));
  // Blue to red gradient
  colors[idx] = t;
  colors[idx + 1] = 0.2 * (1 - t) + 0.3 * t;
  colors[idx + 2] = 1 - t;
  
  pointCount++;
  
  geometry.attributes.position.needsUpdate = true;
  geometry.attributes.color.needsUpdate = true;
  geometry.setDrawRange(0, pointCount);
}

// UI buttons
const pauseBtn = document.getElementById('pauseBtn');
const resetBtn = document.getElementById('resetBtn');

pauseBtn.addEventListener('click', () => {
  paused = !paused;
  pauseBtn.textContent = paused ? 'Resume' : 'Pause';
});

resetBtn.addEventListener('click', () => {
  x = 0.1; y = 0; z = 0;
  pointCount = 0;
  geometry.setDrawRange(0, 0);
  paused = false;
  pauseBtn.textContent = 'Pause';
});

// Animation loop
function animate() {
  requestAnimationFrame(animate);
  
  if (!paused) {
    for (let i = 0; i < stepsPerFrame; i++) {
      const result = lorenzStep(x, y, z, dt);
      x = result.x;
      y = result.y;
      z = result.z;
    }
    addPoint(x, y, z);
  }
  
  // Update head position
  head.position.set(x, y, z);
  
  updateCamera();
  renderer.render(scene, camera);
}

animate();

// Handle resize
window.addEventListener('resize', () => {
  camera.aspect = window.innerWidth / window.innerHeight;
  camera.updateProjectionMatrix();
  renderer.setSize(window.innerWidth, window.innerHeight);
});
```

Wait, I need to think about the initial framing more carefully. The task says "Frame the full attractor initially." I should compute the bounding box from the initial trajectory and set the camera accordingly.

Let me pre-compute a short trajectory to find the bounds, then position the camera.

Actually, a simpler approach: I know the Lorenz attractor with these parameters spans roughly x:[-20,20], y:[-30,30], z:[0,50]. So the center is at (0,0,25) and the max distance from center is about sqrt(20² + 30² + 25²) ≈ 43.

Let me set the camera distance to about 80 and the target at (0, 0, 25). This should frame the attractor nicely.

But actually, let me compute it properly. I'll run a few thousand steps of the Lorenz system at initialization to find the bounds, then set the camera.

Hmm, that adds complexity. Let me just use a reasonable default that works for the Lorenz attractor. The values I mentioned should be fine.

Let me also think about the "luminous" look more carefully. I want the trajectory to look bright and glowing. Some ideas:
1. Use a bright color scheme (cyan, magenta, etc.)
2. Add a second, slightly wider line with additive blending for a glow effect
3. Use a Points geometry with large point size for the trajectory

Let me try approach 3: use a Points geometry instead of Line for the trajectory. Points can be larger and have a glow-like appearance. I can use a custom shader or just a large point size with a circular texture.

Actually, for a simple approach, let me use both a Line (for the connected trail) and Points (for the luminous dots). The Points will have a larger size and a bright color, creating a glow-like effect.

Or even simpler: just use a Line with bright vertex colors and add some ambient light to make it look luminous.

Let me also add a subtle background. Instead of pure black, I'll use a very dark blue.

Let me also add some ambient particles or a starfield for atmosphere... but that might be overkill. Let me keep it focused.

One more thing: the task says "actual bloom postprocessing is optional." So I don't need to implement bloom. The luminous look can be achieved with bright colors and good contrast.

Let me also think about the line material. LineBasicMaterial with vertexColors should work. I can also try using a LineDashedMaterial for a different look, but vertex colors with LineBasicMaterial is probably the best choice.

OK, let me finalize the code. I want to make sure:
1. The trajectory is luminous-looking
2. The camera is properly framed initially
3. Orbit controls work smoothly
4. Pause/Resume and Reset work correctly
5. The trail remains connected and visible from new angles

Let me also add a subtle grid or reference plane to help with spatial orientation.

Actually, let me add a very subtle grid on the xz plane. This helps with spatial orientation without being distracting.

Let me also add some fog to the scene for depth.

Here's my revised plan for the visual style:
- Dark background (#000011)
- Cyan-to-magenta gradient trajectory
- White/glowing head sphere
- Subtle grid
- Fog for depth

Let me write the final code now.

One more consideration: the `linewidth` property of `LineBasicMaterial` doesn't work on most WebGL implementations (it's limited to 1px). So I can't make the line thicker. But I can use a `Points` geometry with a larger `size` for a glow effect.

Actually, let me use a different approach for the luminous look. I'll create the trajectory as a series of small, bright spheres (or use Points with a large size). This will look more luminous than a thin line.

But using individual spheres would be too many draw calls. Let me use a Points geometry with a custom shader that makes each point glow.

Actually, for simplicity and effectiveness, let me just use a Line with vertex colors. The bright colors (cyan, magenta, etc.) will look luminous against the dark background. I can also add a second, slightly transparent line with additive blending for a subtle glow effect.

Let me try this: create two lines, one with normal blending (bright colors) and one with additive blending (slightly wider, more transparent). This creates a simple glow effect.

Wait, I can't make the line wider with LineBasicMaterial. The linewidth is limited.

OK, let me just go with a single bright Line and make the colors very saturated and bright. The contrast against the dark background will create a luminous appearance.

Let me also add a small point at the current position (the "head") with a bright white color and a larger size using Points.

Here's my final approach:
1. Main trajectory: Line with vertex colors (bright, saturated)
2. Head: A small bright sphere at the current position
3. Optional: A Points geometry with large size for the trajectory (for a glow-like effect)

Actually, let me add a second line with additive blending and lower opacity for a subtle glow. Even though the line width is the same, the additive blending will make it look like it's glowing.

Wait, that won't work because the line width is the same. The additive blending would just make it brighter, not wider.

Let me just go with the simple approach: a bright Line with vertex colors and a glowing head sphere. This will look good enough.

Let me also think about the color gradient more carefully. I want it to look luminous. Let me use a gradient that goes from bright cyan (#00ffff) through green (#00ff00) to yellow (#ffff00) to red (#ff0000) based on the z-coordinate. This creates a rainbow effect that looks vibrant and luminous.

Actually, for a more cohesive look, let me use a gradient from blue (low z) to cyan to green to yellow to red (high z). This maps the height of the attractor to a color spectrum.

Let me implement this with HSL colors:
- Low z → hue = 0.6 (blue/cyan)
- High z → hue = 0.0 (red)
- Saturation = 1.0
- Lightness = 0.55

This gives a nice rainbow effect.

OK, I think I've planned enough. Let me write the complete code now.

Actually, one more thing: I should make sure the initial camera position frames the attractor properly. Let me pre-compute the bounding box by running the Lorenz system for a short time at initialization.

```javascript
// Pre-compute bounds
let bx = 0.1, by = 0, bz = 0;
let minX = bx, maxX = bx, minY = by, maxY = by, minZ = bz, maxZ = bz;
for (let i = 0; i < 5000; i++) {
  const result = lorenzStep(bx, by, bz, dt);
  bx = result.x; by = result.y; bz = result.z;
  minX = Math.min(minX, bx); maxX = Math.max(maxX, bx);
  minY = Math.min(minY, by); maxY = Math.max(maxY, by);
  minZ = Math.min(minZ, bz); maxZ = Math.max(maxZ, bz);
}
const center = new THREE.Vector3((minX + maxX) / 2, (minY + maxY) / 2, (minZ + maxZ) / 2);
const maxDim = Math.max(maxX - minX, maxY - minY, maxZ - minZ);
const cameraDist = maxDim * 1.5;
```

This is a good approach. Let me incorporate this.

Now let me write the complete index.html file.

Actually, I realize I should also handle touch events for mobile support, but the task doesn't specifically require it. Let me focus on mouse controls.

Let me also add a subtle ambient animation - maybe a slow rotation of the entire attractor, or a subtle pulsing of the head sphere. But the task says "Pause freezes trajectory growth while camera controls remain usable" - so the trajectory should stop growing when paused, but the camera should still be controllable. I shouldn't add automatic rotation.

OK, let me write the final code now.

Let me also think about the CSS for the UI. I want the buttons to look good on a dark background.

```css
#ui {
  position: absolute;
  top: 20px;
  left: 20px;
  display: flex;
  gap: 10px;
  z-index: 10;
}

button {
  background: rgba(0, 200, 255, 0.2);
  border: 1px solid rgba(0, 200, 255, 0.5);
  color: #00c8ff;
  padding: 8px 20px;
  font-size: 14px;
  cursor: pointer;
  border-radius: 4px;
  font-family: monospace;
  transition: all 0.2s;
}

button:hover {
  background: rgba(0, 200, 255, 0.4);
}
```

This gives a nice cyberpunk/tech look that matches the 3D visualization.

Let me also add a title or info text.

OK, let me write the complete file now. I'll be careful to make everything work correctly.

One more thing: I need to make sure the line colors look good. Let me use a gradient based on the progress along the trajectory (not z-coordinate). This way, the colors flow smoothly along the path, creating a more visually appealing effect.

But the problem is that when I shift old points out, the colors of the remaining points need to be recalculated. That's expensive.

Alternative: use a fixed color scheme based on z-coordinate, which doesn't change over time. This is more efficient.

Let me go with z-based coloring. It also provides useful visual information about the height of the trajectory.

Let me finalize the color mapping:
- z < 0: deep blue
- z = 0 to 25: blue → cyan → green
- z = 25 to 50: green → yellow → red

Using HSL:
- hue = 0.6 - (z / 50) * 0.6 (maps z=0 to hue=0.6/cyan, z=50 to hue=0.0/red)
- saturation = 1.0
- lightness = 0.55

This gives a nice rainbow from cyan to red.

Wait, I should also handle z values outside [0, 50]. The Lorenz attractor with these parameters has z values roughly in [0, 50], but they can occasionally go outside this range. Let me clamp the mapping.

OK, let me write the complete code now. I'll be thorough and make sure everything works.

Let me also think about the `stepsPerFrame` value. If I use dt=0.005 and 4 steps per frame, that's an effective dt of 0.02 per frame. At 60fps, that's 1.2 seconds of simulation per second of real time. The Lorenz system evolves quickly, so this should give a nice, visible trajectory growth.

Actually, let me use dt=0.005 and 8 steps per frame, giving an effective dt of 0.04 per frame. That's about 2.4 seconds of simulation per second of real time. This should be a good speed for visualization.

Hmm, let me just use dt=0.005 and 4 steps per frame. That gives a nice speed.

Wait, I should also consider that the Lorenz system is chaotic, so the trajectory grows quickly. With dt=0.005 and 4 steps per frame, I'm adding 4 points per frame. At 60fps, that's 240 points per second. With MAX_POINTS=30000, the trail would last about 125 seconds before oldest points start being removed. That seems reasonable.

Actually, let me increase MAX_POINTS to 50000 for a longer trail. Or maybe 30000 is fine.

Let me finalize and write the code.

One more consideration: I should make the head sphere glow. I can do this by using a MeshBasicMaterial with a bright color and maybe a larger size. Or I can add a PointLight at the head position for a local glow effect.

Adding a PointLight at the head position would create a nice glow effect on nearby parts of the trajectory. Let me add that.

```javascript
const headLight = new THREE.PointLight(0x00ffff, 2, 20);
scene.add(headLight);
```

This will make the area around the head glow, illuminating nearby parts of the trajectory.

OK, let me write the complete code now. I'll be comprehensive.

Let me also add a subtle grid on the xz plane for spatial reference.

```javascript
const gridHelper = new THREE.GridHelper(100, 20, 0x111133, 0x111133);
gridHelper.position.y = -30;
scene.add(gridHelper);
```

This adds a subtle grid below the attractor.

Actually, the Lorenz attractor is centered around z=25, and the grid at y=-30 would be below it. But in the Lorenz system, y is not the vertical axis - z is. So the grid should be on the xz plane or the xy plane, depending on how we orient things.

In the standard Lorenz system visualization, x is horizontal, y is horizontal (depth), and z is vertical. So the grid should be on the xz plane (horizontal plane).

Let me add a grid on the xz plane:
```javascript
const gridHelper = new THREE.GridHelper(100, 20, 0x111133, 0x111133);
gridHelper.position.y = -30; // Below the attractor
scene.add(gridHelper);
```

Wait, GridHelper creates a grid on the xz plane by default, positioned at y=0. If I set position.y = -30, it would be below the attractor. That's fine for a reference plane.

Actually, let me not add a grid. It might clutter the visualization. The dark background and bright trajectory should be enough.

Let me finalize the code now. Here's my complete plan:

1. HTML structure with UI buttons
2. CSS for dark theme, styled buttons
3. Three.js scene with:
   - Dark background
   - Trajectory line with vertex colors
   - Head sphere at current position
   - Head point light for glow
   - Ambient light
   - Custom orbit camera controls
4. Lorenz system simulation
5. Animation loop
6. UI event handlers

Let me write it all now.

Actually, I realize I should also think about the initial camera framing more carefully. Let me pre-compute the bounds and set the camera accordingly.

Also, I need to make sure the line is visible from all angles. The vertex colors should be bright enough against the dark background.

Let me also add a slight fog to the scene for depth:
```javascript
scene.fog = new THREE.FogExp2(0x000011, 0.005);
```

This will make distant parts of the trajectory fade into the background, creating a nice depth effect.

OK, I'm ready to write the code. Let me do it now.

Wait, one more thing about the line material. I want the line to look luminous. Let me use a LineBasicMaterial with a bright color. But since I'm using vertex colors, each vertex will have its own color.

For the "luminous" look, I should make sure the colors are very bright and saturated. Let me use HSL with lightness around 0.55-0.6 and full saturation.

Also, I should consider adding a second, slightly transparent line with additive blending for a glow effect. Even though the line width is the same, the additive blending will make overlapping areas brighter, creating a subtle glow.

```javascript
// Main line
const mainMaterial = new THREE.LineBasicMaterial({ vertexColors: true });
const mainLine = new THREE.Line(geometry, mainMaterial);
scene.add(mainLine);

// Glow line (same geometry, additive blending)
const glowMaterial = new THREE.LineBasicMaterial({ 
  vertexColors: true, 
  transparent: true, 
  opacity: 0.3, 
  blending: THREE.AdditiveBlending 
});
const glowLine = new THREE.Line(geometry, glowMaterial);
scene.add(glowLine);
```

This should create a nice glow effect! The main line provides the bright, crisp trajectory, and the glow line adds a luminous halo around it.

Let me incorporate this into the final code.

Now, let me also think about the head sphere. I want it to look like a bright, glowing point. I can use a small sphere with MeshBasicMaterial (white or bright cyan) and a PointLight at its position.

For the head sphere, I'll use a slightly larger sphere (radius 0.8) with a bright color. I'll also add a PointLight at its position.

Let me also add a second, larger, semi-transparent sphere around the head for a glow effect:
```javascript
const glowSphereGeometry = new THREE.SphereGeometry(1.5, 16, 16);
const glowSphereMaterial = new THREE.MeshBasicMaterial({
  color: 0x00ffff,
  transparent: true,
  opacity: 0.2,
  blending: THREE.AdditiveBlending
});
const glowSphere = new THREE.Mesh(glowSphereGeometry, glowSphereMaterial);
scene.add(glowSphere);
```

This creates a nice glow around the head point.

OK, I think I have a solid plan. Let me write the complete code now.

One more thing: I need to make sure the trajectory line is properly initialized and visible from the start. The first few points will be close together (near the initial state (0.1, 0, 0)), so the line will start small and grow as the simulation progresses. This is the desired behavior.

Let me also make sure the camera is positioned correctly at the start. I'll pre-compute the bounds and set the camera distance accordingly.

Here's my final code:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Lorenz Attractor</title>
<style>
  * { margin: 0; padding: 0; box-sizing: border-box; }
  body { overflow: hidden; background: #000; font-family: 'Courier New', monospace; }
  canvas { display: block; }
  #ui {
    position: absolute;
    top: 20px;
    left: 20px;
    display: flex;
    gap: 12px;
    z-index: 10;
  }
  button {
    background: rgba(0, 180, 255, 0.15);
    border: 1px solid rgba(0, 200, 255, 0.6);
    color: #00d4ff;
    padding: 10px 24px;
    font-size: 14px;
    cursor: pointer;
    border-radius: 4px;
    font-family: 'Courier New', monospace;
    letter-spacing: 1px;
    transition: all 0.2s ease;
    text-transform: uppercase;
  }
  button:hover {
    background: rgba(0, 180, 255, 0.35);
    box-shadow: 0 0 15px rgba(0, 200, 255, 0.3);
  }
  button:active {
    transform: scale(0.97);
  }
  #info {
    position: absolute;
    bottom: 20px;
    left: 20px;
    color: rgba(0, 200, 255, 0.5);
    font-size: 12px;
    z-index: 10;
  }
</style>
</head>
<body>
<div id="ui">
  <button id="pauseBtn">Pause</button>
  <button id="resetBtn">Reset</button>
</div>
<div id="info">Drag to orbit · Scroll to zoom</div>
<script src="three.min.js"></script>
<script>
// === Lorenz Attractor Visualization ===

// Parameters
const SIGMA = 10;
const RHO = 28;
const BETA = 8 / 3;
const DT = 0.005;
const STEPS_PER_FRAME = 4;
const MAX_POINTS = 40000;

// Initial state
let simX = 0.1, simY = 0, simZ = 0;
let paused = false;
let pointCount = 0;

// Pre-compute bounds for camera framing
(function computeBounds() {
  let bx = 0.1, by = 0, bz = 0;
  let minX = bx, maxX = bx, minY = by, maxY = by, minZ = bz, maxZ = bz;
  for (let i = 0; i < 8000; i++) {
    const dx = SIGMA * (by - bx);
    const dy = bx * (RHO - bz) - by;
    const dz = bx * by - BETA * bz;
    bx += dx * DT;
    by += dy * DT;
    bz += dz * DT;
    minX = Math.min(minX, bx); maxX = Math.max(maxX, bx);
    minY = Math.min(minY, by); maxY = Math.max(maxY, by);
    minZ = Math.min(minZ, bz); maxZ = Math.max(maxZ, bz);
  }
  window.attractorCenter = new THREE.Vector3((minX + maxX) / 2, (minY + maxY) / 2, (minZ + maxZ) / 2);
  window.attractorRadius = Math.max(maxX - minX, maxY - minY, maxZ - minZ) / 2;
})();

// Three.js setup
const scene = new THREE.Scene();
scene.background = new THREE.Color(0x000008);
scene.fog = new THREE.FogExp2(0x000008, 0.004);

const camera = new THREE.PerspectiveCamera(55, window.innerWidth / window.innerHeight, 0.1, 1000);
const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(window.innerWidth, window.innerHeight);
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
document.body.appendChild(renderer.domElement);

// Trajectory buffers
const positions = new Float32Array(MAX_POINTS * 3);
const colors = new Float32Array(MAX_POINTS * 3);

// Main trajectory line
const geometry = new THREE.BufferGeometry();
geometry.setAttribute('position', new THREE.BufferAttribute(positions, 3));
geometry.setAttribute('color', new THREE.BufferAttribute(colors, 3));
geometry.setDrawRange(0, 0);

const mainMaterial = new THREE.LineBasicMaterial({ vertexColors: true });
const mainLine = new THREE.Line(geometry, mainMaterial);
scene.add(mainLine);

// Glow trajectory line (additive blending)
const glowMaterial = new THREE.LineBasicMaterial({
  vertexColors: true,
  transparent: true,
  opacity: 0.25,
  blending: THREE.AdditiveBlending
});
const glowLine = new THREE.Line(geometry, glowMaterial);
scene.add(glowLine);

// Head sphere
const headGeom = new THREE.SphereGeometry(0.6, 16, 16);
const headMat = new THREE.MeshBasicMaterial({ color: 0xffffff });
const head = new THREE.Mesh(headGeom, headMat);
scene.add(head);

// Head glow sphere
const glowSphereGeom = new THREE.SphereGeometry(1.2, 16, 16);
const glowSphereMat = new THREE.MeshBasicMaterial({
  color: 0x00ccff,
  transparent: true,
  opacity: 0.15,
  blending: THREE.AdditiveBlending
});
const glowSphere = new THREE.Mesh(glowSphereGeom, glowSphereMat);
scene.add(glowSphere);

// Head point light
const headLight = new THREE.PointLight(0x00ccff, 3, 30);
scene.add(headLight);

// Ambient light
scene.add(new THREE.AmbientLight(0x222244, 0.5));

// Camera orbit state
const target = new THREE.Vector3();
let cameraDist = 0;
let theta = 0;
let phi = Math.PI / 4;

function updateCamera() {
  camera.position.x = target.x + cameraDist * Math.sin(phi) * Math.cos(theta);
  camera.position.y = target.y + cameraDist * Math.cos(phi);
  camera.position.z = target.z + cameraDist * Math.sin(phi) * Math.sin(theta);
  camera.lookAt(target);
}

// Initialize camera
target.copy(window.attractorCenter);
cameraDist = window.attractorRadius * 3.5;
theta = 0.3;
phi = Math.PI / 3.5;
updateCamera();

// Mouse orbit controls
let isDragging = false;
let prevMX = 0, prevMY = 0;

const canvas = renderer.domElement;

canvas.addEventListener('mousedown', (e) => {
  isDragging = true;
  prevMX = e.clientX;
  prevMY = e.clientY;
});

canvas.addEventListener('mousemove', (e) => {
  if (!isDragging) return;
  const dx = e.clientX - prevMX;
  const dy = e.clientY - prevMY;
  theta -= dx * 0.004;
  phi -= dy * 0.004;
  phi = Math.max(0.05, Math.min(Math.PI - 0.05, phi));
  prevMX = e.clientX;
  prevMY = e.clientY;
});

canvas.addEventListener('mouseup', () => { isDragging = false; });
canvas.addEventListener('mouseleave', () => { isDragging = false; });

canvas.addEventListener('wheel', (e) => {
  e.preventDefault();
  cameraDist *= (1 + e.deltaY * 0.001);
  cameraDist = Math.max(cameraDist * 0.9, Math.min(cameraDist * 1.1, 300));
  // Simpler: just scale
  cameraDist *= (1 + e.deltaY * 0.001);
  cameraDist = Math.max(10, Math.min(300, cameraDist));
}, { passive: false });

// Lorenz step (Euler - simple but with small dt it's stable enough)
function lorenzStep(x, y, z, dt) {
  const dxdt = SIGMA * (y - x);
  const dydt = x * (RHO - z) - y;
  const dzdt = x * y - BETA * z;
  return {
    x: x + dxdt * dt,
    y: y + dydt * dt,
    z: z + dzdt * dt
  };
}

// Add point to trajectory
function addPoint(x, y, z) {
  // Shift if buffer full
  if (pointCount >= MAX_POINTS) {
    const shiftBytes = 3 * 4; // 3 floats * 4 bytes
    positions.copyWithin(0, 3, MAX_POINTS * 3);
    colors.copyWithin(0, 3, MAX_POINTS * 3);
    pointCount = MAX_POINTS - 1;
  }
  
  const idx = pointCount * 3;
  positions[idx] = x;
  positions[idx + 1] = y;
  positions[idx + 2] = z;
  
  // Color based on z-height: blue → cyan → green → yellow → red
  const t = Math.max(0, Math.min(1, z / 50));
  const hue = 0.6 - t * 0.6; // 0.6 (cyan) to 0.0 (red)
  const c = new THREE.Color().setHSL(hue, 1.0, 0.55);
  colors[idx] = c.r;
  colors[idx + 1] = c.g;
  colors[idx + 2] = c.b;
  
  pointCount++;
  
  geometry.attributes.position.needsUpdate = true;
  geometry.attributes.color.needsUpdate = true;
  geometry.setDrawRange(0, pointCount);
}

// UI
const pauseBtn = document.getElementById('pauseBtn');
const resetBtn = document.getElementById('resetBtn');

pauseBtn.addEventListener('click', () => {
  paused = !paused;
  pauseBtn.textContent = paused ? 'Resume' : 'Pause';
});

resetBtn.addEventListener('click', () => {
  simX = 0.1; simY = 0; simZ = 0;
  pointCount = 0;
  geometry.setDrawRange(0, 0);
  paused = false;
  pauseBtn.textContent = 'Pause';
});

// Animation loop
function animate() {
  requestAnimationFrame(animate);
  
  if (!paused) {
    for (let i = 0; i < STEPS_PER_FRAME; i++) {
      const result = lorenzStep(simX, simY, simZ, DT);
      simX = result.x;
      simY = result.y;
      simZ = result.z;
    }
    addPoint(simX, simY, simZ);
  }
  
  // Update head
  head.position.set(simX, simY, simZ);
  glowSphere.position.set(simX, simY, simZ);
  headLight.position.set(simX, simY, simZ);
  
  updateCamera();
  renderer.render(scene, camera);
}

animate();

// Resize handler
window.addEventListener('resize', () => {
  camera.aspect = window.innerWidth / window.innerHeight;
  camera.updateProjectionMatrix();
  renderer.setSize(window.innerWidth, window.innerHeight);
});
</script>
</body>
</html>
```

Wait, I have a bug in the wheel handler. I have two `cameraDist *= ...` lines. Let me fix that.

Also, I should use RK4 for better numerical stability. Let me implement that.

Actually, with dt=0.005 and Euler method, the Lorenz system should be stable enough for visualization purposes. The Lorenz system is not stiff in the traditional sense, and Euler with a small enough dt works fine. But RK4 would be more accurate and stable.

Let me implement RK4:

```javascript
function lorenzDerivatives(x, y, z) {
  return {
    dx: SIGMA * (y - x),
    dy: x * (RHO - z) - y,
    dz: x * y - BETA * z
  };
}

function lorenzStepRK4(x, y, z, dt) {
  const k1 = lorenzDerivatives(x, y, z);
  const k2 = lorenzDerivatives(x + k1.dx * dt / 2, y + k1.dy * dt / 2, z + k1.dz * dt / 2);
  const k3 = lorenzDerivatives(x + k2.dx * dt / 2, y + k2.dy * dt / 2, z + k2.dz * dt / 2);
  const k4 = lorenzDerivatives(x + k3.dx * dt, y + k3.dy * dt, z + k3.dz * dt);
  
  return {
    x: x + (k1.dx + 2 * k2.dx + 2 * k3.dx + k4.dx) * dt / 6,
    y: y + (k1.dy + 2 * k2.dy + 2 * k3.dy + k4.dy) * dt / 6,
    z: z + (k1.dz + 2 * k2.dz + 2 * k3.dz + k4.dz) * dt / 6
  };
}
```

This is more stable and accurate. Let me use this.

Also, I realize I should double-check the wheel handler. Let me fix it:

```javascript
canvas.addEventListener('wheel', (e) => {
  e.preventDefault();
  cameraDist *= (1 + e.deltaY * 0.001);
  cameraDist = Math.max(10, Math.min(300, cameraDist));
}, { passive: false });
```

Wait, the issue is that `e.deltaY` is positive when scrolling down (zoom out) and negative when scrolling up (zoom in). So `cameraDist *= (1 + e.deltaY * 0.001)` means:
- Scrolling down (deltaY > 0): cameraDist increases (zoom out) ✓
- Scrolling up (deltaY < 0): cameraDist decreases (zoom in) ✓

That's correct. But the factor 0.001 might be too small. Let me use 0.002 for a slightly more responsive zoom.

Actually, let me also clamp the zoom speed. The current formula `cameraDist *= (1 + e.deltaY * 0.001)` means each wheel tick changes the distance by about 0.1%. That's very slow. Let me increase it to 0.005 or even 0.01.

Hmm, let me think about this. A typical mouse wheel event has deltaY of about 100 (one "click" of the wheel). So with 0.001, each click changes the distance by 0.1 (10% of 1). That's actually reasonable.

Wait, no. `cameraDist *= (1 + 100 * 0.001) = cameraDist * 1.1`. That's a 10% change per wheel click. That might be too fast. Let me use 0.0005 for a 5% change per click.

Actually, let me just use a simpler approach:
```javascript
cameraDist += e.deltaY * 0.05;
cameraDist = Math.max(10, Math.min(300, cameraDist));
```

This adds or subtracts from the distance directly. Each wheel click changes the distance by 5 units. That's more intuitive.

But this doesn't scale with the current distance. Let me use a multiplicative approach:
```javascript
const zoomFactor = e.deltaY > 0 ? 1.1 : 0.9;
cameraDist *= zoomFactor;
cameraDist = Math.max(10, Math.min(300, cameraDist));
```

This zooms by 10% per wheel click, which is a good speed.

OK, let me finalize the code. Let me also make sure I handle the `copyWithin` correctly for the Float32Array.

`positions.copyWithin(0, 3, MAX_POINTS * 3)` - this copies elements from index 3 to MAX_POINTS*3 - 1 into positions starting at index 0. This effectively removes the first 3 elements (the first point) and shifts everything left by 3. This is correct.

Wait, actually `copyWithin(target, start, end)` copies elements from `start` to `end` (exclusive) into positions starting at `target`. So `positions.copyWithin(0, 3, MAX_POINTS * 3)` copies elements from index 3 to MAX_POINTS*3-1 into positions starting at index 0. This removes the first point and shifts everything left. Correct.

But I also need to update `pointCount` after shifting. I set `pointCount = MAX_POINTS - 1` after shifting, which is correct because we removed one point and added one new point (net count stays the same).

Wait, actually I need to be more careful. When `pointCount >= MAX_POINTS`, I shift the data to remove the oldest point, then I add the new point at position `pointCount`. But after shifting, `pointCount` should be `MAX_POINTS - 1` (since we removed one point), and then I add the new point, making it `MAX_POINTS` again.

Let me re-examine my code:
```javascript
if (pointCount >= MAX_POINTS) {
  positions.copyWithin(0, 3, MAX_POINTS * 3);
  colors.copyWithin(0, 3, MAX_POINTS * 3);
  pointCount = MAX_POINTS - 1;
}
// Then add the new point at position pointCount
```

This is correct. After shifting, pointCount is MAX_POINTS - 1, and then we add one point, making it MAX_POINTS again.

OK, the code looks correct. Let me finalize it.

Actually, I just realized there's an issue with the `copyWithin` approach. When I shift the data, the new point I'm adding at position `pointCount` (which is MAX_POINTS - 1 after shifting) will overwrite the last element of the shifted data. But that's fine because the last element was already the oldest data that got shifted.

Wait, no. After `copyWithin(0, 3, MAX_POINTS * 3)`, the data from indices 3 to MAX_POINTS*3-1 is copied to indices 0 to MAX_POINTS*3-4. The last 3 elements (indices MAX_POINTS*3-3 to MAX_POINTS*3-1) are now duplicates of what was at indices MAX_POINTS*3-6 to MAX_POINTS*3-4. But I'm about to overwrite them with the new point anyway.

So the logic is:
1. Shift all data left by 3 elements (removing the oldest point)
2. Set pointCount to MAX_POINTS - 1
3. Add the new point at index pointCount * 3 = (MAX_POINTS - 1) * 3
4. Increment pointCount to MAX_POINTS

This is correct. The oldest point is removed and the new point is added at the end.

Great, the code is correct.

Let me also make sure I handle the case where `pointCount` is exactly `MAX_POINTS` correctly. The condition `pointCount >= MAX_POINTS` will be true, and we shift and set pointCount to MAX_POINTS - 1. Then we add the new point and increment to MAX_POINTS. Good.

Now let me also think about the `setDrawRange` call. `geometry.setDrawRange(0, pointCount)` tells WebGL to draw `pointCount` vertices starting from index 0. This is correct.

One more thing: I should make sure the initial state is correct. When the page loads, `pointCount` is 0, so no points are drawn. As the simulation runs, points are added and the trajectory grows. When paused, no new points are added. When reset, `pointCount` is set to 0 and the draw range is set to 0, clearing the trail.

This all looks correct.

Let me also add a subtle animation to the head sphere - maybe a pulsing effect. But the task says "Pause freezes trajectory growth while camera controls remain usable" - it doesn't say the head should be animated. Let me keep it simple.

Actually, let me add a very subtle pulsing to the head glow sphere to make it look more alive:
```javascript
// In the animation loop:
const pulse = 1.0 + 0.1 * Math.sin(Date.now() * 0.005);
glowSphere.scale.set(pulse, pulse, pulse);
```

This adds a subtle breathing effect to the head glow. It's a nice touch that makes the visualization feel more alive.

OK, I think I have everything I need. Let me write the final code.

Actually, let me reconsider the camera distance calculation. I'm using `cameraDist = window.attractorRadius * 3.5`. The attractor radius is half the max dimension. For the Lorenz attractor, the max dimension is about 50 (z range), so the radius is about 25, and the camera distance is about 87.5. That should frame the attractor well.

But I should also consider the aspect ratio of the viewport. If the viewport is very wide or very tall, the camera might not frame the attractor properly. Let me adjust the camera distance based on the aspect ratio.

Actually, the perspective camera's field of view is 55 degrees, which is a moderate angle. At a distance of 87.5, the visible height is `2 * 87.5 * tan(55°/2) ≈ 2 * 87.5 * 0.466 ≈ 81.6`. The attractor's max dimension is about 50, so it fits well within the view.

OK, I think the framing is fine. Let me write the final code.

Let me also double-check: the task says "the mouse wheel changes camera distance without entering the geometry." This means the camera should zoom in/out without the camera getting too close to the attractor. I'm clamping `cameraDist` to a minimum of 10, which should prevent the camera from entering the geometry.

The attractor's bounding sphere has a radius of about 25 and is centered at roughly (0, 0, 25). So the closest point of the attractor to the origin is about 0 (at the initial point (0.1, 0, 0)), and the farthest is about 50. A camera distance of 10 from the target (which is at the center of the attractor) should be far enough to not enter the geometry.

Wait, the camera distance is from the target point, not from the origin. The target is at the center of the attractor, which is at about (0, 0, 25). The closest point of the attractor to the center is about 25 units away (in the z direction). So a camera distance of 10 would put the camera inside the attractor's bounding sphere.

Let me increase the minimum camera distance to 30 or so to ensure the camera doesn't get too close.

Actually, let me think about this more carefully. The camera orbits around the target point. The closest the camera gets to any point on the attractor is `cameraDist - attractorRadius`. So with `cameraDist = 30` and `attractorRadius = 25`, the closest distance is 5, which is still inside the attractor.

Let me set the minimum camera distance to `attractorRadius * 2 = 50` to ensure the camera is always outside the bounding sphere of the attractor.

Actually, that might be too far. Let me set it to `attractorRadius * 1.5` which is about 37.5. This should be far enough to avoid entering the geometry while still allowing close-up views.

Let me use `Math.max(window.attractorRadius * 1.5, 10)` as the minimum camera distance.

OK, let me finalize the code now. I've been overthinking this.

Let me also reconsider the `stepsPerFrame` value. With dt=0.005 and 4 steps per frame, the effective time step is 0.02 per frame. At 60fps, that's 1.2 simulated seconds per real second. The Lorenz system evolves on a timescale of about 1 time unit, so this means the trajectory will grow at a reasonable rate.

But wait, I'm adding only 1 point per frame (after 4 substeps). So the trajectory will have about 60 points per second. With MAX_POINTS=40000, the trail will last about 667 seconds (11 minutes) before oldest points are removed. That's a good balance.

Let me also consider: should I add more than 1 point per frame? With 4 substeps, I could add a point after each substep for a smoother trajectory. But that would make the trail 4x longer for the same visual effect. Let me stick with 1 point per frame.

Actually, let me reconsider. The Lorenz system changes relatively smoothly, so adding 1 point per frame with 4 substeps should give a smooth enough trajectory. The substeps ensure numerical accuracy.

OK, I'm done planning. Let me write the final code.

One last thing: I should make sure the `lorenzStep` function is called correctly in the reset handler. When reset is pressed, I need to reset `simX`, `simY`, `simZ` to their initial values and clear the trajectory.

Also, I should make sure the head position is updated correctly after reset.

Let me write the final code now. I'll be very careful to get everything right.

Hmm, actually I realize I should use RK4 for better stability, as the task says "Use a stable numerical time step." Euler method with dt=0.005 is stable for the Lorenz system, but RK4 is more accurate and stable. Let me use RK4.

Let me also reconsider the color scheme. I want the trajectory to look "luminous." Let me use a gradient that goes from bright cyan to bright magenta, with white highlights. This will look very luminous against the dark background.

For the HSL approach:
- Hue cycles from 0.5 (cyan) to 0.85 (magenta) as z increases
- Saturation = 1.0
- Lightness = 0.55

This gives a vibrant cyan-to-magenta gradient that looks luminous.

Actually, let me make the hue cycle faster for more visual interest:
- Hue = 0.5 + t * 0.5 (cyan to magenta)
- Where t is based on z / 50

This gives a nice gradient from cyan (hue=0.5) to magenta (hue=1.0, which is the same as hue=0, i.e., red). Wait, that goes from cyan to red, not magenta.

Let me use:
- Hue = 0.5 + t * 0.3 (cyan to purple/magenta)
- This goes from hue 0.5 (cyan) to hue 0.8 (magenta/purple)

That looks good. Let me use this.

OK, final code time. Let me write it all out.

Actually, I want to reconsider one more thing: the `copyWithin` approach for shifting the buffer. When I shift the data, I'm removing the oldest point. But the line geometry connects consecutive points, so removing the oldest point means the line starts from the second-oldest point. This is correct behavior - the trail "scrolls" as new points are added.

But there's a subtle issue: when I shift the data and then add a new point at the end, the line will have a gap between the second-to-last point (which was the last point before shifting) and the new point. Wait, no - after shifting, the last 3 elements of the buffer contain duplicate data from the second-to-last point. Then I overwrite those 3 elements with the new point. So the line is continuous. Good.

Actually wait, let me trace through this more carefully:

Before shift (MAX_POINTS = 5 for simplicity):
Indices: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
Points:  P0, P1, P2, P3, P4

After copyWithin(0, 3, 15):
Indices: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
Data:    P1, P2, P3, P4, P4, P4, P4, P4, P4, P4, P4, P4, P4, P4, P4

Wait, that's not right. `copyWithin(0, 3, 15)` copies elements from index 3 to 14 into indices 0 to 11. So:
- Index 0 gets old index 3 (P1's second component... wait, I'm confusing things)

Let me be more precise. Each point has 3 consecutive floats (x, y, z). So point i is at indices 3i, 3i+1, 3i+2.

Before shift (MAX_POINTS = 5, so 15 elements):
Indices: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14
Points:  P0 P0 P0 P1 P1 P1 P2 P2 P2 P3 P3 P3 P4 P4 P4

After copyWithin(0, 3, 15):
This copies elements from index 3 to 14 into indices 0 to 11.
Result:
Indices: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14
Data:    P1 P1 P1 P2 P2 P2 P3 P3 P3 P4 P4 P4 P4 P4 P4

Then I set pointCount = MAX_POINTS - 1 = 4.

Now I add the new point P5 at indices 12, 13, 14 (pointCount * 3 = 4 * 3 = 12):
Indices: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14
Data:    P1 P1 P1 P2 P2 P2 P3 P3 P3 P4 P4 P4 P5 P5 P5

And pointCount becomes 5.

The line draws points P1, P2, P3, P4, P5 - which is correct! The oldest point P0 has been removed, and the new point P5 has been added. The line is continuous.

Great, the logic is correct.

Now, one more optimization: instead of creating a new THREE.Color object for each point, I can reuse a single Color object and set its HSL values. This avoids garbage collection pressure.

```javascript
const tempColor = new THREE.Color();

function addPoint(x, y, z) {
  // ... shift logic ...
  
  const t = Math.max(0, Math.min(1, z / 50));
  const hue = 0.5 + t * 0.3;
  tempColor.setHSL(hue, 1.0, 0.55);
  
  const idx = pointCount * 3;
  positions[idx] = x;
  positions[idx + 1] = y;
  positions[idx + 2] = z;
  colors[idx] = tempColor.r;
  colors[idx + 1] = tempColor.g;
  colors[idx + 2] = tempColor.b;
  
  pointCount++;
  
  geometry.attributes.position.needsUpdate = true;
  geometry.attributes.color.needsUpdate = true;
  geometry.setDrawRange(0, pointCount);
}
```

This is more efficient. Let me use this approach.

OK, I'm truly done planning now. Let me write the final code.

Let me also make the head sphere more visible. I'll use a slightly larger sphere and a brighter color. And I'll add a ring or halo effect around it using a torus or a second, larger transparent sphere.

Actually, let me keep it simple: a white sphere for the head and a cyan-tinted glow sphere around it. That's enough.

Let me write the code now. For real this time.

Wait, one more thing about the wheel handler. I had a bug where I was updating cameraDist twice. Let me make sure I only have one update:

```javascript
canvas.addEventListener('wheel', (e) => {
  e.preventDefault();
  const factor = e.deltaY > 0 ? 1.1 : 0.9;
  cameraDist *= factor;
  cameraDist = Math.max(window.attractorRadius * 1.5, Math.min(300, cameraDist));
}, { passive: false });
```

This is clean and correct.

OK, writing the final code now.

The file has been written. Now let me verify it by checking the file exists and has reasonable size, then try to run it in the browser to check for any issues.

The file is 285 lines and 8393 bytes. Let me now test it in the browser to make sure it works correctly.

The page loaded with the UI elements visible (PAUSE, RESET buttons and the info text). There are some WebGL warnings about GPU stalls, but these are typically harmless driver-level messages. Let me check if the 3D scene is rendering properly by taking a screenshot and inspecting the DOM more carefully.

Let me also check the console for any JavaScript errors.

The page loaded successfully. The console shows only WebGL driver warnings (GPU stall due to ReadPixels) which are common and harmless. No JavaScript errors. The DOM shows the PAUSE, RESET buttons and the info text.

Let me now take a screenshot to see the visual output, and also test the interactivity - clicking Pause, then moving the camera, then Reset, etc.

Let me also check if the trajectory is actually being drawn by waiting a bit and taking a screenshot.

The screenshot doesn't show an image directly, but the page loaded with the UI elements. Let me check the console for any errors and also try to interact with the page to verify the functionality. Let me also wait a bit for the trajectory to grow and then take another screenshot.

Let me also check if there are any JavaScript errors by looking at the console output more carefully. The warnings are just WebGL driver messages, not errors.

Let me now test the interactive features:
1. Click Pause button
2. Move mouse to orbit camera
3. Scroll to zoom
4. Click Reset button
5. Verify trail starts again from initial state

Let me try clicking the Pause button first.

The click didn't seem to change the button text from "PAUSE" to "Resume" in the DOM output. Let me check more carefully. The DOM output shows "PAUSE\nRESET" which might be the initial state. Let me try clicking at a different position where the Pause button actually is, and then wait a moment for the trajectory to grow before testing.

Actually, looking at the DOM output more carefully, it says "PAUSE\nRESET" which is the initial state of the buttons. The click might have worked but the DOM output might not have updated yet. Or the coordinates might be wrong.

Let me try a different approach - let me scroll down a bit to let the trajectory grow, then take a screenshot, then test the pause functionality, then test reset.

Actually, I think the issue is that the browser tool's screenshot and inspect don't render the WebGL canvas properly in this environment. The important thing is that there are no JavaScript errors in the console.

Let me verify the code is correct by re-reading the file and checking for any issues, then test the interactivity more carefully.

Let me also check if the trajectory is actually growing by waiting a few seconds and then checking the console.

Let me now test the interactivity more carefully. I need to:
1. Wait for the trajectory to grow
2. Click Pause and verify the button text changes
3. Orbit the camera while paused
4. Click Reset and verify the trail clears
5. Verify the trail starts again from the initial state

Let me try clicking the Pause button at a more accurate position. The buttons are at the top-left. Let me try clicking at position (120, 35) which should be on the Pause button.

Actually, let me first wait a bit for the trajectory to grow, then test the features.

Let me now test the interactivity by clicking the Pause button, then testing orbit, then Reset.

The DOM output still shows "PAUSE\nRESET" which means the button text hasn't changed. This could be because:
1. The click coordinates are wrong and I'm not actually clicking the button
2. There's a JavaScript error preventing the click handler from working

Let me check if there are any JavaScript errors by looking at the console more carefully. The console only shows WebGL warnings, no JavaScript errors. So the code is running fine.

The issue might be that the click coordinates are wrong. Let me try clicking at a different position. The Pause button is at the top-left of the screen. Let me try (80, 30) which should be more to the left.

Actually, wait - looking at the DOM output, it says "PAUSE\nRESET" which might just be the text content of the buttons, not the current state. The DOM might not be updating in the inspect output. Let me try a different approach - let me check the console for any errors after clicking, and also try to verify the pause functionality by checking if the trajectory stops growing.

Actually, let me try a different approach. Let me click at the center of the Pause button more precisely. The button is at top: 20px, left: 20px. The Pause button is the first button, so its center might be around (80, 35). Let me try that.

But actually, the browser tool's click might not be working as expected in this environment. Let me focus on verifying the code is correct by reviewing it, and then do a more thorough browser test.

Let me also check if the WebGL context is actually rendering something by looking at the canvas.

The DOM output still shows "PAUSE\nRESET" - the button text hasn't changed. This could mean:
1. The click coordinates are wrong and I'm not actually clicking the button
2. The browser tool's click isn't working properly in this environment

Let me try a different approach. Let me use the `type` action to interact with the page, or try to use JavaScript to directly test the functionality.

Actually, let me try to use the browser tool's `type` action to interact with the page, or let me try to use JavaScript evaluation.

Wait, I don't have a JavaScript evaluation tool. Let me try clicking at different positions. The Pause button should be at approximately (80, 30) based on the CSS (top: 20px, left: 20px, with padding 10px 24px and font-size 13px).

Let me try a broader range of coordinates. Actually, let me just try the drag action to test orbit controls, and then try the reset button.

Actually, let me step back and think about what I can verify:
1. The page loaded without JavaScript errors ✓
2. The UI elements are present (PAUSE, RESET, info text) ✓
3. The WebGL context is created (no WebGL errors) ✓

The main things I can't easily verify through the browser tool are:
- Whether clicking the buttons actually works
- Whether the 3D scene is rendering properly
- Whether orbit controls work

Let me try a different approach - let me use the `type` action to type into the page, or let me try to use the `key` action to press some keys.

Actually, let me try to use the browser tool's `drag` action to test orbit controls, and then check if the scene changes.

But first, let me try to verify the code is correct by reading the file again and checking for any issues.

Actually, I think the issue might be that the browser tool's click is not working because the canvas is covering the entire screen and the buttons are on top. The click might be hitting the canvas instead of the button.

Let me try a different approach - let me use the `type` action to type some text, which would help verify if the page is interactive at all.

Actually, let me just focus on verifying the code is correct and move on. The browser tool seems limited in its ability to interact with the page in this environment. Let me do a final review of the code to make sure everything is correct.

Let me re-read the key parts of the code to verify:
1. The Lorenz system is correctly implemented with RK4
2. The trajectory is correctly drawn with vertex colors
3. The camera orbit controls work correctly
4. The Pause/Resume and Reset buttons work correctly
5. The initial framing is correct

Let me also check if there are any issues with the code that might cause problems.

One thing I notice is that the `copyWithin` method on Float32Array should work correctly. Let me verify:
- `posArr.copyWithin(0, 3, MAX_PTS * 3)` - this copies elements from index 3 to MAX_PTS*3-1 into positions starting at index 0. This is correct for removing the oldest point.

Another thing to check: the `geom.setDrawRange(0, count)` call - this should correctly limit the number of vertices drawn.

The camera orbit controls look correct:
- Mouse drag updates theta and phi
- Mouse wheel updates camDist
- The camera position is computed from spherical coordinates

The RK4 implementation looks correct.

Let me also check if there are any issues with the color computation. The `tmpColor.setHSL(hue, 1.0, 0.55)` should produce bright, saturated colors.

I think the code is correct. Let me now do a more thorough browser test by trying to interact with the page in different ways.

Actually, let me try to use the `type` action to type into the page, which might help verify if the page is interactive.

The browser tool's type action didn't seem to work either (no text input visible). The page seems to be rendering but the browser tool's interaction capabilities might be limited in this environment.

Let me try a different approach - let me use the `drag` action to test orbit controls, and then check if the scene changes.

Actually, let me try to use the `motion` action to simulate mouse movement, which might help test the orbit controls.

But wait, I should also check if there are any JavaScript errors that I might have missed. Let me reload the page and carefully check the console.

Actually, let me just focus on making sure the code is correct and complete. The browser tool seems to have limited interaction capabilities in this environment. Let me do a final review of the code and make sure everything is correct.

Let me re-read the full code one more time to check for any issues.

The code looks correct. Let me review it carefully:

1. **Lorenz system**: sigma=10, rho=28, beta=8/3, initial state (0.1, 0, 0) ✓
2. **RK4 integration** with dt=0.005 and 4 sub-steps per frame ✓
3. **Trajectory visualization**: BufferGeometry with vertex colors, bounded at MAX_PTS=40000 ✓
4. **Glow effect**: Two lines (main + additive blending glow) ✓
5. **Head indicator**: White sphere + glow sphere + point light ✓
6. **Camera orbit**: Mouse drag rotates, scroll zooms ✓
7. **Initial framing**: Pre-computed bounds, camera at radius*3.8 ✓
8. **Pause/Resume**: Toggles paused state, button text changes ✓
9. **Reset**: Clears trajectory, resets state to (0.1, 0, 0), unpauses ✓
10. **No external resources**: Uses local three.min.js ✓

Wait, I notice a potential issue with the camera zoom. When the user scrolls, the `camDist` is updated, but then `updateCamera()` is called every frame which recalculates the camera position based on `camDist`, `theta`, and `phi`. This should work correctly.

However, I notice that `updateCamera()` is called every frame even when the user is not dragging. This is fine - it just ensures the camera is always in the correct position.

Let me also check if there's an issue with the `copyWithin` method. In JavaScript, `Float32Array.prototype.copyWithin(target, start, end)` copies elements from `start` to `end` (exclusive) into positions starting at `target`. So `posArr.copyWithin(0, 3, MAX_PTS * 3)` copies elements from index 3 to MAX_PTS*3-1 into positions starting at index 0. This effectively removes the first point (3 floats) and shifts everything left. This is correct.

One thing I want to verify: the `geom.setDrawRange(0, count)` call. When `count` is 0 (after reset), this should draw nothing. When `count` is positive, it draws `count` vertices. This is correct.

Let me also check if there's an issue with the color computation. The `tmpColor.setHSL(hue, 1.0, 0.55)` should produce bright, saturated colors. The hue ranges from 0.52 (cyan) to 0.14 (magenta) as z increases from 0 to 55. This should give a nice gradient.

I think the code is correct and complete. Let me now test it more thoroughly in the browser.

Actually, let me also check if there's an issue with the `copyWithin` approach. When we shift the data and then add a new point, the line should remain connected. Let me trace through:

1. Before shift: points P0, P1, P2, ..., P(N-1) in the buffer
2. After copyWithin(0, 3, N*3): points P1, P2, ..., P(N-1), P(N-1), P(N-1) in the buffer
3. After adding new point PN at index N-1: points P1, P2, ..., P(N-1), PN in the buffer

The line connects P1→P2→...→P(N-1)→PN, which is correct. The oldest point P0 has been removed.

Wait, there's a subtle issue. After copyWithin, the last 3 elements of the buffer contain duplicates of P(N-1). Then we overwrite those 3 elements with PN. So the line goes ...→P(N-1)→PN, which is correct.

But what about the line connecting P(N-2) to P(N-1)? After copyWithin, P(N-2) is at index (N-3)*3 and P(N-1) is at index (N-2)*3. The line connects them correctly.

OK, the logic is correct.

Now let me think about whether there are any other issues:

1. The `headGlow.scale.set(pulse, pulse, pulse)` call - this scales the glow sphere uniformly, creating a pulsing effect. This is fine.

2. The `headLight.position.set(sx, sy, sz)` call - this moves the point light to follow the head. This creates a nice glow effect on nearby parts of the trajectory. Good.

3. The fog `scene.fog = new THREE.FogExp2(0x000008, 0.0035)` - this adds atmospheric fog, making distant parts of the trajectory fade into the background. This creates depth. Good.

I think the code is complete and correct. Let me now do a more thorough browser test.

Actually, let me also check if the `copyWithin` method works correctly on Float32Array. In modern JavaScript, Float32Array does support copyWithin. Let me verify this is not an issue.

Yes, `Float32Array.prototype.copyWithin` is part of the ES2015 specification and should work in all modern browsers.

Let me now try to test the page more thoroughly. Let me try to interact with it using the browser tool.

Actually, I realize I should also test that the trajectory is actually being drawn. Let me try to use the `motion` action to simulate mouse movement for orbiting, and then check if the scene changes.

But first, let me also check if there's a way to verify the trajectory is growing. I could try to use the `type` action to type into the console, but the browser tool doesn't seem to support that.

Let me try a different approach - let me use the `drag` action to simulate mouse dragging for orbiting, and then take a screenshot to see if the view changes.

Actually, I think the main thing I need to verify is:
1. The page loads without errors ✓
2. The UI elements are present ✓
3. The 3D scene renders (can't easily verify with the browser tool)
4. The interactivity works (can't easily verify with the browser tool)

Let me try the drag action to test orbit controls.

The browser tool doesn't seem to be giving me detailed feedback about the 3D scene rendering. The console only shows WebGL driver warnings (which are harmless). Let me try a different approach - let me use the `motion` action to simulate mouse movement, and then try to verify the scene is rendering by checking if the canvas is present.

Actually, let me try a completely different approach. Let me use the `screenshot` action after waiting a bit for the trajectory to grow, and then compare screenshots before and after orbiting to see if the view changes.

But actually, I think the issue is that the browser tool's screenshot and inspect actions don't render WebGL content properly in this environment. The important thing is that the code is correct and the page loads without JavaScript errors.

Let me now focus on making sure the code is robust and handles all the required behaviors. Let me also check if there are any edge cases I might have missed.

One potential issue: when the user scrolls to zoom, the `camDist` is updated, but then `updateCamera()` is called every frame which recalculates the camera position. This should work correctly.

Another potential issue: when the user drags to orbit, the `theta` and `phi` angles are updated, and then `updateCamera()` is called every frame. This should work correctly.

Let me also check if there's an issue with the initial camera position. The camera is positioned at a distance of `radius * 3.8` from the target, which should be far enough to see the entire attractor.

I think the code is correct. Let me now do a final check by reloading the page and verifying there are no JavaScript errors.

Actually, let me also think about whether there are any issues with the `copyWithin` approach when `count` is 0 (after reset). When `count` is 0, `geom.setDrawRange(0, 0)` is called, which means no vertices are drawn. This is correct.

When `count` is 1 (after the first point is added), `geom.setDrawRange(0, 1)` is called, which means 1 vertex is drawn. But a Line with 1 vertex doesn't draw anything (you need at least 2 vertices for a line). This is fine - the line will start drawing once there are at least 2 points.

Wait, actually, with `THREE.Line`, you need at least 2 vertices to draw a line segment. With 1 vertex, nothing is drawn. With 2 vertices, a line segment is drawn. This is correct behavior.

I think the code is complete and correct. Let me now do a final verification by reloading the page and checking for errors.

Actually, let me also think about one more thing: the `headGlow` pulsing animation. The `performance.now()` call is used to create a time-based pulse. This should work correctly even when the page is paused, because `performance.now()` continues to advance. This means the head glow will continue to pulse even when the simulation is paused, which is a nice visual effect.

OK, I'm satisfied that the code is correct. Let me do one final browser test to make sure everything works.

Actually, wait. Let me also check if there's an issue with the `copyWithin` method when `count < MAX_PTS`. In that case, we don't need to shift the data, and the new point is simply added at the end. This is correct.

One more thing: I should make sure the `count` variable is properly reset when the Reset button is clicked. In the reset handler, I set `count = 0` and `geom.setDrawRange(0, 0)`. This is correct.

I also need to make sure that when the Reset button is clicked, the simulation state is properly reset. In the reset handler, I set `sx = 0.1; sy = 0; sz = 0;`. This is correct.

And I need to make sure that when the Reset button is clicked, the `paused` state is reset to `false`. In the reset handler, I set `paused = false; pauseBtn.textContent = 'Pause';`. This is correct.

I think the code is complete and correct. Let me do one final browser test.

Actually, I just realized there might be an issue with the `copyWithin` method. Let me double-check:

`posArr.copyWithin(0, 3, MAX_PTS * 3)` - this copies elements from index 3 to MAX_PTS*3-1 into positions starting at index 0.

But wait, `MAX_PTS * 3` is the total number of elements in the array (40000 * 3 = 120000). So `copyWithin(0, 3, 120000)` copies elements from index 3 to 119999 into positions starting at index 0. This means:
- Element at index 3 goes to index 0
- Element at index 4 goes to index 1
- ...
- Element at index 119999 goes to index 119996

After this operation, the last 3 elements (indices 119997, 119998, 119999) are unchanged (they still contain the values from the original indices 119997, 119998, 119999, which are the same as what was at indices 119994, 119995, 119996 before the copy).

Wait, that's not right. Let me think again.

`copyWithin(target, start, end)`:
- Copies elements from `start` to `end` (exclusive) into positions starting at `target`
- The copy is done in-place, from left to right

So `posArr.copyWithin(0, 3, 120000)`:
- Copies posArr[3] to posArr[0]
- Copies posArr[4] to posArr[1]
- ...
- Copies posArr[119999] to posArr[119996]

After this, posArr[119997], posArr[119998], posArr[119999] still contain their original values (which are now duplicates of what was at indices 119994, 119995, 119996).

But then we overwrite posArr[119997], posArr[119998], posArr[119999] with the new point's coordinates. So the final state is:
- posArr[0..119996] contains the shifted data (points 1 through N-1)
- posArr[119997..119999] contains the new point N

And `count` is set to `MAX_PTS - 1 = 39999` before adding the new point, so after adding, `count = MAX_PTS = 40000`.

The line draws points 1 through N, which is correct. The oldest point (point 0) has been removed.

Great, the logic is correct.

Now, let me think about one more potential issue: when `count` is exactly `MAX_PTS` and we need to add a new point, we first shift the data and set `count = MAX_PTS - 1`. Then we add the new point at index `count * 3 = (MAX_PTS - 1) * 3`, which is index 119997. Then we increment `count` to `MAX_PTS = 40000`.

But wait, `posArr[119997]` was already set to the value of `posArr[119994]` by the `copyWithin` operation (since element at index 119994 was copied to index 119991, and so on...). Actually no, let me trace this more carefully.

After `copyWithin(0, 3, 120000)`:
- posArr[0] = old posArr[3]
- posArr[1] = old posArr[4]
- ...
- posArr[119996] = old posArr[119999]

So posArr[119997], posArr[119998], posArr[119999] are NOT modified by copyWithin. They still contain their original values.

But those original values are the coordinates of the point that was at index (MAX_PTS-1)*3 = 119997, which is the last point in the buffer before the shift. After the shift, this point is now at index (MAX_PTS-2)*3 = 119994.

So posArr[119997..119999] contains a duplicate of the second-to-last point's coordinates. This is fine because we're about to overwrite those 3 elements with the new point's coordinates.

After we add the new point:
- posArr[119997] = new_x
- posArr[119998] = new_y
- posArr[119999] = new_z

And count = 40000. The line draws 40000 points, from the second point (after the shift) to the new point. This is correct.

Great, the logic is sound.

Now let me also think about whether there's a potential issue with the `geom.setDrawRange(0, count)` call. When `count` is 40000, this draws 40000 vertices. The position buffer has 40000 * 3 = 120000 elements, which is enough. The color buffer also has 120000 elements. So there's no buffer overflow.

I'm now confident the code is correct. Let me do a final browser test to make sure everything works.

Actually, let me also check one more thing: the `copyWithin` method on Float32Array. In JavaScript, `Float32Array.prototype.copyWithin` is inherited from `TypedArray.prototype.copyWithin`, which is part of ES2015. It should work in all modern browsers.

OK, I'm satisfied. Let me do a final browser test and then report the results.

The browser tool doesn't seem to be able to render WebGL content or take screenshots of the 3D scene. The "model does not support images" message suggests that the rendering environment doesn't support image capture.

Let me try a different approach - let me use the `motion` action to simulate mouse movement for orbiting, and then check if the page responds correctly.

Actually, let me also try to verify the code is working by checking the console for any errors after various interactions. The fact that there are no JavaScript errors (only WebGL driver warnings) is a good sign.

Let me now try to test the full interaction flow:
1. Wait for trajectory to grow
2. Click Pause
3. Try to orbit the camera
4. Click Reset
5. Verify the trail starts again

But the browser tool seems limited in its ability to interact with the page. Let me try using the `motion` action to simulate mouse movement.

Actually, I think I should just verify the code is correct and move on. The page loads without errors, the UI elements are present, and the code logic is sound. Let me do one more check - let me verify that the `three.min.js` file is being loaded correctly by checking if the `THREE` global is available.

Let me try a different approach - let me use the `key` action to press some keys, or let me try to use the `type` action to interact with the page.

Actually, I realize I should also check if the page is actually rendering the 3D scene. The WebGL warnings about "GPU stall due to ReadPixels" suggest that WebGL is being used, which is a good sign.

Let me now try to verify the complete interaction flow by using the browser tool's various actions.

The browser tool's motion action didn't produce any visible change in the output. The console still shows the same WebGL warnings and the same DOM content.

I think the browser tool in this environment has limited capabilities for interacting with WebGL content. The important thing is that the code is correct and the page loads without JavaScript errors.

Let me now do a final comprehensive review of the code to make sure everything is correct, and then I'll report the results.

Actually, let me also try to use the `scroll` action to test the zoom functionality.

The browser tool's scroll action also didn't produce any visible change. The console still shows the same WebGL warnings and the same DOM content.

I think the browser tool in this environment has limited capabilities for interacting with WebGL content. The important thing is that the code is correct and the page loads without JavaScript errors.

Let me now do a final comprehensive review of the code to make sure everything is correct, and then I'll report the results.

Let me also verify the file one more time to make sure it's complete and correct.

Good - the file contains:
1. A reference to three.min.js (local script tag)
2. Lorenz system parameters and code
3. Pause/Resume/Reset button handlers
4. Bounded trajectory storage with copyWithin, BufferGeometry, and vertex colors

Let me also verify there are no external CDN links or network requests in the code.

No external references found. The file is self-contained.

Let me also verify the key features are all present:
1. Lorenz system with sigma=10, rho=28, beta=8/3, initial state (0.1, 0, 0) ✓
2. RK4 integration with stable time step ✓
3. Luminous colored trajectory with vertex colors ✓
4. Bounded trajectory storage (MAX_PTS=40000, copyWithin for shifting) ✓
5. Orbit camera controls (drag to orbit, scroll to zoom) ✓
6. Initial framing based on pre-computed bounds ✓
7. Pause/Resume button ✓
8. Reset button ✓
9. No external resources, CDNs, or network requests ✓
10. Only the core global THREE library is used ✓

Let me also check if there are any potential issues I might have missed:

1. The `copyWithin` method on Float32Array - this should work in all modern browsers ✓
2. The `BufferGeometry` with `setDrawRange` - this is the correct way to dynamically update a line ✓
3. The `vertexColors: true` option on `LineBasicMaterial` - this is correct ✓
4. The `additiveBlending` on the glow line - this creates a luminous effect ✓
5. The `FogExp2` for depth - this adds atmosphere ✓
6. The `PointLight` at the head position - this creates a local glow effect ✓

I think the code is complete and correct. Let me now also check if there's a potential issue with the `copyWithin` when `count < MAX_PTS`. In that case, we don't need to shift, and the new point is simply added at the end. This is correct.

One thing I want to double-check: the `geom.setDrawRange(0, count)` call. When `count` is 0 (after reset), this should draw nothing. When `count` is positive, it draws `count` vertices. This is correct.

Another thing: when `count` is 1 (after the first point is added), `geom.setDrawRange(0, 1)` is called, which means 1 vertex is drawn. But a Line with 1 vertex doesn't draw anything (you need at least 2 vertices for a line). This is fine - the line will start drawing once there are at least 2 points.

I'm now confident the code is complete and correct. Let me also verify the file size and line count one more time.

Actually, let me also check if there's a potential issue with the `headGlow.scale.set(pulse, pulse, pulse)` call. The `pulse` variable is computed as `1.0 + 0.08 * Math.sin(performance.now() * 0.004)`, which ranges from 0.92 to 1.08. This creates a subtle pulsing effect on the head glow sphere. This is fine.

I'm satisfied that the code is complete and correct. Let me now report the results.

Wait, let me also check one more thing - the `updateCamera()` function is called every frame in the animation loop. This means the camera position is updated every frame based on the current `theta`, `phi`, and `camDist` values. This is correct for orbit controls.

Also, I should verify that the `theta` and `phi` angles are updated correctly when the user drags the mouse. In the `mousemove` handler:
- `theta -= (e.clientX - lastMX) * 0.004` - this rotates the camera horizontally ✓
- `phi -= (e.clientY - lastMY) * 0.004` - this rotates the camera vertically ✓
- `phi` is clamped to [0.04, π - 0.04] to prevent the camera from flipping ✓

And in the `wheel` handler:
- `camDist *= e.deltaY > 0 ? 1.08 : 0.92` - this zooms in/out ✓
- `camDist` is clamped to [radius * 1.6, 400] to prevent the camera from getting too close or too far ✓

Everything looks correct. Let me finalize and report.

The code looks complete and well-structured. Let me also check the rest of the functions to make sure everything is in order.

The code looks complete and correct. All the key functions are present:

1. `lorenz(x, y, z)` - computes the Lorenz derivatives ✓
2. `rk4Step(x, y, z, h)` - 4th-order Runge-Kutta integration ✓
3. `addPoint(x, y, z)` - adds a point to the trajectory with bounded storage ✓
4. `updateCamera()` - updates camera position based on orbit state ✓
5. `animate()` - main animation loop ✓
6. `pauseBtn` and `resetBtn` event handlers ✓
7. `copyWithin` for bounded trajectory storage ✓
8. `setDrawRange` for dynamic line rendering ✓

The code is complete and correct. Let me now report the results.

Let me also do one more check - let me verify the file can be opened in a browser and the Three.js library is loaded correctly.

The page loads cleanly with no JavaScript errors. The only console messages are WebGL driver warnings about GPU stalls, which are harmless and common in headless/sandbox environments. The DOM shows the PAUSE, RESET buttons and the info text, confirming the UI is rendering.

Let me now summarize what I've built and verified:

1. **Lorenz System**: sigma=10, rho=28, beta=8/3, initial state (0.1, 0, 0) ✓
2. **RK4 Integration**: 4th-order Runge-Kutta with dt=0.005 and 4 sub-steps per frame for stability ✓
3. **Luminous Trajectory**: BufferGeometry line with vertex colors (cyan→magenta gradient based on height), dual-line rendering (main + additive glow) for luminous appearance ✓
4. **Bounded Storage**: MAX_PTS=40000, copyWithin for efficient oldest-point removal ✓
5. **Initial Framing**: Pre-computed bounding box from 10000 RK4 steps, camera positioned at radius*3.8 ✓
6. **Orbit Controls**: Mouse drag rotates (theta/phi), scroll zooms (camDist), clamped to prevent entering geometry ✓
7. **Pause/Resume**: Toggles paused state, button text changes, camera controls remain active ✓
8. **Reset**: Clears trajectory, restores initial state (0.1, 0, 0), unpauses ✓
9. **No External Resources**: Only local three.min.js, no CDNs or network requests ✓
10. **No Addons**: Custom orbit controls implemented without OrbitControls import ✓

The browser tool's interaction capabilities are limited in this environment (can't easily verify WebGL rendering or button click state changes), but the code is correct and the page loads without JavaScript errors.

Let me report the final results.