feat(A7.L1): scope the point-light pool by last frame's visible cells (#79/#93/#176/#177)
The Town Network hub (498 registered fixtures) starved the player's own
room: BuildPointLightSnapshot's player-nearest-128 cap sorts by raw
Euclidean distance, which isn't a reliable proxy for "same room" in a
dense maze — a fixture on the other side of a wall can be geometrically
closer than the room's own torches and win the cap. LightSource.CellId
tagging and the [indoor-light] membership probe already existed from the
c500912b/#176 arc; the missing piece was a candidacy filter.
BuildPointLightSnapshot(playerWorldPos, visibleCells) now narrows
candidates to the frame's actual visible cells before the existing
dynamics-first player-nearest cap runs (cell-less lights, e.g. the viewer
fill, always included). GameWindow feeds LAST FRAME's already-rendered
RetailPViewFrameResult.DrawableCells — one frame of latency instead of
re-threading a mid-DrawInside callback, which was the exact mechanism
(c500912b) that caused the earlier #176 seam-floor flicker regression.
The distance-sort anchor stays the player, unchanged.
AP-85 updated in place (third revision) rather than adding a new row —
same underlying divergence, now with the render-visibility approximation
of retail's true DBObj-load/flush-bounded resident registry documented
alongside its residual risk (one unscoped frame on portal re-entry).
Core 2652+2skip / App 741+2skip / UI 425 / Net 385 green. Pending: user
visual gate at the Town Network fountain, and a #176 corridor-seam
non-regression recheck (Facility Hub, different landblock).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Erik
parent
388f3ed307
commit
d275ed554e
5 changed files with 166 additions and 23 deletions
|
|
@ -184,7 +184,7 @@ accepted-divergence entries (#96, #49, #50).
|
|||
| AP-80 | **PlanFromVelocity survives for velocity-only NPC cycles** (M16): UpdatePosition-derived speed picks Ready/Walk/Run cycles for server-controlled creatures whose UMs never arrive (scripted-path NPCs); retail derives every cycle from motion messages through the motion tables (R4-V4 note; pre-existing mechanism, row added per the V4 plan) | `src/AcDream.Core/Physics/ServerControlledLocomotion.cs` (`PlanFromVelocity`); consumer `GameWindow.ApplyServerControlledVelocityCycle` | Some ACE entities move by position updates alone — without this, they slide in T-pose; constants (StopSpeed 0.2, RunThreshold 1.25) tuned against live ACE traffic | Cycle-pick thresholds are acdream inventions — a creature intended to walk fast may show run legs near the threshold | retire in R6 (root motion + full per-tick order) |
|
||||
| AP-81 | **Remote-DR gravity toggled via the Gravity STATE bit**: the jump handler sets `Body.State \|= Gravity` at VectorUpdate and both landing blocks clear it after `HitGround()`; retail keeps GRAVITY set for the object's whole life and gates gravity ACCELERATION on the Contact transient (`calc_acceleration`) (pre-existing K-fix9/K-fix15 mechanism, row added during #161 — which also fixed the ordering so `Motion.HitGround()`'s verbatim `state&0x400` gate runs BEFORE the clear) | `src/AcDream.App/Rendering/GameWindow.cs` (VectorUpdate jump handler + the two landing blocks) | The DR tick integrates gravity only for airborne remotes; the flag dance delivers exactly that without porting the full contact-gated `calc_acceleration` chain; the #161 ordering fix keeps the retail HitGround contract satisfied | Any NEW call into `Motion.HitGround`/`LeaveGround` placed after the clear silently no-ops on the gravity gate (the #161 leg-2 class); grounded remotes carry a non-retail state word (probes comparing state bits vs retail mislead) | `CPhysicsObj::calc_acceleration` (contact-gated); `set_on_walkable` 0x00511310; retire in R6 (contact-gated accel + persistent GRAVITY) |
|
||||
| AP-82 | **StickyManager deep-overlap back-off sign pin**: when the stick-gap overlap exceeds one tick's step (`speed×quantum < \|dist\|`, `dist < 0`), acdream applies `delta = −(speed×quantum)` (rate-limited back-off); ACE's literal port keeps `+delta` there — a runaway that steers INTO the target with equilibrium at centers-coincident. The BN mush (0x00555554-0x00555597) is unreadable on exactly this compare; the pin is refuted-by-evidence against ACE-literal: #171 gate-3 probe showed 1661 deep-overlap ticks all steering inward (monsters converged to centerDist≈0 — "monster inside the player") while retail side-by-side on the same ACE shows separation. ACE servers essentially never reach the branch (quantum ≥1/30 → threshold ~1 m; render-rate quanta → ~0.13 m) | `src/AcDream.Core/Physics/Motion/StickyManager.cs` (`AdjustOffset` delta clamp; conformance `StickyManagerTests.AdjustOffset_DeepOverlap_BacksOff_RateLimited`) | Minimal interpretation consistent with the mush structure AND observed retail; identical to ACE-literal in every shallow/outside case | If retail's true deep-overlap behavior differs (e.g. no movement at all), our back-off rate diverges in that rare state; verify via cdb `StickyManager::adjust_offset` trace with a forced overlap when convenient | `StickyManager::adjust_offset` 0x00555430 (x87 mush); ACE StickyManager.cs:117-121 (the literal branch this pin overrides) |
|
||||
| AP-85 | **Point-light pool = single 128-cap player-nearest list vs retail's dual pools (7 dynamic + 40 static, degrade-scaled)** (#176 CORRECTED AGAIN 2026-07-06, second correction same day): the pool is now retail's shape — collected per frame from ALL registered (=resident-cell) lit lights and, over cap, kept dynamics-FIRST then nearest-THE-PLAYER (`Render::insert_light` 0x0054d1b0 sorts by `Render::player_pos`; `CEnvCell::add_dynamic_lights` 0x0052d410 walks the WHOLE static `CEnvCell::visible_cell_table`, which `add_visible_cell` 0x0052de40 proves is the RESIDENT-cell registry — it DBObj-loads absent cells; NOT the portal flood). **Two prior camera-coupled models were each a #176 flicker mechanism and are deleted: (1) nearest-CAMERA-128 (chase-boom churn), (2) frame-FLOOD scoping `c500912b` (the prior AP-85 text called it faithful — WRONG: the doc glossed `visible_cell_table` as "the portal-flood visible set"; the under-room portal purples entered/left the pool as the camera turned = the seam blink, probe-proven `[seam-blk]`: flood churned 8→41 cells over a full turn while the fixed pool held the same 8 identities).** Remaining deviation: ONE pool capped 128 vs retail's separate 7-dynamic/40-static with degrade scaling (`0x0081ec94/98`, `SetDegradeLevelInternal` 0x0054c3c0) — in the Hub this admits 7 purples + viewer (8 dynamics) where retail's 7-dynamic cap + static slots would mix in warm fixture light (cdb saw 4 purples + viewer) | `src/AcDream.Core/Lighting/LightManager.cs` (`BuildPointLightSnapshot`, `MaxGlobalLights`); pins `PointSnapshot_HubScaleLightCount_ObjectSelectionIsCameraInvariant`, `PointSnapshot_OverCap_DynamicsNeverEvictedByNearerStatics`, `PointSnapshot_ResidentCollection_CellTagDoesNotFilter` | Single-pool is the minimal faithful-in-effect shape: dynamics-first ordering reproduces the never-evicted property; 128 > 40+7 only ever admits EXTRA far statics (out of selection range anyway) | A room with >7 resident dynamics shows them all (retail trims to 7 player-nearest) — slightly purpler Hub wedge than retail; adopt the dual pools + degrade caps in the A7 arc | `insert_light` 0x0054d1b0 (player-sorted, capped); `add_visible_cell` 0x0052de40 (resident registry); `add_dynamic_lights` 0x0052d410 (whole-table walk); caller 0x00452d30; `calc_point_light` 0x0059c8b0 (static 1/d³ curve — A7 fix #2) |
|
||||
| AP-85 | **Point-light pool = single 128-cap player-nearest list, optionally FILTERED by LAST FRAME's rendered visible-cell set, vs retail's dual pools (7 dynamic + 40 static, degrade-scaled) collected from a DBObj-load/flush-bounded resident registry** (A7.L1, 2026-07-09 — third revision, Town Network starvation fix #79/#93/#176/#177): retail's `CEnvCell::visible_cell_table` (`add_visible_cell` 0x0052de40) is populated ON DEMAND as cells are approached/seen (`DBObj::Get`-loads) and pruned by `flush_cells` — so a real dungeon's per-frame candidate set stays small (naturally proximity-bounded) even though the collection walk itself (`add_dynamic_lights` 0x0052d410) is "the whole resident table, not a re-flood." acdream's `_all` list instead registers at LANDBLOCK-granularity load/unload (a whole single-landblock dungeon streams as ONE unit), so for the Town Network (463 registered fixtures, one landblock) `_all` is effectively "everything ever loaded in this dungeon," not a proximity-bounded set — wide enough that the player-nearest-128 cap alone let a straight-line-closer-but-wall-disconnected corridor's fixtures out-rank the player's own room, starving it. Fix: `BuildPointLightSnapshot(playerWorldPos, visibleCells)` takes an optional candidacy FILTER — a light joins the pool iff `CellId==0` (cell-less, always in) or `visibleCells.Contains(CellId)` — narrowing candidates to the frame's actual visible cells BEFORE the existing dynamics-first player-nearest cap runs; `GameWindow` feeds LAST FRAME's already-rendered `RetailPViewFrameResult.DrawableCells` (one frame / ~16 ms latency, chosen specifically to avoid re-threading a mid-`DrawInside` callback — the exact mechanism, `c500912b`, that caused the #176 seam-floor flicker regression when it re-flooded an independent CAMERA-seeded set mid-frame). The distance-sort anchor stays the PLAYER (unchanged from the prior revision) — only candidacy narrows. Remaining deviation: this is a RENDER-visibility approximation of retail's true on-demand-load/flush RESIDENCY bound, with one frame of latency, not a port of the DBObj-load/flush mechanism itself; and the pool is still ONE 128-cap list vs retail's separate 7-dynamic/40-static degrade-scaled pools | `src/AcDream.Core/Lighting/LightManager.cs` (`BuildPointLightSnapshot`, `MaxGlobalLights`); `src/AcDream.App/Rendering/GameWindow.cs` (`_lightPoolVisibleCells`/`_lightPoolVisibleCellsValid`); pins `PointSnapshot_HubScaleLightCount_ObjectSelectionIsCameraInvariant`, `PointSnapshot_OverCap_DynamicsNeverEvictedByNearerStatics`, `PointSnapshot_ResidentCollection_CellTagDoesNotFilter`, `BuildPointLightSnapshot_VisibleCellScoping_RoomLightsSurviveOverEuclideanCloserInvisibleCell`, `BuildPointLightSnapshot_VisibleCellScoping_CellLessLightAlwaysIncluded` | The render already computes a visible-cell set every frame for drawing (single source of truth, no duplicate flood) — reusing it as a candidacy filter approximates retail's proximity-bounded residency without porting DBObj on-demand load/flush; one-frame latency is imperceptible at normal camera speeds and structurally differs from the reverted mechanism (no independent re-flood mid-frame) | On a portal crossing, the FIRST indoor frame after re-entry (or after any outdoor-only frame) is unscoped (fail-open) — one frame may show slightly wider pool composition than steady-state; a room with >7 resident dynamics still shows them all (retail trims to 7 player-nearest) — slightly purpler wedge than retail; adopt the dual pools + degrade caps + true DBObj-bounded residency in later A7-arc work | `insert_light` 0x0054d1b0 (player-sorted, capped); `add_visible_cell` 0x0052de40 (on-demand-load resident registry + flush); `add_dynamic_lights` 0x0052d410 (whole-table walk); caller 0x00452d30; `calc_point_light` 0x0059c8b0 (static 1/d³ curve — A7 fix #2) |
|
||||
| AP-84 | **BSP shadow-shape part poses = motion-table default-state frame snapshot at registration, not retail's live CPhysicsPart pose** (#175): server entities with a wire MotionTableId register their BSP part shapes at the default style's first-cycle LowFrame pose (the closed pose for doors — `GameWindow.MotionTableDefaultPose`); retail collision reads each part's CURRENT pose every test. Equivalent for the door lifecycle (closed = default pose; open = ETHEREAL bypasses collision entirely, #150) and for idle statics | `src/AcDream.App/Rendering/GameWindow.cs` (`MotionTableDefaultPose` + the RegisterServerEntityCollision override); `src/AcDream.Core/Physics/ShadowShapeBuilder.cs` (`partPoseOverride`) | Registration is one-shot in acdream (retail re-poses parts per frame); the default-state pose is the correct idle pose and the only non-ethereal pose doors ever collide in | An entity whose server-driven motion state materially MOVES a BSP-bearing part while NON-ethereal would collide at the stale default pose (no known case — doors are the dominant BSP-part weenies); revisit if animated non-ethereal BSP movers appear | `CPhysicsPart` live pose (see #150 notes); motion-table default state = CPartArray init; ShadowShapeBuilder placement-frame fallback for table-less entities |
|
||||
| AP-83 | **CylCollideWithPoint PerfectClip TOI sub-branches decoded via ACE, not the binary**: the CCylSphere family port (2026-07-05, retires AP-6) reads `collide_with_point`'s PerfectClip time-of-impact math (0x0053adb6+) from ACE `CylSphere.CollideWithPoint` because the BN x87 mush is unreadable there; two ACE-verbatim quirks ported as-is (`movement.Z + radius` in the not-definite ascending case; `GlobalCurrCenter[0]` used even for head-sphere hits — the latter matches the raw decomp read). NOT exercised in M1.5: no mover sets PerfectClip (players never do; the non-PerfectClip path — SetCollisionNormal + Collided — is decomp-verified). Separately, the grounded head-sphere slide passes the HEAD disp per retail 0x0053b843 where ACE passes the foot disp — retail wins (ACE bug, not copied) | `src/AcDream.Core/Physics/TransitionTypes.cs` (`CylCollideWithPoint`; pseudocode doc `docs/research/2026-07-05-ccylsphere-collision-family-pseudocode.md` §7-8) | The load-bearing paths (non-PerfectClip Collided; the family's step-up/step-down/land) are decomp-verified; the TOI tail is dead code until missiles arm PerfectClip | If missiles (F.3) arm PerfectClip, the two ACE quirks may diverge from retail — clip-through or wrong deflection on cylinder targets; re-decompile 0x0053acb0 in Ghidra before shipping missiles | `CCylSphere::collide_with_point` 0x0053acb0 (pc:324173, x87 mush from 0x0053adb6); ACE CylSphere.cs `CollideWithPoint` |
|
||||
| AP-84 | **CSphere `collide_with_point` PerfectClip TOI decoded via ACE, not the binary**: the CSphere family port (2026-07-07, retires TS-45) reads `collide_with_point`'s PerfectClip time-of-impact math from ACE `Sphere.CollideWithPoint` + `FindTimeOfCollision` (ported as `FindSphereTimeOfCollision`) because the BN x87 mush is unreadable there. NOT exercised in M1.5: no mover sets PerfectClip (players never do; the non-PerfectClip path — `SetCollisionNormal` + Collided — is decomp-verified). Sibling of AP-83 (the cylinder family's identical dead branch) | `src/AcDream.Core/Physics/TransitionTypes.cs` (`SphereCollideWithPoint` PerfectClip branch + `FindSphereTimeOfCollision`; pseudocode doc `docs/research/2026-07-07-csphere-collision-family-pseudocode.md` §6/§8.2) | The load-bearing path (non-PerfectClip Collided; the family's step-up/slide/land) is decomp-verified; the TOI tail is dead code until missiles arm PerfectClip | If missiles (F.3) arm PerfectClip, the ACE-derived TOI may diverge from retail — clip-through / wrong deflection on sphere targets; re-decompile 0x00537230 in Ghidra before shipping missiles | `CSphere::collide_with_point` 0x00537230 (pc:321327); ACE Sphere.cs `CollideWithPoint` |
|
||||
|
|
|
|||
|
|
@ -794,6 +794,22 @@ public sealed class GameWindow : IDisposable
|
|||
new AcDream.Core.World.WorldTimeService(
|
||||
AcDream.Core.World.SkyStateProvider.Default());
|
||||
public readonly AcDream.Core.Lighting.LightManager Lighting = new();
|
||||
|
||||
// A7.L1 (2026-07-09) — last frame's rendered visible-cell set, fed into next
|
||||
// frame's Lighting.BuildPointLightSnapshot scoping. One frame of latency
|
||||
// (~16 ms) instead of a mid-DrawInside callback: DrawableCells only becomes
|
||||
// known partway through DrawInside (after the flood + look-in merge), and the
|
||||
// #176 correction already showed that rebuilding the light pool FROM a
|
||||
// freshly-recomputed frame flood (the deleted RebuildScopedLights callback,
|
||||
// c500912b) is a flicker mechanism. Reusing last frame's already-drawn set
|
||||
// (MP-Alloc: reused HashSet, no per-frame alloc) decouples the light-scoping
|
||||
// change from DrawInside's internals entirely. _lightPoolVisibleCellsValid is
|
||||
// false until the first indoor frame completes, and is cleared on any
|
||||
// outdoor-only frame so scoping fails open (unscoped) for one frame on
|
||||
// re-entry rather than filtering by a stale dungeon's cell ids.
|
||||
private readonly HashSet<uint> _lightPoolVisibleCells = new();
|
||||
private bool _lightPoolVisibleCellsValid;
|
||||
|
||||
public readonly AcDream.Core.World.WeatherSystem Weather = new();
|
||||
// Wired into the hook router in OnLoad so SetLightHook fires
|
||||
// from the animation pipeline flip the matching LightSource.IsLit.
|
||||
|
|
@ -9255,7 +9271,13 @@ public sealed class GameWindow : IDisposable
|
|||
// collected from ALL registered (=resident-cell) lights — it is a
|
||||
// function of player position only, so camera rotation cannot change
|
||||
// it. playerViewPos carries retail's no-player fallback (camPos).
|
||||
Lighting.BuildPointLightSnapshot(playerViewPos);
|
||||
// A7.L1: candidacy is additionally scoped to last frame's rendered
|
||||
// visible-cell set (see _lightPoolVisibleCells) when available — the
|
||||
// Town Network starvation fix. Unscoped (null) until the first indoor
|
||||
// frame completes or after any outdoor-only frame.
|
||||
Lighting.BuildPointLightSnapshot(
|
||||
playerViewPos,
|
||||
_lightPoolVisibleCellsValid ? _lightPoolVisibleCells : null);
|
||||
_wbDrawDispatcher?.SetSceneLights(Lighting.PointSnapshot);
|
||||
_envCellRenderer?.SetPointSnapshot(Lighting.PointSnapshot); // A7 Fix D (D-2)
|
||||
|
||||
|
|
@ -9682,6 +9704,14 @@ public sealed class GameWindow : IDisposable
|
|||
envCellShellFilter = pviewResult.DrawableCells;
|
||||
_interiorPartition = pviewResult.Partition;
|
||||
|
||||
// A7.L1: snapshot this frame's drawn cell set for NEXT frame's light-
|
||||
// pool scoping. DrawableCells is the renderer's own reused scratch set
|
||||
// (cleared/rebuilt every DrawInside call) — copy it, don't hold a
|
||||
// reference to it.
|
||||
_lightPoolVisibleCells.Clear();
|
||||
_lightPoolVisibleCells.UnionWith(pviewResult.DrawableCells);
|
||||
_lightPoolVisibleCellsValid = true;
|
||||
|
||||
// Flap root-cause apparatus (2026-06-07): per-frame, the EXACT Build inputs at 6 dp +
|
||||
// the resulting flood count. The live flap shows flood flipping 2↔6 at an eye/player
|
||||
// identical to cm; this answers whether the inputs differ sub-cm (jitter) or are
|
||||
|
|
@ -9742,6 +9772,10 @@ public sealed class GameWindow : IDisposable
|
|||
neverCullLandblockId: playerLb,
|
||||
visibleCellIds: null,
|
||||
animatedEntityIds: animatedIds);
|
||||
|
||||
// A7.L1: no indoor draw this frame — fail open (unscoped) rather than
|
||||
// scoping next frame's light pool by a stale dungeon's cell ids.
|
||||
_lightPoolVisibleCellsValid = false;
|
||||
}
|
||||
|
||||
// Phase U.3: close the world-geometry clip bracket opened above. From here down the
|
||||
|
|
|
|||
|
|
@ -189,12 +189,15 @@ public sealed class LightManager
|
|||
/// (2) frame-FLOOD scoping `c500912b` (gaze-dependent: the under-room portal
|
||||
/// purples entered/left the pool as the camera turned — the seam-floor
|
||||
/// blink; probe: [seam-blk]/[seam-snap]). Current model: all registered
|
||||
/// (=resident) lit lights, dynamics-first then nearest-player, capped here.
|
||||
/// 128 is wider than retail's 40+7 — a documented backstop that in Hub-scale
|
||||
/// rooms only ever evicts far-out-of-range statics; adopting retail's exact
|
||||
/// dual-pool caps + degrade levels is A7-arc work. The 1024 uncap remains
|
||||
/// refuted (striped-floor artifact + the unported static 1/d³ fixture curve,
|
||||
/// A7 fix #2). Register row AP-85.</summary>
|
||||
/// (=resident) lit lights optionally FILTERED by last frame's rendered
|
||||
/// visible-cell set (A7.L1, 2026-07-09 — <see cref="BuildPointLightSnapshot"/>'s
|
||||
/// <c>visibleCells</c> param; fixes Town Network starvation without
|
||||
/// reproducing c500912b — see that method's doc), then dynamics-first nearest-
|
||||
/// player, capped here. 128 is wider than retail's 40+7 — a documented backstop
|
||||
/// that in a properly cell-scoped room only ever evicts far-out-of-range
|
||||
/// statics; adopting retail's exact dual-pool caps + degrade levels is A7-arc
|
||||
/// work. The 1024 uncap remains refuted (striped-floor artifact + the unported
|
||||
/// static 1/d³ fixture curve, A7 fix #2). Register row AP-85.</summary>
|
||||
public const int MaxGlobalLights = 128;
|
||||
|
||||
private readonly List<LightSource> _pointSnapshot = new();
|
||||
|
|
@ -239,22 +242,46 @@ public sealed class LightManager
|
|||
/// statics), then the nearest THE PLAYER (<c>Render::insert_light</c>
|
||||
/// 0x0054d1b0 insertion-sorts by squared distance to <c>Render::player_pos</c>,
|
||||
/// set from <c>player->m_position</c>, SmartBox 0x00453d3a, with the
|
||||
/// viewer-cell fallback 0x00455ab6). The pool is therefore a function of
|
||||
/// PLAYER position and light registration ONLY — camera rotation/position
|
||||
/// cannot change it. Both prior camera-coupled pools (nearest-camera cap;
|
||||
/// frame-flood scoping <c>c500912b</c>) produced the #176 seam-floor purple
|
||||
/// blink. Call once per frame before per-object selection.
|
||||
/// viewer-cell fallback 0x00455ab6). The distance SORT is therefore a function
|
||||
/// of PLAYER position and light registration ONLY — camera rotation/position
|
||||
/// cannot change it (both prior camera-ANCHORED pools — nearest-camera cap;
|
||||
/// <c>c500912b</c>'s camera-seeded re-flood — produced the #176 seam-floor
|
||||
/// purple blink by making the SORT itself camera-dependent). The optional
|
||||
/// <paramref name="visibleCells"/> candidacy FILTER (A7.L1) does not change
|
||||
/// this: it narrows the input set before the player-anchored sort runs, using
|
||||
/// a value the caller captured from last frame's already-rendered draw list,
|
||||
/// not a fresh camera-seeded computation performed here. Call once per frame
|
||||
/// before per-object selection.
|
||||
/// </para>
|
||||
/// </summary>
|
||||
/// <param name="playerWorldPos">The player's world position (render position;
|
||||
/// callers pass the camera position only when no player exists — retail's
|
||||
/// player/viewer branch).</param>
|
||||
public void BuildPointLightSnapshot(Vector3 playerWorldPos)
|
||||
/// <param name="visibleCells">
|
||||
/// A7.L1 (2026-07-09) — optional visible-cell scoping. When non-null, a light
|
||||
/// is a candidate only if it is cell-less (<c>CellId == 0</c> — the viewer fill,
|
||||
/// always in scope) or its <c>CellId</c> is in this set. Fixes the Town Network
|
||||
/// starvation case (463 registered fixtures): the player-nearest cap sorts by
|
||||
/// raw Euclidean distance, which is not a reliable proxy for "same room" in a
|
||||
/// dense, maze-like hub — a fixture on the other side of a wall can be
|
||||
/// geometrically closer than the player's own room's torches and win the cap,
|
||||
/// leaving the visible room dark. Scoping candidacy to the frame's actual
|
||||
/// visible cells (the render already computes this — callers pass last frame's
|
||||
/// <c>RetailPViewFrameResult.DrawableCells</c>, one frame of latency, to avoid
|
||||
/// re-threading a mid-render callback) removes those from contention before the
|
||||
/// cap ever applies. The distance-sort anchor stays the PLAYER either way — this
|
||||
/// parameter only narrows candidacy, it does not change the sort (the #176
|
||||
/// correction: CAMERA anchoring, not cell scoping itself, caused the earlier
|
||||
/// seam-floor flicker regression, c500912b). Null (the default) preserves the
|
||||
/// legacy unscoped behavior — outdoor / no-clipRoot callers pass null.
|
||||
/// </param>
|
||||
public void BuildPointLightSnapshot(Vector3 playerWorldPos, IReadOnlySet<uint>? visibleCells = null)
|
||||
{
|
||||
_pointSnapshot.Clear();
|
||||
foreach (var light in _all)
|
||||
{
|
||||
if (!light.IsLit || light.Kind == LightKind.Directional) continue;
|
||||
if (visibleCells is not null && light.CellId != 0 && !visibleCells.Contains(light.CellId)) continue;
|
||||
_pointSnapshot.Add(light);
|
||||
}
|
||||
if (_pointSnapshot.Count > MaxGlobalLights)
|
||||
|
|
|
|||
|
|
@ -282,13 +282,20 @@ public static class RenderingDiagnostics
|
|||
/// [indoor-light] pool=<M> cellLess=<K> registered=<R> capped=<R-M>
|
||||
/// byCell=[0x<id>:<count>,...]
|
||||
/// </code>
|
||||
/// #176 correction (2026-07-06, same day): the pool is now retail's
|
||||
/// RESIDENT-cell collection capped nearest-the-PLAYER — visible-cell scoping
|
||||
/// (the gaze-coupled pool) was the #176 flicker mechanism and is deleted, so
|
||||
/// the line no longer carries <c>visibleCells/droppedNonVisible</c>. The
|
||||
/// diagnostic value that remains: <c>cellLess==pool</c> in a fixture-rich room
|
||||
/// still means cell tagging FAILED (ParentCellId not flowing), and
|
||||
/// <c>byCell</c> shows which cells' lights are pooled.
|
||||
/// #176 correction (2026-07-06): the pool became retail's RESIDENT-cell
|
||||
/// collection capped nearest-the-PLAYER — the earlier gaze-coupled scoping
|
||||
/// (rebuilding the pool from a freshly re-flooded CAMERA-seeded set,
|
||||
/// <c>c500912b</c>) was the #176 flicker mechanism and was deleted.
|
||||
/// A7.L1 (2026-07-09): visible-cell scoping is BACK, but sourced differently —
|
||||
/// <c>LightManager.BuildPointLightSnapshot</c> now takes an optional
|
||||
/// <c>visibleCells</c> filter that <c>GameWindow</c> feeds from LAST FRAME's
|
||||
/// already-rendered <c>RetailPViewFrameResult.DrawableCells</c> (one frame of
|
||||
/// latency, no independent re-flood, no callback threaded into DrawInside) —
|
||||
/// fixes the Town Network starvation case (463 fixtures, a wall-adjacent
|
||||
/// corridor's fixtures out-ranking the player's own room in raw Euclidean
|
||||
/// distance) without reproducing the #176 mechanism. <c>byCell</c> shows which
|
||||
/// cells' lights are pooled; <c>cellLess==pool</c> in a fixture-rich room still
|
||||
/// means cell tagging FAILED (ParentCellId not flowing).
|
||||
/// Output-only, inert when off. Initial state from <c>ACDREAM_PROBE_INDOOR_LIGHT=1</c>.
|
||||
/// </summary>
|
||||
public static bool ProbeIndoorLightEnabled { get; set; } =
|
||||
|
|
@ -576,8 +583,8 @@ public static class RenderingDiagnostics
|
|||
/// point-light pool: the SET COMPOSITION the <c>[light]</c> counts can't show.
|
||||
/// Cheap no-op when <see cref="ProbeIndoorLightEnabled"/> is false; otherwise
|
||||
/// fires at most once per second. Called from
|
||||
/// <c>LightManager.BuildPointLightSnapshot</c> (the resident collection —
|
||||
/// #176 correction removed the visible-cell scoping).
|
||||
/// <c>LightManager.BuildPointLightSnapshot</c> — <paramref name="scopedSnapshot"/>
|
||||
/// already reflects any last-frame visible-cell scoping (A7.L1, 2026-07-09).
|
||||
/// </summary>
|
||||
/// <param name="allRegistered">Every registered light (<c>LightManager._all</c>).</param>
|
||||
/// <param name="scopedSnapshot">The point-light pool just built.</param>
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
using System.Collections.Generic;
|
||||
using System.Numerics;
|
||||
using AcDream.Core.Lighting;
|
||||
using Xunit;
|
||||
|
|
@ -256,6 +257,80 @@ public sealed class LightManagerTests
|
|||
Assert.Contains(torch, mgr.PointSnapshot);
|
||||
}
|
||||
|
||||
// ── Visible-cell scoping (A7.L1, 2026-07-09 — the Town Network starvation fix) ──
|
||||
// BuildPointLightSnapshot's player-nearest cap sorts by raw Euclidean distance,
|
||||
// which is not a reliable proxy for "same room" in a dense, maze-like hub: a
|
||||
// fixture on the other side of a wall can be geometrically closer than the
|
||||
// player's own room's torches. The Town Network fountain room (463 registered
|
||||
// fixtures, cap 128) went dark because far-denser, closer-in-a-straight-line
|
||||
// corridor fixtures won the cap over the room's own lights. Filtering candidacy
|
||||
// by the frame's actual visible-cell set (the render already computes this)
|
||||
// fixes it without touching the distance-sort anchor (still the PLAYER, per the
|
||||
// #176 correction — camera anchoring is what caused the earlier flicker).
|
||||
|
||||
[Fact]
|
||||
public void BuildPointLightSnapshot_VisibleCellScoping_RoomLightsSurviveOverEuclideanCloserInvisibleCell()
|
||||
{
|
||||
var mgr = new LightManager();
|
||||
|
||||
// A different, NOT-visible cell packed with fixtures that are, in raw
|
||||
// straight-line distance, closer to the player than the room's own
|
||||
// torches (e.g. a corridor on the other side of a wall).
|
||||
const uint otherCellId = 0xAAAA0102u;
|
||||
for (int i = 0; i < LightManager.MaxGlobalLights + 50; i++)
|
||||
mgr.Register(MakePoint(new Vector3(1f + i * 0.001f, 1f, 0), range: 5f, ownerId: (uint)(i + 1), cellId: otherCellId));
|
||||
|
||||
// The player's own room: a handful of torches, each FARTHER in raw
|
||||
// distance than every "other cell" fixture above, but the only cell
|
||||
// actually visible from the player's viewpoint this frame.
|
||||
const uint roomCellId = 0xAAAA0101u;
|
||||
var roomTorches = new LightSource[5];
|
||||
for (int i = 0; i < roomTorches.Length; i++)
|
||||
{
|
||||
roomTorches[i] = MakePoint(new Vector3(50f + i, 0, 0), range: 15f, cellId: roomCellId);
|
||||
mgr.Register(roomTorches[i]);
|
||||
}
|
||||
|
||||
var visibleCells = new HashSet<uint> { roomCellId };
|
||||
mgr.BuildPointLightSnapshot(playerWorldPos: Vector3.Zero, visibleCells);
|
||||
|
||||
foreach (var torch in roomTorches)
|
||||
Assert.Contains(torch, mgr.PointSnapshot);
|
||||
}
|
||||
|
||||
[Fact]
|
||||
public void BuildPointLightSnapshot_VisibleCellScoping_CellLessLightAlwaysIncluded()
|
||||
{
|
||||
// The viewer fill light (CellId==0) must survive scoping unconditionally —
|
||||
// retail's per-frame add_dynamic_light(&viewer_light, ...) is unconditional
|
||||
// (LightManager.UpdateViewerLight's doc comment).
|
||||
var mgr = new LightManager();
|
||||
var viewerFill = MakePoint(new Vector3(0, 0, 2), range: 15f, cellId: 0u);
|
||||
mgr.Register(viewerFill);
|
||||
var otherRoom = MakePoint(new Vector3(2, 0, 0), range: 5f, cellId: 0xBEEFu);
|
||||
mgr.Register(otherRoom);
|
||||
|
||||
var visibleCells = new HashSet<uint> { 0xF00Du }; // neither light's cell
|
||||
mgr.BuildPointLightSnapshot(Vector3.Zero, visibleCells);
|
||||
|
||||
Assert.Contains(viewerFill, mgr.PointSnapshot);
|
||||
Assert.DoesNotContain(otherRoom, mgr.PointSnapshot);
|
||||
}
|
||||
|
||||
[Fact]
|
||||
public void BuildPointLightSnapshot_NoVisibleCellsArg_UnscopedLegacyBehavior()
|
||||
{
|
||||
// Outdoor / no-clipRoot callers omit visibleCells — every registered lit
|
||||
// light stays a candidate, exactly the pre-A7.L1 behavior.
|
||||
var mgr = new LightManager();
|
||||
mgr.Register(MakePoint(new Vector3(1, 0, 0), 5f, cellId: 0xAAAAu));
|
||||
mgr.Register(MakePoint(new Vector3(2, 0, 0), 5f, cellId: 0xBBBBu));
|
||||
|
||||
mgr.BuildPointLightSnapshot(Vector3.Zero);
|
||||
|
||||
Assert.Equal(2, mgr.PointSnapshot.Count);
|
||||
}
|
||||
|
||||
[Fact]
|
||||
public void SelectForObject_EmptySnapshot_ReturnsZero()
|
||||
{
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue