L-system tree · kimi-k3

Let me plan an L-system tree in p5.js.

Design:
- Axiom: "F", rules: F -> FF+[+F-F-F]-[-F+F+F] (classic). Angle ~22°.
- Better: use a rule that creates nice tree. Axiom "X", X -> F[+X][-X]FX, F -> FF. Angle 25°. At generation 5 that can blow up. Count: X expansion... let's compute lengths.

Actually a good bounded grammar: use "F" axiom with rule F -> F[+F]F[-F]F maybe. Number of F per generation: each F produces 3 F, so 3^5 = 243 segments... fine.

Let me choose a nicer grammar: axiom "X"; rules: X -> "F[+X]F[-X]+X"; F -> "FF". Angle 20°. Each X produces 3 X; each F produces 2 F. Count at gen 5: Xs: 3^5=243 strings each with Fs. Total segments manageable (~a few thousand).

To bound: cap segment count; if exceeds, stop expanding early.

Implementation:
- Expand string up to generation (or until segment budget).
- Interpret into a tree structure of segments (not just turtle drawing) so wind sway can rotate children with parents. Build hierarchical nodes: each segment node has length, angle relative to parent, children, depth, and a "birth time" for progressive growth.

Approach: parse the L-system string with a stack. Each 'F' creates a segment child of current node. Each '[' push, ']' pop, '+'/'-' adjust current heading (affects subsequent segments' relative angle).

Node: { len, relAngle (relative to parent's direction), children: [], depth, order (index for growth timing) }.

Growth: assign each node a growStart time proportional to depth (or order). During draw, if time < growStart, skip node and its children. Segment drawn length = len * clamp(progress).

Wind sway: angle offset = sin(time*speed + phase based on depth + node id) * amplitude * depthFactor. Apply recursively so children follow.

Draw recursively: translate, rotate(relAngle + sway), line(0,0,0,-len*growth), translate to tip, draw children.

Scaling: compute total tree height to fit canvas. Compute max depth and segment length; set baseLen = height / (maxDepthPathLength * 1.1). Compute the longest root-to-tip length sum to scale. Keep whole tree visible: compute bounds by simulating without wind? Simpler: scale by longest path sum * 1.15, and width is less than that generally. Good enough.

Leaves: at terminal nodes (no children), draw small ellipses in green/pink when grown.

UI: slider or select for generation 1-5, Regrow button. Also show stats maybe.

Let me write the code.

Expansion:
```js
const axiom = "X";
const rules = { X: "F[+X]F[-X]+X", F: "FF" };
function expand(gen){
  let s = axiom;
  for(let i=0;i<gen;i++){
    let next="";
    for(const ch of s){
      next += rules[ch] || ch;
      if(next.length > 120000) break; // bound
    }
    s = next;
    if(s.length > 120000) break;
  }
  return s;
}
```
Segment count at gen 5: F count: gen produces... let's just compute quickly mentally? F->FF doubles Fs each generation after X expands. Rough estimate fine with the cap; also we can reduce base length. Actually with gen 5, string length might be ~ tens of thousands. p5 can draw thousands of lines per frame at 60fps fine.

Wait — growth drawing only draws grown portion; sway draws everything. A few thousand lines fine.

Parse:
```js
function parse(str){
  const root = { children:[], rel:0, len:0, depth:-1, parent:null };
  let cur = root, angle = 0;
  const stack = [];
  for(const ch of str){
    if(ch==='F'){
      const node = { len:1, rel:angle, children:[], depth:cur.depth+1, parent:cur===root?null:cur };
      cur.children.push(node);
      cur = node; angle = 0;
    } else if(ch==='+'){ angle += A; }
    else if(ch==='-'){ angle -= A; }
    else if(ch==='['){ stack.push([cur, angle]); }
    else if(ch===']'){ [cur, angle] = stack.pop(); }
  }
  return root;
}
```
Note: after 'F', turtle keeps heading — reset angle=0 since node's rel already captured.

Hmm, careful: 'F' moves turtle forward; subsequent F continues same direction -> rel=0 for chained segments. Correct.

Assign growStart by depth: nodes with depth d start at d * stepTime. Step maybe 0.35s, grow duration 0.6s. Max depth maybe ~ gen*3+... fine.

Scaling: compute maxPathLen = max sum of len from root to leaf = maxDepth since each len=1. baseLen = (height*0.8)/maxDepth. Also ensure horizontal fits: max horizontal extent roughly less than height; okay.

Actually gen 5: X->F[+X]F[-X]+X: depth per X level: each X adds 2 F's in main chain (F then F after [+X])? X expands to F [+X] F [-X] + X — the trailing X is at depth+2 (two F's before it). So chain depth ≈ 2*gen... plus F->FF doubling. At gen 5: F expansions double... depth could be up to ~ 2^5? Hmm, F->FF means each F becomes 2 F's per generation, chained, so a chain of F of length k becomes 2k. Depth at gen g: roughly let me not overthink — compute maxDepth programmatically and scale. But if depth is huge (like 50+), branches get tiny. Let me count actual string length at gen 5 to be safe — I'll test in browser.

Alternative simpler grammar with known bounds: axiom "F", rule F -> "F[+F]F[-F]F", angle 25°. F count = 3^g. Gen 5: 243 F's, depth = g+1 = 6... but chain: each F produces F...F with an F between branches: depth grows by 2 per gen? F -> F[+F]F[-F]F: main chain has 3 F's, so depth ≈ 3*gen? At gen 5, depth ~15? Hmm no — depth along main chain: each generation replaces each F with 3 chained F's (plus side branches). So chain depth = 3^g too? No: a chain of n F's becomes 3n after one expansion (each F → 3 chained F's along the same path). So depth = 3^g? At gen 5 = 243 deep with len 1 each — tree would be 243 units tall, 243 segments along one path. That's too deep and spindly.

Use the X grammar which is better balanced: X->F[+X][-X]FX, F->FF (Hilbert-ish tree from Prusinkiewicz). Depth: X chain: X→F[+X][-X]FX, trailing X at depth +2 (F, then F). Side X at depth+1. F->FF doubles F chains each gen. Final generation: the X's become... Let me just estimate: this is a well-known tree, looks good at gen 5-7 with angle ~25°. String length at gen 7 is fine (~30k). Gen 5 moderate. Depth maybe ~20-30. Scaling handles visibility.

Hmm but F->FF doubling makes depth grow: at generation count g, final F-run lengths ~2^g. Gen 5: 32-length chains? No — F->FF applied g times gives chains of 2^g only if all expansions apply to same F. X introduces 2 F's per X; after g generations, F's from early X get doubled many times. Final chain depth along main spine: X at top expands at last gen only, so its F's are single. Lower F's doubled. Spine depth ≈ sum 2^(g-i) over i=0..g-1... ≈ 2^g. Gen 5 → 32. That's tall and spindly but scaling makes it fit; might look okay actually, like a young tree. Total F count at gen 5: maybe ~2000. Fine.

Alternatively use rule X->F[+X][-X]FX with F->F (no doubling) for gens, and only double at... keep it simple: F->FF is the classic and looks nice.

Let me just build and check visually in browser.

Growth animation: growStart = depth * 0.12s? With depth 32, total 3.8s + grow time. Fine, speed factor adjustable. Use per-node: start = depth * 0.1, dur = 0.45.

Leaves: terminal nodes (children empty) get leaf: draw ellipse with greenish color, size scales, maybe appear at end of growth with fade.

Wind: sway(node) = sin(t*1.2 + node.phase) * amp * (depth/maxDepth)^1.5 * 0.06 radians. Phase from node id hash. Apply only after grown (or partial sway scaled by growth).

Draw:
```js
function drawNode(node, t){
  const g = growthProgress(node, t); // 0..1
  if(g<=0) return;
  const sway = windAmp * Math.pow(node.depth/maxDepth, 1.6) * Math.sin(t*1.3 + node.phase) * smoothGrowth;
  push();
  rotate(node.rel + sway);
  strokeWeight(map depth);
  line(0,0,0,-node.len*g*scale);
  translate(0,-node.len*g*scale);
  for child drawNode
  if leaf && g>=1: draw leaf
  pop();
}
```

UI: range input 1..5 with label, Regrow button. On change: rebuild.

Also display string length / segment count and generation.

Write index.html, then run browser to verify: initial growth, screenshot at later time, change generation, check sway.

Let me write the file.

p5.min.js present. Write index.html.

Growth just started (3%). Segments: 130 at gen 4 — hmm, that seems low. Let me check: X->F[+X][-X]FX, F->FF. Count of F at gen 4? Gen 1: X → F[+X][-X]FX has 2 F, 3 X. Gen 2: F→FF (4 F), each X→2F+3X → 3*(2F+3X)=6F+9X, total 10F+9X... it grows but slowly. Depth 30 reported though — because F chains. Whatever; screenshot later at full growth. Gen 5 might have ~1000 segments. Let me wait for growth and take a screenshot. totalGrowSecs = 30*0.09+0.5 = 3.2s. Take a motion/screenshot after some seconds.

Tree fully grown at gen 4: connected trunk, branches, leaves at tips, fits in view. Looks good. Now test generation change to 5 and check restart + structure, and sample wind motion.

Generation 5 restarted growth (3%, 422 segments, depth 62). Growth time = 62*0.09+0.5 ≈ 6.1s. Wait for full growth — take screenshot after delay. The screenshot tool may capture immediately; let me wait via motion or take another screenshot (each call advances time). Let me take another screenshot.

Gen 5 at 85% — denser, different structure, still fully visible. Now sample wind motion after full growth. Use motion action to capture frames, or two screenshots. Let me take a motion sample.

Across the 4 motion frames the canopy visibly shifts (branches/leaves lean left/right between frames) while trunk stays put — wind sway works, branches stay attached. Everything verified: growth from trunk to tips, parent-child connections, generation change restarting growth with different structure, bounded expansion (422 segs at gen 5), whole tree visible, wind sway.

Test Regrow button quickly? Clicking it restarts growth — same code path as slider (regrow function). Quick click to confirm no errors.

Regrow works — growth restarted at 1% with the same grammar (422 segments, gen 5). All required behaviors verified. Console is clean (only a sandbox iframe warning from the harness, unrelated).

Final report.