Rewrite the #136 entry with the definitive root cause (editor-only dat placement marker hidden by retail's distance degrade, inherited as visible from the WB-derived render path) replacing the earlier refuted texture-pipeline hypothesis; mark FIXED. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik
parent
6f81e2c91d
commit
fd0ecfcf2e
1 changed files with 36 additions and 49 deletions
|
|
@ -46,60 +46,47 @@ Copy this block when adding a new issue:
|
|||
|
||||
---
|
||||
|
||||
## #136 — "Red cone" decoration renders solid red in the 0x0007 dungeon (retail shows nothing)
|
||||
## #136 — DONE — "red cone" in the 0x0007 dungeon was an editor-only placement marker acdream drew (retail hides it)
|
||||
|
||||
**Status:** OPEN — root-cause narrowed; fix touches a FROZEN phase (awaiting decision)
|
||||
**Severity:** LOW (cosmetic; one decoration in one dungeon)
|
||||
**Filed:** 2026-06-14
|
||||
**Component:** rendering — WB bindless texture-array pipeline (FROZEN) / possibly lighting (FROZEN)
|
||||
**Status:** FIXED `6f81e2c` (2026-06-14) — verified live via frame dump: the red cone +
|
||||
green floor "petals" are gone, all real dungeon decorations still render. User-approved
|
||||
frozen-phase fix.
|
||||
**Severity:** LOW (cosmetic; one marker in one dungeon)
|
||||
**Filed/Fixed:** 2026-06-14
|
||||
**Component:** rendering — EnvCell static-object hydration (WB-derived path) vs retail degrade
|
||||
|
||||
**Description:** In the `0x0007` Town Network dungeon, a static decoration renders as a
|
||||
solid bright-RED cone (apex toward the floor) ~3 m up, ~6.8 m from the login spawn. The
|
||||
user's side-by-side retail client shows NOTHING there — acdream draws geometry retail
|
||||
doesn't. Became visible only after the #135 login-into-dungeon fix placed the player at the
|
||||
exact saved spawn next to it (the object always existed; it wasn't reachable/rendered
|
||||
before).
|
||||
**Description:** In the `0x0007` Town Network dungeon a bright-RED downward cone (+ a
|
||||
green/red shape on the floor) rendered ~6 m from the login spawn; the user's side-by-side
|
||||
retail client showed NOTHING there. Became visible only after the #135 login-into-dungeon
|
||||
fix placed the player at the exact saved spawn next to it.
|
||||
|
||||
**Root cause / status (investigated 2026-06-14):** narrowed by elimination, NOT yet fixed.
|
||||
- It is GEOMETRY, not a VFX: survives with particle rendering fully disabled.
|
||||
- The object: server static landblock object `guid=0x70007055` (ACE `0x7`+lb`0x0007`+idx
|
||||
`0x55`), Setup `0x020019F0`, `physState=0x1C` (Ethereal) — **NoDraw (0x20) and Hidden
|
||||
(0x4000) are NOT set**, so it's not acdream ignoring retail's NODRAW_PS gate
|
||||
(`acclient.h:2822`; `CPhysicsObj::set_nodraw` 0x0050fca0).
|
||||
- Setup `0x020019F0` = 1 part (GfxObj `0x0100447F`, 23 polys), 2 surfaces; it is
|
||||
near-IDENTICAL to neighbour decoration `0x020019EE` (renders FINE) — they share surface
|
||||
`0x0800122B` and differ only in one surface: cone `0x0800162B` → tex `0x06006D65`,
|
||||
neighbour `0x08001629` → tex `0x06006D63`.
|
||||
- Both distinguishing textures are `PFID_DXT1 256x128`, and BOTH **decode to the same
|
||||
tan/beige, fully-opaque** image offline (`SurfaceDecoder`: cone avgRGB (210,179,126),
|
||||
neighbour (214,181,127), 0% alpha). So the source texture is NOT red and NOT transparent
|
||||
— acdream's decode is correct.
|
||||
- It is NOT a per-instance tint/highlight (that hook was dropped; `EnvCellRenderer`).
|
||||
- => The red is introduced at RUNTIME, downstream of decode: most likely the WB bindless
|
||||
`sampler2DArray` UPLOAD/SAMPLING path (a layer that samples UNDEFINED storage until a
|
||||
flush runs — the #105 white-walls mechanism class, `ManagedGLTextureArray` PendingUpdate),
|
||||
or a layer/handle misassignment for this specific texture. Lighting not fully excluded.
|
||||
**Root cause (definitive):** the cone is ONE dat-hydrated EnvCell static object (`guid=0`,
|
||||
`id=0x40000835`, Setup `0x02000C39` / GfxObj `0x010028CA`) baked into cell `0x00070145`,
|
||||
using pure red+green MARKER surfaces (`0x08000109` red, `0x0800010A` green). It is an
|
||||
**editor-only placement marker**: its `DIDDegrade` table `0x11000118` =
|
||||
`{slot0 Id=mesh MaxDist=0, slot1 Id=0 MaxDist=FLT_MAX}` — visible ONLY at distance 0 (the
|
||||
WorldBuilder editor origin) and degraded to GfxObj **id 0 (= nothing)** at any real distance.
|
||||
Retail's distance-based degrade (`CPhysicsPart::UpdateViewerDistance` 0x0050E030 → `Draw`
|
||||
0x0050D7A0 draws `gfxobj[deg_level]`) therefore never draws it in the live client. acdream's
|
||||
render path is extracted from **WorldBuilder**, which — being an editor — renders every cell
|
||||
static's base mesh directly and has **no degrade handling at all** (zero `DIDDegrade` refs in
|
||||
`references/WorldBuilder`), so acdream inherited "show the marker" and drew it forever. (NOT
|
||||
a texture/lighting bug — the cone's *own* object 0x70007055 decodes tan and was a red
|
||||
herring; the marker is a separate `guid=0` dat static.)
|
||||
|
||||
**Why deferred:** the fix lands in the **WB rendering migration** (and possibly **sky/
|
||||
lighting**) — both FROZEN phases (CLAUDE.md). A genuine defect, but touching a frozen
|
||||
subsystem needs explicit user sign-off; flagged for that decision. Also: the acdream dev
|
||||
window can't be granted to computer-use (not a Start-menu app) and acdream has no
|
||||
screenshot-to-disk feature, so autonomous visual verification needs a frame-dump feature
|
||||
added first.
|
||||
**Fix (`6f81e2c`):** `GfxObjDegradeResolver.IsRuntimeHiddenMarker()` detects the editor-marker
|
||||
pattern (`HasDIDDegrade` + `Degrades[0].MaxDist==0` + a degrade entry with `Id==0`). EnvCell
|
||||
static-object hydration (`GameWindow.cs` ~5793) skips such GfxObjs — whole-stab for bare
|
||||
GfxObj stabs, per-part for Setup stabs (an all-marker Setup then drops via `meshRefs.Count==0`).
|
||||
Faithful equivalent of retail's runtime degrade for static geometry (always viewed at
|
||||
distance > 0); real LOD objects (`slot0.MaxDist>0`) and degrade-to-real-mesh objects are
|
||||
untouched. 4 new `GfxObjDegradeResolver` unit tests.
|
||||
|
||||
**Files:** `src/AcDream.App/Rendering/Wb/ManagedGLTextureArray.cs` (array upload/flush),
|
||||
`src/AcDream.App/Rendering/Wb/TextureCache.cs` (id→array/layer), `mesh_modern.frag:87`
|
||||
(bindless `sampler2DArray(vTextureHandle)`), the cone = `0x70007055`/Setup `0x020019F0`/tex
|
||||
`0x06006D65` in cell `0x00070145`.
|
||||
|
||||
**Diagnostic approach (reusable):** a throwaway `RedConeSetupProbeTests` dumped the
|
||||
Setup→part→surface→SurfaceTexture→texture chain + decoded alpha/avg-color from the dat; the
|
||||
`[static-spawn]` + nearby-entity probes in `OnLiveEntitySpawnedLocked`/`OnUpdate` ID'd the
|
||||
guid/flags. A draw-time probe of the cone's resolved bindless handle/layer/PendingUpdateCount
|
||||
would confirm the exact mechanism.
|
||||
|
||||
**Acceptance:** the `0x70007055` decoration renders with its tan texture (matching its
|
||||
neighbour) OR is correctly suppressed to match retail (which shows nothing there).
|
||||
**Follow-up (not done):** outdoor `LandBlockInfo.Objects` stabs could carry the same markers;
|
||||
apply `IsRuntimeHiddenMarker` there too if any surface. Also revealed (separate): the per-
|
||||
pixel point-light shader overblows close torches (no per-channel `min(scale·color,color)` cap
|
||||
vs retail `calc_point_light`) — the bright-red dungeon WALL under normal lighting; tracked
|
||||
under the #79/#93 A7 lighting umbrella.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue