acdream/docs/research/2026-08-23-vm6-foliage-wind-pixel-proof.md

# VM6 — does the wind move the trees, and only the trees?

**Date:** 2026-08-23 · **Campaign:** VM slice VM6 · **Status:** see the
verdict at the end; the owner's visual gate (plan §VM6 Acceptance) is still
owed regardless.

**Question.** With the built-in `acdream.atmospheric` pack, does the
foliage-wind displacement reach the **production** world geometry, and is it
confined to procedural scenery foliage?

This note records the apparatus that finally answered it, including the
first method that did not — two wrong conclusions were drawn from it before
the confound was found, and both are recorded here so nobody re-derives them.

## Apparatus

Offline pixel gate (`tools/run-offline-pixel-gate.ps1`, Release, `-SkipBuild`,
`-Uncapped`, 1280×720, day group 0 "Sunny" → `WeatherKind.Clear`, day
fraction 0.5, MSAA 0), isolated settings, the fixed offline scene the VM0/VM3
captures use, drawn through `RetailPViewPassExecutor.DrawPackedProductionRoute`
(the production entity route). `-RenderPackPreset high`; `ACDREAM_SKY_PHASE_SECONDS`
pins the pack's per-graph clock so two captures at the same pin see the same
wind phase. Pixel metric: max-channel |Δ| ≥ 8
(`tools/vm6/wind-pixel-proof.py`, numpy).

### Method 1 (confounded — do not reuse): "t0→t3 with wind on, minus t0→t3 with wind off"

The idea was that the clock pin at 0 s vs 3 s moves only the wind, so the
wind-off pair is a control for everything else the clock drives. It is not:
the same binary, same settings, same pin differs run-to-run by **0 or ~280
px**, bimodally, and those pixels are isolated single-pixel flips along the
treeline's leaf edges (`artifacts/vm6amp/churn-crop.png`) — rasterisation
edge flips, not content. Whether the churn lands in the wind pair or the
control pair is luck, so "wind-only" counts of 23 / 314 / 568 / 703 px from
this method on `43e3abed` / `a82959f1` were all within that churn. The
overlay images looked convincing precisely because the churn sits on tree
silhouettes. Two conclusions drawn from it — "the F1 packed-classifier fix
is confirmed by pixels" and "wind reaches the geometry" — were unsupported.
(The F1 fix itself is correct; the round-3 Opus review traced it to the GPU
word by reading, and the round-4 apparatus below confirms geometry motion.)

### Method 2: same pin, wind on vs off, signal amplified, repeats as the floor

Settings `wind-strength = 2`, `wind-lean-metres = 1`, `wind-branch-metres = 1`,
`wind-flutter-metres = 0.5` make the canopy displacement ~1 m — several
pixels even at this scene's treeline distance, where the default Clear wind
(≤ 11 cm lean) is sub-pixel. Two captures per arm; the repeat pairs measure
the floor; the four cross pairs measure the effect.

## Results

### `fccba839` (round 3), `sun-shadow-strength = 0`

| Pair | px ≥ 8 |
|---|---|
| wind-off A vs wind-off B (floor) | 22 |
| amplified-wind A vs amplified-wind B (floor + churn) | 317 |
| amplified A vs wind-off A / B | 65 / 49 |
| amplified B vs wind-off A / B | 284 / 273 |
| robust mask (all four cross pairs, neither repeat pair) | **1** |

A 1 m wind produced nothing. A CPU probe in `ResolveFoliageWind` (removed
after the run) showed the state was right — first advance at serial 2 snaps
to Clear `(0.25, 0.15)`, strength 1, gate on, one graph instance — so the
uniform was correct and the world pass never used it.

**Cause (by reading, round-4 finding):** the wind was welded to "directional
shadows rendered this frame". `DirectionalSunShadowRenderer.Render` left the
frame binding `Disabled` whenever the environment gate said no;
`WbDrawDispatcher.PipelinesFor` then fell back to the plain `mesh_modern`
pipeline, which has no `foliage_wind.glsl` at all; and
`BindDirectionalShadowReceiver` returned early on `!Enabled`. The gate is
`dayGroupPolicy × sunElevationResponse × strength`, so the wind also stopped
every night, at user strength 0 and under the portal cover. Fixed in round 4
by publishing a valid-but-disabled binding (zeroed shadow block, flags 0 —
the receiver shader already returns visibility 1.0 on that bit — plus the
wind frame slice) so the built-in pack's world pass always runs the receiver
pipeline.

### `eec95535` (round 4), `sun-shadow-strength = 0`

| Pair | px ≥ 8 |
|---|---|
| wind-off A vs wind-off B (floor) | 19 |
| amplified-wind A vs amplified-wind B (repeat) | 51 |
| amplified A/B vs wind-off A/B (four cross pairs) | 13,876 / 13,887 / 13,893 / 13,903 |
| **robust mask (all four cross pairs, neither repeat pair)** | **13,854** |
| **default Clear strength vs both wind-off, floor-excluded** | **1,402** (2,655 at |Δ| ≥ 3) |

Per-60-row band of the robust mask: `[8580, 4101, 800, 61, 0, 110, 14, 188, 0, 0, 0, 0]` —
the treeline (rows 0–180), the hillside trees (rows 300–360) and the
shoreline bushes (rows 420–480). Overlays:
`evidence/vm6/eec95535-amplified-wind-vs-off-shadows-off.png` (every tree
and bush red; no house, fence, road, lifestone, ground, water or UI pixel),
`evidence/vm6/eec95535-default-clear-wind-vs-off-shadows-off.png`, the
amplified frame itself `evidence/vm6/eec95535-amplified-wind-frame.png`, and
the Method-1 churn crop `evidence/vm6/method1-run-to-run-churn-crop.png`.

### `754d59d9` (round 5 — gated-off frames light from the authored sun again)

The round-4 narrow review found that round 4's decoupling lit every
shadow-gated-off frame from straight overhead: both receiver vertex shaders
take the sun *direction* from the shadow block, and the disabled block's
`(0,0,1)` guard became the sun. Round 5 makes the receiver verts fall back
to the plain pipeline's `uLights` expression when the flag bit is clear.
Same apparatus, wind-off arm compared across binaries (shadows off, same
pin):

| Pair | px ≥ 8 | mean |Δ| |
|---|---|---|
| `754d59d9` wind-off A vs B (floor) | 65 | 0.002 |
| **`754d59d9` vs `fccba839` (plain pipeline, pre-round-4)** | **277** | **0.007** |
| `eec95535` vs `fccba839` (the round-4 regression) | 32,538 | 1.77 |

Wind on `754d59d9`: robust mask **14,993 px** (amplified), same bands as
round 4.

## Verdict

On `754d59d9` the foliage wind reaches the production world geometry with
the shadow term removed (so it is geometry, not shadow), is 700× the
run-to-run floor when amplified and 70× at the default Clear strength, and
is confined to procedural scenery foliage in this scene. Earlier binaries:
`43e3abed` had no geometry wind at all on the production route (round-2
review F1, confirmed by reading); `a82959f1`/`fccba839` had it only while the
shadow gate was open (round-4 defect); `eec95535` had the wind but lit
shadow-gated-off frames from overhead (round-5 defect).

Commands: `tools/run-offline-pixel-gate.ps1 -Out <dir> -SkipBuild
-RenderPackPreset high -SkyPhaseSeconds 3 -Uncapped
-RenderPackSettingOverrides @{ 'wind-enabled'='true'|'false';
'sun-shadow-strength'='0'; [amplified: 'wind-strength'='2';
'wind-lean-metres'='1'; 'wind-branch-metres'='1'; 'wind-flutter-metres'='0.5'] }`
(Release, two captures per arm as above); analysis
`py tools/vm6/wind-pixel-proof.py <root>` (robust mask = AND of the four
cross-pair masks minus both repeat-pair masks; writes `diff-robust-wind.png`).

## What this does and does not prove

- Method 2 with shadows off isolates geometry motion (no shadow term can
  change), and the robust mask confines it to where the wind model says it
  should be.
- It does not prove the motion *looks* right — amplitude, rhythm and the
  Clear/Rain/Storm table are the owner's call at the visual gate — nor does
  the offline scene exercise weather other than Clear.