docs(parity): scene144 bloom parity ceiling investigation (ON HOLD)

[RaananW]

⏸️ ON HOLD — awaiting maintainer decision. Do not merge. No guardrail change applied.

The branch contains no ceiling change — the proposed 0.07 → 0.072 edit was reverted, so this PR is now a documented investigation only (net-zero diff vs master). The maintainer has chosen to hold; the 0.072 widen is not approved and not rejected on the merits.

Options on the table for the record:

• (a) widen scene144 maxMad to ~0.072 with the justification below, or
• (b) commit a fixed golden PNG for scene144 — but this trades away the live BJS↔Lite parity signal (the gate would become Lite-vs-frozen-golden instead of a true two-engine comparison).

This is a standalone, pre-existing issue on master, independent of the dependency PRs (#374 / #376). Note: #374's parity gate is currently red solely because of this ceiling sitting flush at the quantization floor.

---

Root cause

scene144's parity gate has no committed golden (reference/**/babylon-ref-*.png is gitignored), so every run captures a live Babylon.js reference and compares it against the live Babylon Lite render on the same renderer — a genuine two-engine comparison.

The two independent WebGPU float pipelines computing a full-screen, multi-pass Gaussian bloom differ only at the 8-bit quantization floor:

Metric	Value
Pixels exact match	92.1%
Within 1 LSB	97.2%
Within 2 LSB	99.6%
Share of MAD from ≤2-LSB gradient rounding	71%

MAD is measured in 0–255 space, so 0.07 means an average per-channel difference of 0.07/255 ≈ 0.03% — essentially pixel-perfect. The residual is dominated by unavoidable ±1–2 LSB rounding across the smooth bloom gradient, which quantizes differently between renderers.

Why it's an inherent floor, not a closable bug

• Bloom params (threshold 0.1, weight 2, kernel 64, scale 0.5) and the extract/blur/merge math already match the BJS reference (bjs/scene144.ts) exactly.
• The BJS engine uses antialias: true. I tried mirroring that by rendering the Lite source into a 4× MSAA target and resolving before bloom — parity got 4× worse (MAD 0.309), proving BJS's bloom input is effectively single-sample and the current single-sample Lite config is already the closest match. There is no closable algorithmic drift.

Measurements (deterministic, zero run-to-run variance)

The scene is fully deterministic (frozen animation frame 180, fixed camera). The only variable is the renderer's float rounding:

Environment	MAD	vs ceiling 0.07
Hardware GPU (local, ×3 fresh-golden runs)	0.0700043	+4.3e-6
CI SwiftShader (cloud)	0.0700051	+5.1e-6

The 0.07 ceiling was calibrated right at this floor with no headroom, so deterministic cross-renderer rounding on a handful of pixels tips it over. CI's SwiftShader is deterministic, hence the identical failure across independent cloud runs.

Recommendation (for whenever the hold is lifted)

Option (a): widen maxMad to 0.072 — ~2.8% over the observed floor, still orders of magnitude below any genuine bloom regression (a wrong weight/threshold/kernel moves MAD by ≥ 0.1, not millionths). Held pending maintainer sign-off.

[bjsplat]

Lab - Static Site

Open deployed site

_{Build 20260707.22 - merge @ 010e9bd}

[bjsplat]

📋 perf — Test Report

View full Playwright report

_{Build 20260707.26 · merge @ 010e9bd}

[Copilot]

Pull request overview

This PR proposes widening the parity MAD ceiling for scene144 (bloom post-process) by updating the per-scene threshold in scene-config.json, and adds an inline justification note intended to document why the ceiling change is being requested.

Changes:

• Increase scene144 maxMad from 0.07 to 0.072.
• Add a note field to the scene144 config entry describing the justification and marking the change as pending approval.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bjsplat]

Lab - Static Site

Open deployed site

_{Build 20260707.26 - merge @ 010e9bd}