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
@@ -2075,3 +2075,70 @@ and forgets the `* 100` reports "1.0%" for 99.4%. That happened here, in the
 diagnostic line only -- the assertions compare fractions and were always right --
 but it is the same family of error as everything else in this log: the readout
 disagreeing with the claim.
 ## Tie slots 3, 6 and 7: what they are not
 Having established that `i16[0..2]` are positions, the remaining slots were
 attacked with two more measurements rather than by inspection.
 ### Does slot 3 index a skeleton?
 `i16[3]` holds 201 distinct values in `0..=254`, and **50 distinct values within a
 single draw packet** (median, 1,804 records). A material or texture-set index
 would be constant per packet, so it is per vertex -- which invites the obvious
 reading: tie objects are skinned, and slot 3 is a joint index.
 That reading is wrong. If it named a joint, vertices sharing it would sit
 together. They do not:
    mean pairwise distance, same slot-3 value        14,481
    mean pairwise distance, different slot-3 value  13,795
    ratio different/same                              0.95x
    control: same position-x bucket                   8,105
 Vertices sharing a slot-3 value are if anything marginally *farther* apart than
 vertices differing in it -- 0.95x, the wrong side of neutral, though not far
 enough to claim much on its own. The control shows the measurement works:
 bucket by position-x and pairs collapse to 8,105, half the global distance.
 So slot 3 is not a skin index. It is also not shared across LODs: 75.3%
 same-class against a 78.7% control, i.e. no signal at all. Per-vertex, in
 `0..=254`, correlated with neither the geometry it sits in nor the detail level.
 **It is not understood**, and no reading is offered here. A per-vertex phase
 would fit the arithmetic, but that is a guess and is labelled as one.
 ### Slots 6 and 7 are mostly not per-vertex
 Distinct values per draw packet, median over 1,804 records:
 | slot | median | constant for the whole packet |
 | --- | ---: | ---: |
 | `i16[0..2]` | 13-17 | 0% |
 | `i16[4]`, `i16[5]` | 6, 4 | 0% |
 | `i16[6]` | 2 | **43%** |
 | `i16[7]` | 4 | **34%** |
 `i16[6]` and `i16[7]` take a single value across the entire packet in well over a
 third of records, and two or three values in the median. Whatever they are, they
 are usually a property of the packet rather than of the vertex -- consistent with
 the 91.8%/88.9% dominance of 4096 and 0 respectively. They are left unnamed.
 ### A note on why the per-slot LOD test does not generalise
 Run across all eight slots, the LOD1/LOD2 overlap test discriminates only on
 `i16[0..2]`:
 | 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 |
 The other slots come from small value sets -- 226 to 1,759 distinct values across
 a level -- so two arbitrary sets of that size overlap heavily whether or not the
 field means anything. The test's power came from `i16[0..2]` being the only slots
 with tens of thousands of distinct values. **A passing result from a method that
 has run out of discriminative power is not a passing result**, and the 1x rows are
 recorded so the table is not later mistaken for nine confirmations.
@@ -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