"Number 80 is closed, I verified again." Moved #93 (the lighting umbrella) and #80 (2nd-floor darkness) to Recently closed. #94 (held-item spotlight) is NOT folded into this closure and stays open — user confirmed acdream doesn't support equipping hand-held items yet, so it's currently untestable; marked BLOCKED rather than an active A7 target so it doesn't keep resurfacing as unfinished lighting work. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Erik
parent
754b299f7a
commit
44cced715c
2 changed files with 46 additions and 84 deletions
116
docs/ISSUES.md
116
docs/ISSUES.md
|
|
@ -2895,35 +2895,6 @@ matching torch-light pools.
|
|||
|
||||
---
|
||||
|
||||
## #80 — Camera on 2nd floor goes very dark
|
||||
|
||||
**Status:** OPEN — **M1.5 scope (A7 lighting fidelity)**
|
||||
**Severity:** MEDIUM
|
||||
**Filed:** 2026-05-19
|
||||
**Component:** lighting
|
||||
|
||||
**Description:** Walking up to the second floor of a building, the
|
||||
lighting suddenly goes much darker than retail.
|
||||
|
||||
**Root cause / status:** Possible causes:
|
||||
1. The `playerInsideCell` lighting trigger (Phase 1 / commit `1024ba3`)
|
||||
uses `CellVisibility.IsInsideAnyCell(playerPos)` which is a brute-force
|
||||
PointInCell scan. The 2nd floor cell may not be in the loaded set OR
|
||||
may have wrong bounds.
|
||||
2. The per-cell ambient is currently a flat `(0.20, 0.20, 0.20)` for
|
||||
any indoor cell. Retail has per-cell ambient overrides; ours doesn't
|
||||
read them. A 2nd-floor cell with stairwell shadowing may need a
|
||||
different value.
|
||||
|
||||
**Files:**
|
||||
- `src/AcDream.App/Rendering/GameWindow.cs:8330+` (`UpdateSunFromSky`,
|
||||
indoor branch).
|
||||
|
||||
**Acceptance:** 2nd-floor cells render with similar brightness to
|
||||
ground floor; transition is not abrupt.
|
||||
|
||||
---
|
||||
|
||||
## #81 — Static building stabs don't react to atmospheric lighting changes
|
||||
|
||||
**Status:** OPEN — **M1.5 scope (A7 lighting fidelity)**
|
||||
|
|
@ -3236,64 +3207,20 @@ Retail oracle for cell-id hysteresis: `acclient_2013_pseudo_c.txt:308742-308783`
|
|||
|
||||
---
|
||||
|
||||
## #93 — Indoor lighting broken (M1.5 lighting umbrella)
|
||||
|
||||
**Status:** OPEN — **M1.5 scope (A7 lighting fidelity, primary lighting issue)**. Two real
|
||||
root causes found + fixed 2026-07-09 (A7.L1), user-confirmed improvement at the Town
|
||||
Network fountain room ("lightning is better"). Not closing outright — the umbrella covers
|
||||
several symptom classes (#80 2nd-floor darkness, #94 held-item spotlight direction) that
|
||||
weren't re-verified this session, and #189 (missing ambient particles, found in the same
|
||||
room) shows there's more to the "feels right" bar than point lights alone.
|
||||
**Severity:** HIGH (degrades indoor experience; M1.5 acceptance depends on it closing)
|
||||
**Filed:** 2026-05-20
|
||||
**Component:** lighting, rendering
|
||||
|
||||
**Description:** Interior cells (inn, cottages, dungeons — anywhere with `cellLow >= 0x0100`) render with lighting that doesn't match retail. Specific symptoms include #80 (2nd floor goes dark), wrong per-cell ambient, missing cell-internal light sources (torches/lanterns), and outdoor day-cycle bleeding into indoor cells. Umbrella issue covering the family; sub-issues to be filed during A7.L1 probe spike.
|
||||
|
||||
**Root cause / status:** Two DISTINCT root causes confirmed + fixed 2026-07-09 for the
|
||||
Town Network "fountain room too dark" symptom (#79/#176/#177's deferred light-cap arc):
|
||||
1. **Candidate-pool starvation in dense hubs** (`d275ed55`): `LightManager.BuildPointLightSnapshot`
|
||||
sorted ALL registered lights by raw player-distance with no visibility filter — in a
|
||||
463+ fixture hub, geometrically-closer-but-wall-disconnected fixtures could out-rank a
|
||||
visible room's own (farther) torches for the 128-cap. Fixed by scoping candidacy to
|
||||
last frame's rendered visible-cell set (`RetailPViewFrameResult.DrawableCells`, one
|
||||
frame of latency — see AP-85 in the divergence register for why this specific approach
|
||||
was chosen over re-threading a mid-`DrawInside` callback, the exact mechanism that
|
||||
caused the earlier c500912b #176 regression).
|
||||
2. **THE actual fountain-room darkness (`9ebb2060`, the bigger fix):** the mesh-empty
|
||||
hydration gate (`GameWindow.cs` ~7324) dropped an entity's WHOLE registration — including
|
||||
its `Setup.Lights` — whenever its visual mesh flattened to zero parts (a common dat
|
||||
pattern: a "light attach point" Setup whose sole visual part is a legitimately
|
||||
runtime-hidden marker, #136-class). Confirmed via direct dat-truth inspection
|
||||
(`Issue93TownNetworkFountainRoomLightInspectionTests`): the fountain room's ONE
|
||||
dat-authored light (a ceiling fixture, Setup 0x02000365) was silently dropped this way —
|
||||
the room registered ZERO lights of its own, so scoping fix #1 alone had no local light
|
||||
to redistribute. Fixed via `EntityHydrationRules.ShouldKeepEntity` — an entity survives
|
||||
hydration if it has mesh OR lights, not just mesh. Dungeon-wide effect: registered
|
||||
lights jumped 498→892 on the same launch.
|
||||
|
||||
**Files:**
|
||||
- `src/AcDream.Core/Lighting/LightManager.cs` (`BuildPointLightSnapshot` visible-cell scoping)
|
||||
- `src/AcDream.App/Rendering/GameWindow.cs` (hydration gate, `_lightPoolVisibleCells`)
|
||||
- `src/AcDream.Core/Meshing/EntityHydrationRules.cs` (the mesh-empty-but-has-lights predicate)
|
||||
- `src/AcDream.App/Rendering/GameWindow.cs:8330+` (`UpdateSunFromSky`, indoor branch with flat ambient — unrelated, unchanged)
|
||||
- `src/AcDream.App/Rendering/Shaders/mesh_modern.frag` (per-pixel light evaluation)
|
||||
- Retail oracle: grep `Render::lighting_*` / `add_light` in `acclient_2013_pseudo_c.txt`
|
||||
|
||||
**Acceptance:** Holtburg inn interior lighting matches retail at the same character position. Holtburg Sewer dungeon torchlight reads correctly per-room. 2nd-floor cells brightness matches ground floor. **Remaining before this can close:** re-verify #80 (2nd floor) and #94 (held-item spotlight direction) specifically — neither was re-checked this session; the Town Network fix targeted the starvation/hydration-drop symptom, not every #93 sub-symptom.
|
||||
|
||||
---
|
||||
|
||||
## #94 — Held items project spotlight on walls
|
||||
|
||||
**Status:** OPEN — **M1.5 scope (A7 lighting fidelity)**
|
||||
**Status:** OPEN — **BLOCKED, not an active A7 investigation target.** acdream does not
|
||||
yet support equipping hand-held items (weapons, orbs, light sources) at all
|
||||
(user-confirmed 2026-07-09), so this can't be reproduced or verified either way right
|
||||
now. Re-open for real investigation once item-equipping ships; until then this is a
|
||||
placeholder, not a live bug.
|
||||
**Severity:** MEDIUM (visual fidelity; doesn't block gameplay)
|
||||
**Filed:** 2026-05-20
|
||||
**Component:** lighting, rendering
|
||||
|
||||
**Description:** Items the player is holding (torches, light-source items) project a spotlight effect onto nearby walls. The spotlight direction is wrong — should be omnidirectional from the item, but appears to project specifically toward wall surfaces.
|
||||
|
||||
**Root cause / status:** Per-entity light direction transform. `LightingHookSink` owner-tracking applies an entity-rotation transform that's probably wrong for held-light items — likely passing the entity's facing-direction as the spotlight cone direction when retail's behavior is omnidirectional point-light.
|
||||
**Root cause / status:** Per-entity light direction transform. `LightingHookSink` owner-tracking applies an entity-rotation transform that's probably wrong for held-light items — likely passing the entity's facing-direction as the spotlight cone direction when retail's behavior is omnidirectional point-light. UNTESTABLE until item-equipping exists — this is a hypothesis from the original 2026-05-20 filing, not re-confirmed.
|
||||
|
||||
**Files:**
|
||||
- `src/AcDream.App/Rendering/Vfx/LightingHookSink.cs` (suspected — verify during A7.L1)
|
||||
|
|
@ -7345,6 +7272,37 @@ outdoors at the angle that previously erased it.
|
|||
|
||||
# Recently closed
|
||||
|
||||
## #93 — Indoor lighting broken (M1.5 lighting umbrella)
|
||||
|
||||
**Status:** DONE (2026-07-09). Two real root causes found + fixed (A7.L1): (1)
|
||||
`LightManager.BuildPointLightSnapshot` candidate-pool starvation in dense hubs — fixed by
|
||||
scoping candidacy to last frame's rendered visible-cell set (`d275ed55`); (2) THE actual
|
||||
fountain-room darkness — the mesh-empty hydration gate dropped an entity's whole
|
||||
registration (Setup.Lights included) whenever its visual mesh flattened to zero parts, a
|
||||
common "light attach point" dat pattern; fixed via `EntityHydrationRules.ShouldKeepEntity`
|
||||
(`9ebb2060`) — dungeon-wide registered lights jumped 498→892. User-confirmed at the Town
|
||||
Network fountain room ("lightning is better") and separately at a 2nd-floor room (`#80`,
|
||||
re-verified fixed). `#189` (missing fountain particle, found investigating this same room)
|
||||
turned out to be a third, unrelated bug (`#190`, entity-id overflow), also closed. `#94`
|
||||
(held-item spotlight) does NOT gate this closure — it's currently untestable (acdream
|
||||
doesn't yet support equipping hand-held items) and stays open on its own, blocked on that
|
||||
unrelated feature. Files: `src/AcDream.Core/Lighting/LightManager.cs`
|
||||
(`BuildPointLightSnapshot`), `src/AcDream.App/Rendering/GameWindow.cs` (hydration gate,
|
||||
`_lightPoolVisibleCells`), `src/AcDream.Core/Meshing/EntityHydrationRules.cs`. Apparatus:
|
||||
`Issue93TownNetworkFountainRoomLightInspectionTests` (dat-truth, reusable).
|
||||
|
||||
---
|
||||
|
||||
## #80 — Camera on 2nd floor goes very dark
|
||||
|
||||
**Status:** DONE (2026-07-09, user re-verified: "Number 80 is closed, I verified again").
|
||||
Closed as part of the `#93`/A7.L1 lighting-umbrella fix arc (candidate-pool scoping +
|
||||
mesh-less light-carrier hydration, `d275ed55` + `9ebb2060`) — not independently
|
||||
root-caused to this specific symptom, but the user's direct re-check at a 2nd-floor room
|
||||
confirmed it's fixed. See `#93` for the fix mechanism.
|
||||
|
||||
---
|
||||
|
||||
## #189 — Ambient particle scripts (fountain water, possibly candle flames) don't render indoors
|
||||
|
||||
**Status:** DONE (2026-07-09, user visual gate passed — "Fountain is back! We
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue