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 2026-08-23 11:20:24 +02:00
parent 51a5fe99ef
commit 517d17b4b3
18 changed files with 755 additions and 40 deletions

View file

@ -347,9 +347,20 @@ public sealed class MeshExtractor {
if (poly.VertexIds.Count < 3) continue;
// Handle Positive Surface
if (!poly.Stippling.HasFlag(StipplingType.NoPos)) {
AddSurfaceToBatch(poly, poly.PosSurface, false);
}
// #426 (2026-08-23, Holtburg windmill axle 0x010010CE): NoPos
// ("NO_POS_UVS", acclient.h:7386) means "this side has no texture
// coordinates" — that's true of every SOLID-COLOUR polygon, not
// "there is no positive face". Retail's D3DPolyRender::DrawMesh
// draws untextured (solid) subsets on ordinary objects same as
// textured ones (see RetailUntexturedSurfacePolicy); only a
// building shell or an EnvCell interior skips them, and that is
// a DRAW-time decision (RetailUntexturedSubsetPolicy, applied in
// WbDrawDispatcher), not an extraction-time one. So the positive
// side is always emitted when PosSurface is a valid index;
// AddSurfaceToBatch already falls back to UV index 0 / zero
// texcoords (via BuildPolygonIndices) when NoPos leaves no UVs to
// read.
AddSurfaceToBatch(poly, poly.PosSurface, false);
// Handle Negative Surface
// Some objects use Clockwise CullMode to indicate negative surface data is present
@ -376,7 +387,13 @@ public sealed class MeshExtractor {
TextureFormat textureFormat;
UploadPixelFormat? uploadPixelFormat = null;
UploadPixelType? uploadPixelType = null;
bool isSolid = poly.Stippling.HasFlag(StipplingType.NoPos) || surface.Type.HasFlag(SurfaceType.Base1Solid);
// #426: "solid" (untextured) is a SURFACE fact, not a
// polygon-stippling fact — see RetailUntexturedSurfacePolicy.
// The old `NoPos ||` term conflated "this polygon's positive
// side has no UVs" with "this surface is untextured"; it also
// wrongly classified a NEG-side batch by the POS-side's NoPos
// flag, since this method is shared by both sides.
bool isSolid = RetailUntexturedSurfacePolicy.IsUntextured(surface.Type);
bool isClipMap = surface.Type.HasFlag(SurfaceType.Base1ClipMap);
uint paletteId = 0;
bool isDxt3or5 = false;
@ -710,6 +727,20 @@ public sealed class MeshExtractor {
// GL cull enum: 0 = pos, 1 = pos twice with reversed winding,
// 2 = pos + neg surface. The DAT-side NoPos/NoNeg flags still
// suppress hidden portal/cap faces before they reach our mesh.
//
// #426: unlike PrepareGfxObjMeshData (ordinary objects — fixed to
// emit every NoPos-flagged positive side, since NoPos means "no
// UVs", not "no face"), this NoPos gate is INTENTIONALLY kept.
// Cell-wall geometry draws through retail's
// RenderDeviceD3D::DrawEnvCell (@0x0059f170), which calls
// D3DPolyRender::DrawMesh with arg4=1 and skips every UNTEXTURED
// subset — approximated here by the polygon's own NoPos flag
// rather than by resolving Surface.Type
// (Base1Image/Base1ClipMap, see RetailUntexturedSurfacePolicy)
// before this decision is made. See
// docs/architecture/retail-divergence-register.md AP-234. Do NOT
// remove this gate to mirror the GfxObj fix — that would draw
// solid-colour cell-wall faces retail never shows.
bool hasPos = !poly.Stippling.HasFlag(StipplingType.NoPos);
bool hasNeg = !poly.Stippling.HasFlag(StipplingType.NoNeg);
@ -745,7 +776,13 @@ public sealed class MeshExtractor {
TextureFormat textureFormat;
UploadPixelFormat? uploadPixelFormat = null;
UploadPixelType? uploadPixelType = null;
bool isSolid = poly.Stippling.HasFlag(StipplingType.NoPos) || surface.Type.HasFlag(SurfaceType.Base1Solid);
// #426: "solid" (untextured) is a SURFACE fact, not a
// polygon-stippling fact — see RetailUntexturedSurfacePolicy.
// The old `NoPos ||` term conflated "this polygon's positive
// side has no UVs" with "this surface is untextured"; it also
// wrongly classified a NEG-side batch by the POS-side's NoPos
// flag, since this method is shared by both sides.
bool isSolid = RetailUntexturedSurfacePolicy.IsUntextured(surface.Type);
bool isClipMap = surface.Type.HasFlag(SurfaceType.Base1ClipMap);
uint paletteId = 0;
bool isDxt3or5 = false;

View file

@ -22,9 +22,15 @@ public static class PakFormat {
/// version 3 embeds exact render-pass translucency in each texture batch
/// so production never rebuilds surface metadata from live DAT. Version 4
/// adds complete immutable flat collision and EnvCell-topology payloads.
/// The binary format remains version 1.
/// Version 5 (#426, 2026-08-23) extracts untextured (solid-colour)
/// positive faces that versions &lt;=4 dropped — every GfxObj polygon
/// whose Stippling carries NoPos (NO_POS_UVS) previously extracted to
/// zero vertices on its positive side, so any pak baked by an older tool
/// is missing those faces (e.g. the Holtburg windmill axle 0x010010CE,
/// 8 polygons all NoPos + Base1Solid, extracted to a 0-vertex mesh). The
/// binary format remains version 1.
/// </summary>
public const uint CurrentBakeToolVersion = 4;
public const uint CurrentBakeToolVersion = 5;
}
/// <summary>