E544 — Duncan Fewkes reel analysis digest

E544 — Duncan Fewkes reel analysis digest

Source video: `../reels/E544-DU-52fcinww.mp4` (symlink to `[home-path]`)
Caption: `../reels/E544-DU-52fcinww.txt`

This file aggregates every playbook chunk section that cites E544. 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 — Logo / text as VFX volume (E527-E531, E544)

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

This is a concept the prior playbook missed. Logos / wordmarks are not just static overlays — they are 3D volumes that become particle obstacles, spawn surfaces, or "punch through" reveals:

• E530 "Punch Through": invisible logo + inverted-obstacle fluid sim → particles get thrown out of letter shapes, leaving you visible through the gaps between letters. "Works because 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.
• E536 self-critique: "Need to rewrite spawning buffers to use entire screen (not just depth camera point cloud) so can easily spawn particles on/in eg logos, metaballs or other geometry." — this is a major architectural TODO he hasn't done yet. LUME can leapfrog: build the spawn buffer to accept any signed-distance source (depth, logo SDF, metaball SDF) from day 1.
• 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."

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 or trapped inside the letter cavities.

---

NEW — Pinscreen / cube-grid depth-pushed VFX (E544, E545)

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

The "Blocky PinScreen" effect (E544) and its transparent variant (E545):
- A regular grid of small cubes locked into XY position
- Z-position pushed by reprojected depth + fluid-sim dye buffer
- Two-tone shading: front-facing material = white plastic; rear-facing material = gold (or other accent)
- Transparent variant uses HDRP thickness for transmission color

LUME: this is a clean alternative to point-cloud particles. Less "swarmy", more "architectural / pinscreen / Chladni table" feel. Single mesh, instanced grid of cubes, vertex shader displaces by depth. Cheaper than per-pixel particles. Good Wave 2 add.

---

NEW — "Hole Punch" depth render mode (E532, E544)

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

> "Person depth visual using the 'hole punch' variant where it doesn't z-test, so it renders on top of any particles even if they are in front in 3D space. Helpful for not losing track of where you are, but gets quite visually confusing as lose so many depth cues." (E532)

Trade-off he names explicitly:
- HolePunch ON: silhouette always visible (good for "where am I?"), bad for spatial cues (particles in front look like behind)
- HolePunch OFF: proper z-test, true depth, but user can lose themselves behind particle clouds

LUME: ship both as Depth presets (`HolePunch`, `GhostChromatic`, `ProperDepth`). Default to ProperDepth for the bar (people will mostly stand in clear space). Switch to HolePunch when particle counts are very high.

---

Risks / open questions

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

1. Holovis: Is Duncan employed by / contracted to Holovis (the company)? The branded reels (E527, E544, E532, E544) plus "registered trademark" suggest yes. LUME positioning implication: Duncan's stack is a commercial product behind an installation services company. We're not ripping off a hobbyist; we're building a competitor primitive on a smaller scale (bar lounge vs LED CAVE).
2. HDRP `thickness` for URP: still no clean solution. Density-based absorption tint is a 60
3. Spawn-buffer rewrite: Duncan flagged this as an architectural TODO he hasn't shipped. LUME should build the unified spawn-source interface from day 1 — explicit advantage over copying his current impl.
4. One-euro filter: name-checked by him for motion smoothing (E567). Already a known good filter in interactive systems. Pull a Rust/C# one-euro impl for `LumeMotionGatedFluidSim.cs` rather than rolling our own.
5. Holovis flat 17m × 3m: he's in the middle of porting from CAVE to flat large screen — exactly LUME's form factor. Consider DM: he might be open to discussing the porting gotchas. (Defer — not urgent.)

---

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.

---

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`.

---

G. Logo / wordmark as 3D VFX volume (E527-E531, E544, E470, E489)

_From `lume-duncan-playbook.md`_

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)

_From `lume-duncan-playbook.md`_

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.

---

Risks and open questions

_From `lume-duncan-playbook.md`_

1. HDRP vs URP: Confirmed across 8+ reels (E461/E462/E468/E470/E595/E544/E545). HDRP-only features: compute thickness, MULTIPLE_SCATTERING sky, advanced volumetrics. Most other effects port fine. Decision still deferred to post-Sat.
2. Spine-bone tracking: His `Framed_MotionCap` Digital Human implies real skeleton stream, not depth alone. Need mocopi PRO landed (in transit) for parity.
3. HOLOVIS context: Duncan ships into a CAVE / LED-wall / curved-screen install business (now porting to flat 17m × 3m). LUME ships single-monitor / 1-3 vertical monitors. Particle scale, FoV, reflection probe positioning will need re-tuning for non-LED-CAVE targets. Reflection probes drop from 6-face per frame to 1-face planar.
4. Hardware ceiling: A6000@60fps is his target ceiling; his dev box is 3070 (8GB VRAM) running 2×150k particles. Mac5 M4 (16GB unified) should clear comfortably for dev. Beelink K8 / SER7 with iGPU = won't run 300k particles. Confirm we're targeting discrete-GPU x86 mini-PCs post-Sat (BOM pivot already moves us to GMKtec K8 Plus etc., but verify VRAM for VFX-Graph load).
5. Per-install calibration is mandatory: not optional polish. Ship `[home-path]` from Wave 2.
6. One-euro filter: known-good interactive filter, name-checked by Duncan. Pull a C# impl rather than rolling our own.
7. HOLOVIS may be Duncan's employer/client: branded reels suggest commercial relationship. We're not ripping off a hobbyist; we're competing on a smaller scale. Positioning implication for LUME marketing.
8. "Auto Cycle VFX": he hand-waved "would be cool to get music-aware auto-transition" (E588) — meaning he hasn't built it yet either. We can leapfrog him here using Mac5 strudel BPM detection.

---