Screen the capture scenarios for determinism, and correct what rested on one

Routine work on the sharpening lane needed a byte-identity control, so I
checked the baseline against itself first. Three of seven scenarios do not
reproduce run to run with ONE binary:

  overlook-noon, water-lake, water-ocean, fence-shadowline-night   identical
  stormwind-canal-near   bimodal: 7 of 15 pairs identical, rest 0.01% / max 96
  inn-noon, volfog-inn   usually the bottom bit; one pair 37.8% / max 199

`stormwind-canal-near` is the one that matters, because the water-mirror
write-up used it as a byte-identity control and it cannot be one. The identity
measured there was a coin flip that landed well.

The finding it supported still stands, but on its EXTENT and not on the
amplitude it was also quoted at. "0.75% of pixels by up to 96/255" reads as one
observation; it is two, and only the first is evidence. 96 is what the canal's
own flicker reaches with nothing changed at all — the amplitude says nothing.
0.75% against the scene's own 0.01% is 75x, which is the part that was real,
and the run condition is still the right fix.

docs/GRAPHICS.md's harness section now carries the table, so the next person
reaching for a control picks from the first row.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
This commit is contained in:
2026-10-27 17:03:04 -06:00
co-authored by Claude Opus 5
parent 11dda4f9cf
commit 4c3c128594
+27 -4
View File
@@ -50,6 +50,21 @@ A/B cannot tell them apart; `WOW_CVAR_LATE` can. Anisotropy's live path is verif
proves the harness is actually reaching the thing being measured. Five such pairs once matched byte
for byte before anyone checked whether the view read the table at all.
**And check the baseline against ITSELF before using it as one.** Not every scenario reproduces,
and the ones that do not are not obvious from the outside. Screened by rendering each twice with
the same binary and once more over six runs:
| scenario | byte-identical run to run? |
|---|---|
| `overlook-noon`, `water-lake`, `water-ocean`, `fence-shadowline-night` | **yes** |
| `stormwind-canal-near` | **no** — bimodal: 7 of 15 pairs identical, the rest differ on **0.01%** of pixels by up to **96**/255 |
| `inn-noon`, `volfog-inn` | **no** — usually the bottom bit, but one pair came back **37.8%** of pixels at up to **199** |
So a byte-identity claim can only rest on the first row. The second row is the dangerous one: the
canal's own flicker reaches a channel delta of **96**, which is exactly the amplitude a real
finding there was once read at — amplitude alone says nothing, only extent does, and the canal's
own noise is 0.01% of the frame.
## Already shipped and worth spending
These need no code. They are the cheapest picture available today.
@@ -229,8 +244,14 @@ Three defects, in the order they were found:
canal inside the noise; CPU +0.2 to +1.1 ms. It is the first lane here that spends **main thread**,
which is why it is a rung of its own above High rather than part of it, and why the default stays 2.
**Two things it could not be allowed to cost.** With the lane off, both scenarios are
**byte-identical** to the build before it — and getting there took two findings:
**Two things it could not be allowed to cost.** With the lane off, the build is **byte-identical**
to the one before it on `water-lake` — and getting there took two findings. (This was written up
as holding for `stormwind-canal-near` too. It does not, and cannot: the canal is **bimodal between
runs of one binary**, 7 of 15 pairs identical and the rest differing on 0.01% of pixels by up to
96/255 — see the harness section. The identity measured there was a coin flip that landed well.
The finding below still stands on its extent, not on its amplitude: 0.75% of the frame is 75x the
scene's own 0.01%, and the amplitude the two share — 96 — turns out to be the canal's own flicker
and to mean nothing at all.)
- The system could not live in `Update` at all. `&mut Transform` on a camera is shared with
everything that moves anything; declaring it put 59 undeclared orders into `Update` and tripped
@@ -240,8 +261,10 @@ which is why it is a rung of its own above High rather than part of it, and why
the asset handle changed the count by zero.)
- **A system that runs and returns on its first line is still not free.** Holding `&mut Camera` and
`&mut GlobalTransform` for a frame is enough to change which undeclared orders the executor
picks: the canal moved 0.75% of its pixels by up to 96/255 with the lane switched off. So the
whole system sits behind a run condition, not an early return. The same effect killed a
picks: the canal moved 0.75% of its pixels with the lane switched off, 75x the extent of its own
run-to-run noise. So the whole system sits behind a run condition, not an early return. (Read
the EXTENT: the 96/255 this was also quoted at is the canal's own flicker amplitude, which it
reaches with nothing changed at all.) The same effect killed a
`.before(UpdateDirectionalLightCascades)` order that was correct in itself — declaring it moved
the canal's lamp light with the feature off, and what it bought was a half-res rippled
reflection whose shadow cascades fit this frame's pose rather than last frame's.