From b4ed8e7908c029e99c397f1acfa55b57fc94e7ef Mon Sep 17 00:00:00 2001 From: Erik Date: Sun, 14 Jun 2026 18:11:15 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20file=20#136=20=E2=80=94=20red-cone=20du?= =?UTF-8?q?ngeon=20decoration=20renders=20red=20(frozen-phase=20render=20d?= =?UTF-8?q?ivergence)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Investigated the user-reported divergence (a solid-red cone in the 0x0007 dungeon that retail doesn't draw). Narrowed by elimination: - geometry, not VFX (survives particles-off) - object 0x70007055 / Setup 0x020019F0, physState=0x1C — NOT NoDraw/Hidden - its distinguishing texture 0x06006D65 (DXT1 256x128) DECODES tan/opaque offline, identical to a neighbour decoration (0x020019EE / tex 0x06006D63) that renders fine - not a per-instance tint (hook dropped) => the red is introduced at runtime in the WB bindless texture-array upload/sampling path (a #105-class "samples undefined until flushed" / layer-handle misassignment), possibly lighting. Both WB-render-migration and sky/lighting are FROZEN phases, so the fix awaits explicit sign-off. Full diagnosis + reusable diagnostic approach in the issue. Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/ISSUES.md | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index ddb9b279..02b630da 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -46,6 +46,63 @@ Copy this block when adding a new issue: --- +## #136 — "Red cone" decoration renders solid red in the 0x0007 dungeon (retail shows nothing) + +**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) + +**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). + +**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. + +**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. + +**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). + +--- + ## #135 — ~30 s low-FPS ramp at login (≈10 fps → high) before streaming settles **Status:** FIX LANDED — pending visual gate (login into the 0x0007 dungeon → FPS steady in ~1–2 s, no neighbour load/unload churn)