From a100bc37a7f07d03ef64c80460713a988208af23 Mon Sep 17 00:00:00 2001 From: Erik Date: Sun, 14 Jun 2026 14:33:07 +0200 Subject: [PATCH] docs(G.3): file #134 (ramp slide) + #135 (login FPS); record #133 grey+FPS fixes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Wrap-up bookkeeping for the dungeon work this session: - #135 — login FPS ramp (~10 fps -> high over ~30 s): the streaming collapse only fires once CurrCell resolves to a sealed cell, so the first-frame bootstrap loads ~24 neighbour ocean-grid dungeons (+ ~19k entities each) then unloads them. Residual of the dungeon collapse; clean fix = pre-collapse at login when the spawn cell is a sealed dungeon cell. - #134 — ramp slide-response feel ("lags downward" instead of gliding along the slope). SURFACED (not caused) by 3e006d3 caching the ramp connector cell in the physics graph; the slope-walk/edge-slide is now exercised. Port the retail slide-response; no band-aid. - #133 — progress note: dungeon FPS FIXED (streaming collapse to the single dungeon landblock, 14-30 -> ~1000+ fps) + grey barrier FIXED (register portals-only connector cells for BOTH visibility and the physics graph even when they build 0 sub-meshes; d90c538 + 3e006d3). A7 per-vertex lighting bake (LightBake Core 3b93f91) is the remaining "lighting off" work; revised diagnosis (intensity=100 is the real dat value; the divergence is no-static-light-burnin, not a mis-read). Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/ISSUES.md | 122 +++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 107 insertions(+), 15 deletions(-) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 4a672ae3..9a169623 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -46,6 +46,61 @@ Copy this block when adding a new issue: --- +## #135 — ~30 s low-FPS ramp at login (≈10 fps → high) before streaming settles + +**Status:** OPEN +**Severity:** LOW (startup-only; self-corrects) +**Filed:** 2026-06-14 +**Component:** streaming — first-frame bootstrap vs the dungeon collapse + +**Description:** On login into a dungeon, FPS starts ~10 and climbs over ~30 s before +settling (then 1000+ fps). User: "we still have about 30ish seconds before FPS is ramped +up; when logging in I get like 10 then it slowly increases." + +**Root cause / status:** The #133 streaming collapse (`5686050`/`d9e7dd6`/`7d8da99`) only +engages once CurrCell resolves to a sealed cell (the snap, a few s in). Before that the +first Tick bootstraps the full 25×25 window, so ~24 neighbour ocean-grid dungeons (+ their +~19k entities) load, then unload when the collapse fires. The collapse-at-snap change moved +the trigger from finalize-time (~30 s) toward snap-time but the bootstrap churn remains. +Clean fix = pre-collapse at login when the spawn cell is a sealed dungeon cell so the full +window never enqueues (touches the sensitive login spawn path — do carefully; no band-aid). + +**Files:** `GameWindow.cs:6885` (streaming Tick gate); `StreamingController.cs` (collapse); +login recenter `OnLiveEntitySpawnedLocked` ~2470. + +**Acceptance:** Login into a dungeon reaches steady-state FPS within ~1–2 s (no full-window +neighbour load/unload churn). + +--- + +## #134 — Player "lags downward" instead of gliding along a dungeon ramp edge + +**Status:** OPEN +**Severity:** LOW-MEDIUM (movement feel; not a hard traversal block) +**Filed:** 2026-06-14 +**Component:** physics — slope-walk / edge-slide response + +**Description:** Running up or down against a dungeon ramp's edge, the player "sort of lags +downwards" instead of gliding/sliding ALONG the ramp surface (up when running up, down when +running down). Reported in the 0x0007 Town Network dungeon ramp after #133. + +**Root cause / status:** Surfaced (not caused) by the #133 connector-cell physics +registration (`3e006d3`): the ramp connector cell's collision is now fully resident in the +physics graph, so the slope-walk / edge-slide response on it is exercised for the first time. +"Lag down" suggests the slide velocity is projected toward gravity rather than along the +contact plane (the slope tangent). Likely the retail edge-slide / slope-slide response is +incomplete — see #32 (retail edge-slide/cliff-slide/precipice-slide incomplete) and the +AP-6 / TS-1 / TS-4 slide rows in the divergence register. NO band-aid — port the retail +slide-response. + +**Files:** `src/AcDream.Core/Physics/` (slide-response in TransitionTypes / BSPQuery); ramp +cell 0x0007014D + neighbours. + +**Acceptance:** Running up a walkable ramp climbs it smoothly; running into the edge slides +along the slope (up/down per input direction), matching retail feel. + +--- + ## #133 — Teleport into a dungeon snaps the player BEFORE the dungeon landblock streams in → lands at the old landblock's frame (ocean), not the dungeon **Status:** OPEN — promoted to **Phase G.3** (Dungeon streaming + portal @@ -97,6 +152,37 @@ transition` spam), and the render budget is sane — **WB-DIAG instances ~39,000 (meshMissing=0)** vs the 9.1M pre-Bug-A blowup (#95, now RESOLVED as a Bug-A symptom). User-confirmed: "no errors from ACE this time." +**✅ DUNGEON FPS FIXED + GREY BARRIER FIXED (2026-06-14, user-confirmed).** Two +separate causes, both resolved: + +- **FPS (was 14–30, now ~1000+):** AC dungeons sit adjacent in the "ocean" landblock + grid, so the 25×25 (farRadius=12) streaming window pulled ~129 neighbour dungeons + + their ~19k particle emitters / entities each frame. Fix = **collapse streaming to the + player's single dungeon landblock** when CurrCell is a sealed EnvCell (`!SeenOutside`), + with landblock-level hysteresis to stop collapse↔expand thrash. Confirmed against ACE + (`landblock.IsDungeon → return adjacents` with no neighbours): dungeons have no neighbour + landblocks, so collapsing to the one block is retail-faithful. Commits `5686050` (collapse) + + `d9e7dd6` (hysteresis) + `2561918` (pin to CurrCell's landblock, not the position-derived + one — the negative cell-local-Y made `floor(pp.Y/192)` land one block off and unload the + REAL dungeon). Divergence register: AP-36. + +- **GREY BARRIER (the "barrier above the ramp" / cellar-mouth grey):** portals-only + connector cells (ramp mouths, stair landings, cellar throats) build **0 drawable + sub-meshes**, and BOTH cell-registration gates (`BuildLoadedCell` → visibility + `_cellVisibility`, and `CacheCellStruct` → the physics cell graph) were gated on + `cellSubMeshes.Count > 0`. So a connector cell never registered → the portal flood + hit a **lookup-miss** at its opening (the un-flooded opening shows the clear/grey + colour) AND the camera eye-sweep couldn't transit through it. Fix = register EVERY + cell with a valid cellStruct for visibility + physics; only the *drawing* registration + stays gated on having sub-meshes. Commits `d90c538` (visibility) + `3e006d3` (physics + graph). The physics-graph half EXPOSED the ramp slide-response feel (now **#134**). + Three render-MATH theories (portal_side centroid, on-screen clip, near-eye projection) + were instrumented and REFUTED before the real lookup-miss cause was found — apparatus + discipline held. Render-pipeline digest updated. + +Residual (filed separately): login FPS ramp **#135**; ramp slide-response **#134**; the +A7 per-vertex lighting bake (below) is the remaining "lighting off" work. + **✅ A7 dungeon lighting — selection fix LANDED + objectively verified (`a80061b`).** The "lighting off" report was NOT missing torches — the `ACDREAM_PROBE_LIGHT` diagnostic (`d6fb788`) showed the dungeon correctly gets retail's flat 0.2 indoor ambient + sun zeroed @@ -112,21 +198,27 @@ light it). Core lighting suite green. Then `Range = Falloff × 1.5` (retail `ran retail-faithful (`SmartBox::SetWorldAmbientLight(0.2f)`); the 0.30 was a red herring (`CreatureMode` paperdoll renderer, not world cells). -**⚠️ REAL remaining cause — GENERAL light over-saturation (NOT dungeon-specific; belongs to -the #79 indoor-lighting umbrella).** Screenshot + `[light-detail]` probe (`9e809bc`): torches -read **`intensity=100`** (+ garbage `cone`). Our shader does `Diffuse = color × intensity` → -`color × 100` → every lit surface blows out to white = the hard "spotlight" disks. Retail's -`config_hardware_light` (0x0059adc) uses the SAME math (`Diffuse = (color/255) × intensity`) -and is NOT blown out → **retail's intensity is ~1.0; we are mis-reading the dat -`LightInfo.Intensity`** (likely a DatReaderWriter field/type bug — its source is a compiled -NuGet, not vendored, so unconfirmed). Over-saturates EVERY light (houses + outdoors + dungeons — -matches the user's "same issue everywhere; retail is uniform"). **DO NOT ad-hoc `÷100` -(forbidden workaround, risks the frozen outdoor/building lighting).** Proper fix = pin the -dat-format (raw-byte inspect a `LightInfo` / get the DatReaderWriter source) → correct the -intensity read → fixes the general spotty lighting everywhere. GENERAL engine-lighting work, -beyond G.3 dungeon scope. Separately: dungeon FPS 14–30 (WB-DIAG ~22K draws/frame — heavy -cell-geometry draw count / poor instancing — a general rendering-perf task; the 8-light -selection also added a per-frame 2227-light sort that should become a partial-select). +**⚠️ REAL remaining cause — REVISED 2026-06-14 (the earlier "mis-read intensity" theory is +REFUTED).** `intensity=100` is the **REAL dat value** (raw-byte verified `00 00 C8 42` = 100.0f; +DatReaderWriter 2.1.7 parses it correctly; the garbage `cone` is MSVC `CD CD CD CD` +uninitialized fill Turbine baked into the dat — point lights never read it). **DO NOT `÷100`.** +The actual divergence is the **[HIGH] `no-static-light-burnin`**: retail bakes ALL of a cell's +reaching static lights **PER-VERTEX once** (`D3DPolyRender::SetStaticLightingVertexColors` +0x0059cfe0 → `calc_point_light` 0x0059c8b0, Gouraud-interpolated → uniform, never blown out via +the per-channel min-to-colour clamp), while we light **per-PIXEL with only the 8 nearest-to- +CAMERA lights** → bright pools near torches, dark between, and a crescent that slides as the +camera re-ranks the 8-slot list. Diagnosed via a 5-agent investigation + a clean Ghidra +decompile (the BN pseudo-C is x87-mangled). **LANDED:** the per-pixel `(1-dist/falloff_eff)` +shader ramp (`007e287`, necessary but NOT sufficient — it can't fix the per-vertex-vs-per-pixel +structure) + the GL-free `LightBake` Core (`3b93f91`: the verbatim `calc_point_light` port + +7 conformance tests). **REMAINING — the A7 integration:** add a per-vertex linear-RGB colour +attribute to the cell mesh + a bake driver keyed on `envCellId` (NOT the dedup `cellGeomId` — +adjacent rooms share a geom but not their torches) + consume it in `mesh_modern.frag` for cell +draws; bound the bake's light set to the player dungeon (#133's FPS collapse already does this). +Belongs to the #79/#93 indoor-lighting umbrella; outdoor static objects + building shells still +use the per-pixel-8 path (the same spottiness — separate follow-up). **NOTE — dungeon FPS is +FIXED** (was 14–30 from streaming ~129 neighbour ocean-grid dungeons; now ~1000+ fps after the +#133 streaming collapse + the allocation-free 8-light partial-select, `5872bcf`/`5686050`). **Severity:** HIGH (any far/dungeon teleport is unusable) **Filed:** 2026-06-13 (M1.5 dungeon-demo gate attempt — meeting-hall portal) **Component:** physics/streaming — teleport-arrival snap vs async landblock hydration