The user wants me to build a single-page web app in `index.html` that visualizes the Lorenz attractor as a glowing 3D butterfly trajectory using Three.js (pre-provided `three.min.js` in the current directory). Requirements:

1. Single self-contained `index.html`
2. CSS in `<style>`, JS in `<script>`, inline
3. No external resources, CDNs, or network requests
4. Include `<script src="three.min.js"></script>` using exact filename
5. Use pre-provided Three.js global `THREE`
6. Lorenz attractor visualization
7. Glowing 3D butterfly trajectory that draws over time
8. Orbit-drag camera controls

Wait - if we use orbit controls from Three.js, the standard `OrbitControls` is an ES module typically, but `three.min.js` is a UMD bundle that provides global `THREE`. If `OrbitControls` is not provided separately, I need to implement my own orbit controls using mouse events. The prompt says "orbit-drag camera controls". Since I cannot use CDNs, and I don't know if OrbitControls.js is present, I should implement mouse orbit controls manually (track rotation by dragging with mouse, zoom with wheel). This is doable with simple math (spherical coordinates or rotation matrix).

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

Typical parameters: sigma = 10, rho = 28, beta = 8/3.

I need to:
- Compute the attractor points using small time steps.
- Use a `BufferGeometry` and dynamically update positions as the trajectory draws over time.
- Use a glowing effect without post-processing (since we can't easily import EffectComposer without modules/CSS). Instead, we can use:
    - A starfield / darker background
    - Additive blending
    - Sphere-like points along the trajectory
    - Or use a custom shader material with glow-like size attenuation, or simply use many points with point sprites and a circular sprite texture generated on canvas (no external files).
- Camera orbit controls: implement manually with mouse events:
    - Mouse drag to rotate around target (spherical coordinates: theta, phi)
    - Scroll wheel to zoom (dolly in/out) or change target distance.
- Make it look glowing. We can:
    - Use a canvas-generated circular gradient texture for points (on the fly).
    - Set `blending: THREE.AdditiveBlending`.
    - Use colors based on position or time (gradient along the attractor).
    - Maybe use a `LineBasicMaterial` for the path, plus additional point glow.
    - Or better: use a `Line` with opacity and many points, plus a phosphorescent trail.

Approach:
- Scene with dark background (almost black).
- Camera at some distance from center.
- Lorenz integration: Runge-Kutta or simple Euler with very small dt (0.005 or 0.01) to get accurate trajectory. Limit to e.g., 15000-20000 points. Compute in batches.
- Fit numbers: display length ~20000 or ~30000 points.
- Create a `BufferGeometry` with positions attribute, and a color attribute also if we want gradient colors.
- Create a `Line` or `Points`. For "glowing 3D butterfly trajectory", we can use a `Points` object with many overlapping points for a tube-like glow, plus a `Line` to show the path clearly.
- Actually, to get a nice glowing trail, using `Points` with additive blending and a sprite generated from canvas works well. But we also need the "drawing over time" aspect. We can incrementally update the geometry (positions) and the draw range or buffer count. Use `geometry.setDrawRange(0, count)`. Start count at 0 and increase by some number each frame.
- Implement a frame loop where we compute next chunk of points, extend buffer, update geometry, increment draw range, and render.
- Orbit controls: maintain spherical coordinates around target (0,0,0). On drag, update theta and phi. Clamp phi to avoid flipping. Update camera position using spherical math. On wheel, change radius. Use `pointer events` (mousedown, mousemove, mouseup, wheel). Also support touch for mobile? Not strictly necessary but we can add basic support.

Implementation details:
- Precompute positions in chunks. Keep a large Float32Array buffer (e.g., max 30000 * 3). Use `geometry.setAttribute('position', new THREE.BufferAttribute(positions, 3))`. Or create with initial size and reuse. But `BufferGeometry` requires setting attribute; we can create with `position: new THREE.BufferAttribute(positionsArray, 3)`, then after computing new points, we need `geometry.attributes.position.needsUpdate = true` and `geometry.setDrawRange(0, currentCount)`. That works.
- Precompute colors in a `THREE.BufferAttribute` with color based on index (time progression) or using HSL based on index to simulate a glowing gradient (e.g., cyan to pink).
- For glow effect with `Points`:
    - Create a canvas element offscreen: 64x64. Draw radial gradient white center -> transparent edge. Use it as a `THREE.PointsMaterial` map. Set `blending = THREE.AdditiveBlending`, `depthWrite = false`, `transparent: true`, `opacity: 0.6`.
    - `sizeAttenuation: true`.
- To get a sharper path, also add a `THREE.Line` with vertex colors:
    - Use a second geometry or same geometry? `Line` uses same `position` attribute if we share it, but we can have separate geometries. Better: same position buffer, but line material is opaque or emissive. For Line, we can use `vertexColors: true` and `LineBasicMaterial` with `blending: AdditiveBlending` and `transparent: true`, `depthWrite: false` to make it also glow-ish but closer to core.
- Since we have two objects sharing the same position buffer, as we increase draw range, both will render more points. Fine.

Orbit controls implementation:
```javascript
let theta = 0; // azimuth
let phi = Math.PI / 4; // elevation from top? Let's define phi as angle from vertical (0 = top, PI = bottom), or use spherical convention where phi is polar angle from positive Z-axis. We'll keep it simple: 
We want to orbit around origin. We can represent camera in spherical coords:
- azimuth angle `theta`
- elevation angle `phi` (angle from horizontal plane, or from vertical). Let's use `theta` around Y axis and `phi` as elevation from XZ plane.
Actually typical orbit controls: spherical coordinates with polar angle `phi` (0 at +Z, PI at -Z) and azimuth `theta`. But simpler: let's just use:
`camera.position.x = radius * Math.cos(phi) * Math.sin(theta)`
`camera.position.y = radius * Math.sin(phi)`
`camera.position.z = radius * Math.cos(phi) * Math.cos(theta)`
Where `phi` is elevation from horizontal plane (positive up). Clamp to [-PI/2+0.1, PI/2-0.1].
On drag: track delta X and Y, multiply by sensitivity. `theta -= deltaX * factor`, `phi += deltaY * factor`. Clamp.
On wheel: `radius += event.deltaY * 0.01`. Clamp min/max.
Target always (0,0,0). Camera lookAt target.

Need to handle initial position. Set `phi = Math.PI/4` (about 45° elevation). `theta = 0`. `radius = 60` maybe (since attractor fits roughly within [-20,20] for x/z, y up to ~50). Let's compute approximate bounding box: x range ~[-20,20], z range ~[-30,30], y range ~[0,50]. So starting radius ~50-60 is fine.

Renderer:
- `THREE.WebGLRenderer` with antialias.
- Set size to window inner size. Append to body.
- On resize: update camera aspect and renderer size.

Styling:
- Full screen, margin 0, overflow hidden.
- Maybe a subtle UI overlay with instructions ("Drag to rotate, scroll to zoom").

Animation / drawing:
- Each animation frame:
    - If we haven't reached max points, compute next package of N points (e.g., 100-200 per frame) using Euler or RK4. Since we want smooth drawing over time, maybe compute 10-20 points per frame is enough, but to fill in faster, we can compute 200 per frame. Total 20000 points at 200/frame = 100 frames ~1.5s. Maybe compute 100 per frame for longer tail. So ~200 frames = ~3.3s. We also want a continuous feel.
    - Actually, we can keep adding indefinitely and let the attractor cycle. But in practice, attractor repeats without being periodic, so we can compute until maxPoints.
    - We can also precompute a fixed set of points to avoid numerical drift? Since it's deterministic, we can generate an array of length `MAX_POINTS` upfront using a for-loop over time. Then the animation just increments `count`. This is simpler and runtime doesn't need to compute on the fly. However, the "draws over time" implies it appears sequentially, not all at once.
    - Let's precompute positions and colors at startup. Use time step dt=0.005 (or 0.008) and 25000 steps. That gives a lot of detail. The buffer sizes are set at `MAX_POINTS`. During animation, we set `drawRange(0, count)` and increment count.
    - Euler integration is okay for visualization. Use dt = 0.008 or 0.005. Because with rho=28, it might get fast. Let's test mentally: initial conditions (0.1, 0, 0). With dt=0.005, it's fine. We can even use dt=0.01 and more steps.

Lorenz parameters:
- sigma = 10
- rho = 28
- beta = 8/3 ≈ 2.6667

We need to handle initialization; initial point near but not exactly at origin to avoid fixed point: `(0.1, 0, 0)`.

Glowing colors:
- Use HSL conversion: each point color depends on its index modulo something, or we map the value of x or y to hue.
- For a nice butterfly, maybe color by z height. But a palette (purple -> purple -> blue -> cyan) gives neon glow.
- We can compute color for each vertex using a generic linear interpolation between two colors based on index.
- With `vertexColors: true` on materials, colors will vary along the path.

Structure of index.html:
```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>
  body { margin:0; overflow:hidden; background:#000; font-family: sans-serif; }
  canvas { display:block; }
  #ui { position:absolute; top:10px; left:10px; color:#aaa; pointer-events:none; font-size:14px; }
</style>
</head>
<body>
<div id="ui">Drag to orbit · Scroll to zoom</div>
<script src="three.min.js"></script>
<script>
  // all JS here
</script>
</body>
</html>
```

JS inside script:
1. Setup scene, camera, renderer.
2. Generate Lorenz data.
3. Create textures / materials / geometries.
4. Create Points and Line objects.
5. Add to scene.
6. Initialize orbit state.
7. Event listeners.
8. Animation loop: update draw count, update orbit, render.

Generating canvas glow sprite:
```javascript
function createGlowTexture() {
  const canvas = document.createElement('canvas');
  canvas.width = 64;
  canvas.height = 64;
  const ctx = canvas.getContext('2d');
  const gradient = ctx.createRadialGradient(32, 32, 0, 32, 32, 32);
  gradient.addColorStop(0, 'rgba(255,255,255,1)');
  gradient.addColorStop(0.2, 'rgba(255,255,255,0.8)');
  gradient.addColorStop(0.5, 'rgba(120,120,255,0.4)');
  gradient.addColorStop(1, 'rgba(0,0,0,0)');
  ctx.fillStyle = gradient;
  ctx.fillRect(0,0,64,64);
  const texture = new THREE.CanvasTexture(canvas);
  return texture;
}
```

Material for points:
```javascript
const pointMaterial = new THREE.PointsMaterial({
  size: 0.8,
  map: createGlowTexture(),
  blending: THREE.AdditiveBlending,
  depthWrite: false,
  transparent: true,
  vertexColors: true,
  sizeAttenuation: true
});
```

Material for line:
```javascript
const lineMaterial = new THREE.LineBasicMaterial({
  vertexColors: true,
  blending: THREE.AdditiveBlending,
  transparent: true,
  depthWrite: false,
  linewidth: 1 // note: linewidth only works in some renderers
});
```

Since `THREE.Line` only draws 1px lines on many systems. But the line is just a core; the Points provide the glow. So line 1px is okay if points overlap. But to make the line also visible, we can use a tube-like geometry or `Line` with many segments. Since it's 1px, maybe points should be somewhat larger (size: 1.0 or 1.2) and spaced close. With 30000 points along 25000 steps, spacing is equal to dt * velocity magnitude? The velocity is ~10-50. dt=0.005 => distance per step ~0.05-0.25. Total path length maybe ~1000-2000 units. With 20000 points, average spacing ~0.05-0.1. If point size is 0.8, they'll heavily overlap, good for glow. Even if line is 1px, it will be a thin core. Points will create the glow.

Alternatively, we can avoid a separate Line object and just use Points with a slight opacity and additive blending to create a gaze. That is simpler and very beautiful. But to give structure, a line helps. Let's keep both.

Wait: Creating Points and Line with same position buffer? We can have separate BufferGeometry each with their own position attribute, but both referencing the same underlying Float32Array. But if we update `needsUpdate` on one, does it affect the other? No, unless it's the exact same `BufferAttribute` object (so same typed array). They can share the typed array but each geometry wraps its own `BufferAttribute` instance. If we have:
```javascript
const positions = new Float32Array(MAX_POINTS * 3);
const lineGeo = new THREE.BufferGeometry();
lineGeo.setAttribute('position', new THREE.BufferAttribute(positions, 3));
const pointsGeo = new THREE.BufferGeometry();
pointsGeo.setAttribute('position', new THREE.BufferAttribute(positions.slice(), 3)); // shares data?
```
A slice copies, not desired. We can share the same `BufferAttribute` instance, but `BufferGeometry` retains ownership; you can set the same object on both. Let's try:
```javascript
const posAttr = new THREE.BufferAttribute(positions, 3);
lineGeo.setAttribute('position', posAttr);
pointsGeo.setAttribute('position', posAttr);
```
This works, and updating `needsUpdate = true` on one will affect both? Since it's the same object, yes. But I need to check if `Line` and `Points` both read from the same attribute at draw time. Usually they do. This saves memory.

Same for colors.

Data generation:
```javascript
const sigma = 10;
const rho = 28;
const beta = 8/3;
const dt = 0.005;
const MAX_POINTS = 25000;
const positions = new Float32Array(MAX_POINTS * 3);
const colors = new Float32Array(MAX_POINTS * 3);
let x = 0.1, y = 0, z = 0;
for (let i = 0; i < MAX_POINTS; i++) {
  const dx = sigma * (y - x) * dt;
  const dy = (x * (rho - z) - y) * dt;
  const dz = (x * y - beta * z) * dt;
  x += dx; y += dy; z += dz;
  positions[i*3] = x;
  positions[i*3+1] = y;
  positions[i*3+2] = z;
  // color map: e.g., hue based on z normalized or index
  const t = i / MAX_POINTS;
  const color = new THREE.Color();
  // gradient from blue to purple to pink
  color.setHSL((0.6 + t * 0.4) % 1.0, 1.0, 0.5 + 0.2 * Math.sin(t * Math.PI));
  colors[i*3] = color.r;
  colors[i*3+1] = color.g;
  colors[i*3+2] = color.b;
}
```
Wait, the attractor shape: x ranges ~[-20,20], y ~[-30,30], z ~[0,50]. Using setHSL where hue goes from blue (0.6) to pink (~0.9) gives a nice gradient.

This color generation uses `new THREE.Color()` inside a loop, which is okay for one-time setup, but to avoid creating garbage, we can compute HSL manually:
```javascript
const hue = (0.6 + t * 0.4) % 1.0;
// Three.js Color conversion:
const c = new THREE.Color().setHSL(hue, 1.0, 0.6);
```
But doing inside loop 25000 times is okay in one-time initialization. Could also compute using simple math approximations.

Could also compute color based on position vector magnitude or sign of x for bi-color effect, but a gradient is nicer.

Orbit controls specifics:
- Track mouse state: `isDragging = false`, `previousMousePosition = {x:0, y:0}`.
- Events: `mousedown` on window. On mousedown button 0, start drag, set previous.
- `mousemove`, if dragging, calc delta, update theta/phi, update camera position. Prevent default? Maybe not needed.
- `mouseup` anywhere on window, stop dragging. Add `mouseleave` just in case.
- `wheel` event: update radius. `deltaY` scrolls.
- Touch support: touchstart/touchmove/touchend. Useful on mobile.

Manual orbit with `camera.position` and `camera.lookAt(0,0,0)`:
```javascript
function updateCamera() {
  const x = radius * Math.cos(phi) * Math.sin(theta);
  const y = radius * Math.sin(phi);
  const z = radius * Math.cos(phi) * Math.cos(theta);
  camera.position.set(x, y, z);
  camera.lookAt(0,0,0);
}
```
We should ensure `phi` is not exactly ±PI/2 to avoid gimbal / projection singularities. Clamp between `-Math.PI/2 + 0.01` and `Math.PI/2 - 0.01`.

Initial values: `theta = 0`, `phi = Math.PI * 0.25` (45° up), `radius = 80`.

Animation loop:
```javascript
let drawCount = 0;
const CHUNK = 150; // points per frame

function animate() {
  requestAnimationFrame(animate);
  if (drawCount < MAX_POINTS) {
    drawCount = Math.min(drawCount + CHUNK, MAX_POINTS);
    lineGeo.setDrawRange(0, drawCount);
    pointsGeo.setDrawRange(0, drawCount);
    lineGeo.attributes.position.needsUpdate = true;
    pointsGeo.attributes.position.needsUpdate = true;
  }
  renderer.render(scene, camera);
}
```
Wait, since we precomputed the entire buffer, we don't actually need to "compute new points" per frame, just extend the draw range. That's simpler and ensures stable dt with no runtime dependencies. It also avoids needing a large incremental buffer.

Could we slowly extend it? Yes. We start with drawCount = 0, then increment by CHUNK per frame until max. That makes the attractor "draw over time".

Potential issue: ` neon` + additive blending on black background => points accumulate and become very white near center of path if point size overlaps self. With large radius (0.8) and many close points per segment, the line will appear very thin white core with colored glow around because of additive. That's perfect.

We might want to add a very subtle ambient light, but PointsMaterial and LineBasicMaterial are unlit (blinn/phong not supported). We rely on `vertexColors` + additive.

We also need some "background stars" to make it feel 3D? Maybe not required, but simple to add a few white points far away. However, keep it minimal.

WebGL renderer with alpha? Not needed.

Implementation plan:

Let's write the file.

Edge cases:
- `three.min.js` is a UMD script so `THREE` is available inline after it.
- Orbit controls need `window` and `document`. Fine.
- We need to initialize renderer after DOM load? Since script at end of body, DOM is ready.
- Handle window resize events.

Lorenz attractor drawing speed:
- If MAX_POINTS = 30000 and CHUNK = 200, it takes 150 frames (~2.5s at 60fps). That's a nice reveal speed.

Colors:
- Use HSL gradient. Hue from blue (240°) to pink (300°) or more. `setHSL(h, s, l)` takes h in [0,1]. 0.6 = blue, 0.9 = pink. That works.

Let's refine to use HSL and maybe a slight brightness pulse based on index.

Potential memory usage: 30000 * 3 * 4 bytes * 2 (positions + colors) = 720KB. Fine.

Let's write the file content.

One subtlety: when using `new THREE.BufferAttribute(positions, 3)`, if we pass `normalized: true` or not, default is false. Fine.

Include `#ui` overlay with pointer-events:none so it does not block mouse drag.

Let's also add `touch-action: none` on the canvas to prevent scroll on touch devices when dragging. We can apply that via style to a container or body.

Add `user-select: none` to body to avoid highlighting text while dragging.

Code structure:

```javascript
(() => {
  // constants
  const MAX_POINTS = 30000;
  const CHUNK = 120;
  const SIGMA = 10;
  const RHO = 28;
  const BETA = 8/3;
  const DT = 0.005;

  // scene, camera, renderer
  const scene = new THREE.Scene();
  const camera = new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 500);
  const renderer = new THREE.WebGLRenderer({ antialias: true });
  renderer.setPixelRatio(window.devicePixelRatio);
  renderer.setSize(window.innerWidth, window.innerHeight);
  renderer.setClearColor(0x050510, 1); // very dark blue-black
  document.body.appendChild(renderer.domElement);

  // generate data
  const positions = new Float32Array(MAX_POINTS * 3);
  const colors = new Float32Array(MAX_POINTS * 3);
  let x = 0.1, y = 0, z = 0;
  const tmpColor = new THREE.Color();
  for (let i = 0; i < MAX_POINTS; i++) {
    const dx = SIGMA * (y - x) * DT;
    const dy = (x * (RHO - z) - y) * DT;
    const dz = (x * y - BETA * z) * DT;
    x += dx; y += dy; z += dz;
    positions[i*3] = x;
    positions[i*3+1] = y;
    positions[i*3+2] = z;
    const t = i / MAX_POINTS;
    tmpColor.setHSL((0.58 + t * 0.42) % 1.0, 1.0, 0.55 + 0.1 * Math.sin(t * Math.PI * 2));
    colors[i*3] = tmpColor.r;
    colors[i*3+1] = tmpColor.g;
    colors[i*3+2] = tmpColor.b;
  }

  // geometries sharing attribute
  const posAttr = new THREE.BufferAttribute(positions, 3);
  const colAttr = new THREE.BufferAttribute(colors, 3);

  const lineGeo = new THREE.BufferGeometry();
  lineGeo.setAttribute('position', posAttr);
  lineGeo.setAttribute('color', colAttr);

  const pointGeo = new THREE.BufferGeometry();
  pointGeo.setAttribute('position', posAttr);
  pointGeo.setAttribute('color', colAttr);

  // texture
  function createGlowTexture() {
    const size = 128;
    const canvas = document.createElement('canvas');
    canvas.width = canvas.height = size;
    const ctx = canvas.getContext('2d');
    const grad = ctx.createRadialGradient(size/2, size/2, 0, size/2, size/2, size/2);
    grad.addColorStop(0, 'rgba(255,255,255,1)');
    grad.addColorStop(0.15, 'rgba(255,255,255,0.8)');
    grad.addColorStop(0.4, 'rgba(180,180,255,0.35)');
    grad.addColorStop(0.7, 'rgba(20,20,80,0.05)');
    grad.addColorStop(1, 'rgba(0,0,0,0)');
    ctx.fillStyle = grad;
    ctx.fillRect(0,0,size,size);
    return new THREE.CanvasTexture(canvas);
  }

  const pointMat = new THREE.PointsMaterial({
    size: 1.0,
    map: createGlowTexture(),
    blending: THREE.AdditiveBlending,
    depthWrite: false,
    transparent: true,
    vertexColors: true,
    sizeAttenuation: true
  });

  const lineMat = new THREE.LineBasicMaterial({
    vertexColors: true,
    blending: THREE.AdditiveBlending,
    depthWrite: false,
    transparent: true
  });

  const points = new THREE.Points(pointGeo, pointMat);
  const line = new THREE.Line(lineGeo, lineMat);

  scene.add(points);
  scene.add(line);

  // camera orbit state
  let theta = 0;
  let phi = Math.PI * 0.28;
  let radius = 90;
  const target = new THREE.Vector3(0, 20, 0); // target slightly above origin to center view
  const EPS = 0.001;
  const phiMin = -Math.PI/2 + EPS;
  const phiMax = Math.PI/2 - EPS;

  function updateCamera() {
    const sx = radius * Math.cos(phi) * Math.sin(theta);
    const sy = radius * Math.sin(phi);
    const sz = radius * Math.cos(phi) * Math.cos(theta);
    camera.position.set(target.x + sx, target.y + sy, target.z + sz);
    camera.lookAt(target);
  }
  updateCamera();

  // interaction
  let isDragging = false;
  let prev = {x:0, y:0};
  const canvas = renderer.domElement;

  canvas.addEventListener('pointerdown', (e) => {
    if (e.button === 0) {
      isDragging = true;
      prev.x = e.clientX;
      prev.y = e.clientY;
      canvas.setPointerCapture(e.pointerId);
    }
  });
  window.addEventListener('pointermove', (e) => {
    if (!isDragging) return;
    const dx = e.clientX - prev.x;
    const dy = e.clientY - prev.y;
    prev.x = e.clientX;
    prev.y = e.clientY;
    theta -= dx * 0.005;
    phi += dy * 0.005;
    phi = Math.max(phiMin, Math.min(phiMax, phi));
    updateCamera();
  });
  window.addEventListener('pointerup', (e) => {
    isDragging = false;
  });
  canvas.addEventListener('wheel', (e) => {
    e.preventDefault();
    radius *= (1 + e.deltaY * 0.0005);
    radius = Math.max(20, Math.min(radius, 200));
    updateCamera();
  }, { passive: false });

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

  // draw range animation
  let drawCount = 0;

  function animate() {
    requestAnimationFrame(animate);
    if (drawCount < MAX_POINTS) {
      drawCount = Math.min(drawCount + CHUNK, MAX_POINTS);
      lineGeo.setDrawRange(0, drawCount);
      pointGeo.setDrawRange(0, drawCount);
      lineGeo.attributes.position.needsUpdate = true;
      pointGeo.attributes.position.needsUpdate = true;
      lineGeo.attributes.color.needsUpdate = true;
      pointGeo.attributes.color.needsUpdate = true;
    }
    renderer.render(scene, camera);
  }
  animate();
})();
```

Let's polish:

- `points` uses `PointsMaterial` with animation? No, static color in material. But vertex colors change as draw range updates, but need `needsUpdate` on color attribute. With shared attributes, we only need to set needs update once, but doing twice is harmless.
- To make "glowing" more effective, we can set `size` of PointsMaterial to ~0.8. With 30000 points and dt=0.005, close enough to overlap.
- `lineGeo` draw range step count refers to number of vertices. Since line uses vertices directly, renderer will draw segments from i=0 to i=drawCount-1. Works for points too.

Potential issue: If we share the same `BufferAttribute` for position and color between `Points` and `Line`, setting `needsUpdate` on one should be enough, but modifying it via the same object property is okay. However, `setDrawRange` on each geometry is independent.

One more visual enhancement: Add a subtle fog to depth-fade the line? Probably not needed.

Also, since the attractor is attractor, points dense in the butterfly region, and sparse elsewhere? Actually, the attractor fills space in a fractal dimension but denser inside a lobe. Additive blending works fine.

Target offset: The attractor is roughly centered at (0, 25, 0) because z ranges [0,50]. Setting target to (0, 25, 0) will center the view better. Let's do that.

`phi` initial: `Math.PI * 0.2` (about 36°) for slight top-down? No, that's too flat. `0.3` is ~54°, good. `0.2` is ~36°, fine but maybe too high. Let's keep `0.3`.

`radius = 100` (since attractor spans ~50 units).

Check if running efficiently: 30000 points in one geometry is lightweight.

Colors mapping: current code uses hue 0.58 to 1.0 (approx 210° to 360° -> blue to red). That covers cyan-blue-indigo-pink. Looks good. The lightness oscillates slightly to give brightness variation. We can simplify to just linear gradient: `0.6` to `1.0`.

Let's consider making the number of points smaller but more stylish: accept that it draws over ~3 seconds. 30000 points with CHUNK=200 => 150 frames (2.5s). If user prefers slower, they could increase CHUNK, but 200 is good.

Let's re-check: the data generation loop uses Euler with dt=0.005. The attractor dynamics often have dt stability issues if dt is too large, but 0.005 is very safe. The total time is MAX_POINTS * dt = 30000 * 0.005 = 150 units. Typically the attractor's structure repeats on time scales of tens, so we get a lot of overlap but overdraw is okay. Since we just draw the whole path, it's fine.

Alternative: we could use RK4 to have slightly better accuracy, but for a glowing visual, Euler is irrelevant.

Now let's write the HTML content. Ensure no external resources.

Double check: we are writing to `index.html` in the current directory. Use `write` tool.

Finalize.

The file has been written successfully. Let me provide a concise summary of what was built and verify everything matches the request.

Done.