acdream/docs/research/2026-06-10-corner-seal-refuted-openings-edgeon-handoff.md

§2b corner "camera-seal" REFUTED — both §4 siblings converge on edge-on clip collapse

Date: 2026-06-10. Branch: claude/thirsty-goldberg-51bb9b. Commits this arc: b21bb28 (corner-seal replay apparatus + characterization). Earlier same day: c4df241 closed the outdoor full-world flap (depth-mask leak — see 2026-06-10-flap-outdoor-fullworld-CLOSED-depthmask-leak.md).

---

0. TL;DR

After the depth-mask fix, the user re-validated the §4 siblings and reported two symptoms: (1) background covering windows/entrances/passages during ALL transition types (room↔room, indoor↔outdoor, cellar↔floor), and (2) background at certain angles when pressing the camera into an interior corner ("like the camera is clipping into the wall").

A fresh [flap-sweep] capture + a dat-backed replay harness settle it:

• The §2b "eye penetrates the wall → camera-seal failure" hypothesis is REFUTED. Every zero-contact camera traversal in the capture runs through a real opening:
  • the viewer-outdoor "escapes" (48 frames) go through 0170's exit-door portal (other=0xFFFF, local x[5.55,7.45] z[0,2.5]) — the player was standing at the threshold (playerCell flickering 0031↔0170);
  • the corner-press frames (player=0172, viewer=0171, 2,963 frames) go through the 0171↔0173↔0172 doorway chain — 0173 is a 20 cm doorway-threshold cell (two parallel portal planes at local x=4.10 / x=3.90). The captured eyes land inside the door-opening rectangle, 0.35 m past the doorway plane.
• Camera collision is healthy: 8,703 of 14,230 indoor sweeps in the same capture collided (pull-in up to 2.77 m, valid normals). Nothing penetrates solid geometry.
• Therefore the corner symptom is render-side: with the eye hovering at/near an opening's plane, the portal's screen projection collapses edge-on, the flood through the opening dies for those frames, and the room/world behind it (often the room the player is standing in) is not drawn → background color. That is the same §2a mechanism as the transition flashes. §4 is now ONE mechanism, not two.

1. Evidence chain

1. Capture: corner-seal-capture.log (untracked, worktree root) — clean run, user did corner presses + doorway passes. Probes: ACDREAM_PROBE_FLAP + ACDREAM_PROBE_PVINPUT.
2. Sweep classification: 17,999 [flap-sweep] frames; 48 player-indoor → viewer-outdoor "escapes", ALL ok=True pulledIn≈0 collNormValid=False; plus the player=0172/viewer=0171 corner population (2,963 frames, same signature).
3. Replay harness: tests/AcDream.Core.Tests/Physics/CameraCornerSealReplayTests.cs (b21bb28) — loads the real Holtburg building cells (0x016F–0x0175), replays the captured sweeps with the camera's exact call shape, reproduces the zero-contact traversals deterministically, and maps the geometry:
   • full portal/room map (printed by the Diagnostic fact): 016F + 0170 carry the exit doors; 0173 is the 0171↔0172 threshold; 0175/0174 are the cellar chain below 0171.
   • containment walk: no point of the "escape" paths lies inside solid cell volume.
   • the assertion fact is now a characterization: those opening paths must pass clean (no collision, full traversal) — pins the verified-correct behavior.
4. SmartBox::update_viewer port verified verbatim against decomp :92761-92892 (including both fallbacks — retail also places the camera at the un-collided sought eye when the sweep fails). No divergence in the camera layer.

2. What this kills (DO-NOT-RETRY — added to the render digest)

• Any "camera-seal" / camera-collision fix for the corner symptom. The camera is right.
• Re-opening the membership/physics side for these symptoms — the digest's #106/#98 exonerations stand; playerCell flicker at thresholds is the player genuinely straddling a portal.

3. NEXT (the §4 fix arc — gated on the retail oracle read)

Per the 2026-06-08 handoff §5.3 (never done): read retail's edge-on clip handling BEFORE designing anything:

• PView::GetClip (0x5a4320, decomp ~:432344)
• PView::ClipPortals (0x5a5520, :433572)
• ACRender::polyClipFinish (the w=0 clip, :702749)

Questions: does retail's clip collapse to zero area at edge-on exactly like ours; does retail keep a flooded cell once added (per-frame hysteresis); what does retail draw for the 1–2 frames the eye is inside a threshold cell (0173-style reveal slab)? Cross-check our PortalProjection.cs at edge-on specifically. The fix lands either in clip robustness (PortalProjection / PortalVisibilityBuilder) or in eye dynamics (retail holds the eye collided/head-on 93% at doorways while ours floats — [flap-sweep] pull-in distribution is now measurable in the harness).

Conformance pre-gate for whatever fix: "smooth monotonic eye through/at a doorway ⇒ monotonic vis (no oscillation)" — buildable on the CameraCornerSealReplayTests fixture.

4. Apparatus inventory (reuse, don't rebuild)

• CameraCornerSealReplayTests — dat-backed sweep replay + room map + containment (Diagnostic fact prints everything; extend its sample table from any new capture).
• corner-seal-capture.log — the full corner+doorway capture (UTF-16LE).
• [flap-sweep] / [flap-cam] / [pv-input] probes — unchanged.
• The §4 outdoor flap probes (ACDREAM_PROBE_CLIPROUTE, [gl-state]) remain in-tree.