Grand Diomande Research · Full HTML Reader

E460 — Duncan Fewkes reel analysis digest

The prior chunk caught his recent product surface (VFX Editor, two-channel audio+motion reactivity, sunset preset, bullet-time/clones). This chunk catches the **rendering tech** under the surface:

Embodied Trajectory Systems research note backlog reference score 24 .md

Full Public Reader

E460 — 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 E460. Sections are de-duplicated by heading.

Big picture additions to the prior playbook

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

The prior chunk caught his recent product surface (VFX Editor, two-channel audio+motion reactivity, sunset preset, bullet-time/clones). This chunk catches the rendering tech under the surface:

1. The product is called "HOLOVIS" — that's the brand text rendered as 3D letters in nearly every install demo. It's not a placeholder. The letters are the payload object of his rendering: blendshape inflated by audio, reflection probe hit-target, particle attractor, light source. Treat HOLOVIS_LETTERS as a first-class object in his architecture, not chrome.
2. Target hardware = Quadro A6000 @ 60fps (E470 caption verbatim: "Target hardware is Quadro A6000 at 60 fps"). His laptop dev box is a 3070. This sets the LUME perf target ceiling — A6000 ≈ RTX 4080. Anything we plan that wouldn't run on a single 4080 at 60fps is over-budget for parity.
3. The calibration grid IS the LED stage UI — the gridded floor + walls + circular degree-marked "calibration markers" you see in every recent reel are actually his runtime spatial reference, used for depth-camera reprojection and multi-screen LED alignment. Not just decoration. He runs an "LED-backed XR / CAVE-like volume" (Gemini on E460/E466/E472).
4. Two render-mode profiles ship together (E473 visual analysis): `tint Lights, No Shadows` (160-170 fps, ambient/emissive only) and `Spot Lights, Shadows` (70-110 fps, cast shadows from 7x point/spot lights). Operator can A/B at runtime. Add to LumeVfxEditor: a `LightingProfile` dropdown with at least these two modes — fast/cheap and full/cinematic.
5. Reflection-probe budget: realtime reflection probe render every frame across 6 faces is a known toggle (E460 caption) — adds depth/colour but he calls it "as an option toggled in settings." Same toggle slot in LUME.
6. Depth-camera kaleidoscope is a discrete VFX preset he calls out explicitly (E469 first introduces it, E471 adds metallic vs non-metallic, E472 stretches to full body). Net new mode for LUME not in the prior playbook.
7. Marching Cubes is Keijiro's, confirmed (E427 caption verbatim: `https://github.com/keijiro/ComputeMarchingCubes`). Source particles → MC compute shader → mesh. He runs 2 surface thresholds simultaneously to get nested skins (inner gold, outer glass).

---

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.

---

3. Optical flow on linearised depth (E460)

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

---

Architecture details revealed in UI panels (visible in 8 analyses)

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

Top-left "Media Player" panel (E460, E473 visible)

His runtime UI has a top-left media player widget with:
- play/pause/skip/forward/rewind buttons
- volume slider (0–100)
- track title text (Galvanize - Chris Lake / Godzilla Dub / etc.)
- progress bar
- a separate vertical slider (use unclear — possibly master VFX intensity)

LUME UI takeaway: he treats music as part of the install state, not just background audio. Track title is shown on screen during demos. We should make the audio source first-class in `LumeVfxEditor` — not just an audio reactor input but a transport (play/pause/skip) so the operator can sync demos.

Top-right performance overlay (E473 verbatim)

`avg min max fps` and `ms` per-frame: e.g. `58 77 270 fps` / `5.2 ms`. Visible during demos.

LUME: ship a Prometheus-style FPS+ms HUD toggle. He keeps it on during dev/perf-testing. We should add an `F8` toggle in the VFX Editor.

Recording indicator (E460)

Top-right red `00:00:xx` recording timer + blue play icon + white sound icon. Implies internal screen-recording is built into the install runtime so he can capture demos without external OBS.

LUME enhancement (Wave 4): add `LumeRecorder.cs` that writes 4K MP4 to disk on operator hotkey. Would massively improve demo-clip turnaround for marketing/social.

Lighting mode toggle (E473 text overlay verbatim)

Two named modes: `tint Lights, No Shadows` and `Spot Lights, Shadows`. Visible as on-screen text overlay during the demo.

LUME mapping: `LumeVfxEditor.LightingProfile` enum:

csharp

public enum LumeLightingProfile {
    EmissiveOnly,    // no shadows, fastest
    SpotShadows,     // 7x cast shadows, "cinematic"
    PointShadows,    // off — too expensive even on his target HW
}

---

Top-left "Media Player" panel (E460, E473 visible)

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

---

Recording indicator (E460)

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

Top-right red `00:00:xx` recording timer + blue play icon + white sound icon. Implies internal screen-recording is built into the install runtime so he can capture demos without external OBS.

LUME enhancement (Wave 4): add `LumeRecorder.cs` that writes 4K MP4 to disk on operator hotkey. Would massively improve demo-clip turnaround for marketing/social.

---

Updated wave plan deltas

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

Revisions to the prior playbook's wave plan based on this chunk's findings:

### Wave 1 (Sat demo) — additions
- Linearise depth before any motion / optical-flow consumer (per E460). Even if optical flow itself is Wave 3, the calibration system that produces depth-textures should already linearise. One-line shader change in `LumeDepthReprojection`.
- Bound the 2D fluid sim (per E466 / E444). Reflective wall conditions at LED-region edges.

### Wave 2 — additions
- `LumeVfxEditor.LightingProfile` enum (EmissiveOnly / SpotShadows). Default to EmissiveOnly for floor-show, SpotShadows for "cinematic" set pieces.
- Top-left media-transport widget (track title, play/pause, progress).
- F8 perf HUD toggle.
- VFX-Graph particle ceiling: target 100–200k on Mac5 / Beelink (his ceiling on 3070 was 300k).

### Wave 3 — additions
- `LumeFluidDriver` primitive: any rig (mesh / bone / point) emits source particles into the fluid grid. Replaces the "depth pixels are the only fluid source" assumption.
- `LumeKaleidoscope.cs` preset (depth silhouette + N-fold rotation, chrome/matte toggle). Net new visual mode.

### Wave 4 — additions
- `LumeRecorder.cs` — internal 4K MP4 capture on operator hotkey.
- Lighting profile per-preset overrides.

### Wave 5 — additions
- Twin-mesh nested MC surfaces (`_InnerThreshold` + `_OuterThreshold`) for glass-over-gold pattern.
- Inverse-thickness checkbox on metaball shader (alpha ∝ 1−thickness, emissive ∝ (1−thickness)^k).
- Audio-reactive blendshape on logo mesh + tight power-curve emission gating.
- Wall-decal projector on fluid intersect (deferred from Wave 5 of prior plan; same wave).

---

Wave 1 (Sat demo) — additions

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

Linearise depth before any motion / optical-flow consumer (per E460). Even if optical flow itself is Wave 3, the calibration system that produces depth-textures should already linearise. One-line shader change in `LumeDepthReprojection`.
Bound the 2D fluid sim (per E466 / E444). Reflective wall conditions at LED-region edges.

---

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.

---

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.

---

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

---

Linearise depth before any motion consumer (E460 verbatim)

_From `lume-duncan-playbook.md`_

---

Architectural primitives (extracted from his patterns)

_From `lume-duncan-playbook.md`_

The chunks revealed several primitives Duncan implements as separate classes/services. LUME should adopt the same:

### `LumeFluidSim2D` — universal middleware (E421 verbatim)
> Most things I make end up going through the fluid sim at some point or other lol.

Treat as shared service, not per-effect component. Optical flow / audio impulses / depth motion / wordmark blendshape all feed the fluid; each VFX preset reads from the fluid as input. Confirms our Evo3 explore-findings recommendation to fork StableFluids.

### `ILumeSpawnSource` — leapfrog his TODO (E536 verbatim)
> 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.

He flagged this as architectural TODO he hasn't shipped. LUME builds it from day 1:

csharp

interface ILumeSpawnSource {
    Texture2D GetSpawnMaskSDF();    // signed-distance source
    Vector3 GetWorldOffset();
    float GetIntensity();
}
class DepthPointCloudSource : ILumeSpawnSource { ... }
class LogoSDFSource : ILumeSpawnSource { ... }
class MetaballSDFSource : ILumeSpawnSource { ... }
class PaintingMaskSource : ILumeSpawnSource { ... }
// Compose multiple via union/intersection

Explicit advantage over copying his current impl.

### `LumeFluidDriver` — animatable source rig (from E468 hidden blue-fish pattern)
Any rig (skeleton / cube / fish mesh) emits source particles into the fluid grid. Animate the rig, fluid follows. His pattern for "getting the metaball fluid sim to follow a path."

`LumeMotionGatedFluidSim` — SuperHot + FreezeVelocityField modes (above)

### `LumeWordmarkInflator` — audio-reactive blendshape feeding fluid sim (E489)
- BlendShape inflation driven by FFT bands
- Inflation generates motion vectors → fluid sim
- Tight power-curve emission gating (`pow(thickness, k)`, k=6-10)

`LumeKaleidoscope` — 16-clone radial ring (E475-E479, E469-E472)

### `LumeRecorder` — internal 4K MP4 capture on operator hotkey (E460 has built-in recording indicator)
Massively improves demo-clip turnaround for marketing/social.

### `LumeFluidPhysicsRules` — drop-physics rules (E488)
- Disable depth-buffer self-collision when particles cast shadows
- Pure gravity+collision = boring; ALWAYS layer fluid-sim kick + turbulence
- Couple sim systems unidirectionally — "pick one direction" or feedback loop

---

`LumeRecorder` — internal 4K MP4 capture on operator hotkey (E460 has built-in recording indicator)

_From `lume-duncan-playbook.md`_

Massively improves demo-clip turnaround for marketing/social.

---

Updated wave plan (v2 — supersedes v1)

_From `lume-duncan-playbook.md`_

Wave 1 (Sat demo, ship-blocking) — keep tight, only adopt cheap items

Two-channel reactivity scaffolding in `LumeAudioReactor.cs` (carry over from v1):
`OutlineFlash` uniform (audio RMS + beat-threshold step)
`InnerSpread` uniform (placeholder = 0 until Wave 3 optical flow lands)
NEW Wave 1 adds from v2:
4 EQ'd frequency bands (bass / low-mid / high-mid / treble), NOT just RMS+3 — drives position offsets directly, not force
EQ before auto-gain (or fixed dynamic range)
Audio transient channel ("overamp" — separate from RMS, drives velocity-kick AddForce in VFX Graph)
Per-particle hue-shift by speed — cheap shader patch (`hue += speedScalar * shiftAmount`)
Performance HUD overlay (avg/min/max/ms FPS top-right) — visible during Sat demo helps detect frame drops live, F8 toggle
Linearise depth in `LumeDepthReprojection` — even though optical flow is Wave 3, the calibration layer should already linearise (one-line shader change)
Bound the 2D fluid sim — reflective Dirichlet boundaries at screen edges
Mic-capture as dev default (already P1 from chain:genesis, now confirmed by Duncan's E504/E521 pattern)
Lighting: warm directional + neutral fill (closer to "sunset" preset than cold studio)

Wave 2 — VFX Editor scaffolding (post-Sat)

Build `LumeVfxEditor.cs` with 9 slots + 15+ enums (see complete data model above)
Every preset enum's last entry = `None`
6-preset FluidSim taxonomy by literal name: Default / Default_Smooth / LongThrow / MidThrow / ShortThrow / InvertedObstacle
`LumeSettingsMenu.cs` — separate operator panel (Calibration / Camera / Motion / Performance / Audio + Setup save/load)
`[home-path]` per-install settings file
`LightingProfile` enum (EmissiveOnly / SpotShadows) — runtime A/B
Top-left media-transport widget (track title, play/pause, progress)
VFX-Graph particle ceiling: target 100-200k on Mac5 / Beelink (his ceiling on 3070 = 300k)
Pinscreen mesh (cube-grid, instanced, vertex displaced by depth+dye) — clean alternative to point-cloud
`ILumeSpawnSource` interface from day 1 with `DepthPointCloudSource`, `LogoSDFSource`, `MetaballSDFSource`, `PaintingMaskSource`
`LumeWordmarkInflator.cs` — audio-reactive blendshape feeding fluid sim + tight power-curve emission gating
Material variants on disk (asset references, not parameter blobs) — drag-drop preset extension

Wave 3 — Spine-bone particles + motion-gated sim (depends on mocopi PRO)

mocopi PRO arrives → 12-bone skeleton stream → particle emitters bound to spine bones
`LumeMotionGatedFluidSim.cs` — SuperHot mode (motion → sim timescale) + `FreezeVelocityField` toggle (frozen velocity buffer mode)
One-euro filter for motion smoothing (name-checked E567; pull a C# impl, don't roll our own)
`LumeOpticalFlow` on linearised depth (E460 promotion)
`LumeFluidDriver` primitive — any animatable rig emits source particles
Wall-spawn / Floor-spawn / MidPlane / CeilingPlane spawn topology enum
Plexus links shader with endpoint-emissive average

Wave 4 — Bullet-time + clones + kaleidoscope + strip particles

Audio-transient-triggered freeze + clone capture
Snapshot timing locked: `holdDuration = 0.25s` + `kGravityEaseIn` curve into gravity
Speed-to-brightness power curve + threshold (live operator dial, no preset)
Camera-spin (full bullet-time) AND screen-warp (no-spin variant) — both modes per install
`LumeKaleidoscope.cs` — 16-clone radial ring with chrome/matte toggle + central reflection probe
VFX Graph particle strips (ribbon particles) with per-strip stiffness, parent→child force propagation
Spectrum-mapped vertical audio response on strips (FFT bin → Y position)
`LumeRecorder.cs` — internal 4K MP4 capture on operator hotkey
Drop-physics rules (no shadow-cast self-collision; always layer fluid kick on top of gravity)

Wave 5 — Metaball / surface-material family + HDRP migration

Either HDRP migration OR screen-space SDF metaball approximation in URP
Material presets: slime, water, energy, chrome, oily — as on-disk material variants, not parameter blobs
Shader parameter dump mirrored: IOR=1.33, Translucency=0.003, Emissions Scale 0.00-0.05, Fresnel default 0.0
Twin-mesh nested MC (`_InnerThreshold` + `_OuterThreshold`) — Keijiro `ComputeMarchingCubes` fork
Inverse compute-thickness mode (alpha ∝ 1−thickness, emissive ∝ (1−thickness)^k) — `Inverse` checkbox on metaball shader
Wall-decal projector on fluid intersect

---

Wave 3 — Spine-bone particles + motion-gated sim (depends on mocopi PRO)

_From `lume-duncan-playbook.md`_

mocopi PRO arrives → 12-bone skeleton stream → particle emitters bound to spine bones
`LumeMotionGatedFluidSim.cs` — SuperHot mode (motion → sim timescale) + `FreezeVelocityField` toggle (frozen velocity buffer mode)
One-euro filter for motion smoothing (name-checked E567; pull a C# impl, don't roll our own)
`LumeOpticalFlow` on linearised depth (E460 promotion)
`LumeFluidDriver` primitive — any animatable rig emits source particles
Wall-spawn / Floor-spawn / MidPlane / CeilingPlane spawn topology enum
Plexus links shader with endpoint-emissive average

---

Promotion Decision

Keep in the searchable backlog until it intersects a live paper or system.

Source Anchor

lume-commerce/hardware/reference/duncan/analyses/E460-noreel.md

Detected Structure

Method · References · Architecture