fix #426: extract solid-colour (NO_POS_UVS) faces; skip untextured subsets only on building shells and cells like retail
The Holtburg windmill axle (GfxObj 0x010010CE, 8 polygons, all
Stippling.NoPos + SurfaceType.Base1Solid) extracted to a 0-vertex mesh.
NoPos ("NO_POS_UVS", acclient.h:7380-7388) means "this side has no
texture coordinates" — true of every solid-colour polygon, since
nothing samples them — not "there is no positive face". Extraction read
it as the latter and dropped the polygon entirely, client-wide, for
every untextured polygon on every object.
Retail's D3DPolyRender::DrawMesh (@0x0059d4a0, named-retail decomp
~line 426048) draws an untextured subset on an ordinary object exactly
like a textured one; the only retail cases that skip an untextured
subset are a building shell (RenderDeviceD3D::DrawBuilding @0x0059f2a0
sets ObjBuildingOrBuildingPart=1) or an EnvCell interior
(RenderDeviceD3D::DrawEnvCell @0x0059f170, arg4=1). The #119
investigation's "retail's skipNoTexture never draws them either"
conclusion was itself wrong as a general rule.
- MeshExtractor.PrepareGfxObjMeshData / GfxObjMesh.Build: emit the
positive side whenever PosSurface is a valid index, regardless of
NoPos; the existing UV-index-0 fallback already produces zero
texcoords for a NoPos polygon with no UVs on the wire.
- RetailUntexturedSurfacePolicy.IsUntextured(SurfaceType): the one
place that answers "is this surface textured"
((type & (Base1Image|Base1ClipMap)) == 0), replacing the old
`isSolid = NoPos || Base1Solid` (which also mis-classified a NEG-side
batch by the POS-side's NoPos flag).
- RetailUntexturedSubsetPolicy.Draws(isBuildingShell, isUntextured):
the shared draw-time gate wired into WbDrawDispatcher.ClassifyBatches,
.PackedOracle.ClassifyPackedBatches, and
.DirectionalShadows.AddDirectionalShadowBatches — one predicate so the
three walks cannot drift (Campaign VM VM6 lesson).
- CellMesh.cs / MeshExtractor.PrepareCellStructMeshData deliberately
KEEP their NoPos-gated skip for cell-wall geometry — retail's
DrawEnvCell really does skip untextured subsets there; register row
AP-234 documents the NoPos-vs-Surface.Type approximation.
- PakFormat.CurrentBakeToolVersion 4->5 (LauncherInstallRecordStore in
lockstep): a pak baked by an older tool is missing every untextured
face. No bake was run as part of this commit.
Also fixed: WorldBuilder's own upstream ObjectMeshManager.cs has the
identical NoPos bug (ObjectMeshManager.cs:959,984) — our port had
faithfully carried it over, and our own conformance test
(Build_NoPosFlag_OnlyEmitsNegSide) asserted the bug as correct WB
conformance. Renamed/reworded to Build_NoPosFlag_EmitsBothPosAndNegSide
with a citation for why retail decomp overrides WB here.
Issue119UpNullGfxObjDumpTests re-run against the installed DAT:
#119's own two objects (0x010002B4 9/9 polys, 0x010008A8 1/1 poly) now
gate DRAWS on every polygon instead of extracting to nothing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Erik
parent
51a5fe99ef
commit
517d17b4b3
18 changed files with 755 additions and 40 deletions
|
|
@ -24,6 +24,74 @@ What does NOT go here:
|
|||
- Every session: scan OPEN issues at start; promote/close anything we touched during the session before ending.
|
||||
- Promoting to a Phase: mark as `DONE (promoted to Phase X)` + commit SHA where the Phase entry landed.
|
||||
|
||||
## #426 — Every solid-colour (untextured) polygon on every object client-wide was invisible: mesh extraction misread NO_POS_UVS as "no positive face"
|
||||
|
||||
**Status:** ✅ FIXED 2026-08-23 (found on the Holtburg windmill axle, GfxObj
|
||||
0x010010CE, 30.4N 28.2E).
|
||||
**Component:** content extraction (`MeshExtractor`/`GfxObjMesh`) + draw-time
|
||||
classification (`WbDrawDispatcher`)
|
||||
|
||||
**Symptom:** the windmill axle's 8 polygons (all `Stippling.NoPos` +
|
||||
`SurfaceType.Base1Solid`) extracted to a 0-vertex mesh —
|
||||
`[up-null] 0x010010CE produced a 0-vertex mesh`. Not an isolated case: EVERY
|
||||
flat-coloured (untextured) polygon on EVERY GfxObj client-wide extracted to
|
||||
nothing, because `PrepareGfxObjMeshData`/`GfxObjMesh.Build` gated emission of
|
||||
a polygon's positive side on `!Stippling.HasFlag(StipplingType.NoPos)`.
|
||||
|
||||
**Root cause:** `StipplingType.NoPos` (`NO_POS_UVS = 0x4`,
|
||||
`docs/research/named-retail/acclient.h:7380-7388`) means "this side has no
|
||||
texture coordinates" — true of every solid-colour polygon, since nothing
|
||||
samples them — NOT "there is no positive face". The extraction code read it
|
||||
as the latter and silently dropped the polygon entirely. Retail's
|
||||
`D3DPolyRender::DrawMesh` (@0x0059d4a0,
|
||||
`docs/research/named-retail/acclient_2013_pseudo_c.txt` ~line 426048) draws
|
||||
an untextured subset (`(surface->type & 6) == 0`, i.e. neither
|
||||
`BASE1_IMAGE` nor `BASE1_CLIPMAP`) on an ORDINARY object exactly like a
|
||||
textured one; the ONLY retail cases that skip an untextured subset are a
|
||||
BUILDING SHELL (`RenderDeviceD3D::DrawBuilding` @0x0059f2a0 sets
|
||||
`ObjBuildingOrBuildingPart = 1`) and an EnvCell interior
|
||||
(`RenderDeviceD3D::DrawEnvCell` @0x0059f170, `arg4 = 1`). The earlier #119
|
||||
investigation's "retail's skipNoTexture never draws them either" conclusion
|
||||
was itself wrong — that only happened to hold for #119's two specific
|
||||
GfxObjs because retail's per-model draw call passes `arg4` from the caller's
|
||||
own context, not because untextured subsets are universally skipped (see the
|
||||
#119 amendment below).
|
||||
|
||||
**Fix:** `MeshExtractor.PrepareGfxObjMeshData` and `GfxObjMesh.Build` now
|
||||
emit a polygon's positive side whenever `PosSurface` is a valid index,
|
||||
regardless of NoPos; a NoPos polygon with no UVs on the wire falls back to
|
||||
UV index 0 / zero texcoords (the pre-existing fallback path, unchanged).
|
||||
`RetailUntexturedSurfacePolicy.IsUntextured(SurfaceType)`
|
||||
(`src/AcDream.Core/Meshing/RetailUntexturedSurfacePolicy.cs`) is the ONE
|
||||
place that now answers "is this surface textured", built from the surface's
|
||||
own `Type` flags (`Base1Image`/`Base1ClipMap`) instead of the polygon's
|
||||
Stippling — `MeshExtractor`'s `isSolid`/`TextureKey.IsSolid` now uses it
|
||||
(previously `isSolid = NoPos || Base1Solid`, which also mis-classified a
|
||||
NEG-side batch by the POS-side's NoPos flag). `RetailUntexturedSubsetPolicy
|
||||
.Draws(isBuildingShell, isUntextured)` in the same file is the shared
|
||||
draw-time predicate wired into `WbDrawDispatcher.ClassifyBatches`,
|
||||
`.PackedOracle.ClassifyPackedBatches`, and
|
||||
`.DirectionalShadows.AddDirectionalShadowBatches` — the ONE thing that
|
||||
still skips an untextured subset is a building-shell entity, matching
|
||||
retail's `DrawBuilding` gate; the shadow caster and receiver agree by
|
||||
construction. `CellMesh.cs` and `MeshExtractor.PrepareCellStructMeshData`
|
||||
(EnvCell/cell-wall geometry) deliberately KEEP their existing NoPos-gated
|
||||
skip — retail's `DrawEnvCell` really does skip untextured cell subsets, and
|
||||
the NoPos flag remains an approximation of that rule rather than a bug (see
|
||||
register row AP-234).
|
||||
|
||||
**Verification:** `Issue119UpNullGfxObjDumpTests` (Lane=InstalledDat) reran
|
||||
against the installed DAT post-fix: #119's own two objects (0x010002B4, 9/9
|
||||
polygons; 0x010008A8, 1/1 polygon — both all-NoPos+Base1Solid) now gate
|
||||
`DRAWS` on every polygon instead of producing a 0-vertex mesh.
|
||||
|
||||
**Pak version:** `PakFormat.CurrentBakeToolVersion` 4→5 (also
|
||||
`LauncherInstallRecordStore.CurrentBakeToolVersion`, kept in lockstep) — a
|
||||
pak baked by an older tool is missing every untextured face and MUST be
|
||||
regenerated; no bake was run as part of this fix (out of scope for a code
|
||||
commit — the next scheduled bake picks it up via the version bump forcing a
|
||||
rebuild).
|
||||
|
||||
## #425 — Options Apply "Atmospheric rendering" fell back to the default path and stayed locked out: Low's 64 MiB resident budget did not scale with resolution
|
||||
|
||||
**Status:** ✅ FIXED 2026-08-23 (found at the owner's VM3/VM6 gate launch).
|
||||
|
|
@ -16763,6 +16831,18 @@ failing step pins which candidate fires.
|
|||
**Filed:** 2026-06-11 (T5 comprehensive gate, user items 9+13)
|
||||
**Component:** render — mesh upload / content inclusion
|
||||
|
||||
**AMENDED 2026-08-23 (#426):** the "Retail's skipNoTexture never draws them
|
||||
either" conclusion below is WRONG as a general rule — retail only skips an
|
||||
untextured (solid-colour) subset on a BUILDING SHELL or inside an EnvCell;
|
||||
an ORDINARY object's untextured polygons DO draw, and the extraction was
|
||||
dropping every one of them client-wide via a NoPos misread (fixed by #426).
|
||||
Post-fix, `Issue119UpNullGfxObjDumpTests` shows BOTH of this entry's
|
||||
GfxObjs now gate DRAWS on every polygon instead of extracting to nothing —
|
||||
whether that geometry is actually visible on screen (i.e. whether either
|
||||
object is a building-shell part, which would still skip it at draw time)
|
||||
is unverified and NOT the same question as the extraction-level "no draw"
|
||||
claim this entry made in 2026-06-12.
|
||||
|
||||
**RESOLUTION (2026-06-12) — three root causes, fixed in sequence, each
|
||||
pinned by the ACDREAM_DUMP_ENTITY decisive probe (`3cf6bcc`):**
|
||||
1. **`2163308` — Tier-1 cross-entity batch serving** (the broken stairs +
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue