E568 — Duncan Fewkes reel analysis digest

E568 — Duncan Fewkes reel analysis digest

Source video: `../reels/E568-DV6A04wislr.mp4` (symlink to `[home-path]`)
Caption: `../reels/E568-DV6A04wislr.txt`

This file aggregates every playbook chunk section that cites E568. Sections are de-duplicated by heading.

Source

_From `lume-duncan-playbook-chunk-DV-DU.md`_

• 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/`
• Episodes covered: E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570
• 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited
• All on HDRP + VFX Graph + Shader Graph (confirmed every caption)

---

Single most important new finding — Holovis client install

_From `lume-duncan-playbook-chunk-DV-DU.md`_

E527, E544, E532, E544 (DUSui7PioUD, DU-52fcinww, DUgoDHlipPu) all confirm Duncan ships into a branded "Holovis®" CAVE / wide LED installation venue. This is not lab work, this is a live commercial installation product. Implications for LUME:

• The visuals are tuned for a wide curved LED CAVE (multi-panel) — but he is now porting to a flat 17m × 3m screen (E567 caption). LUME's 1-3 vertical monitors is a smaller close-cousin of "flat 17m × 3m".
• Each install gets per-site calibration — he literally calls out: "need to rebalance threshold etc values for the actual usage distance — probably easiest to expose in settings and debug menu to allow for tweak values for each install individually" (E568). LUME action: ship a per-install settings file (motion threshold, depth-camera distance, smoothing) loaded from disk, exposable via debug menu.
• The Holovis logo is itself one of the VFX targets — a "Logo:" preset slot on the VFX editor (we already had this in the prior playbook). New twist below.

---

NEW — UI panel: Settings menu (from E568 analysis, full reveal)

_From `lume-duncan-playbook-chunk-DV-DU.md`_

This is a separate panel from the VFX Editor. Top-left overlay during runtime:

Settings
├── Pause
├── Freeze Input With Pause          ← (CAVE-specific: pause sim but keep camera input frozen too)
├── Calibration Settings
├── Camera Settings
├── Motion Settings                  ← ← expanded below
│   ├── Optical Flow Imagine X       (range observed: 3-9)
│   ├── Optical Flow Imagine Y       (range observed: 3-9)
│   ├── Drag Max Intensity X         (range observed: 0.0 - 0.1+)
│   ├── Drag Max Intensity Y         (range observed: 0.0 - 0.1+)
│   ├── Drag Scale (X/Y)             (range observed: ~0.006)
│   ├── Image Threshold (0-255)      (slider: 50 = more concentrated motion)
│   ├── Image Invert (0/1)           (toggle: flips colour scheme — green/blue when inverted)
│   └── Motion Blur (0/1)            (toggle: smooths trails)
├── Performance Settings
├── Audio Settings
├── Load Setup Settings
├── Save To Setup Settings           ← per-install setup save/load
└── Delete Setup Settings

LUME: this is the operator-side debug menu (separate from VFX Editor which is the artist-side). Build as `LumeSettingsMenu.cs`. The Setup Settings save/load is the per-install calibration file mentioned above.

---

NEW — VFX Editor extra fields (from E532, E534, E568 visual analyses)

_From `lume-duncan-playbook-chunk-DV-DU.md`_

Augments the prior playbook's VFX Editor data model:

• Depth: <preset> — new field. Observed values: `HolePunch` (renders silhouette on top of all particles, no z-test, hurts depth cues but never lose track of yourself), `GhostChromatic`. Add to `LumeVfxEditor.cs`.
• Painting: <preset> — new field. Observed: `SpotsLeftRightWithFill`, `Bounce_Frosted`, `Bounce, Plastic`. Probably the surface-shader / material slot.
• Background: <preset> — already had it. New observed values: `Gallery2`, plus the prior `StudioBG_Grey`.
• FX: <preset> — observed values: `Clones Snapshot Red`, `Clones Snapshot Red Plexus` (= same effect with plexus links between particle pairs).
• BodySim: <preset> — observed in E532. Same value set as FluidSim (Default / Default_Smooth / LongThrow / MidThrow / ShortThrow). This implies a separate sim slot specifically for body-driven motion, distinct from the global fluid sim.
• HUD overlay: the FX name itself is rendered on screen in the lower-left area as text. "only the last one (shows as 'Clones Red' in screen text on the lower left) is audio-reactive" — operator sees the active preset live.

---

NEW — "SuperHot" motion-gated sim timescale (E567, E568)

_From `lume-duncan-playbook-chunk-DV-DU.md`_

This is a massive and entirely new visual mode not in the prior playbook:

> "Utility script hooks user motion (from depth camera) to fluid sim timescale with a fairly quick smoothing/falloff — so a bit like SuperHot, where the sim only updates/moves when you move." (E567)

Implementation pattern:
- Compute scalar motion level from depth-camera frame-to-frame delta (smoothed)
- Map motion level → `Time.timeScale` for fluid sim only (NOT global Unity time scale — fluid sim has its own dt)
- Add lower-threshold so "no motion → fully frozen sim"
- Issue he's hitting: depth noise prevents reaching zero when user is far from camera. Fix mentioned: one-euro filter on motion level + per-install threshold tuning.

LUME action: implement as `LumeMotionGatedFluidSim.cs`. Killer feature for bar/lounge installs — when nobody moves, the visuals freeze into a sculpted form. When the room moves, it comes alive. Wave 2-3 deliverable.

---

NEW — Frozen sim buffers as accidental art (E560, E567, E568)

_From `lume-duncan-playbook-chunk-DV-DU.md`_

E560 caption — found by accident, kept:
> "Stopped Unity editor playback and the fluid sim stops updating but the buffers don't get cleared (as they exist in asset database), so the particle VFX continue to update and the particles follow the frozen sim velocity buffer paths. This creates frozen forms in the motion paths that you don't get while the sim is updating."

This is distinct from SuperHot mode: SuperHot pauses sim time when user is still; this is freezing the velocity field while the particles keep flowing through it. The result is laminar streams flowing along etched-in paths. Implement as another mode on the LumeMotionGatedFluidSim controller: `FreezeVelocityField` toggle.

---

NEW — Hue-by-speed per-particle coloring (E568)

_From `lume-duncan-playbook-chunk-DV-DU.md`_

> "hue-cycling colour being added to particle every frame according to its current speed" (E568)

Per-particle shader: `hue = baseHue + speedScalar * shiftAmount`. Particles moving fast get hue-shifted; slow particles stay near base. Combined with the prior playbook's "per-particle hue from RGB luma at spawn", LUME has 3 hue inputs:
1. global slow cycle (1 rev / 30s) — already in plan
2. per-particle RGB luma at spawn — already in plan
3. per-particle speed-driven hue shift each frame — NEW. Add as VFX Graph "Set Color over Lifetime" node modulated by `Get Velocity → length`.

---

Self-critique quotes worth borrowing as LUME design principles

_From `lume-duncan-playbook-chunk-DV-DU.md`_

• E534: "Plexus links almost invisible so I need to figure out how to match brightness with the source/linked particles." → emissive consistency between primitives is its own bug class
• E535: "Not very noticeable so needs more definite/large change in motion, but without it going crazy and losing coherence." → audio-transient response: needs to read clearly without losing form coherence
• E548: "Pretty huge fail when I finally check some footage of real kelp and realise mine looks bugger all like an actual kelp forest. I think I must have had some kind of Spongebob cartoony swishy stuff in mind." → reference-check before lookdev
• E556: "Otherwise it would feedback and he'd go apeshit." → coupled sim systems: pick one direction
• E567/E568: "Probably easiest to expose in settings and debug menu to allow for tweak values for each install individually." → ship per-install settings as first-class architecture, not afterthought

---

Critical product context — Duncan ships HOLOVIS

_From `lume-duncan-playbook.md`_

This is the framing the v1 playbook missed. He is not a hobbyist; he ships into a commercial CAVE / LED-wall installation product called HOLOVIS®. Confirmed across E527, E532, E544, E460, E466, E472. Key implications:

1. The HOLOVIS letters are a payload object, not chrome. They are simultaneously: blendshape inflation target, reflection probe hit-target, particle spawn surface, light source, SDF for "punch through" reveals (E528, E530, E544, E470).
2. Target hardware: Quadro A6000 @ 60fps (E470 verbatim). Sets LUME parity ceiling at ~RTX 4080. His dev box is a 3070 laptop running 2 × 150k VFX Graph particle systems = 300k mesh particles total at interactive rates.
3. Currently porting from CAVE → flat 17m × 3m screen (E567). LUME's 1-3 vertical monitors are the smaller close-cousin. We are not reverse-engineering hobby work; we are competing on a smaller scale with someone who already shipped the same form factor pivot.
4. Per-install calibration is a hard product requirement, not a nice-to-have (E568 verbatim: "need to rebalance threshold etc values for the actual usage distance — probably easiest to expose in settings and debug menu to allow for tweak values for each install individually"). The calibration grid + circular degree-marked reference markers visible in dozens of reels are runtime spatial UI, not decoration.

---

Three-channel reactivity philosophy

_From `lume-duncan-playbook.md`_

v1 had two channels (outline=audio, inner=motion). v2 elevates this to three with the audio-transient discovery (E535):

Verbatim from E579:
> Outline (form) reacts to audio: brightness flashes on beat — shows you "where you are."
> Inner color (action) reacts to motion: hue/spread driven by motion vectors — shows you "what you're doing."

Verbatim from E535 (the third channel):
> WIP testing quick "overamp" method for audio transients to add a kick to the particle motion. Not very noticeable so needs more definite/large change in motion, but without it going crazy and losing coherence.

Concrete audio→VFX rules from E512 (most actionable engineering note in entire corpus)

> 1) Fluid sim preset with shorter range (lower velocity propagation) works better at full screen scale — and also for multiple people.
> 2) Audio response boosting position directly (rather than feeding into force levels) makes it nice and snappy without blowing up the fluid sim.
> 3) Audio response still needs work. Need to EQ before auto-gain (or fixed dynamic range with no auto-gain) to tame bass level but give natural response where louder parts make particles react more than quieter.
> 4) Bass should affect sim large low-freq positional offsets, mid range and highs work nicely when the timer cycle causes higher-freq position offsets.

For `LumeAudioReactor.cs`:
- 4 frequency bands (bass / low-mid / high-mid / treble) NOT just RMS+3 generic
- Bass band → low-freq large positional offset (slow wave bulges)
- Mid + high bands → high-freq small positional offsets (timer-cycled)
- Audio drives position directly, NOT force/velocity (avoids sim blowup)
- EQ stage BEFORE auto-gain (or use fixed dynamic range entirely)
- Speed→brightness as the "twinkle" parameter (E490) — power curve with threshold, tune live by ear (no preset)

Per-particle hue inputs (3 stacked sources)

1. Global slow cycle — 1 rev / 30s, applied to all particles
2. Per-particle hue from RGB luma at spawn — each particle takes color from where on the body it spawned (RGB texture binding alongside depth)
3. Per-particle speed-driven hue shift each frame — `hue = baseHue + speedScalar * shiftAmount` (E568)

---

Per-particle hue inputs (3 stacked sources)

_From `lume-duncan-playbook.md`_

1. Global slow cycle — 1 rev / 30s, applied to all particles
2. Per-particle hue from RGB luma at spawn — each particle takes color from where on the body it spawned (RGB texture binding alongside depth)
3. Per-particle speed-driven hue shift each frame — `hue = baseHue + speedScalar * shiftAmount` (E568)

---

Per-install calibration (Settings menu, NEW from DV-DU)

_From `lume-duncan-playbook.md`_

Duncan's runtime has TWO operator UIs, not one. v1 only documented the VFX Editor (artist-facing). The Settings menu (operator-facing) is separate.

Settings menu (top-left runtime overlay, from E568 visual analysis)

Settings
├── Pause
├── Freeze Input With Pause       # CAVE: pause sim but keep camera input frozen
├── Calibration Settings
├── Camera Settings
├── Motion Settings               # ← expanded below
│   ├── Optical Flow Imagine X    (range observed: 3-9)
│   ├── Optical Flow Imagine Y    (range observed: 3-9)
│   ├── Drag Max Intensity X      (range observed: 0.0 - 0.1+)
│   ├── Drag Max Intensity Y      (range observed: 0.0 - 0.1+)
│   ├── Drag Scale (X/Y)          (range observed: ~0.006)
│   ├── Image Threshold (0-255)   (slider: 50 = more concentrated motion)
│   ├── Image Invert (0/1)        (toggle: flips colour scheme)
│   └── Motion Blur (0/1)         (toggle: smooths trails)
├── Performance Settings
├── Audio Settings
├── Load Setup Settings
├── Save To Setup Settings        # per-install setup save/load
└── Delete Setup Settings

For LUME: build `LumeSettingsMenu.cs` separate from `LumeVfxEditor.cs`. Settings file format `[home-path]` with motion threshold, depth-camera distance, smoothing values per install.

Linearise depth before any motion consumer (E460 verbatim)

> Finally got round to rewriting optical flow motion detection system to use linear depth and give even motion response in all parts of interactive region (previously would have large response near camera, but hardly any at max distance of depth buffer).

Foundational fix for the motion channel. Naive depth-buffer differencing has strong z-near bias (depth values are non-linear). Linearise via `linear_z = nearfar / (far - depth(far-near))` BEFORE optical flow.

Wave 1 promotion: even though optical flow itself is Wave 3, the calibration/depth-prep layer should already linearise. One-line shader change in `LumeDepthReprojection`. Without this, particles right next to the camera over-react and far particles look dead.

Boundary-conditioned 2D fluid sim (E466)

Reflective Dirichlet boundaries at LED-region edges. Don't ship torus-wrap or open boundary — particles escape and visuals die (E444 self-critique: "motion feels too high … source particles leave screen, collision to keep on screen might help").

---

Settings menu (top-left runtime overlay, from E568 visual analysis)

_From `lume-duncan-playbook.md`_

Settings
├── Pause
├── Freeze Input With Pause       # CAVE: pause sim but keep camera input frozen
├── Calibration Settings
├── Camera Settings
├── Motion Settings               # ← expanded below
│   ├── Optical Flow Imagine X    (range observed: 3-9)
│   ├── Optical Flow Imagine Y    (range observed: 3-9)
│   ├── Drag Max Intensity X      (range observed: 0.0 - 0.1+)
│   ├── Drag Max Intensity Y      (range observed: 0.0 - 0.1+)
│   ├── Drag Scale (X/Y)          (range observed: ~0.006)
│   ├── Image Threshold (0-255)   (slider: 50 = more concentrated motion)
│   ├── Image Invert (0/1)        (toggle: flips colour scheme)
│   └── Motion Blur (0/1)         (toggle: smooths trails)
├── Performance Settings
├── Audio Settings
├── Load Setup Settings
├── Save To Setup Settings        # per-install setup save/load
└── Delete Setup Settings

For LUME: build `LumeSettingsMenu.cs` separate from `LumeVfxEditor.cs`. Settings file format `[home-path]` with motion threshold, depth-camera distance, smoothing values per install.

---

Complete VFX Editor data model (v2 — supersedes v1)

_From `lume-duncan-playbook.md`_

The v1 model had ~7 slots with placeholder names. v2 has 9 slots with verbatim preset names from his UI overlays (E516, E521, E532, E534, E568):

VFX Editor
├── Auto Cycle VFX [checkbox]    # BPM/16-bar phrase auto-transition
│
├── Depth: <preset>              # surface treatment of human silhouette
│   options: GhostChromatic2, GlassThin, GlassThick, GlassScan1/2/3, DepthCubes, HolePunch, None
│
├── VFX 01: <preset>             # additional particle layer
│   options: ClonesAudioDropBright, ParticleClone, ParticleClonesAudio,
│            SwirlyParticles, KaleidoscopeRing16, Multiparticle_Spine_FX, None
│
├── VFX 02: <preset>             # second layer (compositional)
│   options: ParticleSystem_Spine_Trail, ClonesSnapshotRed, ClonesSnapshotRedPlexus, None
│
├── Painting: <preset>           # surface-shader / material slot
│   options: SpotsLeftRightWithFill, Bounce_Frosted, Bounce_Plastic, None
│
├── Lighting: <preset>           # named lighting rigs
│   options: FogSpotLeftRight1, FogSpotLeftRight2, FogSpotRight, FogSpotOverhead,
│            FogPointOrbitPulse, BrightRoom, SpotsLeftRightWithFill, EmissiveOnly, None
│
├── LightingProfile: <enum>      # NEW from E473 — perf vs cinematic toggle
│   options: EmissiveOnly (160-170 fps, no shadows), SpotShadows (70-110 fps, 7x cast)
│
├── Environment: <preset>        # 3D scene around the figure
│   options: Studio_Sky_Sphere, Sunset, BolivianSaltFlats, TestRoomDark, None
│
├── Background: <preset>         # 2D backdrop layer
│   options: StudioBG_Grey, Gallery2, TestRoomDark, None
│
├── Logo: <preset>               # brand overlay slot — also acts as VFX volume
│   options: HOLOVIS_Letters_AudioBlendshape, KOATJI/LUME_equivalent, Off
│
├── FluidSim: <preset>           # 6 verbatim names from E534
│   options: Default, Default_Smooth, LongThrow, MidThrow, ShortThrow, InvertedObstacle
│
├── BodySim: <preset>            # NEW from E532 — separate sim slot for body-driven motion
│   options: same value set as FluidSim
│
├── FX: <preset>                 # additional one-shot effects
│   options: ClonesSnapshotRed, ClonesSnapshotRedPlexus, None
│
├── SpawnTopology: <enum>        # NEW from E509 floor-spawn discovery
│   options: FloorPlane, BodyVolume, CeilingPlane, WallPlanes, MidPlane
│
├── NoiseAxisMode: <enum>        # NEW from E514
│   options: XZ_Twist_Contained, Y_Lift_With_LowFreqBulges
│
├── Auto Load Default Scene [button]
├── Update Settings Default Scene [button]
│
├── Camera Settings: FOV slider + Sensitivity slider
├── VFX Settings: Intensity, Density, Count, Gravity, InitialVelocity, Lifetime, SpawnRate
├── Render Settings: Exposure, Gamma, AmbientOcclusion, Bloom
├── VFX Color: RGB sliders + hex + color picker
└── FX LiveOnColorClear [checkbox]

Critical UX rule (E516 verbatim)

> Cycling through test lighting presets and the last is always 'None' (same for the script for cycling through depth visuals, VFX, backgrounds etc — always allow for 'Off' to be an option).

Every preset enum's last entry MUST be `None`. The negative-space look that emerges from `Lighting=None + emissive depth particles` is its own aesthetic, not a bug. From E516: "looked interesting without any realtime lights because the emissive particles and live 3D depth projection makes it look like solid shadow/negative space punch through."

Depth ≠ VFX: 4×4=16 combos for free

Prior assumption (v1): "depth particles" was one thing. v2 reveals they are two independent slots — `Depth:` (surface treatment of the silhouette) + `VFX:` (the additional particle layer on top). They cycle independently.

Depth: Ghost / Glass / Cubes / Off    (~4-6 surface treatments)
VFX:   Clones / Particles / Swirl / Off  (~4-6 particle layers)

= 16+ distinct combinations before lighting/colour/background variation. Operator gets massive variety from a small preset library.

Performance HUD (top-right, persistent in every reel)

avg min max
38  39  60   16.6ms
FPS: 60

Build `LumePerfHud.cs` with same layout. F8 toggle. Useful both for dev and operator confidence the install is healthy.

---

Effect taxonomy (catalogued across 72 reels — all families)

_From `lume-duncan-playbook.md`_

### A. Metaball / liquid / blobby family (E461, E462, E468, E593, E595)
- "Blobby guys" with material variants: slime, water, pink energy, oily, chrome/mercury
- HDRP compute thickness + translucent materials = the depth/turntable look
- Inverse compute-thickness mode (E468): alpha ∝ (1−thickness), neon-edge look + glowing wall decals
- Twin-mesh nested MC (E427): inner gold + outer glass, same particles, two surface thresholds
- LUME equivalent: URP doesn't ship compute thickness. Approximate with screen-space SDF metaball shader (cheap, ~80

### B. Bullet-time / freeze-snapshot family (E536, E599, E595, E604)
- Audio-transient trigger (clap/snap) → pause → swap to debug orbit camera → 1 full orbit with ease-in/out curve → swap back → unpause
- "In-place slowmo with screen-warping" alternative (no camera spin — for wall installs)
- Beat-triggering of clone snapshots stays active during bullet-time — no "down time"
- LUME: `LumeBulletTime.cs` + `LumeCloneSnapshot.cs`. Wave 3.

### C. Clone / dissolve / multi-self family (E483, E488, E491, E598, E604)
- Frozen poses captured as red snapshots, layered with live purple/orange depth mesh
- Snapshot timing locked: `holdDuration = 0.25s` then ease-in to gravity (E491 verbatim self-critique)
- Drop-physics rules from E488:
- Particles MUST NOT cast shadows (or use layer-filtered depth buffer) — self-collision turns it into a mess
- Pure gravity + collision is visually dead — ALWAYS layer fluid-sim kick + turbulence on top
- "Don't quit at the first disappointing test" — verbatim
- Dual-channel: red snapshots (frozen) vs live purple/orange mesh (current)
- LUME default: both layers, with slider to toggle live-depth opacity 0-1

### D. Sunset / infinite plane / planar reflection (E605)
- "Sunset" lighting preset = warm directional + atmospheric haze
- Infinite plane (procedural ground) with planar floor reflection — but toggleable because it's a known perf hit (E532)
- "Bolivian Salt Flats" environment ambition
- LUME: URP planar reflection probe + procedural ground shader + warm-tone post-processing volume. `LumeFloorReflection.cs` togglable.

### E. Motion-sparks / particle-burst family (E579, E587, E589)
- Surface shader audio reaction: brightness flash on beat
- Surface shader motion reaction: fresnel pulled down where motion occurs
- Particles: hue cycle + per-spawn hue-shift by RGB luma + size/glow fade by speed + speed-driven hue shift
- "Music on/off" toggle is part of his demo (E587) — proves audio-reactivity is opt-in, not always-on

### F. Maximalism stress-test (E599)
- Pushed fluid forces and particle count/lifespan to the limit
- Caption: "sometimes more is more" — he likes the busy look, not the minimal
- LUME tuning: don't be conservative on particle count. Aim high then dial back.

### G. Logo / wordmark as 3D VFX volume (E527-E531, E544, E470, E489)
NEW family from DV-DU + DR-DQ chunks. Logos are not static overlays — they are 3D volumes that become particle obstacles, spawn surfaces, "punch through" reveals, AND audio-reactive blendshape drivers:

• E530 "Punch Through": invisible logo + inverted-obstacle fluid sim → particles thrown out of letter shapes, leaving the user visible through gaps. "High fluid influence throws particles out of the logo letters, and no particle kill for zero velocity, so particles get stuck in non-fluid-flow area."
• E528 cymatics: ShortThrow fluid sim + logo letters → particles "stuck" on letters bouncing internally → almost cymatic (Chladni-plate) pattern.
• E544 "Blocky PinScreen Revisit": HOLOVIS text reacts volumetrically — "interactive text displayed and reacts volumetrically to the user's movements, allowing the user to walk through or displace the letters."
• E489 wordmark feedback loop (CRITICAL): wordmark uses BlendShape inflation driven by FFT bands → blendshape inflation generates motion vectors → motion vectors get injected into fluid sim → fluid sim pushes nearby particles. The wordmark BECOMES part of the audio-reactivity loop, not just an overlay.
• E470 power-curve emission gating: HDRP compute-thickness → screen-space buffer → tight power curve `pow(thickness, k)` with `k≈6-10` → bistable letter glow (dark, then suddenly glow at threshold). Cleaner than `emission *= audioRMS`.

LUME mapping: KOATJI / LUME wordmark becomes a 3D extruded SDF that the depth-camera point cloud can punch through, with particles spawning along the letter surface. Build `LumeWordmarkInflator.cs` + tight power-curve emission gating in shader.

### H. Pinscreen / cube-grid VFX (E544, E545)
NEW family.
- Regular grid of small cubes locked into XY position
- Z-position pushed by reprojected depth + fluid-sim dye buffer
- Two-tone shading: front-facing white plastic; rear-facing gold (or accent)
- Transparent variant uses HDRP thickness for transmission color
- Cleaner alternative to point-cloud particles. Less "swarmy", more "architectural". Single mesh, instanced grid, vertex shader displaces by depth. Cheaper than per-pixel particles. Wave 2 add.

### I. Strip-particle / kelp / boids family (E546-E549, E556-E557)
NEW family.
- VFX Graph particle strips (= ribbon particles) used as kelp strands
- Per-strip stiffness; motion/forces propagated parent→child
- Spectrum-mapped vertical audio response (E557): map FFT bin index → vertical Y position on strip particle. Bass drives bottom leaves, treble drives top leaves.
- Boids variant: Reynolds boids sim with audio params on cruising speed and separation.
- "Wobbly Lads" feedback gotcha (E556): bidirectional sim coupling = feedback loop. Pick one direction.
- LUME relevance: kelp aesthetic is niche, but the strip-particle physics primitive is broadly useful (tendrils, smoke ribbons, hair). Wave 4-5.

### J. SuperHot motion-gated fluid sim (E567, E568)
NEW killer mode. Verbatim:
> Utility script hooks user motion (from depth camera) to fluid sim timescale with a fairly quick smoothing/falloff — so a bit like SuperHot, where the sim only updates/moves when you move.

Implementation:
- Compute scalar motion level from depth-camera frame-to-frame delta (smoothed via one-euro filter — name-checked E567)
- Map motion level → fluid sim's local timescale (NOT `Time.timeScale` — fluid has own dt)
- Lower-threshold → "no motion = fully frozen sim"
- Per-install threshold tuning (depth noise prevents reaching zero when user is far)

Killer feature for bar/lounge installs — when nobody moves, visuals freeze into a sculpted form. When the room moves, it comes alive. Wave 2-3.

### K. Frozen velocity buffer (E560, E567, E568)
NEW mode, distinct from SuperHot. Found accidentally and kept:
> Stopped Unity editor playback and the fluid sim stops updating but the buffers don't get cleared (as they exist in asset database), so the particle VFX continue to update and the particles follow the frozen sim velocity buffer paths. This creates frozen forms in the motion paths that you don't get while the sim is updating.

Distinct mechanism: SuperHot pauses sim time when user is still; this freezes the velocity field while particles keep flowing through it. Result: laminar streams along etched-in paths. Implement as a `FreezeVelocityField` toggle on `LumeMotionGatedFluidSim`.

### L. Human Kaleidoscope (E475, E476, E479, E469, E471, E472)
NEW mode (entirely missing from v1).
- 16-clone radial ring around centre — N=16 is settled value (tested 20/24/32, "harder to read the human form")
- Each clone is rotational copy of live depth silhouette
- Slow top-level rotation of entire ring
- LOD mesh switching to push more clones (tunnel formation in E476)
- E479: SECOND ring of new-colour clones snapshot every second, falling inwards into turbulence — temporal stacking on top of spatial mirroring
- Explicitly rejected per-clone twist — "too much variance and makes the shape much harder to read"
- E472 extends to full body so legs participate
- DR-prefix variant uses chrome / matte material toggle + reflection probe in middle of symmetry

LUME design rule from this: when stacking visual transforms, ONE rotational symmetry is enough. Don't compound symmetries; pick one and let temporal evolution do the rest.

`LumeKaleidoscope.cs` Wave 4 deliverable. Cheap to ship — single render texture + N copies rotated by `360°/N`.

---

J. SuperHot motion-gated fluid sim (E567, E568)

_From `lume-duncan-playbook.md`_

NEW killer mode. Verbatim:
> Utility script hooks user motion (from depth camera) to fluid sim timescale with a fairly quick smoothing/falloff — so a bit like SuperHot, where the sim only updates/moves when you move.

Implementation:
- Compute scalar motion level from depth-camera frame-to-frame delta (smoothed via one-euro filter — name-checked E567)
- Map motion level → fluid sim's local timescale (NOT `Time.timeScale` — fluid has own dt)
- Lower-threshold → "no motion = fully frozen sim"
- Per-install threshold tuning (depth noise prevents reaching zero when user is far)

Killer feature for bar/lounge installs — when nobody moves, visuals freeze into a sculpted form. When the room moves, it comes alive. Wave 2-3.

---

K. Frozen velocity buffer (E560, E567, E568)

_From `lume-duncan-playbook.md`_

NEW mode, distinct from SuperHot. Found accidentally and kept:
> Stopped Unity editor playback and the fluid sim stops updating but the buffers don't get cleared (as they exist in asset database), so the particle VFX continue to update and the particles follow the frozen sim velocity buffer paths. This creates frozen forms in the motion paths that you don't get while the sim is updating.

Distinct mechanism: SuperHot pauses sim time when user is still; this freezes the velocity field while particles keep flowing through it. Result: laminar streams along etched-in paths. Implement as a `FreezeVelocityField` toggle on `LumeMotionGatedFluidSim`.

---

Self-critiques worth borrowing as LUME design principles

_From `lume-duncan-playbook.md`_

• E534: "Plexus links almost invisible so I need to figure out how to match brightness with the source/linked particles." → emissive consistency between primitives is its own bug class
• E535: "Not very noticeable so needs more definite/large change in motion, but without it going crazy and losing coherence." → audio-transient response: read clearly without losing form coherence
• E548: "Pretty huge fail when I finally check some footage of real kelp and realise mine looks bugger all like an actual kelp forest. I think I must have had some kind of Spongebob cartoony swishy stuff in mind." → reference-check before lookdev
• E556: "Otherwise it would feedback and he'd go apeshit." → coupled sim systems: pick one direction
• E567/E568: "Probably easiest to expose in settings and debug menu to allow for tweak values for each install individually." → ship per-install settings as first-class architecture, not afterthought
• E516: "Always allow for 'Off' to be an option." → every preset enum ends with `None`
• E488: "Another lesson to myself to push past the disappointing failures and keep digging to see if there's anything there." → don't quit at first disappointing test
• E521 / E479 evolution arc: Duncan transitioned from bespoke per-reel demos to a swappable preset matrix (Depth × VFX × Lighting × Background). LUME should target this pattern from Wave 2 onwards. Earlier work was bespoke; later work is a control surface.
• #normalizefailure — he tags failures and shows them. Authenticity move worth borrowing for LUME devlog culture.

---