feat(content): S1 exact CellStruct surface-index construction, recipe 8
Campaign OVERHAUL S1 chunk A. Retail's D3DPolyRender::ConstructMesh @0x0059DFA0 is ported as one pure Core descriptor plus the Content extraction that consumes it: - side candidates come only from sides_type (0/1/2); NoPos/NoNeg mean UV-array absence only and never suppress a side (CPolygon::UnPack @0x00538650); - ST_DOUBLE's second copy is reversed with a negative normal; ST_BOTH's negative side has a negative normal and forward fan order (reverse is on the copy ordinal, not the side ordinal); - an absent UV-index array is UV index 0 (ConstructMesh @0x0059E691 xor ebx,ebx, arbitrated on the PDB-paired binary); copyVert @0x0059C080 zeroes coordinates only for a negative or out-of-range index or a vertex without UVs, never by clamping to slot 0; - the subset owner is the source surface-array index, emitted in ascending slot order with retail's per-slot mask (2 > 8 > 4 precedence, positive surface OR on signed stippling > 0); - built-EnvCell admission is (Surface.Type & (BASE1_IMAGE|BASE1_CLIPMAP)) != 0 after surface resolution (DrawEnvCell @0x0059F170 -> DrawMesh @0x0059D4A0 arg4=1); untextured slots are constructed but not emitted; - cell batches carry SourceSurfaceIndex, RetailSurfaceMask, RawSurfaceType, IsCellShell, and fixed clockwise raster cull (RenderMeshSubset @0x0059CA10); authored sides_type is no longer stored as GPU cull. Prepared-mesh serializer gains the four fields; bake recipe 7 -> 8 with a FullRebuild migration; pak format stays 2 (pinned). Ordinary GfxObj extraction is unchanged. AP-234's register row and CellMesh unification land in chunk B. Core: 32 descriptor tests. Content: 170/170. Bake: 18/18. Launcher.Core: 365/365 (Lane!=Linux). Solution Release build 0 warnings / 0 errors. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
parent
14d8fe6478
commit
acf172469e
15 changed files with 1746 additions and 296 deletions
|
|
@ -261,9 +261,17 @@ The inverted-normal lane adds the maximum-UV-span offset before that product
|
|||
|
||||
- the same authored vertex and UV may be shared within one sign lane;
|
||||
- positive- and negative-normal copies cannot alias;
|
||||
- a null UV map uses UV index `0`, rather than suppressing the candidate;
|
||||
- `copyVert @0x0059C080` writes zero UV coordinates when the UV pointer is
|
||||
absent or the index is out of range (`pseudo-C:424797-424829`);
|
||||
- a null UV map uses UV index `0`, rather than suppressing the candidate.
|
||||
**Arbitrated on the PDB-paired binary 2026-09-02 (S1 chunk A2 review):**
|
||||
`ConstructMesh @0x0059E683-0x0059E693` loads the polygon's UV-index array
|
||||
pointer, and on null executes `xor ebx,ebx`; otherwise
|
||||
`movsx ebx, byte ptr [edx+edi]` (the element is a SIGNED char). `ebx` is
|
||||
the index `copyVert` consumes. So an absent array is exactly "vertex UV
|
||||
slot 0", not a zero coordinate;
|
||||
- `copyVert @0x0059C080` writes zero UV coordinates only when that index is
|
||||
negative, when it is `>= CVertex::num_uvs`, or when the VERTEX has no UV
|
||||
array (`edi[4] == 0`) (`pseudo-C:424797-424829`; Ghidra confirms the three
|
||||
conditions). It never clamps an out-of-range index to slot 0;
|
||||
- `copyVert` multiplies the authored normal by the selected `+1/-1`
|
||||
(`424791-424793`).
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue