The user wants me to build a single-page web app showing the Lorenz attractor as a glowing 3D butterfly trajectory that draws over time, with orbit-drag camera controls. They've mentioned three.min.js is available in the current directory.

Let me first check the current directory and the three.min.js file.

Let me check the three.min.js file to understand what's in it.

This is Three.js r128. Good. Now let me think about the Lorenz attractor.

The Lorenz attractor equations:
- dx/dt = σ(y - x)
- dy/dt = x(ρ - z) - y
- dz/dt = xy - βz

Standard parameters: σ = 10, ρ = 28, β = 8/3

The "butterfly" refers to the two lobes of the Lorenz attractor.

The user wants:
1. A glowing 3D butterfly trajectory
2. That draws over time
3. Orbit-drag camera controls
4. All in one self-contained index.html file
5. Use three.min.js (already in the current directory)

Since this is Three.js r128, I need to check what's available. OrbitControls is NOT included in the main three.min.js file. It's typically in examples/jsm/controls/OrbitControls.js or a separate build. Since the user only mentioned three.min.js, I need to implement orbit-drag camera controls manually.

Let me implement the orbit controls manually - that's the safest approach since we can't load external files.

Let me write the Lorenz attractor simulation:

The Lorenz system is a set of three ODEs. I'll use RK4 integration for accuracy.

To make it draw over time, I'll build a line geometry incrementally - add points over time.

For the "glowing butterfly" effect, I'll use:
- A Line with a glowing material
- Maybe add a halo/glow effect

Let me think about the design:
- Use a Line with Line2 or just a regular Line with a custom shader that has glow
- Actually, for simplicity and compatibility, I'll use a Line with Points and a MeshLine-like effect, or I'll implement a custom shader material for glow.

Actually, let me think about what works in r128. I'll create a custom ShaderMaterial that:
- Takes the trajectory points as a buffer attribute
- Renders the line with a glow effect (thicker line that's more transparent and brighter)

For the glow effect, I can render the line twice: once thick and transparent (glow), once thin and bright (core). Or I can use a single shader with distance-based glow.

A common technique: render a thin core line with bright color, and render a thicker "halo" line behind it with a much more transparent, brighter version. Using additive blending.

Actually, a nicer glow approach: use a custom shader that computes the distance from the line segment and applies a falloff. Let me use the approach of rendering a quadstrip or using Points with a sprite texture.

Let me think more carefully. The cleanest approach for a glowing line in three.js r128:

Option A: Use a custom ShaderMaterial on a Line (or BufferGeometry with custom attributes)

Option B: Use MeshLine - but that's an external library.

Option C: Render two lines - one thick semi-transparent white glow, one thin bright colored core. Both additive blended.

Let me go with a custom shader approach that's self-contained. I'll create a shader that:
- Takes positions as a buffer attribute
- For each line segment (pair of vertices), computes the thick quad (extruding perpendicular to the line and camera direction)
- Computes distance from center, applies glow falloff

Actually, the simplest robust approach for a glowing 3D line that always faces the camera:

Use a shader that turns the line into a ribbon. For each pair of consecutive points, we create a quad. We need to pass the previous, current, next positions and compute the normal/binormal.

This is the classic "thick line" shader. Let me implement it.

Actually, let me simplify. I'll use a THREE.Line with a custom shader that uses the technique from this classic example:

The line is defined by vertices. For each vertex, I'll pass `previous`, `middle`, and `next` positions. The shader extrudes the line perpendicular to the viewing direction and the segment direction.

Let me write a clean version. Here's my plan:

1. Maintain an array of Lorenz points (drawn over time).
2. Each frame, add a few new points, and rebuild/extend the BufferGeometry.
3. Use a ShaderMaterial that makes a glowing ribbon.
4. Add a separate orbit control system.

For orbit-drag camera controls, I'll implement:
- Left mouse drag → orbit horizontally/vertically
- Mouse wheel → zoom
- Right mouse drag → maybe pan

Let me implement a simple but smooth orbit control.

Let me also think about the "glowing butterfly" aesthetic. The Lorenz attractor naturally forms a butterfly shape (two lobes). I'll:
- Color the trajectory with a gradient that shifts (maybe by arc length or by the butterfly wing)
- Add glow via additive blending

Let me write the code now.

For the shader, I'll use the "fat line" approach. Let me write a ShaderMaterial.

Actually, let me reconsider. A really clean and reliable approach for glowing lines that works without issues:

Render the trajectory as a THREE.Points with a custom PointsMaterial, OR use THREE.Line with LineBasicMaterial thick lines (but browser line thickness is limited).

The most reliable cross-browser glow: use a ShaderMaterial that renders the line as a screen-facing ribbon.

Let me write the fat-line shader. Here's the structure:

Vertex shader receives:
- `position` (current vertex)
- `mp` (instance: previous, current, next — but with BufferGeometry we can't easily have previous/current/next per vertex)

Actually the standard approach: duplicate each point and store in a flat buffer where for each segment we have a quad. Let me use the approach from Bruno Simon's "Three.js Journey" fat line shader.

Here's the vertex shader logic:
```glsl
uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;
uniform float uProgress;
attribute vec3 previousPosition;
attribute vec3 nextPosition;
attribute float side; // 0 or 1, which side of the line

vec2 getPositionNormal() { ... }
```

Hmm, this requires the previous/next attributes. Let me set this up.

Actually, let me think about the drawing-over-time requirement. The trajectory draws over time. So I want to reveal points along the line based on a time/progress parameter.

For the fat-line shader, I can use a `lineDistance` or `vLineDist` varying and discard/clip based on progress.

Let me design:
- Geometry: a BufferGeometry with a `lineDistance` attribute (cumulative arc length, normalized to 0..1).
- Each "segment" quad is built from consecutive points.

OK let me just carefully implement this. I'll generate the full geometry structure for the points drawn so far, and update the lineDistance attribute. Actually, since points are added over time and we want to reveal, I'll keep the buffer growing.

Let me simplify the drawing reveal: instead of clipping in shader, I'll literally only add visible points over time and set a lineDistance based on index. The line draws itself because we only add points frame by frame.

But wait — the fat-line shader needs previous/current/next for each vertex. If I add points incrementally, I need to regenerate the quads each frame as new points come in.

Plan for geometry:
- Keep an array `points` of Lorenz points.
- Each frame, add `n` new points to `points`.
- Recompute a BufferGeometry with vertex positions for the ribbon: for each consecutive pair, create 4 vertices forming a quad (two triangles).
- Each vertex carries: position, previousPosition, nextPosition, and a normalized progress value (0..1 along the trajectory) for coloring and for potential clipping.

Actually regenerating the whole buffer each frame is fine performance-wise for the Lorenz attractor (a few thousand points).

Let me think about how many points. The Lorenz attractor is often simulated with thousands of points. For drawing "over time", showing e.g. 1500 points revealed over ~15 seconds with a nice trail.

Let me cap at maybe 2000-3000 points.

Let me now write the fat line shader. I'll base it on the classic "THREE.FatLine" approach.

Here's the vertex shader (adapted, well-known):
```glsl
precision highp float;
uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;
attribute vec3 tPrev;
attribute vec3 tNext;
attribute vec3 tPos; // position — actually position is built-in

attribute float side;   // +1 or -1
attribute float lineDist; // normalized 0..1 along the whole line
varying float vLineDist;
varying vec3 vColor;

void main() {
  // ... compute screen-space perpendicular direction
  vec2 aspect = uResolution;
  // get direction in screen space
  ...
}
```

Let me write it carefully. The classic shader:

```glsl
precision highp float;

uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;
attribute vec3 tPrev;
attribute vec3 tNext;
attribute float side;
attribute vec2 uv;

varying float vLineDist;
varying vec3 vColor;

void main() {
  //...
}
```

Hmm, I realize I should be careful and just write something I know works. Let me use the widely-used "FatLine" shader that passes prev/current/next.

Let me restructure the geometry generation. For the ribbon, the standard trick (from the "fat line" tutorial):

For each point p[i] (except we duplicate), we create vertices. Actually the cleanest: each line segment between p[i-1] and p[i] becomes a quad. The quad is formed by offsetting the line perpendicular to both the segment direction and the up/camera vector.

But to make it look good in 3D and always face the camera appropriately, we use screen-space extrusion.

Let me use this well-tested vertex shader (I'm fairly confident about this one):

```glsl
attribute vec3 tPrev;
attribute vec3 tNext;
attribute float side;
attribute float lineDist;

uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;

varying float vLineDist;

void main() {
    // direction in world space
    vec3 pos = tPrev.xyz; // hmm
    vec3 prev = tPrev;
    vec3 next = tNext;
    vec3 dir1 = normalize(prev - tPos); ...
}
```

I'm overcomplicating. Let me use the exact classic FatLine shader. The geometry is built so that each vertex has position, side (+1/-1), prev, next, lineDist. The position attribute holds the *current* point (the center of the segment's end). Actually no.

Let me recall the exact geometry structure for FatLine:

For each segment from point A to point B, we generate two vertices (one for each side):
- vertex 1: position=B, side=+1, prev=A, next=nextPointAfterB (or B if last)
- vertex 2: position=B, side=-1, prev=A, next=nextPointAfterB

So for N points, we have (N-1) segments × 2 vertices = 2(N-1) vertices, forming N-1 quads (each quad = 2 triangles). Actually 2 vertices per segment gives degenerate. Let me think: to render a quad for a segment as two triangles, we need 6 vertices (or 4 with TRIANGLE_STRIP using degenerate). 

Hmm, let me reconsider. The common FatLine geometry:

For segment between A (prev) and B (current):
- We make a quad. The quad's centerline goes from A to B. We extrude perpendicular to the line.

Geometry per segment (as a quad = 2 triangles = 6 vertices, or 4 with strip):
Actually the typical implementation builds for each vertex TWO triangles... let me just do: for each segment, output 6 vertices (2 triangles) forming a quad. Each vertex gets: position (=A or B), prev, next, side (which corner: +1 top, -1 bottom), lineDist.

Wait, in the shader, prev and next are used to compute the miter direction (the direction perpendicular to the line in the plane of the turn). The `side` determines whether to offset left or right. The current `position` is the segment endpoint.

Let me look at the canonical shader more carefully from memory (the one from "Three.js Journey" / "FatLine"):

Vertex shader:
```glsl
attribute vec3 tNext;
attribute vec3 tPrev;
attribute float side;
attribute float lineDist;

uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;

varying float vLineDist;

void main() {
    vec2 ndcPos = position.xy; // no
    //...
}
```

OK I clearly don't remember exactly. Let me just derive it myself, which I'm confident I can do.

**Approach: screen-space ribbon line.**

For each point along the path, I want a billboarded quad perpendicular to the segment direction, oriented in screen space.

The classic screen-space line algorithm:

For each vertex in a segment (we have 4 vertices per segment forming a quad: corners TL, TR, BR, BL where the segment goes from prev to next, and the quad is around the *current* point B... no).

Let me use this structure instead — the well-known approach where each point generates a quad around it:

Actually, let me use a simpler and very robust formulation. I'll build a `THREE.LineSegments` style but make quads.

Hmm, let me reconsider and just go with an approach I can fully derive and verify: **extrude in world space using a normal computed from the segment, plus a tiny up-component, and use additive blending with two passes for glow.**

Wait — simpler robust idea that definitely works: 

Use `THREE.Points` (a point cloud) where each point is drawn as a screen-facing *sprite* via the default PointsMaterial with a sizeAttenuation and a point texture. But making a continuous line from points leaves gaps at turns.

OK, let me just commit to the screen-space fat-line shader and write it carefully. I'll write the math and verify.

**Screen-space fat line shader (derived):**

We build a geometry where each *segment* produces a quad of 6 vertices (2 triangles). For segment i connecting `p0` (start) to `p1` (end), and with neighboring points to compute miter, we have for each of the quad's vertices:
- `position`: either p0 or p1 (the actual corner's centerline point)
- `normal`: the world-space "side" vector (left or right), computed as a world-space perpendicular
- Actually, the standard method computes the perpendicular in *screen space*.

Let me use the approach from this popular method (the one with `previous`, `current`, `next` as attributes and screen-space computation). Here's the precise known-good shader (I'll reconstruct it):

```glsl
// attributes
attribute vec3 position;  // current point (built-in)
attribute vec3 previous; // previous point
attribute vec3 next;     // next point
attribute float side;    // +1 or -1
attribute float lineDist;

uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;

varying float vLineDist;

void main() {
    // Vector from previous to current (segment direction approaching current)
    // We extrude the current point perpendicular to the segment in screen space.
    
    // project positions to screen
    vec4 sp = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
    vec4 sn = projectionMatrix * modelViewMatrix * vec4(next, 1.0);
    vec4 sprev = projectionMatrix * modelViewMatrix * vec4(previous, 1.0);
    
    // ...
}
```

Hmm, this is getting long. Let me just carefully write the *known, widely-published* screen-space thick line shader. I'm now fairly sure of this version (it's the "fat line" from the three.js examples / various gists):

Vertex shader (this exact form is widely used and I'm confident):
```glsl
precision highp float;

attribute vec3 position;
attribute vec3 previous;
attribute vec3 next;
attribute float side;
attribute float lineDist;

uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;

varying float vLineDist;

void main() {
    // direction in screen space
    vec2 aspect = uResolution;
    
    // get screen positions
    vec4 current = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
    vec4 prevPos = projectionMatrix * modelViewMatrix * vec4(previous, 1.0);
    vec4 nextPos = projectionMatrix * modelViewMatrix * vec4(next, 1.0);
    
    current.xy /= current.w;
    prevPos.xy /= prevPos.w;
    nextPos.xy /= nextPos.w;
    
    // direction of the line
    vec2 dir;
    if (nextPos.xy == current.xy) {
        dir = normalize(prevPos.xy - current.xy);
    } else {
        dir = normalize(nextPos.xy - current.xy);
    }
    // perpendicular in screen space
    vec2 normal = vec2(-dir.y, dir.x);
    // offset
    vec2 offset = normal * side * uThickness * uPixelRatio / 2.0;
    // ... but we also need to scale relative to w for perspective
    current.xy += offset;
    // ... divide back
    current.xy *= current.w;
    
    gl_Position = current;
    vLineDist = lineDist;
}
```

Hmm wait, there's the perspective scaling. The standard fix: offset should be scaled by `w`. Let me incorporate: the offset in screen space needs to account for the fact that dividing by w happens. The trick: 

```
vec2 offset = normal * side * uThickness * uPixelRatio;
// offset in screen space
current.xy += offset * current.w;  // hmm
```

Actually the precise well-known version computes the offset in clip-space directly without the manual perspective divide, OR scales by w. Let me use the version that does it cleanly. I recall the robust version:

```glsl
void main() {
    float aspect = uResolution.x / uResolution.y;
    float offset = ...;
    // screen-space
    vec2 prevScreen = (prevPos.xy/prevPos.w) * vec2(aspect, 1.0);
    ...
    vec2 dir = normalize(nextScreen - prevScreen);
    vec2 normal = vec2(-dir.y, dir.x);
    vec2 offsetPixel = normal * side * uThickness * uPixelRatio;
    // convert to clip space
    current.xy += offsetPixel * current.w / ...;
}
```

This is fiddly. Honestly, let me just go with a simpler and very reliable approach that I can verify mentally and that looks great: **render the line as a 3D ribbon using world-space normals (cylinder-ish), with additive blending, thick, and that's good enough for a "glowing butterfly."** Combined with a glow pass.

Actually, you know what, let me reconsider the whole rendering approach for robustness and visual quality.

**Decision: Use a custom ShaderMaterial rendering a ribbon where I compute the perpendicular in worldspace using the up vector, extruding each segment into a quad. Render two of them: a fat transparent glow (additive) and a thin core (additive). Plus depth. This will look great and I can derive the math confidently.**

Actually, here's an even simpler and very reliable approach that's commonly used and works great visually: 

Use `THREE.Line2`? Not available without the examples.

Let me reconsider — what about `THREE.Line` with `Line2`... no.

What about just using a `THREE.Mesh` of thin quads (a "tube" of segments) — i.e., build an actual 3D geometry as a strip of quads where each quad is perpendicular to the segment using world-space cross products with an up vector. This is the "extruded ribbon" and I can write it confidently.

**Extruded world-space ribbon:**

For each consecutive triple of points (P_prev, P, P_next):
- Compute segment tangent T = normalize(P_next - P_prev).
- Compute a "side" vector S = normalize(cross(T, up)), where up = (0,1,0) (with a fallback if T is parallel to up).
- The two corners are P ± S * halfWidth.

But this creates a ribbon that follows the curve, extruded in world space. The "side" can flip if the curve crosses vertical. To avoid flips, use a consistent reference and parallel transport.

For the Lorenz attractor, using world-space cross with a fixed up generally works but can have twist flips near the vertical. The screen-space approach avoids this entirely.

Hmm. Let me just go with the **screen-space fat line** since it's the right tool, and I'll write it carefully and test it.

Let me write the screen-space shader properly, with the w-scaling fix. I'll use this form which I'm now confident about (it's the canonical "extrude along perpendicular in screen space, scaled by w" approach):

I found a clean mental model. When we have a projected vertex `p = projectionMatrix * modelViewMatrix * vec4(position, 1.0)` (in clip space, before perspective divide), to move it by a 2D screen offset `d` (in pixels), we do:

`p.xy += d * p.w * 2.0 / uResolution` ... actually the relationship: clip-space coordinates map such that a movement of `p.w` in clip-xy corresponds to a full-screen movement. After divide by w, x ranges [-1,1]; the pixel-to-normalized ratio is 2/uResolution. So a screen-space offset `d` (in pixels) translates to clip-space offset `d * (2/uResolution) * p.w`. So:

`p.xy += offsetPixels * (2.0 / uResolution) * p.w;`

where `offsetPixels` is computed in screen space (perpendicular to the line's screen direction).

Wait, that needs the line direction in screen space, which itself needs the projected positions of prev/current/next. So we do the perspective-divide to get NDC, compute the perpendicular in NDC/pixel space, then convert back to clip space by multiplying by w.

This is exactly the standard algorithm. Let me write it:

```glsl
void main() {
    // Project all relevant points to clip space
    vec4 cp = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
    vec4 pp = projectionMatrix * modelViewMatrix * vec4(previous, 1.0);
    vec4 np = projectionMatrix * modelViewMatrix * vec4(next, 1.0);
    
    // NDC
    vec2 cpNdc = cp.xy / cp.w;
    vec2 ppNdc = pp.xy / pp.w;
    vec2 npNdc = np.xy / np.w;
    
    // handle the start/end points where previous or next is the same as current
    // direction along the line in screen space (NDC)
    vec2 dir;
    if (length(npNdc - cpNdc) < 1e-6) {
        // no next, use previous direction reversed
        dir = normalize(cpNdc - ppNdc);
    } else if (length(ppNdc - cpNdc) < 1e-6) {
        dir = normalize(npNdc - cpNdc);
    } else {
        // average the two direction vectors (miter join)
        vec2 d1 = normalize(cpNdc - ppNdc);
        vec2 d2 = normalize(npNdc - cpNdc);
        dir = normalize(d1 + d2);
    }
    
    // perpendicular
    vec2 perp = vec2(-dir.y, dir.x);
    
    // convert pixel offset to NDC offset, then to clip
    vec2 pixelOff = perp * side * (uThickness * uPixelRatio);
    cp.xy += pixelOff * cp.w * (2.0 / uResolution);  // hmm factor
    
    gl_Position = cp;
    vLineDist = lineDist;
}
```

Wait the factor: NDC offset = pixelOff * (1/uResolution)? No. NDC spans [-1,1] over the resolution. So 1 pixel = 2/uResolution in NDC (2 because -1 to 1 is range 2). So NDC offset in x = pixelOff.x * (2.0/uResolution.x). Then clip offset = NDC offset * w. So:

`cp.xy += pixelOff * (2.0/uResolution) * cp.w;`

with `uResolution` being vec2(resX, resY), and pixelOff already in pixels. Yes. Good. This matches what I wrote.

There's subtlety: `uThickness` is in pixels (half-thickness). Let me make uThickness the half-width in pixels.

OK this shader works and produces screen-facing antialiased-free lines (they'll be thick quads). For antialiasing, we can soften the edges in the fragment shader using the distance to center. But since geometry is quads without AA, edges are hard. I can add a fragment shader that computes distance from the centerline (we can pass vLineDist = side or a "width" coordinate) and smooth the alpha. Let me pass an additional varying that represents the position along the local cross — actually `side` tells us +1 or -1; I can pass the side and in fragment compute distance from center as `abs(vSideCoord)` where the quad spans from -1 to 1. Smooth alpha near edges.

Actually, with additive blending and glow, hard edges look okay-ish but let me soften them for a nicer look.

Let me pass the `side` to fragment and a `vLineDist` for color/progress.

**Fragment shader:**
```glsl
varying float vLineDist; // 0..1 along the line
varying float vSide; // -1 or +1
uniform vec3 uColorA;
uniform vec3 uColorB;
uniform float uProgress; // for drawing reveal 0..1
void main() {
    // soften edges based on side
    float edge = 1.0 - abs(vSide); // vSide at -1 or 1, distance from center edge=1 at center (vSide=0), 0 at edge
    // Hmm, vSide is -1 or 1, abs =1, edge =0. That doesn't vary within quad. Need a continuous coord.
}
```

For edge softening I need a continuous coordinate across the quad width, not just ±1. Let me pass `side` as a varying that's actually the signed half-width coordinate... but the vertex only knows ±1. 

Alternative: do edge softening by computing in fragment using the derivative `fwidth(vSide)`? Since vSide is interpolated from -1 to 1 across the quad, `fwidth(vSide)` gives a measure. Then `alpha = 1.0 - smoothstep(1.0 - ..., 1.0, abs(vSide))`. Actually using derivatives: `float alpha = clamp(1.0 - abs(vSide) * (1.0 / fwidth(vSide)), 0.0, 1.0)` — this is the classic AA via fwidth. 

Hmm, `fwidth(vSide)` = |dFdx| + |dFDy|. vSide interpolates linearly so its derivative is roughly constant across the quad = (2 * halfWidthInPixels)... no, in screen pixels it's the rate of change. The AA formula: `alpha = clamp(0.5 - (abs(vSide) - 0.9), 0.0, 1.0)` style, or use the smoothstep with fwidth.

Let me use:
```glsl
float a = 1.0 - smoothstep(0.8, 1.0, abs(vSide));
```
But vSide is exactly -1 or 1 at the extremes (vertices), interpolated to 0 at center. The extreme (abs=1) spans the whole edge. smoothstep(0.8,1.0, abs) gives a soft edge near abs=1. But the actual edge of the quad is at abs(vSide)=1 exactly (the vertices). So the entire region near the edge (abs near 1) gets softened. This softens the outer half-pixel. Good enough. Actually we want it soft only right at the boundary. Let me reconsider: the quad's visible edge is where the triangle edge is, which is at abs(vSide)=1 across the whole edge. So softening near abs=1 is exactly the outer edge. 

But the issue: smoothstep(0.8, 1.0, abs(vSide)) — at abs=0.8 → 0, abs=1.0 → 1, so a = 1 - smoothstep = 1 near center, 0 at edge, with a transition over abs ∈ [0.8,1.0]. That transition covers the outer 20% which might be too much. Let me use a sharper: `smoothstep(0.95, 1.0, abs(vSide))` or better, use fwidth-based AA:

```glsl
float edge = 1.0 - smoothstep(1.0 - fwidth(vSide), 1.0, abs(vSide));
```
Hmm. `fwidth(vSide)` is the pixel-rate. The standard fragment-AA: `alpha = clamp(0.5 + (0.5 - abs(vSide)) / fwidth(vSide), 0,1)`... 

You know, the glow (additive, thick transparent behind) plus the core line will look good enough even with hard edges. Let me not over-engineer the AA. But I'll add basic softening with smoothstep. Actually hard edges on a glowing line look noticeably aliased. Let me include fwidth-based AA; it's a one-liner and I'm confident it works:

```glsl
float dist = abs(vSide); // -1..1 mapped
float aa = fwidth(dist);
float alpha = 1.0 - smoothstep(1.0 - aa, 1.0 + aa, dist);
```

Hmm, fwidth(dist) where dist is the absolute of interpolated side — at edges dist=1. smoothstep(1-aa, 1+aa, dist) → 0 at dist=1-aa, 1 at dist=1+aa. So alpha=1 in interior, falls to 0 at the edge within aa range. That's the AA. Good. But vSide interpolation: the quad's two columns (side -1 and +1) — within a single triangle, side is constant? No! side is a per-vertex attribute (±1). Two triangles per quad. For the quad corners: TL side=+1 top, TR side=+1 top? No wait. Let me lay out the quad corners:

Quad corners around the segment midpoint B: with side = +1 (left) and side = -1 (right). The quad has 4 corners: p0L, p0R, p1R, p1L (using p0 start, p1 end). So side alternates: +1, -1, -1, +1 (going around). With TRIANGLES (6 verts): p0L(+1), p0R(-1), p1R(-1),  p0L(+1), p1R(-1), p1L(+1). So within each triangle, side varies from +1 to -1. Good, so vSide interpolates from -1..1 across, center=0. fwidth gives the pixel change. 

So `vSide` interpolates 0 at center, ±1 at edges. `dist = abs(vSide)` ranges 0..1, =1 at the quad's long edges (the outline) and also =1 at... the short edges (segment ends) because there side jumps from +1 to -1. Hmm, at segment ends the quad has short edges. Those would also be softened by the fwidth. That's fine/acceptable.

OK. Good, this works. Let me finalize.

Actually, let me reconsider using `fwidth` — it's reliable in three.js. Yes.

Now, the color: gradient along the line + drawing reveal. I'll pass `vLineDist` (0..1 = arc length fraction). Color via a palette (e.g., teal→white→magenta, or a butterfly-wing gradient). Drawing reveal: if `vLineDist > uProgress`, discard (alpha=0) — so the line "draws" over time. But since I'm also only adding points over time, the reveal is naturally from adding points. I'll combine: add points over time AND have a progress that reveals based on time so the "tip" glows more. Actually simpler: just add points over time — the line grows. To make the tip bright/glowing, I can color the newest points brighter. 

Let me do: the line grows by adding points each frame. Color gradient by position along the line. To emphasize the drawing tip, I'll make the newest segment bright/white and fade older ones to the palette. Or, render the whole trailing line with a base color and a brighter leading point. 

Hmm, the "glowing butterfly trajectory that draws over time" — I think: as it draws, there's a glowing head that moves along, and a fading trail. Let me implement:
- Maintain points array.
- Render the trailing geometry (all points so far) as a moderately glowing line with a color gradient.
- Render a bright glowing "head" (a small billboard/sphere) at the newest point.
- Optionally a fade so older parts dim. 

For the fade, I can color by vLineDist vs the head position, making recently-added brighter. Let me incorporate an emissive color that's brighter near the tip.

Actually, simplest visually pleasing: color the whole line with a palette gradient based on 3D position (e.g., by `z` or by the wing — points with y>0 one color, y<0 another, like butterfly wings). And make a glowing head. And add a bloom-like glow via the thick additive pass behind.

Let me now also implement the glow effect: render the line twice — once thick+transparent (glow, additive) and once thin+opaque-ish (core, additive too). Both additive. The glow is wide and faint; the core is the bright line. This produces a "glow."

Alternatively, render a single thick line with a fragment shader that applies a Gaussian falloff across the width (bright in center, fading to edges) plus additive — that single line IS the glow. Let me do that: a single fat line, center bright, edges fade to transparent, additive blending. That looks like a glowing neon tube. 

I'll go with: one ShaderMaterial, fat screen-space line, fragment computes:
- color from gradient (palette based on vLineDist and/or 3D coords)
- alpha with AA at edges (fwidth) AND a glow falloff (gaussian across width) — combine so center is fully bright, edges fade.

Let me write the fragment:
```glsl
varying float vLineDist;
varying vec3 vWorldPos;
varying float vSide;
uniform vec3 uColor1;
uniform vec3 uColor2;
uniform float uHeadFrac; // fraction of line that is "head" (bright)
void main() {
    float edge = 1.0 - smoothstep(0.0, 1.0, abs(vSide)); // hmm
    // Actually we want: alpha high in center, low at edge
    float dist = abs(vSide);
    float aa = fwidth(vSide);
    float alpha = 1.0 - smoothstep(1.0 - aa, 1.0 + aa, dist);
    // glow falloff: bright center, dim edges (gaussian)
    float glow = exp(-dist*dist * 2.0);
    alpha *= glow;
    // color
    vec3 color = mix(uColor1, uColor2, vLineDist);
    // head brightness
    float head = smoothstep(0.0, uHeadFrac, 1.0 - abs(vLineDist - uHeadFrac)); // near tip
    color = mix(color, vec3(1.0), head); // tip white-hot
    gl_FragColor = vec4(color, alpha);
}
```

Hmm `head` logic is a bit off. Let me simplify head brightness: the tip region (last ~5% of the line) is brighter. `float tipGlow = smoothstep(1.0, 1.0 - tipWidth, vLineDist);` → near 1 (tip), this is ~1. Use to boost brightness. 

Let me finalize the fragment shader with a clean approach.

Now **the geometry building** (JS side):

I'll build a BufferGeometry where each *segment* (between consecutive points) generates a quad (2 triangles = 6 verts, or 4 with strip). To compute miter joins nicely, each vertex needs previous & next. The cleanest structure for the screen-space shader with prev/next: for each point P[i], we generate the quad around P[i] using prev=P[i-1], next=P[i+1]. But the quad should span the segment between P[i-1] and P[i]. 

There's a well-known structure: generate vertices such that consecutive points share edges. Let me use the structure where for each point i (from 1 to N-1), we add two vertices representing the segment from P[i-1] to P[i], with the extrusion based on prev/next. Actually, let me use the simplest correct structure that I'm SURE produces a continuous ribbon:

**Structure: one quad per segment, no shared vertices between segments (simpler, 4 verts/tri? no, 6).**

For segment i (P[i] to P[i+1]), with prev=P[i-1] (or P[i] if i==0), next=P[i+2] (or P[i+1] if end):
- Compute direction in world space (or we let shader do screen space, using prev/current/next).
- The quad corners: We offset the two endpoints P[i], P[i+1] by ±perp (computed in shader via prev/next). 

But in the screen-space shader, the "current" position for a vertex is the *endpoint* of the segment, and prev/next give the miter. If I give a vertex position=P[i], previous=P[i-1], next=P[i+1], side=±1, then the shader extrudes P[i] perpendicular to the line at P[i]. For a segment quad I need 4 corners: offset P[i] left/right and P[i+1] left/right. That means I create, for the segment, 4 vertices: 
- v0: pos=P[i], prev=P[i-1], next=P[i+1], side=+1
- v1: pos=P[i], prev=P[i-1], next=P[i+1], side=-1
- v2: pos=P[i+1], prev=P[i], next=P[i+2], side=-1
- v3: pos=P[i+1], prev=P[i], next=P[i+2], side=+1
And triangles (v0,v1,v2) and (v0,v2,v3) — wait that's a quad as 2 tris: (v0,v2,v1)? Let me get winding right. Quad corners in order: top-left v0, bottom-left v1, bottom-right v2, top-right v3 (with +1 = left/top). Triangles: (v0,v1,v2) and (v0,v2,v3). Hmm that uses v0 twice. With 6 vertices: v0,v1,v2, v0,v2,v3. Each vertex has its own pos/prev/next/side. This is clean.

lineDist attribute: for each vertex, a value 0..1 along the whole spline (so color/progress). I can compute per-vertex based on the point's index fraction: `lineDist = i/(N-1)` for P[i].

This builds a proper continuous ribbon. Miter joins at corners might slightly separate (since adjoining segments compute their own miter at the shared point, and the corners at the shared point may gap slightly), but because the shader computes the miter direction from prev/current/next at each vertex independently and the two triangles at a joint share the point's extrusion, the ribbon will be continuous at joints actually (both segments extrude the shared point P[i] by the same miter → no gap). Wait, segment i extrudes P[i] using prev=P[i-1],next=P[i+1]; segment i-1 extrudes P[i] using prev=P[i-2],next=P[i+1]? No — segment i-1 uses pos=P[i-1] and pos=P[i], with P[i]'s copy having prev=P[i-2], next=P[i+1]. Hmm so the same world point P[i] appears in segment i-1 (as pos=P[i], prev=P[i-2], next=P[i+1]) and segment i (as pos=P[i], prev=P[i-1], next=P[i+1]). Different `previous`! So the miter differs → potential tiny gap at sharp turns.

To avoid gaps, the standard approach shares the vertex data: at each path point P[i], there's ONE (pos, prev=P[i-1], next=P[i+1]) used for both the start of segment i and end of segment i-1. I.e., the quad for segment i uses:
- pos=P[i] with prev=P[i-1], next=P[i+1] (left & right)
- pos=P[i+1] with prev=P[i], next=P[i+2] (left & right)
And the quad for segment i-1 uses:
- pos=P[i-1] with prev=P[i-2], next=P[i]
- pos=P[i] with prev=P[i-1], next=P[i+1]  ← SAME as segment i's pos=P[i].

So if I index points and build quads where the shared point P[i] appears with the SAME prev/next in both adjacent segments, there's no gap. That means I should build the ribbon such that each path point P[i] contributes a pair of side vertices (left/right) with prev=P[i-1], next=P[i+1], and these are shared between the two adjacent segment quads. This is the "one vertex pair per path point" structure.

So: for each path point P[i] (i=0..N-1), generate 2 vertices: 
- L[i]: pos=P[i], side=+1, prev=P[i-1] (clamp), next=P[i+1] (clamp), lineDist = i/(N-1)
- R[i]: pos=P[i], side=-1, prev=P[i-1], next=P[i+1], lineDist = i/(N-1)

Then quads as triangle strip between consecutive point-pairs: quad for segment i uses L[i],R[i],R[i+1],L[i+1]. As tris: (L[i], R[i], R[i+1]) and (L[i], R[i+1], L[i+1]). Winding: need consistent. Let me define +1 = left (say, world +X-ish / screen left). 

With this structure, shared vertices L[i]/R[i] are used by both segment i-1 and segment i → continuous ribbon, no gaps, perfect miter joins. 

This needs N pairs = 2N vertices, (N-1) quads × 2 tris × 3 = 6(N-1) indices. Clean.

Now lineDist for color: i/(N-1). But points are added over time and I rebuild the buffer each frame (or update attributes). Since the count grows, rebuilding is easiest: each frame, if new points added, regenerate the whole geometry attributes. For a few thousand points that's cheap.

Actually, instead of rebuilding the entire buffer each frame, I can preallocate a buffer for the max point count and just update `lineDist`/positions up to the current count. But regeneration is simpler to code and fast enough. Let me regenerate. But I must reuse the same BufferGeometry and just update its attributes (set from arrays, set draw range). I'll create the geometry once with `maxPoints` capacity and update. Actually three.js BufferAttribute can be updated by writing to `.array` and calling `.needsUpdate = true`, and setting `.count`. Let me preallocate for maxN points and update counts.

Hold on, simpler: I'll just dispose and recreate the line+geometry each frame? No, too wasteful. Let me keep a single geometry and update its vertex buffers.

But the ShaderMaterial uses `modelViewMatrix`, `projectionMatrix` (built-in). Those are fine.

Let me precompute the max number of points, say MAXPTS = 3000. Pre-create attributes of size MAXPTS*2 (pairs). Each frame, fill the first `curPairs*2` vertices and set `geometry.setDrawRange(0, curPairs*2)` and count.

Wait, but I also want a "drawing head" — a bright glowing sphere at the tip. I'll add a small SphereGeometry mesh or a sprite at points[last], with additive glowing material.

Let me also add the two-lobe coloring of a butterfly: color by world `y` sign and `z`? Actually lorenz lobes are left/right in x (the two "wings"). Let me color by `x` (left wing negative x = one color, right wing positive x = another). That gives the butterfly look: two-tone wings. E.g., left (x<0) blue-ish, right (x>0) magenta-ish, meeting at center. 

Let me set: color = mix(colorLeft, colorRight, map(x from -20..20 to 0..1)). The Lorenz attractor x ranges roughly [-20, 20]. 

Let me also add subtle z-based brightness for depth perception. Optional.

Now **orbit controls** (custom, manual):

I'll implement an OrbitCamera:
- State: radius (distance), azimuth angle (theta, horizontal), polar angle (phi, vertical), target (the center focus, default origin).
- Spherical→Cartesian: camera position from target.
- Mouse: drag left button → rotate (change theta/phi). Drag right or wheel → zoom (radius). Shift+drag → pan (target).
- Use requestAnimationFrame to update.

Actually orbit controls typically: left drag rotates, scroll zooms, right drag pans. Let me do that.

Let me implement and attach to the canvas's parent.

Let me write the orbit control as a class managing the camera.

For smoothness, I'll directly set position and use requestAnimationFrame; on mousemove update the angles and recompute camera position, then `camera.lookAt(target)`.

Edge: clamp phi to (0.01, π-0.01) to avoid gimbal. Clamp radius.

Let me also add subtle damping/decay for a nice feel. I'll add velocity-based smoothing: interpolate current angles toward target angles. That gives a buttery feel. Let me include damping.

**Lorenz integration (RK4):**

State: {x,y,z}. 
derivatives:
```
dx = sigma*(y-x)
dy = x*(rho-z) - y
dz = x*y - beta*z
```
RK4 step.

Initial condition: classic starting point (1,1,1) or (0.1,0,0). Let me use (1,1,1).

dt: I'll use a small dt for the physics and sub-step multiple times per frame while also adding one point per physics-substep or per N substeps. To draw over time, I'll add a point every few RK4 steps.

Let me think timing: 
- Run physics at a fixed step, say simulate `stepsPerFrame` RK4 steps per animation frame.
- Add a point every `stepsPerPoint` RK4 steps (or just add every frame's worth). 
- Reveal ~2000 points over ~20 seconds → that's 100 points/sec. At 60fps → ~1.7 points/frame.

But there's tension: drawing over time means the visible tail grows. Meanwhile physics should keep running to produce a full orbit. Let me decouple: the *visible* line grows over `drawDuration` (e.g., 20s) to its full length MAXPTS. The physics runs continuously. The visible portion = points[0 .. floor(progress*MAXPTS)].

So I'll simulate continuously each frame (many RK4 steps), store recent points in a ring/capped array up to MAXPTS, and render points[0..visibleCount]. visibleCount = min(MAXPTS, floor(elapsed/drawDuration * MAXPTS)). Once full, the whole attractor is shown and we can keep simulating (it'll look like a steady glowing butterfly). Good — "draws over time" satisfied, and after drawing it's a stable glowing butterfly.

But if I cap points at MAXPTS and keep simulating, the array is full — I can either keep the last MAXPTS (sliding tail that scrolls — looks like motion blur) or keep first MAXPTS (frozen full butterfly). For a "butterfly" the full attractor is nice. Let me keep a full capped buffer of MAXPTS (don't scroll), so after drawDuration we show the complete butterfly and it stays. The points near the tip will keep changing (new simulation), but since we cap at MAXPTS and stop showing the growth, the tip becomes the last max point and the sim continues updating points beyond which we don't... hmm, this gets complicated.

Simplest clean behavior: 
- Simulate and append points up to MAXPTS.
- visibleCount grows to MAXPTS over drawDuration.
- After MAXPTS reached: keep simulating but DON'T append more (freeze the last point's growth). Actually the attractor is chaotic; freezing at MAXPTS means we keep the same 2000 points forever (already computed). The head stops. Fine — stable butterfly. But the head (glowing tip) would then just sit at the last point. Maybe after drawing is complete, I remove the head glow or keep a subtle one. 

Alternatively, after completed, keep the buffer at MAXPTS but slide (so it's a continuous flowing glow). A sliding window of 2000 points where the tail constantly moves = the butterfly "moves" which is actually the classic look of Lorenz animations (a flowing trail). That looks great! Let me do sliding window after completion: keep the latest MAXPTS points, visibleCount always = MAXPTS, and the trajectory flows. The head glow at the newest point. 

Hmm but a sliding window means the WHOLE thing shifts each frame (newest appended, oldest dropped), and the ribbon is rebuilt each frame. That's fine and looks like flowing lava. The attractor shape is preserved (it's an attractor, the new points fill the same region). 

Decision: 
- Always simulate and push points; keep a deque capped at MAXPTS (drop oldest if exceeded).
- visibleCount = length of deque (≤ MAXPTS). During drawDuration it grows; after, it stays at MAXPTS and slides.
- Render the ribbon over the deque, rebuild each frame (or update buffers each frame since order changes when sliding).
- Head glow at the newest point.

Rebuilding buffers each frame for 2000 points is trivially fast. Good.

Actually, to keep it simpler in code and still look good, let me reconsider: maybe a non-sliding frozen butterfly is cleaner and matches "glowing butterfly trajectory." But the flowing trail is more dynamic and iconic. I'll go with sliding/frozen... let me go with the flowing version because it better showcases "draws over time" and looks alive. But sliding means the tip is always moving — there's always a head glow. Nice.

Wait, but during the initial draw (growing phase), the tail is fixed and head moves — that's the literal "drawing over time." After it fills, sliding keeps it flowing. Both phases show a moving head. 

Let me set MAXPTS ~ 1500-2000, drawDuration ~ 15s, physics step dt small (~0.005), substeps per frame enough to fill 1500 points over 15s = 100/s = ~1.7 per 16ms frame; with dt=0.005, each frame (~16.7ms) do ~3 substeps (16ms/5ms), producing ~1.7 points. I'll add a point every 1-2 substeps. Let me add a point every substep but throttle. Simpler: each frame do `substeps` RK4 with dt, append `pointsToAdd` (e.g., add every substep), capped. That naturally produces the rate.

Let me just add one point per substep; with 3 substeps/frame at dt=0.005 → 0.015s of sim per frame → points come every 0.005s → 200/s → fills 1500 in 7.5s. I can tune via pointsToAdd or dt. Let me make drawDuration a constant and compute pointsToAdd per frame to hit it. Actually simplest: each frame append a fixed number of newly simulated points scaled by dt so it's stable. Let me just pick: substeps per frame = a number giving ~100-150 new points/sec. I'll target points/sec via `POINTS_PER_SEC`. 

Let me code:
```
const POINTS_PER_SEC = 120;
const MAXPTS = 1500;
const SIM_DT = 0.008;
const substeps = ceil(POINTS_PER_SEC * frameDt / POINTS_PER_SUBSTEP)...
```
Too fiddly. Let me do: each frame, accumulate a point timer; when >= 1/POINTS_PER_SEC, integrate and add point. Also run extra physics when the point is the only thing? Hmm. 

Cleanest: separate the physics step from point addition by using a fixed small `simDt` and a fixed ratio: integrate `k` substeps where each "point" = `m` substeps. I.e., for each point I want, run `m` RK4 steps of size simDt. So point rate = (k/m)/frameTime. Let me just fix: each frame run a chunk of physics = `frameTime` worth (so sim stays in sync with real time, dt real seconds). Integrate with RK4 at fixed `RK4_DT` (e.g., 0.01s) using a loop for the elapsed frame time; for each RK4_DT step, append a point (capped). That gives POINTS_PER_SEC = 1/RK4_DT = 100 points/sec. With RK4_DT=0.01, MAXPTS=1500 → 15s draw. Good. Tuning: RK4_DT smaller = more points/sec faster draw. Let me use RK4_DT=0.01 (100/s). Or use a slightly larger fixed step and a separate "add point every N physics steps" so I can independently control. 

Let me use: physics fixed step dt=0.012 (good stability for Lorenz). Add a point every 1 physics step. → 83/s. Fine. I'll just tune visually-ish; the exact rate isn't critical.

Actually for the Lorenz system, a step of 0.01-0.015 with RK4 is stable enough. Let me use dt=0.01, add a point each step. 100 points/sec, 1500 points = 15s. 

Hmm, 0.01 dt RK4 over a chaotic 15s sim — fine.

Edge: when the frame is long, integrate many steps; when short, the remainder carries over (accumulate real dt). I'll accumulate elapsed time and step.

Let me also scale the attractor geometry to fit the camera nicely. Lorenz coordinates: x,y in [-20,20], z in [0,50] roughly. Scale down by ~0.04 → fits in ~1 unit box. Center the camera on origin.

Now let me also set up scene lighting / background. Background: dark gradient or starfield. Simple: a dark navy to black gradient background (shader on a plane or CSS). Since we're using WebGL, set a scene.background to a dark color, or render a fullscreen quad. For a glowing neon line on dark, a dark background is best. Let me use a radial gradient canvas background or just scene.background = dark with a subtle star texture via DataTexture (generate points). Simplest: a full-screen plane with a radial gradient shader, or set body background via CSS to a gradient. But the canvas fills the screen. I can set the WebGL renderer's clear color to a dark gradient? Clear color is flat. For a gradient background, render a big sphere with inside-facing material, or a fullscreen quad in the scene behind. Let me do a simple starfield-ish background using a large sphere with a dark gradient texture I generate via canvas, or just set clear color to near-black with a hint. 

I'll keep it clean: dark gradient background via a fullscreen plane with a gradient shader placed at far distance, OR (simplest and effective) set `scene.background` to a dark color and also add a subtle radial vignette via CSS overlay. Actually, let me generate a small radial-gradient DataTexture and assign to scene.background. That gives a nice dark center→darker edges gradient. Even simpler: use a canvas 2D radial gradient as a texture. Let me do `scene.background = new Color(...)` flat — too flat. 

Let me generate a DataTexture radial gradient (center bright-ish dark, edges blacker) for background. Quick to generate 32x32.

Hmm, scene.background as a texture (via scene.background = texture) — supported. Let me do that.

Actually, also add stars: sprinkle a Points cloud of white dots in the distance for atmosphere. I can make a sparse point cloud. Let me add a small starfield (Points with white, low opacity) positioned around. Nice touch.

Let me also add a subtle glow around the butterfly — I described the line's own glow. Additionally, a soft bloom would be nice but three.js r128 has no EffectComposer built in (that's examples). I'll skip bloom and rely on the additive glowing line which itself provides bloom-like glow.

Let me now also handle: resize, pixel ratio.

Let me write the full HTML now.

Let me also reconsider the fragment shader for the line to be robust. Let me write final shaders.

Uniforms needed:
- uThickness (half thickness in pixels? let me define as full thickness pixels; shader divides appropriately). Let me define `uThickness` = thickness in pixels (full width). In shader, half-width = uThickness/2. Offset: `perpside * side * (uThickness/2) * uPixelRatio`. Then `* (2/res) * w`. 
- uPixelRatio
- uResolution (vec2)
- uColorLeft, uColorRight (rgb)
- uTime (for subtle pulsing head glow)
- uHeadFrac / tip brightness — let me handle tip via the head sphere mesh instead, and keep line color constant gradient. Simpler: line has gradient color by x, plus a brightness falloff so older = dimmer, newest brighter? That reinforces drawing direction. Let me add `uTailBrightness` — segment's brightness based on age: newer (higher lineDist) brighter. I'll compute brightness = mix(dim, bright, lineDist). 

Let me incorporate: `float brightness = 0.4 + 0.6 * vLineDist;` (newer brighter). Combine with x-color. 

Hmm, but with sliding window after completion, lineDist is relative to the window (0..1 newest), so "newest always bright" → head always bright. Good, consistent with head glow. 

Actually I realize with sliding window the "newest" is always at lineDist=1 (right end of deque) → always bright → effectively the head region. And the head sphere sits there too. Maybe redundant. Let me make the line dimmer and let the head sphere provide the bright tip. Let me set brightness modestly.

Let me finalize fragment:
```glsl
precision highp float;
varying float vLineDist;
varying float vSide;
varying vec3 vColor;

void main() {
    // edge antialiasing across the line width
    float d = abs(vSide);
    float aa = fwidth(d);
    float edgeAlpha = 1.0 - smoothstep(1.0 - aa, 1.0 + aa, d);
    // soft glow falloff (bright center)
    float falloff = exp(-d * d * 2.5);
    float alpha = edgeAlpha * falloff;
    gl_FragColor = vec4(vColor, alpha);
}
```
vColor computed in vertex as palette mix × brightness.

Vertex:
```glsl
precision highp float;
attribute vec3 position;
attribute vec3 previous;
attribute vec3 next;
attribute float side;
attribute float lineDist;
attribute vec3 color;
uniform float uThickness;
uniform float uPixelRatio;
uniform vec2 uResolution;
varying float vLineDist;
varying float vSide;
varying vec3 vColor;

void main() {
    vec4 cp = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
    vec4 pp = projectionMatrix * modelViewMatrix * vec4(previous, 1.0);
    vec4 np_ = projectionMatrix * modelViewMatrix * vec4(next, 1.0);
    vec2 ndcCurrent = cp.xy / cp.w;
    vec2 ndcPrev = pp.xy / pp.w;
    vec2 ndcNext = np_.xy / np_.w;

    vec2 dir;
    float dl1 = length(ndcCurrent - ndcPrev);
    float dl2 = length(ndcCurrent - ndcNext);
    if (dl1 < 1e-7 && dl2 < 1e-7) {
        dir = vec2(1.0, 0.0);
    } else if (dl2 < 1e-7) {
        dir = normalize(ndcCurrent - ndcPrev);
    } else if (dl1 < 1e-7) {
        dir = normalize(ndcNext - ndcCurrent);
    } else {
        vec2 d1 = normalize(ndcCurrent - ndcPrev);
        vec2 d2 = normalize(ndcNext - ndcCurrent);
        dir = normalize(d1 + d2);
    }
    vec2 normal = vec2(-dir.y, dir.x);
    // pixel-space offset -> ndc -> clip (multiply by w)
    vec2 pixelOffset = normal * side * (uThickness * 0.5) * uPixelRatio;
    cp.xy += pixelOffset * (2.0 / uResolution) * cp.w;
    gl_Position = cp;
    vLineDist = lineDist;
    vSide = side;
    vColor = color;
}
```

This is the canonical screen-space fat line. Good.

Note: `2.0 / uResolution` should be per-component (uResolution is vec2). `pixelOffset * (2.0/uResolution)` → vec2 division works componentwise. Then `* cp.w`. Good.

One concern: when the line is viewed and `uResolution` aspect — using actual pixel resolution with NDC [-1,1] means x scale 2/resX and y scale 2/resY, which correctly handles non-square pixels. Good.

Now the geometry building each frame. I'll build Float32Array for position, previous, next, side, lineDist, color. Capacity 2*MAXPTS vertices.

For the deque: I store points as a flat array `pts` of [x,y,z,...] but with sliding I need order. Let me store as array of Vec3 (objects) or flat with index pointers. For simplicity and 2000 points, using array of THREE.Vector3 or plain {x,y,z}. I'll use a plain array of objects `{x,y,z}` and cap at MAXPTS via shift when exceeding. shift on 1500-element array each frame is O(n) ~ 1500, fine. Actually rebuilding geometry each frame is also O(n). All fine.

Let me reconsider: 60fps × 1500 shifts = trivial. Good.

Geometry build:
```
const count = pts.length; // path points
if (count < 2) return;
const nVerts = (count) * 2; // pairs per point; quads between i and i+1
Actually we need pairs for all points 0..count-1: 2*count vertices. Quads: count-1.
```
Indices: for i in 0..count-2: quad using pair i (L[i],R[i]) and pair i+1 (L[i+1],R[i+1]).
Triangles: (L[i], R[i], R[i+1]) and (L[i], R[i+1], L[i+1]).
Vertex at pair i: L has side=+1, R has side=-1, both pos=pts[i], prev=pts[i-1]||pts[i], next=pts[i+1]||pts[i], color by palette, lineDist=i/(count-1).

Let me write color: 
```
const t = (i + ... )/ (count-1); // along path
// also use world x for wing color
const wing = map(pts[i].x, -XW, XW, 0,1) clamped;
color = lerp(colorLeft, colorRight, wing) * brightness
```
brightness = 0.5 + 0.5*t (newer brighter) — or constant. Let me use brightness = 1.0 with a slight fade older: brightness = 0.35 + 0.65 * t. Eh, let me keep newer brighter to emphasize flow: brightness = 0.4 + 0.6*t. Cap.

Actually, with additive blending, bright values accumulate; let me keep brightness moderate (0.5-1.0 range) and rely on glow. Let me use brightness = 0.5 + 0.5*t but clamp to 1? additive so values can exceed; fine.

Hmm, I want the wings to look like a butterfly with distinct color halves. Let me set:
- colorLeft (x<0) = teal/cyan: (0.2, 0.9, 0.8)? or (0.1,0.6,0.9)
- colorRight (x>0) = magenta/pink: (0.9, 0.2, 0.7)
- multiply by brightness based on t.

And maybe shift hue slightly by z for depth. Let me keep simple: wing color + brightness.

Let me set XW = 18 (lorenz x range). Normalize x to [-1,1] via /20, then 0..1 via (x/20+1)/2.

Head sphere: at pts[count-1], a small SphereGeometry radius ~0.03, material additive emissive white/cyan with some size. Use a MeshBasicMaterial with color white, transparent, opacity, additive blending, depthWrite false, and scale ~2 for glow. Or use a sprite. Mesh sphere is easy. Let me use a small sphere, material = MeshBasicMaterial({color:0xffffff, transparent:true, opacity:0.8, blending:AdditiveBlending, side:DoubleSide, depthWrite:false}). Position updated each frame. It glows due to additive + the surrounding. To make it "glow" (bloom-like), I can also add a larger transparent sphere behind it with lower opacity. Let me add two spheres: core (small, bright) + halo (larger, faint). 

Now orbit controls. Let me write:

```
class OrbitCamera {
  constructor(camera, domElement) {
    this.camera = camera;
    this.dom = domElement;
    this.target = new THREE.Vector3(0,0,0);
    this.radius = 12; // initial distance
    this.theta = 0.3; // azimuth
    this.phi = 0.7;   // polar
    this.targetTheta = this.theta;
    this.targetPhi = this.phi;
    this.targetRadius = this.radius;
    this.rotating = false;
    this.panning = false;
    this.minPhi = 0.05; maxPhi = Math.PI-0.05;
    this.minRadius = 2; maxRadius = 40;
    this.damping = 0.08;
    this._addEvents();
  }
  _addEvents() {
    // wheel zoom
    this.dom.addEventListener('wheel', (e)=>{ e.preventDefault(); 
      let delta = e.deltaY >0 ? 1 : -1; this.targetRadius *= (1 - delta*0.12);
      this.targetRadius = clamp...
    }, {passive:false});
    this.dom.addEventListener('mousedown', (e)=>{
      if (e.button===0){ this.rotating=true; e.preventDefault(); }
      else if (e.button===2){ this.panning=true; e.preventDefault(); }
    });
    window.addEventListener('mousemove', (e)=>{ if(!rot&&!pan)return; ... });
    window.addEventListener('mouseup', ...);
    // touch
  }
  update() {
    this.theta += (this.targetTheta-this.theta)*damping;
    ...
    // compute camera position from spherical
    let x = ... ; set camera.position; camera.lookAt(target);
  }
}
```

The drag to rotate: store last mouse x,y; on move, delta → add to targetTheta/targetPhi. For pan: right-drag moves target in plane.

Let me define the spherical mapping: 
```
pos.x = target.x + radius * sin(phi) * sin(theta)
pos.y = target.y + radius * cos(phi)
pos.z = target.z + radius * sin(phi) * cos(theta)
```
(Using three's coordinate system where y is up; theta azimuth around y.)

Rotate drag: mouseX delta → targetTheta += deltaX * 0.005; mouseY delta → targetPhi -= deltaY*0.005 (invert). Clamp phi.
Pan: use camera right/up vectors scaled by delta × some factor, move target.
Zoom: radius change.

Damping for buttery.

Also enable on the canvas' container. I'll attach to the canvas element directly (renderer.domElement) and set its style.

Let me make the canvas fill window via CSS: html,body{margin:0;height:100%;overflow:hidden} canvas{display:block;width:100%;height:100%}.

Now let me also add a small on-screen instruction hint (optional). Maybe a subtle "orbit: drag | zoom: scroll" text via HTML overlay. Fine.

Let me write the final file.

Let me also double check three.js r128 API:
- `THREE.WebGLRenderer`, `THREE.Scene`, `THREE.PerspectiveCamera`, `THREE.BufferGeometry`, `THREE.ShaderMaterial`, `THREE.MeshBasicMaterial`, `THREE.Mesh`, `THREE.SphereGeometry`, `THREE.Points`, `THREE.BufferAttribute`, `THREE.Vector3`, `THREE.Color`, `THREE.AdditiveBlending`, `THREE.DataTexture`, `THREE.TextureLoader` (avoid—no network), `THREE.RGBAFormat`, `THREE.LinearFilter`, etc. All exist in r128.
- For points material line? I'll only use the custom ShaderMaterial for the ribbon and a MeshBasicMaterial for head, and PointsMaterial for stars.
- `renderer.setPixelRatio(window.devicePixelRatio)`.
- `THREE.Color` set from hex.
- `scene.background = texture` works in r128.

For stars: generate positions in a sphere shell, use Points with PointsMaterial({size:0.2, sizeAttenuation:true, color:white, transparent:true, opacity:0.5, depthWrite:false}) and additive. Or just set scene.background texture (gradient) and optionally a starfield Points cloud. Let me add a starfield for atmosphere.

Let me write the gradient background texture via DataTexture:
```
const size=32; 
const data = new Uint8Array(3*size*size);
for y... for x...:
  // radial from center
  let dx = (x+0.5)/size*2-1; let dy=(y+0.5)/size*2-1;
  let r = sqrt(dx*dx+dy*dy); // but aspect: width maybe not square; use x res
  let t = 1 - smoothstep(0,1,r*0.8)... 
  let col = mix(inner, outer, r^2) // inner slightly lighter dark, outer black
set pixel.
const tex = new THREE.DataTexture(data, size,size, RGBFormat); tex.needsUpdate=true;
scene.background = tex;
```
Hmm `scene.background = tex` expects a texture or color. In r128, assigning a texture to scene.background works (it renders fullscreen). Good. But note: a texture background with a gradient where center is somewhat lighter — but we want dark so the glow pops. Let me make center = very dark navy (0.02) and edges = black. Subtle. Actually a flat dark navy is fine; the gradient adds polish. Let me do center dark (0.92 factor) edges black.

Wait, careful: scene.background as texture is drawn; but also stars Points cloud rendered in scene. With background texture, the stars should be at large distance (e.g., radius 50) so they're in front of the background. Points cloud at z - but with perspective, points at distance 50 appear small. Fine. Actually if scene.background is a texture, it fills everything behind; stars in front will show. Good.

Alternatively skip starpoints and just gradient background + the glowing butterfly. Let me include sparse stars for "night sky" feel — quick to generate and looks nice. I'll add maybe 200 stars.

Let me also ensure the butterfly is centered/well-lit by camera orbit. Default camera radius ~25, phi ~0.9, theta ~0.5. 

Let me scale the attractor: positions from RK4 at scale — lorenz coords ~ [-20,20] x,y, z [0,48]. Multiply by 0.035 → x in [-0.7,0.7], z in [0,1.7]. Then the shape fits in ~1.7 height. Camera radius ~2.5. Let me set scale 0.03 → [-0.6,0.6]x, z up to 1.4. radius ~3. Looks good. I'll center the model by translating: since z ranges [0,1.4], center of mass ~z=0.7. Let me center by subtracting mean, or shift z -= 0.7. Simpler: after computing a fresh orbit, the attractor is roughly centered in x,y around 0 and in z around ρ-ish? The Lorenz "butterfly" center is around (0,0,ρ) ≈ (0,0,28) before scaling → after scale z≈0.84. So subtract 0.84 from z to center. Let me just compute a running mean and subtract, OR hardcode center (0, ~0.8*scale...). Let me subtract a fixed offset (0, 0.84*scale) = (0,0,0.0294) at scale 0.035... let me just center on first point? Hmm. Let me instead center the whole thing by computing the bounding box and centering at origin. Each frame recompute bbox center and subtract? That would shift with sliding. For a stable look, compute a fixed center from an initial burn-in. 

Simplest: scale the raw coords (which are centered ~0 in x,y and ~z around 28... actually z mean ~28, but the two lobes sit at z near 27-48; mean z ~ 35?). Wait Lorenz z: the lobes are centered around z = ρ = 28? Let me recall: the two stable fixed points of Lorenz (the "butterfly bodies") are at (±sqrt(β(ρ-1)), ±sqrt(β(ρ-1)), ρ-1) = (±8.485, ±8.485, 27). So z center ~27. After scaling by 0.035 → z≈0.945. So to center, subtract ~0.035*27 = 0.945 from z. Let me subtract centerOffset = (0,0,0.035*27) ≈ (0,0,0.945). 

But the trajectory also has points with z ranging 0..48. Centering on z=27 (0.945) is reasonable. Let me subtract 0.945 from z. The x,y are centered at 0 already (the attractor is symmetric). So offset = (0,0,0.945). Let me apply scale s=0.035, then z-=0.945 to center.

Hmm, let me recompute: fixed points at z = ρ-1 = 27. Yes subtract 27*s. With s=0.035: 0.945. Good.

Let me just use a constant CENTER_Z = 27*scale.

Actually, I'll make the drawing more robust: I'll compute the center by averaging the first, say, 500 points' positions at startup and use that as the fixed center offset. But simpler to hardcode 27*scale; it's the known attractor center. Fine.

Let me finalize constants:
- scale = 0.035
- z offset = 0.035*27 = 0.945 (subtract from z)

Now initial condition (1,1,1) gives a nice orbit from near origin; it'll spiral out to the lobes. Good classic look.

Let me also add a subtle rotation of the whole scene or auto-rotation? No, user controls. But a gentle auto-rotation when idle is nice. I'll add mild auto-spin of theta when not interacting, can be disabled on interaction. Optional. Let me include gentle auto-rotation (theta += small) that pauses on drag. Keeps it alive even without interaction (good for a passive viewer). I'll implement: a small idle spin.

Hmm, but orbit controls with damping already. Let me add auto-rotate of targetTheta by a tiny amount when mouse is up, for a slow turn. Fine.

Let me set max points, physics:

RK4:
```
function lorenz(p){ return {
  x: sigma*(p.y-p.x),
  y: p.x*(rho-p.z)-p.y,
  z: p.x*p.y - beta*p.z
}; }
function rk4(p,dt){
  let k1=lorenz(p);
  let k2=lorenz({x:p.x+0.5*dt*k1.x, y:p.y+0.5*dt*k1.y, z:p.z+0.5*dt*k1.z});
  let k3=lorenz({x:p.x+0.5*dt*k2.x,...});
  let k4=lorenz({x:p.x+dt*k3.x,...});
  return {x:p.x+dt/6*(k1.x+2k2.x+2k3.x+k4.x), ...};
}
```
sigma=10, rho=28, beta=8/3.

dt per step = 0.01. Add point per step. POINTS_PER_SEC=100. MAXPTS=1500. drawDuration=15s. After full, sliding window keeps latest 1500.

Implementation of sliding window with capped array: `if(pts.length>=MAXPTS) pts.shift(); pts.push(point)`. But during the first 15s we grow; the rebuild each frame uses pts.length.

For the head glow: pts[pts.length-1].

Edge AA: using `fwidth` requires WebGL2? fwidth is available in WebGL1 through OES_standard_derivatives extension. three.js enables `OES_standard_derivatives` automatically when needed? Actually GLSL `fwidth`/`dFdx`/`dFdy` in WebGL1 vertex/fragment need the extension. Three.js's ShaderMaterial with `fragmentShader` using fwidth — does three enable the extension? I believe three.js automatically enables `OES_standard_derivatives` for fragment shaders? Not automatically. Hmm. To be safe, add `#extension GL_OES_standard_derivatives : enable` at the top of the fragment shader, and request extension? In WebGL1, the extension must be enabled by the renderer. three.js sets `gl.getExtension('OES_standard_derivatives')` ... Actually three.js does enable it: in WebGLRenderer init, it enables `OES_standard_derivatives`? Let me recall — three's `WebGLExtensions` register 'standardDerivatives' and I think three enables it when the shader requests derivatives. Hmm not sure.

To avoid the dependency, I can avoid fwidth and use a fixed smoothstep edge. The downside: no adaptive AA based on pixel density, but with uPixelRatio scaling the line thickness, a fixed smoothstep near the edge will AA okay. Let me use:
```
float edge = 1.0 - smoothstep(0.9, 1.0, d);  // d=abs(side), soften near edge
```
But `d` (abs of side) at the quad edge = 1.0 exactly (vertices). The interior interpolates to 0. smoothstep(0.9,1.0,d) → 0 at d≤0.9, 1 at d=1. So edge (alpha) = 1-... = 1 for d<0.9, 0 at d=1, with transition over d∈[0.9,1.0]. That transition is a band near the outer edge. In pixel terms, d goes 0→1 over half the line width. If line width is 10 pixels, the d∈[0.9,1.0] band = 1 pixel → good 1px AA. If line width is 2px, band = 0.2px → too thin to AA. 

To make AA pixel-aware without fwidth, I can scale the smoothstep range by (1/thickness): edge softness in d-units = (pixelRadius/thickness) ≈ 1/(thickness/2) = 2/thickness. So `float e = 1.0/pixelRadiusInHalfWidth`. Let me compute: halfWidthPixels = uThickness*uPixelRatio/2. The d range 0..1 maps to halfWidthPixels pixels. To get a 1px AA band, use d band = 1/halfWidthPixels. So:
```
float edgeSoft = 1.0 / max(0.001, halfWidthPixels); // but clamp
float edge = 1.0 - smoothstep(1.0 - edgeSoft, 1.0, d);
```
with `halfWidthPixels = uThickness*uPixelRatio/2`. Let me pass uThickness in CSS pixels and uPixelRatio. Compute halfWidthPixels in shader. This gives ~1px AA. 

But the glow falloff `exp(-d*d*2.5)` already softens edges to some degree, so even without perfect AA it looks glowy. The combination: the glow falloff makes edges fade, and the explicit edge smoothstep just cleans the very outer edge. Let me keep both.

Actually, let me just enable OES_standard_derivatives properly. I can do: `renderer.getContext().getExtension('OES_standard_derivatives')` won't help the shader. 

Let me check: three.js WebGLRenderer — when compiling a shader that uses `fwidth`/`dFdx`/`dFdy`, does it auto-enable the extension? Looking at three.js source: `WebGLShader` / `GLSL1` ... three.js's `parseChunk` and the `#extension` — three auto-injects `#extension GL_OES_standard_derivatives : enable` and calls `this._extensions.get('OES_standard_derivatives')` when the shader uses derivative functions? I recall three.js does `enableExtension('OES_standard_derivatives')` and prepends the extension directive automatically via the `fragmentShader` ... Hmm. Actually I recall that in WebGL1, three.js's ShaderChunk `common` does NOT enable derivatives, and using `fwidth` without the extension yields a compile error. But three.js's `WebGLExtensions.enable` for 'standardDerivatives' — and the material would need `#extension` directive in source.

To be safe across both WebGL1/2, I'll add at top of fragment shader:
```
#ifdef GL_ES
precision highp float;
#else
precision highp float;
#endif
```
and just not use fwidth; use the explicit edgeSoft approach above. WebGL1 default is fine with smoothstep. Good, avoid fwidth entirely.

Let me set `precision highp float;` — in WebGL1 fragment shaders need a default precision; three.js auto-injects `precision highp float;`? Actually three.js prepends `#version` / precision? For WebGL1, three.js adds `precision highp float;` to the fragment shader if not present? I think ShaderMaterial fragment shaders: three auto-injects `precision ... ` no — the user is expected to provide. Hmm. Actually three.js's WebGLGLSL1 parser prepends a default `precision highp float;`? Let me just include `precision highp float;` at the top of both shaders explicitly to be safe. But in GLSL3 (WebGL2) with `#version 300 es`, you'd write differently. To support WebGL1 (the default for r128 unless explicit), include `precision highp float;`. r128 WebGLRenderer defaults to WebGL1 unless `powerPreference`/version? Actually `new THREE.WebGLRenderer` uses WebGL2 if available by default? In three.js, `WebGLRenderer` defaults `context: null` and internally tries WebGL2 first then WebGL1. In r128, default is WebGL2 if supported. With WebGL2 (`#version 300 es`), `precision highp float;` is not needed at top (it has defaults) but is it allowed? In GLSL3 ES 300, `precision` statements are allowed at global scope. So including `precision highp float;` is fine in both. Good, I'll include it. Actually in WebGL2 / GLSL ES 3.00, `precision highp float;` is valid. Fine.

But built-in uniforms `projectionMatrix` etc. are available in both. Good.

Now `gl_FragColor` — in WebGL2 GLSL3 default, `gl_FragColor` is NOT available (deprecated); three.js handles this by providing a `#version 300 es` and defines `out`. But ShaderMaterial's default code? three.js auto-transforms `gl_FragColor` to the output variable for WebGL2. Actually, three.js's material has `#version 300 es` injected for WebGL2, and the GLSL1→GLSL3 transform maps `gl_FragColor`? I believe three.js does map `gl_FragColor` → `gl_FragColor` is replaced by the output. Hmm, uncertain. To be safe, in WebGL1 the renderer is used by default if I don't force WebGL2. But r128 may default to WebGL2.

To maximize compatibility, I can force WebGL1: `new THREE.WebGLRenderer({ antialias:true })` — in r128 default is WebGL2 if available. There's no easy flag... Actually there is: you can't easily force WebGL1 via constructor in r128? There's no `version` param then. Hmm.

But three.js WebGL2 GLSL3 transform: ShaderMaterial with a fragment shader string containing `gl_FragColor` — three.js's `GLSL3` token replacement handles `gl_FragColor`? Let me recall: three.js's WebGL2 backend rewrites shaders; for `ShaderMaterial`, the source is compiled under WebGL2 with `#version 300 es`. The legacy built-ins `gl_FragColor`, `gl_Vertex`, `gl_Position`, `gl_PointSize`, `gl_FragCoord` — `gl_Position` and `gl_FragCoord` are still valid in GLSL3? `gl_Position` yes; `gl_FragColor` no. Does three.js rewrite `gl_FragColor`? I don't think the GLSL3 transform handles ShaderMaterial user code's `gl_FragColor`. 

Hmm, this is a real compatibility risk. Let me handle it by NOT relying on WebGL2 transform: I'll write the shader using `#version 300 es` features only if I detect... too complex.

Alternative: avoid WebGL2 issues by using three.js's standard materials / approach. But the fat-line needs a custom shader.

Wait — actually, I recall three.js DOES handle `gl_FragColor` in WebGL2 for ShaderMaterial via the `glsl3` parser's `enableExtension`/replacements? Let me reconsider. In three.js, the WebGL2 shader code path wraps fragment output. Looking at three.js source (GLSL1): for WebGL2, it uses `WebGLGLSL3` which performs replacements including mapping `gl_FragColor` to `outFragmentColor`? I genuinely recall that three.js's GLSL3 transform DOES replace `gl_FragColor` → `outputGl_FragColor` (a declared `out` variable). Let me check memory of `glsl3.js` token `fragColor`: yes! three.js GLSL3 transform has tokens: `fragColor`, and a `replace` that declares `out highp vec4 gl_FragColor;` and replaces `gl_FragColor` usages. I'm now fairly confident: GLSL3 transform declares `out vec4 gl_FragColor;` and rewrites. Also `gl_FragCoord` etc. So using `gl_FragColor` works in both. 

Therefore, writing shaders with `precision highp float;`, `gl_FragColor`, `gl_Position`, and built-in `uniforms` (projectionMatrix, modelViewMatrix, etc.) works in WebGL1 and WebGL2 via three's GLSL3 transform. 

Also attributes via `attribute`/`in`? In WebGL2 GLSL3, `attribute` keyword is replaced — three's GLSL3 transform replaces `attribute` → `in`. Yes, GLSL3 transform handles `attribute`, `varying`, `uniform` keywords. Good. So `attribute vec3 position;` `varying vec3 vColor;` etc. all work.

So my shaders using legacy keywords are fine in both WebGL1 and WebGL2 (r128 default). 

Now let me also double-check `projectionMatrix` and `modelViewMatrix` are provided by ShaderMaterial? three.js auto-injects common uniforms including `projectionMatrix`, `modelViewMatrix`, `viewMatrix`, `modelMatrix`, `normalMatrix`, `uv`, `instance...`, and `gl_Point` etc. For ShaderMaterial without custom uniform list issues, yes these are included automatically. Also `gl_Position` works. Good.

One more: my vertex shader uses `position` as an attribute (built-in name, auto-bound). But I'm also storing `position` as custom (it's the point). Good — `position` attribute is standard. I add custom attributes `previous`, `next`, `side`, `lineDist`, `color`. These must be in the BufferGeometry with matching names. Good.

Now, `THREE.ShaderMaterial` with `vertexColors`? I'm using a custom `color` attribute, so I'll just read it in shader; not using `vertexColors` (which adds `color` attribute handling). Fine, my custom `color` attribute named "color" should be auto-bound as attribute `color`. Good. Wait — naming a custom attribute "color" might clash with three's `color` (which is used when vertexColors=true). If vertexColors is false (default), the `color` attribute isn't consumed by three. Should be fine to define a custom attribute named "color". I think it works. To be safe, name it `vColorAttr` and read `attribute vec3 vColorAttr;`. Let me use distinct names to avoid any clash: `attrColor`. Actually three maps GLSL attribute name to buffer attribute name 1:1 (with the GLSL3 transform preserving names). So `attribute vec3 aColor;` → read from geometry attribute `aColor`. Let me name it `aColor` to be safe and avoid "color" clash. Hmm but is "aColor" valid? yes. Let me use `aColor`, `aLineDist`, `aSide`, `aPrev`, `aNext`. Wait `aNext` vs built-ins — fine. But `position` is a built-in attribute (auto). I'll keep position built-in and add aPrev/aNext/aSide/aLineDist/aColor. Good.

Let me write it with those names.

Now the geometry builder creates a BufferGeometry, adds attributes via `geometry.setAttribute('position', new THREE.BufferAttribute(arr,3))`, and custom `aPrev`, `aNext`, `aSide` (1), `aLineDist` (1), `aColor` (3). And `setDrawRange`. Use `geometry.setFromPoints`? No, manual. Also set `geometry.computeVertexNormals`? Not needed for unlit shader. Set `frustumCulled:false`.

I should also set `geometry.attributes.position.copy(...)`? I'll setAttribute with a new BufferAttribute wrapping a Float32Array; mark needsUpdate and set count. For rebuild each frame, I can keep the same BufferAttributes and just update their `.array` contents and `.count`-via setDrawRange. But sizes are constant (2*MAXPTS). I'll pre-create them with fixed size and update values up to 2*count each frame, set draw range to 2*count. Let me do that.

Actually for lineDist color etc. I recompute per vertex each frame. Let me just rewrite arrays and set needsUpdate=true for all. Performance: 1500 points × 2 copies × 6 floats-ish ≈ 18000 floats per frame × 60 = ~1M writes, fine.

Memory: preallocate Float32Array of length 2*MAXPTS*3 for position, same for prev,next, color; 2*MAXPTS for side,lineDist.

Let me code the builder.

Let me also reconsider: do I want the ribbon to use prev/next from the *path* points (miter) — yes, that yields nice smooth corners. Good.

Now, head glow spheres: two spheres (core + halo) at pts[last]. Core: radius 0.04, white. Halo: radius 0.12, faint cyan/blue. Materials MeshBasicMaterial additive transparent.

Alternatively, instead of spheres I can use a bright point sprite. Spheres with additive material and `transparent:true` will glow. A single sphere with a radial gradient texture would look most bloom-like. Generating a radial gradient texture via canvas at runtime (no network) is fine — I can create a canvas, draw radial gradient, use as map. Let me do that for the head: a point sprite texture. But using Points (sprites) with a custom map that is a soft radial gradient looks great and always faces camera (good for head glow). Let me use a Points-based head: one Point with a sprite texture (soft white radial). PointsMaterial with map=gradient, size=0.2, sizeAttenuation, transparent, opacity, additive, depthWrite false. That gives a smooth glowing dot that always faces camera. 

Let me generate the sprite texture from a canvas:
```
function makeSprite(){ const size=64; const c=document.createElement('canvas'); c.width=c.height=size; const ctx=c.getContext('2d'); const grad=ctx.createRadialGradient(32,32,0,32,32,32); grad.addColorStop(0,'rgba(255,255,255,1)'); grad.addColorStop(0.2,'rgba(255,240,220,0.5)'); grad.addColorStop(1,'rgba(0,0,0,0)'); ctx.fillStyle=grad; ctx.fillRect(0,0,size,size); const t=new THREE.CanvasTexture(c); return t; }
```
Then a Points cloud with a single point (add point and update position each frame). Or I can keep an array and push. Let me use one THREE.Points with a 1-point buffer, update position each frame. Use PointsMaterial({size:0.18, sizeAttenuation:true, map:t, alphaTest:0.05, transparent:true, opacity:0.9, depthWrite:false, blending:AdditiveBlending, color:0xffffff}). For the head, the head point gets a bright color; maybe also boost with the tip color. Let me set head color = white-ish.

Actually I want the head to glow in the wing color. I can set the point's color via vertex colors (PointsMaterial vertexColors). Let me enable vertexColors and give the head the wing color. Good.

Hmm, that's one glow sprite for the head; plus the ribbon itself has glow. Good.

Additionally, should there be a trailing fading head? The ribbon's brightness already fades toward tail. Fine.

Let me also add bloom-ish via the ribbon's own glow (the exp falloff). Should be sufficient for a neon glow look.

Let me also consider a subtle post-processing glow by rendering the ribbon into a separate render target blurred and composited — too complex. The built-in glow is fine.

Let me now write the file. I'll be careful and thorough.

Let me also add stats? No. Just the visualization.

Let me write the HTML.

One more consideration: the `side` attribute values +1/-1; in shader `normal = (-dir.y, dir.x)` and `pixelOffset = normal * side * halfWidthPx`. With side ±1, this offsets left/right. Good. But I should ensure the two triangles per quad have consistent winding so backface culling doesn't hide half. I'll set `side: THREE.DoubleSide` on the material (for a line ribbon, both faces). Yes set `side:DoubleSide`.

Also `depthTest:true, depthWrite:false` (additive lines, don't write depth to avoid self-occlusion; but for a single line depthWrite false is fine). Let me use depthWrite:false, depthTest:true, blending:AdditiveBlending. Good so overlapping glows bloom.

Now writing.

Let me carefully write the JS.

```js
(() => {
  const canvas container...
  build scene, camera, renderer.
  create orbit controls.
  create geometry + shader material.
  create stars background.
  create head point.
  lorenz state.
  animate loop.
})();
```

Let me write it fully.

Let me define constants in JS and pass uniforms.

Also `uPixelRatio` uniform = window.devicePixelRatio, `uResolution` = canvas size.

Resize handling: update camera aspect, renderer.setSize, and on resize set uResolution. Note: with pixelRatio, renderer.setSize(innerWidth, innerHeight, false) then setPixelRatio. Size in pixels = innerWidth*pixelRatio. uResolution should be in CSS pixels or device pixels? The shader computes `2.0/uResolution` for NDC; uResolution should match the *pixel* dimensions of the viewport for the per-pixel math to align. But uPixelRatio multiplies thickness. If I pass uResolution in CSS pixels (clientWidth/Height) and uPixelRatio separately, then pixelOffset*(2/uResolution)*w where pixelOffset uses uPixelRatio — let me check: I want the offset in NDC = (pixelOffset_in_pixels) / (viewport_in_pixels/2). If uResolution = viewport in CSS pixels, then 1 CSS px = 1 device px * pixelRatio in device space; the NDC per CSS px = 2/(cssSize). And pixelOffset should be in device pixels = uiThickness_px(css) * pixelRatio. Hmm mixing. Let me just pass uResolution in DEVICE pixels (canvas.width/height in px) and uPixelRatio, and define uThickness in device pixels? Simpler: pass `uResolution = vec2(renderer.getSize(new Vector2()).x, ... )` which in three with setPixelRatio gives device-pixel size? `renderer.getSize` returns the drawing buffer size in device pixels? Actually `getSize` returns the size in CSS pixels; `getDrawingBufferSize` / `getContext().drawingBufferWidth` returns device pixels. To avoid confusion, I'll pass uResolution in device pixels = (canvas.clientWidth*pixelRatio, canvas.clientHeight*pixelRatio), and uThickness in CSS pixels, and in shader multiply thickness by uPixelRatio. Then NDC offset = thicknessCSS * uPixelRatio (device px) * (2/deviceResolution). Since deviceResolution = clientSize*pixelRatio, this = thicknessCSS * 2 / clientSize. Consistent. Good. So:

uResolution = vec2(clientWidth*pixelRatio, clientHeight*pixelRatio) (device px).
uThickness = thickness in CSS px.
uPixelRatio = pixelRatio.

In shader: pixelOffset = normal * side * uThickness * uPixelRatio * 0.5; // device px
cp.xy += pixelOffset * (2.0/uResolution) * cp.w; // NDC * w → clip.

Check units: pixelOffset device-px * (2/devicePx) = NDC. *w → clip. Yes consistent.

I'll compute uResolution via `const s = new THREE.Vector2(); renderer.getSize(s)` — but getsize returns css px (I think). Let me just use `renderer.getDrawingBufferSize(new THREE.Vector2())` which gives device px in r128? I recall `getDrawingBufferSize` exists. Or compute manually: `canvas.width` is device px (the actual buffer size) after setSize with pixelRatio. `renderer.setSize(innerW, innerH)` with pixelRatio sets canvas.width = innerW*pixelRatio. So canvas.width/height = device px. I'll use those for uResolution. 

So: uResolution = new THREE.Vector2(canvas.width, canvas.height). Set after each resize.

Good.

Now let me also make sure thickness looks good. At canvas ~1920px wide, a line of ~6 CSS px thickness. Let me set uThickness = 6.0. Glow half = 3px → decent neon. With exp falloff, the visible glow is ~3px half. Hmm maybe increase to 9 for more glow. The core (exp center bright) + edges fade. Let me set uThickness=8. Tuned for nice glow. I can also add a second thicker transparent pass for wider glow, but the exp falloff already gives a glow. Let me add a faint "bloom halo" by also rendering a thicker version? Might be overkill. I'll rely on exp falloff + head sprite. Maybe set uThickness=10 and falloff exp(-d*d*2) for a soft neon. Let me pick: halfWidth 5px, exp(-d²*2.5). Should glow ~ several pixels. Good.

Let me write the code now and then test in node? I can't run a browser. But I can sanity-check by running with `npx`? There's no browser. I can at least check the file for JS syntax via `node --check` (but it's inside HTML). I'll extract and node-check the JS mentally / via a tiny eval. Let me just write carefully and run a `node -e` parse check on the JS portion by copying. Actually I can use `node --check` on a .js file; let me create a temp .js with the JS and check. But the JS uses `THREE` global from three.min.js — node can load three.min.js? `node -e "require('fs').readFileSync... "` — I can do `node -e` with `--require`? Simpler: I'll write a temp check that appends a syntax check using acorn? Not available. Let me just do `node --check temp.js` for syntax (node --check doesn't execute, just parses; THREE undefined is fine since not executed). Good, I'll extract JS to a temp file and `node --check` it.

Also verify three.min.js globals: `THREE` and the classes. In r128, `THREE.WebGLRenderer` etc. Yes.

Let me write index.html.

Let me write the shader strings with proper escaping in JS (template literals inside the HTML <script>). I'll use backticks for shader strings.

Let me write it now. I'll produce a polished, complete file.

Let me also add a small HTML overlay with instructions and maybe the title "Lorenz Butterfly". Keep minimal.

Let me write.

Potential issue: `THREE.DataTexture` for background requires `minFilter` setting and `wrap`. For non-power-of-2 or sized textures, set `minFilter=LinearFilter`, `wrapS/T=ClampToEdge`. 32x32 is power of 2, fine, but still set clamp. Also DataTexture needs `needsUpdate=true`.

For stars, Points with PointsMaterial — fine.

Let me also ensure the ribbon geometry's `position` attribute is set; three auto-binds `position`. Custom attrs must match names in shader: aPrev, aNext, aSide, aLineDist, aColor. Good.

Now, the color: wing color by x. Let me compute per vertex using the point's x. brightness by t. Let me produce color = wingColor * brightness, where wingColor = lerp(left,right, (x/scale + Xmax)/range). Use x raw (pre-scale) for color logic or post-scale; scale is uniform so relative sign same. Let me color by raw x using threshold x<0.

Color constants:
left (x<0): teal = (0.20, 0.70, 0.80)
right (x>0): magenta = (1.0, 0.25, 0.60)
brightness: t = lineDist; bri = 0.4 + 0.6*t; (newer brighter). Multiply.

Actually additive + bright might saturate; that's fine for glow.

Let me write.

Also need to map raw x to a blend for smooth wings rather than hard threshold; the attractor's x spans both signs, so a hard threshold at x=0 gives two clean halves (butterfly wings). That's a nice butterfly effect. Let me hard-threshold: if x<0 use left, else right. But to avoid a hard single-color band, maybe blend near 0. Fine to hard-cut; it's artistic. Let me blend slightly: `wing = smoothstep(...)` no, hard is cleaner for butterfly. I'll hard cut at x=0. Hmm but then near the center strand both wings meet. Fine.

Let me also vary color by z for subtle depth: modulate saturation/brightness by z. Eh, keep simple.

Now write final file.

Let me also make the auto-rotate gentle and stoppable: store `isDragging` flag (set true on mousedown, false on mouseup); when not dragging and not auto, targetTheta += 0.0008 each frame. Also apply radius/phi idle drift? Keep just theta spin.

Wait, but if user orbits with damping and we also auto-spin theta, the idle spin continues after release only if not dragging. Good.

Let me implement controls and pass to animate.

Let me write now.

Actually, I realize for the "draws over time" effect with a sliding window, the visibleCount = pts.length grows to MAXPTS then stays. Good.

Let me also make sure to push the head point; the head sprite uses pts[pts.length-1]. If pts empty skip.

Let me write the final HTML file.

Let me carefully handle the physics time accumulation in animate (use real elapsed, fixed substep dt=0.01, add a point per substep). To keep ~100 pts/sec, dt=0.01. But if the device is slow and frame > dt accumulation, we step multiple; points added per substep. Good. Also maybe cap total accumulated physics per frame to avoid spiral (e.g., max 5 substeps) to keep interactive. I'll cap to e.g. 10 steps.

Let me write.

Also initial burn: starting at (1,1,1) and stepping; the first ~50 points spiral from center to lobes. Fine, looks like it's being drawn. Good.

Now write the file.

Let me write the vertex shader as a JS template string. I'll include `#version 300 es`? No—rely on three's default. But adding `#version` could conflict with WebGL1. Three handles #version injection for WebGL2; if I include my own `#version 300 es`, in WebGL1 it breaks (WebGL1 GLSL1 doesn't allow #version 300). So do NOT include #version. Just start with `precision highp float;`. three's GLSL3 transform strips/handles. In WebGL1, `precision highp float;` is required & valid. In WebGL2 GLSL3, `precision highp float;` is valid (precision statement allowed). Good.

Write shaders with legacy keywords (attribute/varying/gl_FragColor); three's GLSL3 transform rewrites for WebGL2.

Let me write the code.

I'll produce the file content.

```html
<!DOCTYPE html>
<html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=no,user-scalable=no"><style> html,body{margin:0;padding:0;height:100%;overflow:hidden;background:#000} #o{position:absolute;top:14px;left:50%;translate:-50% 0;color:rgba(255,255,255,0.55);font:12px/1 system-ui,monospace;letter-spacing:.04em} </style></head>
<body>
<div id=o>orbit: drag &middot; zoom: scroll &middot; pan: right-drag</div>
<script src="three.min.js"></script>
<script>
(function(){
  const THREE = window.THREE;
  ... code ...
})();
</script>
</body></html>
```

Now the JS:

```js
const scene = new THREE.Scene();
// background gradient texture
const bg = makeBgTexture();
scene.background = bg;
const camera = new THREE.PerspectiveCamera(45,1,0.01,200);
camera.position.set(0,0.2,3.5);
const renderer = new THREE.WebGLRenderer({canvas:canvas, antialias:true, powerPreference:'high-performance'});
renderer.setPixelRatio(Math.min(window.devicePixelRatio,2));
document.body.appendChild(renderer.domElement);
```

Wait I need to create the canvas or use renderer's. `new THREE.WebGLRenderer({})` creates its own canvas. I'll let it. Then add to body and fill. Set style width/height 100%.

```
renderer.setSize(innerW, innerH);
```
But setSize with pixelRatio already? Use `renderer.setSize(innerWidth, innerHeight)` and setPixelRatio separately. setSize sets css size; with pixel ratio the drawing buffer is larger. Good.

I'll set canvas style width:100%,height:100% via CSS (body full).

Orbit controls target the camera.

Let me code the orbit controls as functions modifying camera; then in animate after building geometry, call controls.update() (applies damping) and the animate loop renders.

Let me define a `Controls` object with `target`, `radius`, `theta`, `phi`, and mouse handlers on `renderer.domElement`.

Let me write the math:
```
function sph(){ 
  const r=radius, t=theta, p=clamp(phi,minPhi,maxPhi);
  const sinP = Math.sin(p);
  pos.x = target.x + r*sinP*Math.sin(t);
  pos.y = target.y + r*Math.cos(p);
  pos.z = target.z + r*sinP*Math.cos(t);
  camera.position.lerp(pos, 1); // or set directly
}
```
Since we use damping on angles, set position directly and lookAt.

Mouse rotate: 
```
on mousemove when rotating: 
  dtheta = (e.clientX - lastX)*0.005; dphi = (e.clientY-lastY)*0.005;
  targetTheta += dtheta; targetPhi += dphi (or -=). 
```
I'll do phi += dphi (with mouse up = decrease phi). Let me do targetPhi += deltaY*0.005; clamp.

Pan (right drag): 
```
const right = camera's right vector (world) ; up = (0,1,0)-ish.
target.addScaledVector(right, -deltaX*scale), target.addScaledVector(up,-deltaY*scale)
```
scale = radius*0.001 maybe.

Zoom (wheel): targetRadius *= factor; clamp.

For pan I need camera.right in world. Compute from camera matrix: `camera.matrixWorld` ... `cameraRight = new Vector3().setFromMatrixColumn(camera.matrixWorld,0)`. But during right-drag we update target based on current orientation. Simpler: pan along X/Y of screen using unprojected delta. Let me do: 
```
const panScale = targetRadius * 0.001;
// camera right and up vectors
```
Use `camera.getWorldDirection`? I'll compute right via matrix column 0, up via column 1. Good.

Implement events on domElement; store state in closure.

Let me write `Controls` class.

Now the animate loop:

```
let state = {x:1,y:1,z:1};
let pts = [];
const DT=0.01, MAXPTS=1800;
const SCALE=0.035, ZOFF=0.035*27;
let acc=0;
function stepLorenz(dt){ ... rk4 ... return new state }
function animate(now){
  requestAnimationFrame(animate);
  // physics
  acc += Math.min(now-prev, 0.1); prev=now;
  let steps=0;
  while(acc>=DT && steps<12){ acc-=DT; const p=state; ... rk4; state=p2; 
    pts.push({x:p2.x,y:p2.y,z:p2.z});
    if(pts.length>MAXPTS) pts.shift();
    steps++;
  }
  rebuildBuffer();
  updateHead();
  controls.update();
  renderer.render(scene,camera);
}
```
Wait pushing a point per DT=0.01 → 100/s. Over 1800 → 18s. Fine.

Rebuild buffer each frame even if no new points — minor waste. I'll set a flag `dirty` on append and rebuild only when dirty, plus always update head. But rebuilding each frame is fine (1800 pts). To be safe and smooth, rebuild only if pts.length changed. Since append happens maybe each frame (100/s), it usually changes. After MAXPTS reached, still changes each frame (shift+push). So always dirty. Rebuilding always is fine. OK rebuild always.

`rebuildBuffer()`:
```
const count = pts.length;
if (count<2) return;
const n = count*2; // vertices
let vi=0;
// position array fill: for each i: L and R
for i..count-1:
  const pt = pts[i];
  // prev, next
  const prevP = pts[i-1]||pt;
  const nextP = pts[i+1]||pt;
  for s of [1,-1]:
     pos[vi]=pt.x*scale-ZOFF etc...
```
Wait apply scale & z offset when storing into position array. For color use raw x. lineDist = i/(count-1). side = s. aPrev/aNext = scaled coords of prev/next.

Let me just fill arrays; set attribute arrays (reuse preallocated Float32Array sized 2*MAXPTS*3). Set `.count` via `geometry.setDrawRange(0, n)` and for each attribute set `.count`? BufferAttribute doesn't have count like that in r128; the geometry's `setDrawRange` and `drawRange` controls. Also `geometry.attributes.position` count — we set via `geometry.setDrawRange(0, n)`. But the BufferAttribute's `count` defaults to its array length; drawing uses drawRange. Actually for non-indexed, the number of vertices drawn = drawRange count. Need `geometry.setDrawRange(0, n)`. Good. But the custom attributes are also sized larger (2*MAXPTS); drawing uses drawRange so only first n used. Good. But three may also bound by `geometry.attributes[aPrev].count`? I think drawRange governs. Let me also set each attribute's `.count`? `BufferAttribute` has no count property (the count is the array length); it uses `geometry.drawRange`. Hmm, actually `drawRange` start+count applies to the indexed/non-indexed draw. For non-indexed geometry drawRange controls glDrawArrays count. So set drawRange(0, n). Good.

Also must call `attribute.needsUpdate = true` for all after writing. 

Let me preallocate arrays once (outside animate) and fill each frame. Create geometry with setAttribute using a `new THREE.BufferAttribute(buf, itemSize)`. Then set `geometry.setDrawRange(0,0)` initially.

Let me code buildBuffer to write into the preallocated arrays.

For `aPrev`/`aNext` etc., I set attributes only once (same buffers, updated contents). Good.

Let me also double check: custom attributes named aPrev etc. The shader uses `attribute vec3 aPrev;`. three binds attribute location by name. Good. And `aColor` (vec3), `aSide`(float), `aLineDist`(float). BufferAttribute itemSize matches. Good.

Now head sprite:
```
const headGeom = new THREE.BufferGeometry();
headGeom.setAttribute('position', new THREE.BufferAttribute(new Float32Array(3),3));
headGeom.setAttribute('color', new THREE.BufferAttribute(new Float32Array(3),3));
const headMat = new THREE.PointsMaterial({size:0.12,sizeAttenuation:true,depthWrite:false,transparent:true,opacity:0.9,map:spriteTex,alphaTest:0.01,vertexColors:true,blending:AdditiveBlending});
const head = new THREE.Points(headGeom, headMat);
scene.add(head);
update head.position and color each frame from pts[last].
```

Stars:
```
const starGeom = new THREE.BufferGeometry();
const starArr = new Float32Array(STAR_N*3);
for i..STAR_N: spherical random; place on shell radius R=40; starArr[i*3]=...
starGeom.setAttribute('position', new THREE.BufferAttribute(starArr,3));
const starMat = new THREE.PointsMaterial({size:0.35,sizeAttenuation:true,color:0xffffff,transparent:true,opacity:0.65,depthWrite:false,blending:AdditiveBlending,alphaTest:0.5});
scene.add(new THREE.Points(starGeom,starMat));
```

OK. Let me also reconsider background texture via scene.background=texture: in WebGL2 three expects a Texture; rendering background as texture works (scene.background can be a texture). For a gradient, fine.

Hmm, actually three.js `Scene.background` can be a `Color` or `Texture` (in recent versions a texture/cube. In r128 yes a Texture works — it renders a fullscreen quad with the texture). Good.

Let me now write the complete file and then run a syntax check.

Let me write makeBgTexture and makeSprite helper.

For color palette in JS, I'll compute vertex colors with THREE.Color or directly float arrays. I'll compute RGB floats.

Let me write the code now in full.

I need `clamp`. Define small helpers.

Let me write the file.

Also, camera near/far: set near 0.01 far 100; with radius ~3.5. Good. Controls radii clamp min 0.5 max 40.

Let me set initial phi=0.9 (from top-ish), theta=0.4, radius=4.0.

Let me write final code.

I'll also handle resize: 
```
window.addEventListener('resize', onResize);
function onResize(){ const w=innerWidth,h=innerHeight; camera.aspect=w/h; camera.updateProjectionMatrix(); renderer.setSize(w,h); texSize... }
```
Update uResolution uniform: `uResolution.set(renderer.domElement.width, renderer.domElement.height)` — domElement.width is drawing buffer width (device px) after setSize. Good.

Let me get canvas width: `renderer.domElement.width` returns device-pixel width. Good.

Now write.

Let me also ensure `uThickness` maybe adaptive to pixel ratio so glow looks consistent on retina: thickness in CSS px is device-pixel-independent (since we multiply by uPixelRatio in shader). So uThickness=8 means 8 CSS px thick → consistent. Good. The glow falloff exp(-d²*2.5) is in normalized d (0..1 across half), independent of pixels — but with AA edge soft = 1/halfWidth device-px. Fine.

Let me write it.

Actually, let me reconsider the edge softening formula using CSS vs device. `halfWidthPx = uThickness*uPixelRatio*0.5` (device px). `edgeSoft = 1.0/halfWidthPx`. The d-band [1-edgeSoft, 1]. With uThickness=8, pixelRatio=2 → halfWidthPx=8, edgeSoft=0.125 → AA band spans d∈[0.875,1.0] = outermost 1 device px. Good. With pixelRatio=1 → halfWidth=4, edgeSoft=0.25 → 1 device px band. Good. Consistent 1px AA. 

Now final code. Let me also reduce chance of shader compile errors: check `uniform vec2 uResolution;` and `precision highp float;` at top.

Also note: in the vertex shader, using `next` as variable name — `next` is a reserved word in some GLSL versions? In GLSL, `next` is not reserved I think. To be safe rename `aNext` attribute and use local var `nxt`. Let me use `aPrev`/`aNext` attributes and locals `p0`,`p1`,`p2`. Good. Avoid `next` as identifier.

Also avoid `pos` clash; use `cur`/`prevP`/`nextP`. Good.

Write.

Let me write the file content now.

Let me also think about whether to call `geometry.attributes.position.needsUpdate`. I'll set a helper that sets needsUpdate on all attrs each rebuild.

Now, performance of rebuilding a 2*1800=3600 vertex buffer each frame with JS loop writing floats — trivial. 

Let me write.

After writing, I'll run `node --check` on extracted JS and also `node` with a guard to ensure three.min.js loads. Actually I can test by running a headless check? There's no browser. I could use `npx playwright`? Probably not installed. I'll at least syntax-check JS. And verify three.min.js loads as a global in node by reading it? It references `globalThis` etc.; `node -e "global.THREE; require('./three.min.js')"` — three.min.js uses `e((t=...THREE={}))(this,...)` it defines globalThis.THREE or self. In node `globalThis.THREE`. I can do `node --input-type=commonjs -e "require('./three.min.js'); console.log(typeof THREE.WebGLRenderer)"` — but three.min.js is UMD; `require` returns it? It checks `module`? The UMD wrapper: `function(t,e){"object"==typeof exports&&"undefined"!=typeof module?e(exports):...}`. In CommonJS, `require('./three.min.js')` returns `module.exports` = exports = the object passed (with THREE). So `node -e "const T=require('./three.min.js'); console.log(typeof T.WebGLRenderer)"`. That should print function. Good — verifies three loads and exports WebGLRenderer. I'll run that as a sanity test.

But the app uses `window.THREE` — in node there's no window. For the syntax check I just need the script to parse. I'll extract the JS (between the <script> tags) to a temp file and `node --check`. Let me do that after writing.

Also, to fully test in a browser-like env, I could use `npx jsdom`? three needs WebGL canvas; jsdom doesn't provide WebGL by default. Skip. I'll rely on syntax check + three load check. Reasonable assurance.

Let me write the file.

Let me carefully compose the JS string. I'll write it inline.

Let me write now.

I'll define `buildLorenz`, etc.

Let me produce the final content.

Color palette:
- leftColor = (0.20, 0.72, 0.82) cyan-teal
- rightColor = (0.98, 0.28, 0.58) pink-magenta
- maybe add a third subtle: at the head, white.

Now brightness: bri = 0.45 + 0.55*t (t lineDist). Color = wingColor * bri. With additive, values may get bright. Fine.

Let me write.

Also, I want a slightly wider glow: render the ribbon once (the main glow line). That's enough.

Write final file.

Let me write the makeSprite for head with the same gradient as the tip color? I'll use a white/yellow gradient sprite; head color via vertexColors. Let me set sprite white radial.

Now produce.

Let me write the HTML.

After writing, node-check.

Let me be careful with the RK4 and the point push: I push raw p2 (pre-scale) then scale in buffer build. Good.

ZOFF: subtract 0.035*27 from scaled z. I.e., scaledZ = (p.z - 27)*SCALE. equivalent.

Position scale: x*s, y*s, (z-27)*s.

Color uses p.x sign (raw) → wing. Good. (raw x is fine; threshold 0.)

Let me finalize.

I also realize: the attractor's lobes in the classic rendering appear as two wings; coloring by x sign (left teal, right magenta) yields a nice butterfly. 

Let me write the file.

Let me write a `clamp` helper and `makeBgTexture`, `makeSpriteTexture`.

Background texture generation details:
```
function makeBgTexture(){
  const size=64; const w=size,h=size;
  const img=new Uint8Array(w*h*3);
  const cx=0.5,cy=0.5;
  for(let y=0;y<h;y++)for(let x=0;x<w;x++){
    const i=(y*w+x)*3;
    const dx=(x+0.5)/w-0.5; const dy=(y+0.5)/h-0.5;
    const r=Math.hypot(dx,dy); // 0..~0.7
    const a=1.0-Math.min(1,Math.max(0,r/0.6));
    // inner darker navy, outer black
    const t=a; // near center a~1 -> color1 (navy), edge 0->black
    const col0=0x0a0e19; // navy
    const r0=(col0>>16)&255, g0=(col0>>8)&255, b0=col0&255;
    img[i]=Math.round(r0*t); img[i+1]=g0*t; img[i+2]=b0*t;
  }
  const tex=new THREE.DataTexture(img,w,h,THREE.RGBFormat);
  tex.minFilter=THREE.LinearFilter; tex.magFilter=THREE.LinearFilter;
  tex.wrapS=THREE.ClampToEdgeWrapping; tex.wrapT=THREE.ClampToEdgeWrapping;
  tex.needsUpdate=true;
  return tex;
}
```
Good.

Stars: STAR_N=260, shell radius 60, also some in front. Use random spherical.

Now write everything.

Let me also handle that `THREE.ClampToEdgeWrapping` etc. exist in r128. Yes.

Write the file now. I'll keep JS compact but clear.

Let me write.

For controls damping: 
```
this.theta += (this.targetTheta - this.theta)*this.damping;
this.phi   += (this.targetPhi - this.phi)*this.damping;
this.radius += (this.targetRadius - this.radius)*this.damping;
```
damping 0.1.

Mouse move when rotating updates targetTheta/Phi by deltas (immediate target), so it follows.

Auto-rotate: when !dragging, targetTheta += 0.0006.

Let me also reset damping so when idle the smooth settle.

Implement.

Now, on wheel, use `e.deltaY` sign to zoom. preventDefault.

Edge: set `domElement.style.touchAction='none'` to prevent scroll zoom on touch; I'll add touch support minimally (touchmove drag = rotate). Let me add touch: one-finger drag = rotate, pinch = zoom (wheel not on touch). I'll implement basic touch. Optional but nice. I'll add touchstart/move/end handling mapping to rotate. Keep simple: treat touch as rotate (ignore pinch). Let me add minimal touch rotate.

Given time, I'll add touch for completeness but keep robust.

Let me write the Controls with mouse+touch.

OK write final.

Let me also make sure to set `renderer.domElement.style.width='100%'; height='100%'` and body full.

Write.

I'll now create the file.