Task was to name the axis order and scale of the tie vertex positions by
fitting the class header's bounding sphere. The sphere does not exist: at
+0x30 those bytes are zero on every class. Scanning the header for
float-like words found +0x10, +0x14 and +0x18 (the LOD switch distances,
already named) and +0x40 on 1,676 of 1,864 classes, which is not a sphere.
What the run produced instead is a retraction. Dumping one packet's vertex
region raw shows the first 16 bytes are header material, not a vertex --
0x0000df20 is not a coordinate, and the words after it are the vif and
material words. A 16-byte group does recur at +64 and +128 with identical
structure, so the stride is not uniform: some elements are 4 bytes, some 16,
and the run length varies.
Two candidate bases were measured and neither clusters. With packet +
vert_ofs the per-class extents run median 64,976, p90 65,517; with class +
vert_ofs, median 55,213, p90 64,352. Both span the whole i16 range, where a
position triple in a class-local frame would span a fraction of it. The region
bounds are right -- vert_ofs + vert_size + scissor_size is the length -- it is
the element layout inside it that is wrong.
The i16[3] marker does not rescue it: bucketing every fourth element by the
marker's high byte gives markers 0, 0x48, 0xff and 0x01 with thousands of
vertices each, and only 0x48 shows a position signature (i16[1] extent 425
against 65,535 on the other two axes). The same marker 0 bucket spans all
three axes at full range, so the bucket does not select a layout.
The 95,612-vertex count and the 82.5% texcoord fixedness figure were computed
on the 16-byte reading and are now untested against the correct stride, which
is not yet known. The LOD1/LOD2-sharing test stays the strongest evidence for
positionality and is stride-insensitive.
ReaperOfVeriod
e5cd3df40e