Tie slots 3, 6, 7: two readings excluded, and why the LOD test stops working

Having established that i16[0..2] are positions, ran the same LOD-overlap method across all eight slots to see whether it discriminates elsewhere. It does not, and that is worth recording before someone reads the passing numbers as nine confirmations: slot same class control ratio i16[0] 97.0% 3.0% 32x i16[1] 96.7% 3.2% 30x i16[2] 96.4% 6.0% 16x i16[3] 75.3% 78.7% 1x i16[4..7] 68-91% 52-79% 1x Only i16[0..2] carry signal, because they are the only slots with tens of thousands of distinct values. The rest draw from sets of 226 to 1,759 values, so any two sets of that size overlap heavily regardless of what the field means. A passing result from a method that has run out of discriminative power is not a passing result. Slot 3 excluded as a skin/joint index. It holds 201 values in 0..=254 and 50 distinct values within a single draw packet, so it is per-vertex, not per-material -- which invites the obvious reading, since tie objects are skinned. Wrong: mean pairwise distance, same slot-3 value 14,481 mean pairwise distance, different slot-3 value 13,795 ratio 0.95x control: same position-x bucket 8,105 Vertices sharing a slot-3 value are marginally FARTHER apart than vertices differing in it. The control halves the distance, so the measurement works; the 0.95x is on the wrong side of neutral, though by too little to claim much on its own. Combined with no LOD sharing (75.3% against a 78.7% control), slot 3 is per-vertex, uncorrelated with the geometry it sits in and with the detail level. Recorded as not understood. A per-vertex animation phase fits the arithmetic and is labelled a guess rather than offered as a reading. Slots 6 and 7 are mostly not per-vertex. Distinct values per draw packet, median over 1,804 records: i16[0..2] 13-17 constant for the whole packet 0% i16[4,5] 6, 4 0% i16[6] 2 43% i16[7] 4 34% They take a single value across an entire packet in well over a third of records, which matches the 91.8%/88.9% dominance of 4096 and 0. Unnamed. So the tie element is: position, byte-sized index, texcoords, layout tag, and two slots characterised but not named. Positions, texcoord placement, element size and the layout selector are all asserted; the remaining three are not, and the reasons they are not are now written down rather than left as silence. On "is Phase 2 nearly done": 40 items closed, 9 open. The nine are the hard ones -- collision cells blocked on the game's own code, volumes not located at all, moby_anim ruled out but unexplained, chunk record fields unnamed. Progress on the checklist is real but the remainder is not the easy tail.
2026-10-13 07:24:29 +02:00
parent e86de3c73e
commit bc5ebe559f
2 changed files with 74 additions and 1 deletions
@@ -310,7 +310,13 @@ Phase 1 hands over the extents; this phase works out what each one contains.
      Within the all-zero case, `i16[3] == 0` exactly (5,851) is a third
      distribution at 62%. Three cases: `0x00/0x00`, `0x00/1..255`, and non-zero
      high byte.
- [ ] The remaining tie vertex **fields are not named.** `i16[0..3]` span the full
+- [~] The remaining tie vertex **fields are not named**, and two readings are now
+      excluded. `i16[6]`/`i16[7]` are constant across a whole draw packet in
+      43%/34% of records, so they are usually per-packet rather than per-vertex.
+      `i16[3]` is per-vertex (50 distinct values per packet) but **not a skin or
+      joint index**: vertices sharing it are 0.95x *farther* apart than vertices
+      differing in it, against a control that halves. It is also unshared across
+      LODs. Recorded as not understood rather than guessed.
      `i16` range with 10,803-13,421 distinct values each. `i16[0..2]` are most
      likely position, but that is not established.
 - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at