acdream/docs/research/2026-05-26-a8-rr0-falsification-findings.md

A8 RR0 falsification — are Issues A and C pre-existing or A8-caused?

Date: 2026-05-26 (PM) Method: three-branch launch + visual repro at Holtburg cottage entry / exit transitions.

Observations

Branch	Commit	Issue C (entry transparent floor)	Issue A (exit through-ground / walls missing)	#78 (constant houses-below-terrain visible from inside)
HEAD	2bfeafd (R3.5 v2)	YES	YES (varies by building)	(gone — R1+R2+R3 fixed)
R3 baseline	60f07bc	YES	YES (same as HEAD)	(gone — R1+R2+R3 fixed)
main	7034be9	NO	NO flicker — but DIFFERENT SYMPTOM: houses below terrain visible from inside, constant (not transition)	YES, constant

User screenshots from HEAD captured during the spike:

1. Cottage interior: floor partly see-through to outdoor grass; misplaced textured panel visible
2. Cottage exterior: brown floor/wall panel floating in space; surrounding building walls missing

User quote on main observation:

"No floor is not transparent." "When I now stand in the cottage and look out I can see houses below the terrain. There is no flick when I pass out. They are just visible all the time"

Diagnosis

Issues A and C are NOT pre-existing. They are caused by R3 (the stencil pipeline wire-in):

• R3 successfully closes the original #78 symptom (constant houses-below-terrain visibility from inside) ✓
• R3 introduces two new artifacts as side-effects:
  • Issue C — cottage floor transparent showing cellar during entry transition
  • Issue A — through-ground objects + walls-missing flicker during exit transition

The R3.5 v1+v2 patches were attempts to mitigate, didn't help (R3 baseline and HEAD show identical A+C symptoms).

Decision

Per the design's decision gate at RR0-S5:

• Outcome 2 selected: Only R3 + HEAD reproduce → A and/or C caused by R3 work specifically. PAUSE the plan. Re-brainstorm via superpowers:brainstorming to address them; update the design doc; resume.

The original restructure design assumed Issues A and C might be pre-existing and could be filed as separate out-of-A8-scope issues. RR0 invalidates that assumption. The restructure must address them OR accept that A8 trades one bug class for another (which the user has not approved).

Open questions for the re-brainstorm

1. Mechanism of Issue C (entry transparent floor): what about R3's stencil work makes cottage floor transparent during entry? Hypotheses:

   • Stencil bit 1 set on portal silhouettes but cleared next frame; during the entry the camera-cell hadn't yet promoted, so VisibleCellIds was empty, so MarkAndPunch had no portals to mark → outdoor pass effectively ungated, terrain re-draw beats indoor cell mesh at the floor pixels.
   • Depth-clear-if-inside firing too early or too late, leaving the depth buffer in a bad state.
   • The cottage cell's mesh + the cellar cell's mesh both included in IndoorPass at adjacent Z values, Z-fight is fundamental.

2. Mechanism of Issue A (exit through-ground flicker): during grace frames after exit, cameraInsideCell=true but cameraReallyInside=false. Sky skipped, terrain drawn, depth-clear skipped, stencil branch skipped, outdoor Draw(All) runs. Why do entities below terrain win the depth test in these specific frames?

3. Will the WB-faithful restructure help, hurt, or be neutral on A and C? The restructure removes the depth-clear and initial-terrain workarounds. During grace frames after exit, it gates terrain on !cameraInside (true since cameraInside is strict). So terrain DRAWS unconditionally during grace (because !cameraInside = !false = true → draws). Behavior identical to main during these frames → likely re-introduces #78 main symptom for ~3 grace frames after exit. Trade-off: 3 frames of #78 vs 3 frames of Issue A.

4. Should we shorten or eliminate the cell-switch grace mechanism? Currently 3 frames. If 0 frames, the gate flips strict and cleanly at the threshold. PointInCell epsilon (0.01f) provides minimal hysteresis but might be enough.

5. Is there a third option between "stencil pipeline gates outdoor visibility" (causes A+C) and "no stencil work" (causes #78)? Possibilities:

   • Stencil work but with different cell-set scoping (only camera-cell's portals, not BFS-extended; already in R3).
   • Hybrid: stencil-gate outdoor scenery but NOT terrain (let terrain draw unconditionally + accept #78 leak for terrain only).
   • Frame-based heuristic: skip stencil for first N frames after entry/exit to mask the transition artifact.

Logs

• launch-a8-rr0-head.log / launch-a8-rr0-head-take2.log / launch-a8-rr0-head-take3.log — HEAD launches (2bfeafd)
• launch-a8-rr0-r3.log — R3 baseline launch (60f07bc, GameWindow.cs single-file checkout)
• launch-a8-rr0-main.log — main launch (7034be9, side worktree at .claude/worktrees/tmp-main-baseline with WorldBuilder ref junction)

Cleanup performed

• Restored HEAD's GameWindow.cs in this worktree (no working-tree changes left)
• Removed Windows junction tmp-main-baseline/references/WorldBuilder → strange-albattani-3fc83c
• Removed side worktree .claude/worktrees/tmp-main-baseline