erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

docs(#186): close — render InsideSide from dat PortalSide bit (fix 8257b9ba); retail trace overturned PICK + FLOOD-epsilon hypotheses

Browse source 
The live retail cdb trace decided it: retail roots at the connector 0118 at the
grey pose (NOT the PICK fork) AND still draws the player room 0116 from that root,
because retail's InitCell side test reads the dat PortalSide bit where acdream's
render path reconstructed the interior side from the cell AABB centroid (mis-sides
a thin connector). ISSUES #186 -> CLOSED; handoff gets a RESOLVED banner.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-07-08 15:07:46 +02:00
parent 8257b9ba10
commit 4dea66b633
2 changed files with 40 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

52
docs/ISSUES.md
View file

@ -46,37 +46,37 @@ Copy this block when adding a new issue:
--- ---
## #186 — Indoor→indoor GREY flap at a connecting room (top floor, new house type) ## #186 — [DONE 2026-07-08 · `8257b9ba`] Indoor→indoor GREY flap at a connecting room (top floor, new house type)
**Status:** OPEN (diagnosed by class only — NOT captured for this instance; investigation report-only) **Status:** CLOSED 2026-07-08 — live gate PASSED (no grey at any camera angle) + probe
**Severity:** MEDIUM · **Filed:** 2026-07-08 · **Component:** render / indoor visibility (viewer-cell root) (216 `root=0118` frames, 0 still grey; `0118->0116` now `TRV`, `vis=4`).
**Severity:** MEDIUM · **Filed:** 2026-07-08 · **Component:** render / indoor visibility (portal side-cull)
**Description:** Top floor of a house type not tried before; a connecting opening/room between two **Description:** Top floor of a new house type; a thin connecting cell between two rooms. Passing
parts of the house. Passing through → a brief **GREY** flap (world background). Stopping at the precise through → brief GREY flap; stopping at the spot → whole screen grey and stays; turning the camera
spot → the WHOLE screen is grey and stays; **turning the camera clears it, turning back → grey again** clears it, turning back → grey again (camera-direction dependent, player stationary).
(camera-direction dependent, player stationary).
**Root cause — NARROWED (report-only; retail SEAMLESS at the same spot → real acdream bug). FULL HANDOFF: **Root cause (CONFIRMED via live retail cdb trace + dat diagnostic — the report-only "narrowed" note
`docs/research/2026-07-08-186-connector-grey-flap-handoff.md`.** The eye seats in a sparse 5-render-poly was the right FAMILY but the WRONG mechanism):** the render portal side-cull reconstructed each
CONNECTOR cell `0xF6820118` (between player room `0116` and room `0117`), in the doorway threshold looking doorway's interior side (`PortalClipPlane.InsideSide`) from the cell's **AABB centroid**. For the thin
BACK toward `0116`; acdream's render DROPS `0116` (its back-portal is side-culled) so the doorway aperture connector `0xF6820118` (5 render polys) the bounding-box center falls on the WRONG side of the
shows the fog clear color = grey. Retail keeps `0116` drawn. **RULED OUT (do not revisit):** null-root/AD-21 `0118->0116` doorway → the eye read as a back-portal → the forward room `0116` was culled → the
(root valid indoor 88248/88249 frames); viewer-cell root-lag/AD-20 (`eyeInRoot=Y` — eye genuinely inside aperture showed the fog clear color = grey. Retail's `PView::InitCell` (0x005a4b70) AND acdream's own
`0118`'s BSP); the color-clear gating (retail's gated `Clear` @ DrawCells `0x005a48a9` is depth/stencil, PHYSICS path (`CellTransit.cs:190`) read the explicit dat **`PortalSide` bit** (`(Flags&2)==0`); the
fires AFTER `LScape::draw` — the tempting "3-line fix" is DEAD). Confirmed via workflow `wf_362bbeda-933` render path was the only one guessing from geometry.
(4 tracers + synthesis) + live `ACDREAM_PROBE_FLAP` capture + offline cell dump. It's the doorway-FLAP
FLOOD/PICK family (frozen render, DO-NOT-RETRY-heavy — the deleted `EyeInsidePortalOpening` rescue, the
`PortalSideEpsilon` root-lag).
**Next step (retail cdb, do FIRST — binary MATCHES `refs/acclient.pdb`):** at the grey pose, `bp **Fix (`8257b9ba`):** `GameWindow.BuildLoadedCell` derives `InsideSide` from the dat `PortalSide` bit,
SmartBox::update_viewer 0x00453ce0` (dump `viewer_cell` id) and/or `bp PView::DrawCells 0x005a4840` (dump matching retail + physics. Surgical — the dat diagnostic
`cell_draw_list`). retail `viewer_cell==0116` → PICK fix (acdream over-switches to the connector / (`Issue186…PortalSide_CentroidVsDatBit_AtGreyEye`) shows the bit agrees with the old centroid on every
boom coasts the eye in at `pulledIn=-0.00`); retail roots `0118` but draws `0116` too → FLOOD fix portal of these cells EXCEPT the one #186 breaks; the `CornerFlood`/`Issue113` dat helpers updated to the
(retail admits the back-portal; acdream's side-CULL is the site). Apparatus + code sites + DO-NOT-RETRY same bit keep every real Holtburg/tower/hall flood identical (App 741 / Core 2631 green). Touches neither
in the handoff. `PortalSideEpsilon` nor the deleted `EyeInsidePortalOpening` rescue.
**Acceptance:** no grey flap passing through OR stopping in the connecting room at any camera angle; **The retail trace OVERTURNED both prior hypotheses:** NOT PICK (both clients root at `0118` at the pose,
regression pass on the outside→inside doorway + other multi-room houses. eye ≈ identical) and NOT the handoff's FLOOD-epsilon framing — retail draws `0116` from the `0118` root
because its dat side bit admits the portal; acdream's centroid guess culled it. Apparatus (kept):
`tools/cdb/issue186-connector-decider.cdb` (viewer_cell + cell_draw_list decider) + the offline geometry
test. Handoff (now historical): `docs/research/2026-07-08-186-connector-grey-flap-handoff.md`.
--- ---

15
docs/research/2026-07-08-186-connector-grey-flap-handoff.md
View file

@ -1,6 +1,19 @@
# Handoff: #186 — indoor GREY flap at a top-floor connecting room (new house type) # Handoff: #186 — indoor GREY flap at a top-floor connecting room (new house type)
**Date:** 2026-07-08 · **Status:** ROOT CAUSE NARROWED (report-only) — fix NOT started. It lives in > **✅ RESOLVED 2026-07-08 · fix `8257b9ba` · live gate PASSED.** The retail cdb trace (§3, run via
> `tools/cdb/issue186-connector-decider.cdb`) OVERTURNED both hypotheses below. Retail roots at the
> connector `0118` at the grey pose (same as acdream — so NOT the PICK fork) AND still DRAWS the player
> room `0116` from that root — because retail's `PView::InitCell` side test reads the dat **`PortalSide`
> bit**, while acdream's render path reconstructed the portal's interior side from the cell **AABB
> centroid**, which mis-sides a THIN connector cell (`0118`, 5 render polys → centroid on the wrong side
> of the `0118→0116` doorway → back-portal cull → grey). Fix = derive `InsideSide` from the dat bit in
> `GameWindow.BuildLoadedCell`, matching retail + acdream's own physics (`CellTransit.cs:190`). Surgical
> (dat diagnostic: agrees with the old centroid on every portal but the one #186 broke). **The §2/§3
> "acdream drops the room" read was right; the "acdream over-switches the root / flood-epsilon" mechanism
> was WRONG — it was the InsideSide *source*, not the pick or the epsilon.** Everything below is the
> pre-fix investigation, kept for the trail.
**Date:** 2026-07-08 · **Status:** ~~ROOT CAUSE NARROWED (report-only) — fix NOT started.~~ RESOLVED (see banner). It lives in
the FROZEN portal-flood / viewer-cell render code (the doorway-FLAP family that cost weeks), so it needs the FROZEN portal-flood / viewer-cell render code (the doorway-FLAP family that cost weeks), so it needs
a **retail cdb trace** to pin the last fork BEFORE any code, then a careful change. Milestone: M1.5. a **retail cdb trace** to pin the last fork BEFORE any code, then a careful change. Milestone: M1.5.