E415 — Duncan Fewkes reel analysis digest

E415 — Duncan Fewkes reel analysis digest

⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.

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

New visual modes / techniques not in the prior playbook

_From `lume-duncan-playbook-chunk-DR-DQ.md`_

1. Depth-camera kaleidoscope (E469, E471, E472 = three iteration steps)

Caption progression:
- E469: "shoulda done it sooner — Amazing the daft poses that some rotational symmetry prompts you to hit"
- E471: tests metallic vs non-metallic surface, adds "test box environment so the metallic surface has something to reflect"
- E472: extends from upper-body-only to full body so legs participate

Mechanism (inferred from visuals):
- Take live depth-camera silhouette
- Rotate + mirror N times around screen-center axis (kaleidoscope = rotational symmetry, typically 6 or 8 fold)
- Composite the rotated copies on top of each other
- Apply chrome / matte material toggle for surface change
- Reflection probe in the middle of the symmetry gives the metallic copies something to reflect

LUME mapping: add `LumeKaleidoscope.cs` as a Wave 4 VFX preset. Cheap to ship — single render texture + N copies rotated by `60°*i`. Plays well with our Femto depth stream (silhouette already segmented). Useful as a "performance mode" where one user generates an N-fold pattern. Net new mode for the playbook.

2. Inverse compute-thickness "edge glow" (E468)

Caption verbatim: "Inverted HDRP shadergraph compute thickness contribution to alpha and emissive glow so that the thin parts/edges glow, and the thick parts are transparent. Also made it leave glowing decals where it hits the walls."

Two distinct effects in one:
- Inverse thickness shader: alpha ∝ (1 − thickness), emissive ∝ (1 − thickness)^k — gives a "neon outline" feel where only the silhouette edge of the metaball glows; centre is transparent / void. Inverse of the E462 "core glow" mode.
- Wall decals: when the metaball volume intersects the room geometry, leave a glowing decal stuck to the wall. (Implementation: probably a ray cast from each fluid particle, decal shoot when below-thickness threshold near surface.)
- Hidden core: a "glowing blue fish" model rides at the centre of the metaball, dropping source particles from its position. This is his pattern for getting the metaball fluid sim to follow a path — a hidden driver mesh that emits.

LUME mapping:
- Add an `Inverse` checkbox to the metaball shader; flips one term in the shader (one extra uniform).
- Wall decals deferred — would need a decal projector / persistent texture write — Wave 5.
- The "hidden driver mesh emits source particles" pattern is a generally useful primitive — call it `LumeFluidDriver.cs`. Animate any rig (skeleton, cube, fish), the fluid follows.

3. Optical flow on linearised depth (E460)

Caption 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)".

This is the foundational fix for the two-channel reactivity model from the prior playbook. The "inner color reacts to motion" channel only works if the motion field is linearised — naive depth-buffer differencing has a strong z-near bias because depth values are non-linear.

LUME action item — promote to Wave 1 / Wave 2:
- Our `LumeOpticalFlow` (Wave 3 in rail plan) MUST run on linearised depth, not raw depth-buffer deltas.
- Linearise: `linear_z = nearfar / (far - depth(far-near))` (standard inverse-projection).
- Then optical flow (Lucas-Kanade or simple frame-diff) on the linearised field.
- Without this fix, particles right next to the camera will over-react and far particles will look dead.

4. Twin-mesh nested marching-cubes surfaces (E427)

Caption verbatim: "2 meshes reconstructed: inner gold uses larger surface threshold than outer glass."

Same source-particle field, two different threshold values fed into Keijiro's compute MC. Higher threshold = smaller surface = inner shell. Lower threshold = larger surface = outer envelope. Render outer with refractive glass material, inner with metallic gold. Result: glass shell over gold core, both responding to the same fluid sim.

LUME mapping: when we ship URP screen-space SDF metaballs (Wave 5), add a `_InnerThreshold` and `_OuterThreshold` parameter and render two passes. Cheap visual win.

5. Audio-driven 2D fluid sim flip-board (E421)

Caption: "Liked the 2-tone white/gold look and the flip motion … driven by the fluid sim. Seems like most things I make end up going through the fluid sim at some point or other lol."

Important: this is his self-disclosure that the fluid sim is his universal middleware. Anything physical/dynamic in his system goes through the 2D screen-space fluid sim, even when the surface output is a flip-dot grid (boolean per cell), particles, ribbons, or metaballs.

LUME architectural takeaway: treat `LumeFluidSim2D` as a shared service, not a per-effect component. Optical flow / audio impulses / depth motion all feed the fluid; each VFX preset reads from the fluid as input. This matches his quote and matches our existing rail plan track for fluid (StableFluids fork).

6. Twisty Ribbon VFX-Graph port — instanced-mesh → VFX-Graph migration (E415)

Caption: "As current lookdev not using raytracing, I ported the instanced mesh ribbon to vfxgraph and it ran a lot faster! … 2x systems with 150,000 meshes each on a laptop 3070."

Two foundational facts:
- He abandoned raytracing for the install lookdev. Stays rasterised. Confirms our URP/HDRP-without-RT plan is correct for parity.
- His VFX-Graph density: 2 × 150k = 300k mesh particles on a 3070. So our Mac5 M4 / Beelink x86 budget should clear ≥ 100k particles comfortably; aim 100–200k as the LUME ceiling.

7. Boundary-conditioned screen-space fluid sim (E466)

Caption: "Metaball source particle motion fed from screen space fluid sim with boundary conditions so you can get some nice water-bending swirly stuff going on."

The boundary conditions matter — he's not running an unbounded sim. Walls of the LED stage become reflective boundaries for the 2D fluid grid; particles bounce/swirl rather than escape. Without boundaries, the recent E444 caption ("motion feels too high … source particles leave screen, collision to keep on screen might help") shows the failure mode he later fixed.

LUME action: when we wire the 2D fluid sim, set Dirichlet/reflective boundaries at the screen edges (or display-region edges in multi-screen). Don't ship a torus-wrap or open boundary.

---

6. Twisty Ribbon VFX-Graph port — instanced-mesh → VFX-Graph migration (E415)

_From `lume-duncan-playbook-chunk-DR-DQ.md`_

Caption: "As current lookdev not using raytracing, I ported the instanced mesh ribbon to vfxgraph and it ran a lot faster! … 2x systems with 150,000 meshes each on a laptop 3070."

Two foundational facts:
- He abandoned raytracing for the install lookdev. Stays rasterised. Confirms our URP/HDRP-without-RT plan is correct for parity.
- His VFX-Graph density: 2 × 150k = 300k mesh particles on a 3070. So our Mac5 M4 / Beelink x86 budget should clear ≥ 100k particles comfortably; aim 100–200k as the LUME ceiling.

---

Risks / open questions

_From `lume-duncan-playbook-chunk-DR-DQ.md`_

1. Compute thickness is HDRP-only. Confirmed across E461/E462/E468/E470. URP doesn't ship the same compute-thickness pass. Either (a) post-Sat HDRP migration, or (b) approximate with screen-space SDF distance-from-edge in URP — the inverse-thickness mode (E468) is approximable, the core-glow mode (E462) is harder. Decision still deferred to post-Sat.
2. He has an LED CAVE-like volume. Multiple Gemini analyses (E460/E466/E472) flagged "LED-backed XR stage" / "CAVE-like setup" as the deployment target. LUME ships single-monitor / 1-3 vertical monitors. Particle scale, FoV, and reflection probe positioning will need re-tuning — probes calibrated for 360° walls won't make sense for a single panel.
3. Reflection probes are 6-face per frame (E460). On a single panel install we don't need 6 faces — drop to 1-face planar reflection probe (already aligned with our existing planar-reflection plan).
4. 2x150k VFX-Graph particle systems (E415) is on a 3070 (8GB VRAM) — Mac5 M4 has 16GB unified; should clear comfortably. Beelink K8/SER7 with iGPU will not — confirm we're targeting discrete-GPU x86 mini-PCs (the BOM pivot already moves us to GMKtec K8 Plus etc., but verify VRAM for VFX-Graph load).
5. Marching Cubes (Keijiro) is the canonical fork — already in our Evo3 explore-findings. Reconfirm.

---

v1 vs v2

_From `lume-duncan-playbook.md`_

v1 (this file as of earlier 2026-04-25, 161 lines): 12 most-recent reels (E579-E606, 1 month coverage), 3 Gemini analyses. Established the two-channel reactivity philosophy and v1 VFX Editor data model.

v2 (this file now): 72 reels (E415-E606, ~2 years coverage), 20 Gemini analyses, source data from 4 chunks aggregated. Adds 2 years of foundational architecture decisions Duncan stopped re-explaining in his recent reels: shader parameter values, complete preset taxonomy, target hardware, calibration system, Holovis commercial brand.

If the granular per-chunk evidence is needed, it stays on disk:
- `lume-duncan-playbook-chunk-DV-DU.md` (E485-E570, 20 reels, 5 visual analyses)
- `lume-duncan-playbook-chunk-DT-DS.md` (E475-E521, 20 reels, 4 visual analyses)
- `lume-duncan-playbook-chunk-DR-DQ.md` (E415-E474, 20 reels, 8 visual analyses)

This file is the canonical synthesis. Step 3 (creative:forge) should read this; chunks are authoritative for verbatim quotes and Inspector dumps.

---

Source data

_From `lume-duncan-playbook.md`_

• 161 reels enumerated via gallery-dl from `instagram.com/duncan.fewkes/reels/`
• 72 most recent reels ingested (E415-E606, ~2 years coverage), captions saved
• 20 Gemini multimodal visual analyses on visually densest reels — Inspector / UI / shader panels visible in 8 of them
• Reels cached at `[home]/.openclaw/browser/reels-ingest/{shortcode}/`

---

File locations

_From `lume-duncan-playbook.md`_

• Cached MP4s: `[home]/.openclaw/browser/reels-ingest/D{X,W,V,U,T,S,R,Q}/.mp4`
• Caption JSON: same dirs, `*.info.json`
• Gemini visual analyses: `[home-path]`
• Full URL list (161 reels): `/tmp/duncan_reels.txt`
• Top-72 ingested across 4 chunks: see chunk files for granular shortcode lists
• Per-chunk verbatim evidence (read these for direct quotes / Inspector dumps not summarized here):
• `lume-duncan-playbook-chunk-DV-DU.md` (E485-E570)
• `lume-duncan-playbook-chunk-DT-DS.md` (E475-E521)
• `lume-duncan-playbook-chunk-DR-DQ.md` (E415-E474)

---