diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 2d7180da..f9c24691 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -46,8 +46,33 @@ Copy this block when adding a new issue: --- -## #181 — Portal-flood output flaps on micron eye noise → cell (+ its scoped lights + scissor AABB) strobes in/out (~10 Hz) +## #181 — Facility Hub flicker at pressed camera (residual after the full 2026-07-06 fix ladder) — PARKED +**⏸️ PARKED 2026-07-06 (user decision after the static-curve gate: "flickering is still +there — file it, document it, move on to the stairs").** The session shipped SEVEN +fixes/ports, every one individually verified, and the user-visible flicker at their +pressed-camera pose SURVIVED all of them. Shipped: `48aaab81` (stateful camera sought), +`f10fe4e9` (retail adjust_to_plane — the dead ACE port), `87cddce2` (static light +re-apply stacking), `3f34bca0` (retail viewer step subdivision + viewer-exempt abort), +`233b469b` (A7 fix #2 — stationary weenie fixtures on retail's STATIC light curve, +Ghidra-verified 0x0059c8b0). ELIMINATED with evidence: camera eye strobe (post-fix logs: +zero >2 cm jumps), display tearing (VSync-on 30 fps still shows it; windowed+DWM never +tears anyway), light-pool membership + applied per-cell sets ([seam-cell]: frozen across +107k parked frames incl. every vis-flap frame), the light-stacking leak (fresh-session +flicker), the flood-root flap (stable at the user's standing pose), the sliver-cell's +own geometry (zero-area region). STILL-OPEN leads for whoever resumes: (1) the parked +clean captures at MY pose show a pixel-static scene — the flicker has never been +captured in a frame pair at THE USER'S pose with an unobstructed window: get the user to +hold the pose, capture ≥8 frames, diff (the apparatus is in the scratchpad scripts — +capture-still.ps1/imgdiff.ps1/imgdiffmap.ps1); (2) the deep-cell vis 31↔32 flap +(0x8A020181 sliver admission on the wall-press mm wobble — both real, both measured, +consequence unproven; Issue181VisFlapReplayTests + Issue181WallPressEquilibriumTests are +the pins); (3) cdb-trace retail's wall-pressed viewer to compare equilibria (toolchain +proven, needs a live retail session); (4) the static-curve fix may have changed the +artifact's LOOK (brightness) without killing the motion-flicker — re-characterize +before assuming tonight's captures still describe it. + +**Original filing (mechanism evidence trail below remains valid):** **Status:** OPEN — mechanism PINNED from live evidence; the knife-edge test not yet identified **Severity:** HIGH (THE user-visible #176 flicker that survived the #180 camera fixes: washed regions with hard screen-space rectangle boundaries pulsing at a parked camera) diff --git a/docs/research/2026-07-06-177-stairs-pickup-handoff.md b/docs/research/2026-07-06-177-stairs-pickup-handoff.md new file mode 100644 index 00000000..db8833cd --- /dev/null +++ b/docs/research/2026-07-06-177-stairs-pickup-handoff.md @@ -0,0 +1,131 @@ +# Pickup handoff — #177 dungeon stairs pop in/out (portal-visibility miss at the stair cells) + +**Paste the companion prompt (bottom) into a fresh session.** Read this file, then +`claude-memory/project_render_pipeline_digest.md` (top banners), then **ISSUES #177** +(full entry — including the superseded lighting attribution and why it was re-attributed +to VISIBILITY at the 2026-07-06 gate). + +## TL;DR — what #177 is + +Facility Hub (0x8A02), the staircase connecting two levels (corridor 0x0178 → ramp +0x0182 → lower room 0x0183): (a) **invisible looking into the stair room from the +corridor**, (b) **pops into existence on entering the room**, (c) **the last step +vanishes running down**. The 2026-07-06 gate PROVED this is NOT lighting (the A7 +visible-cell light fix shipped and the stairs were still missing looking back from the +corridor) — it is a **portal-flood admission miss**: the stair cells are not reached by +`PortalVisibilityBuilder` from the viewer's cell until the viewer crosses in. The +digest tags it "#119 class, dungeon edition; floor-portal level links." + +**Acceptance:** the staircase renders whenever its room is visible through the +connecting opening, and stays rendered through the full descent. + +## Where to start (the apparatus already exists) + +1. **`tests/AcDream.App.Tests/Rendering/Issue176177FacilityHubFloodReplayTests.cs`** — + headless flood replays against the REAL dat, with two scenarios written for exactly + this issue and never fully mined: + - Scenario A (stair approach): eye in corridor 0x0178 at several x positions + + pitches, printing whether ramp 0x0182 / lower 0x0183 are admitted. + - Scenario B (descent): eye path down the ramp, printing per-step admitted-set + diffs (the "last step vanishes" case). + **Run these FIRST** — the miss should reproduce headlessly, and the printed + admitted sets name which portal hop fails. +2. **`Issue181VisFlapReplayTests.cs`** — the same-file pattern for perturbation + sweeps + per-cell view-region AREA measurement (the shoelace diagnostic). Cell + **0x8A020181** — right next to the stair complex 0x0182/0x0183 — rides a + knife-edge zero-area admission; the #177 miss and the #181 sliver are plausibly + the SAME flood defect seen two ways (a floor-portal chain that clips to nothing + from above). +3. **The builder:** `src/AcDream.App/Rendering/PortalVisibilityBuilder.cs`. The + admission gates per portal hop, in order: the side test (`CameraOnInteriorSide`, + PortalSideEpsilon 0.01 — AP-19), then `ClipPortalAgainstView` (homogeneous clip + against the parent's accumulated region; `clippedRegion.Count == 0` ⇒ the flood + stops there). For a DOWNWARD stair chain the suspect class is the FLOOR-portal + hop: a horizontal portal seen edge-on from the corridor clips to ~zero area + (exactly the 0x0181 sliver signature) and the chain below never floods. + `ACDREAM_A8_DUMP_PV=1` dumps per-portal census + EXIT-PROJ/EXIT-CLIP lines for + the camera cell (first 2 builds per cell). +4. **Retail oracle:** retail PView floods portals with per-poly clip + (`polyClipFinish` — the W=0 clip pseudocode doc 2026-06-11) and DOES show stair + rooms through their openings. If our clip collapses a genuinely-visible aperture + to zero, compare `ClipPortalAgainstView` against `PView::ClipPortals`/`GetClip` + (decomp:433572) at the failing hop's exact geometry. #119's lesson applies: + visibility must derive from the same data that gets drawn + (`feedback_culling_bounds_from_drawn_data`). + +## What tonight's #180/#181 session gives you for free + +- All camera/sweep mechanisms are Ghidra-verified faithful (stateful sought, + adjust_to_plane, adjust_sphere_to_poly, viewer radius-anchored stepping) — commits + `48aaab81`/`f10fe4e9`/`3f34bca0`. The camera's `ViewerCellId` is trustworthy; the + render roots at it (Option A). +- The wall-pressed camera wanders ~0.5 mm/frame in a bit-exact 12-frame limit cycle + (`Issue181WallPressEquilibriumTests` — measured, all local algorithms verified; + plausibly retail-class). Any admission knife-edge within that wobble band flaps + ~10 Hz (`[flap]` vis 31↔32, whole-session). For #177 this matters at stair + THRESHOLDS: expect flappy admission exactly at descent transitions. +- Lighting is now retail-shaped: resident+player-anchored pool (d8984e87), idempotent + re-apply (`87cddce2`), stationary fixtures on the verified static curve + (`233b469b`). Do NOT re-open lighting for #177 — the gate already refuted it. +- **#181 is PARKED** (see its ISSUES entry for the still-open leads). Do not resume + it inside the #177 arc; if stair work surfaces new flicker evidence, append to + #181's entry instead. + +## Watchouts + +- The old #177 root-cause text (128-cap light eviction) is SUPERSEDED — kept in the + entry for history. The re-attribution is the ⚠️ UPDATE block at the top of #177. +- The flood replay's ViewProj must match production FOV/aspect (π/3, 16:9) — the + Issue181 test does; the older Issue176177 scenarios use 1.2 rad / 1280×720 (fine + for admission questions, but keep in mind for NDC-sensitive comparisons). +- `Issue120ReciprocalPingPongTests.LoadAllInteriorCells` + `CornerFloodReplayTests. + ResolveDatDir` are the shared fixtures loaders (App.Tests); Core.Tests has its own + `ConformanceDats`. +- A client may be running — the user manages its lifecycle; ASK before rebuilding if + the App DLL is locked (MSB3027 = lock, not code). + +## State + +- Branch `claude/vigorous-joliot-f0c3ad` @ `233b469b`+ (this handoff's commit). + Suites green: Core 2600+2skip / App 733+2skip / UI 425 / Net 385 / Content 56. +- Test char spawns in the Facility Hub corridor (0x8A020142 area); the stair complex + is 0x0178/0x0182/0x0183 (+0x0181 adjacent). +- Launch recipe + graceful-close rules: CLAUDE.md "Running the client". The + GDI-capture + keybd_event autonomous visual loop scripts live in this session's + scratchpad (capture-still.ps1, imgdiff.ps1, imgdiffmap.ps1, crop.ps1) — recreate + from the #180 handoff's recipe if the scratchpad is gone. + +## Companion prompt (paste into the fresh session) + +``` +Fix #177 — Facility Hub stairs pop in/out across levels (invisible from the +corridor, pop on entry, last step vanishes running down). The 2026-07-06 gate +re-attributed this from lighting to a PORTAL-FLOOD ADMISSION MISS at the stair +cells (0x8A020178 corridor → 0x0182 ramp → 0x0183 lower; 0x0181 adjacent) — do +NOT re-open lighting (gate-refuted; the A7 fixes are in and verified). + +READ FIRST, in order: +1. docs/research/2026-07-06-177-stairs-pickup-handoff.md (apparatus map, the + #181 park boundary, watchouts) +2. claude-memory/project_render_pipeline_digest.md (top banners) +3. docs/ISSUES.md #177 (the ⚠️ UPDATE block supersedes the old root cause) + +START by running the existing headless replays (Issue176177FacilityHubFloodReplay +Tests Scenarios A/B — real dat, no client): they print per-pose admitted sets for +the stair cells and should reproduce the miss offline. Then trace the failing +portal hop through PortalVisibilityBuilder's gates (side test → ClipPortalAgainst +View; the floor-portal seen edge-on clipping to ~zero area is the suspect class — +the same signature as #181's 0x0181 sliver next door). Retail oracle for the clip: +PView::ClipPortals/GetClip (decomp:433572) + the 2026-06-11 polyClipFinish W=0 +pseudocode doc. Workflow: replay → identify the gate → read retail → pseudocode → +port → the replays become pins → autonomous visual loop (stair approach/descent +drive) → user gate. + +#181 (the pressed-camera flicker) is PARKED with its evidence ledger in ISSUES — +if stair work surfaces flicker evidence, append there; don't resume it in this arc. + +State: branch claude/vigorous-joliot-f0c3ad, suites green (Core 2600+2skip / App +733+2skip). Test char spawns in the Facility Hub corridor. A client may be +running — the user manages its lifecycle; ASK before rebuilding if the App DLL +is locked. +```