90 lines
5.3 KiB
Markdown
90 lines
5.3 KiB
Markdown
# §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.
|