D236 pass 13: live capture demotes draw-order theory, redirects to tree-card fog

User played live with GE_D236ORDER=1, walked toward Surface1's tree line;
wall bug still reproduced. Tree-card count reached 121 tris (vs 2-4 in
deterministic boot), and draw order flips favorably at high counts (tree
drawn last, as pass 12's theory needed) -- but the bug persisted anyway in
that same zone, demoting draw-order as the dominant cause.

Redirects to a lead D280 flagged but never closed: the tree class's own
fog computation (bimodal 25/255 per vertex, never verified against N64,
unlike the noise class's fog which D280 already confirmed correct). Not
attempted this pass -- next session's starting point.

Not v0.3.0-blocking, parked again per standing user priority.

docs/dev/findings.md

@@ -539,7 +539,7 @@ covers D24–D69; the log continues in §H (D32 procedure, D70–D121).
 | D233 | **All levels (intermittent): indoor level geometry invisible near doors — you can see through walls/floors into rooms you can't see into, while world objects…** — full `## D233` entry at file tail | **FIXED + VISUALLY VERIFIED (M-107 fix, M-108 verify).** See the other D233 row for full detail. |
 | D234 | **Dam: guard towers along the dam structure invisible except the first one (M-106, user QA report).** — full `## D234` entry at file tail | **VISUALLY VERIFIED FIXED (M-108), mechanism unexplained.** See the other D234 row for detail. |
 | D235 | **Wrong textures load after dying/restarting a level — not Facility-specific, seen on multiple levels (M-106, user QA report; clarified same session).** — full `## D235` entry at file tail | OPEN — needs: does it repro on a *fresh* level boot (rules out reload-state) vs only after death/restart (confirms it); which surfaces; a screenshot.… |
-| D236 | **Surface 1: 2D billboard trees render as a wall/sheet of tree texture instead of discrete camera-facing tree sprites (M-106, user QA report).** — full `## D236` entry at file tail | OPEN, twelfth pass (2026-09-18) — new mechanism found (both competing texture classes are Z_UPD=0 decals, so on-screen precedence is draw-order not depth) and headless repro finally reproduced the exact bug visually, but the bugged camera position has zero tree-class triangles present, so the new mechanism can't be tested there; still blocked on live CPU-side tree-instantiation data. Not v0.3.0-blocking, parked again. |
+| D236 | **Surface 1: 2D billboard trees render as a wall/sheet of tree texture instead of discrete camera-facing tree sprites (M-106, user QA report).** — full `## D236` entry at file tail | OPEN, thirteenth pass (2026-09-18) — live capture (user walked toward the tree line, `GE_D236ORDER=1`) reached 121 tree-card tris with favorable draw order, yet the wall bug still reproduced — demotes pass 12's draw-order theory, redirects to the tree class's own unverified fog computation (bimodal 25/255, never checked against N64) as the more promising lead. Not v0.3.0-blocking, parked again. |
 | D237 | **QoL ask (M-106, user QA): F10 options overlay — make it scrollable with the mouse wheel, expose more settings into it (e.g. screen-flash / no-hit-flash…** — full `## D237` entry at file tail | OPEN — not designed; port-only |
 | D238 | **QoL ask (M-106, user QA): mouse sensitivity rework toward normal PC-shooter feel.** — full `## D238` entry at file tail | OPEN — not designed; port-only (`port/src/input.c` + `config.c`) |
 | D239 | **QoL ask (M-106, user QA): click-to-lock vs always-grab parity.** — full `## D239` entry at file tail | CLOSED — executed in the v0.2.0 prep pass (port-only)… |
@@ -10908,6 +10908,16 @@ Built `GE_D236ORDER` (`port/fast3d/gfx_pc.cpp`, `gfx_sp_tri1`, env-gated, zero c
 
 **Next pass, concrete (supersedes the "correlate against D280" step above, still valid but now sharper):** a live human session, `GE_D236ORDER=1` set, walking directly toward the tree line from inside the level (not the deterministic boot's opening corridor) is now the single most informative next capture — it would show, in one run: (a) does the tree-card count reach anything near D280's ~720 figure at this camera position, and if so (b) is `GE_D236ORDER`'s per-frame order relationship consistently noise-after-tree (bad) or tree-after-noise (fine) once real geometry is present. That single data point would finally either confirm or rule out the decal draw-order mechanism as the actual fix target, something no headless capture has been able to test in three sessions running. **Not v0.3.0-blocking, per standing user priority** — recommend parking again rather than rushing an unverified fix under release-timeline pressure. `GE_D236ORDER`/`GE_D236ZFIX` left in tree, env-gated, zero behavior change when unset.
 
+**Pass 13 (2026-09-18, same session): the requested live capture landed, and it demotes the draw-order mechanism rather than confirming it — the more promising remaining lead is the tree class's own fog, not draw order.**
+
+User played live with `GE_D236ORDER=1` set, walked toward Surface1's tree line, and confirmed the wall bug still reproduces (`scratch/d236_live_capture.log`, 2024 `D236ORDER` lines). Real data at last: tree-card count reached up to **121 triangles** (still short of D280's old ~720, but far beyond the deterministic boot's 2-4 — confirms the boot genuinely undersamples this class, not that it's absent from the level). More importantly: **the draw-order relationship is distance-dependent** — at low tree counts (6-12 tris, farther away) the noise class is consistently drawn *after* the tree class (bad order, matches pass 12's theory); at high tree counts (100+, closer) this **flips** — the tree class is consistently drawn *after* the noise class (good order, trees should win the color buffer).
+
+**The decisive fact: the user still saw the wall bug while walking through the zone where tree count was high AND draw order favored the trees.** If pass 12's decal-ordering mechanism were the dominant cause, the bug should have resolved (or visibly improved) exactly in that zone — it didn't. **Conclusion: draw order is real (confirmed twice now, in two different measurement contexts) but is NOT the dominant cause of the reported symptom** — something else is preventing the tree cards from reading as discrete trees even when they have substantial triangle count and favorable draw order.
+
+**Redirects the investigation to a lead D280 flagged but never closed: the tree class's own fog computation, not the noise class's.** D280's fog-math verification (`## D280` above, step 1) proved the *noise* class (`0xc81049d8`)'s fog is N64-faithful — it never checked the *tree* class (`0x0c184b50`)'s own fog, which D280's own census separately found to be a strange bimodal 25/255 split per vertex (`gfog=0`, CPU-baked, not RSP-computed). A tree card drawn correctly on top of the noise (as the live data now shows happens at close range) but rendered with fog=255 (fully white-washed) would look exactly like a blank/hazy patch of "wall," not a tree — consistent with the reported symptom persisting despite correct geometry and order.
+
+**Not attempted this pass — genuinely the next step, not a rehash:** trace `0x0c184b50`'s own per-vertex fog computation (where it's set, CPU-side vs RSP, and against what reference distance) and compare it to what N64 would compute for the same vertex positions. This is a different code path than D280's already-verified noise-class fog check and hasn't been looked at directly. Given the depth of this investigation (13 passes) and the release timeline, **recommend keeping this parked for v0.3.0** — the mechanism is narrowed further than ever, but not yet a safe, confident fix. `GE_D236ORDER`/`GE_D236ZFIX` remain in tree, env-gated, zero cost when unset; the live capture log is preserved at `scratch/d236_live_capture.log` for whoever picks this up next.
+
 ## D237 — QoL ask (M-106, user QA): F10 options overlay — make it scrollable with the mouse wheel, expose more settings into it (e.g. screen-flash / no-hit-flash…
 
 **QoL ask (M-106, user QA): F10 options overlay — make it scrollable with the mouse wheel, expose more settings into it (e.g. screen-flash / no-hit-flash `Game.NoHitFlash`, and other easily-exposed config keys), and organise rows by category (mouse settings together, video together, etc.).** The overlay (`port/src/optionsoverlay.c`) already renders over the registered `config.c` option list; what's missing is wheel-scroll nav, a broader row set, and grouping headers. Cross-ref `OPTIONS-MENU-PLAN.md` §3 (v1 minimum set) + QOL-INVENTORY "PD has, GE lacks".