diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 812558c..13f3f38 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -1705,7 +1705,7 @@ fixedness over 36,501 level-0 vertices locates the fields: (i16[0], i16[1]) 1.1% not a texcoord (i16[2], i16[3]) 4.8% not a texcoord - (i16[4], i16[5]) 73.6% <- the texcoords + (i16[4], i16[5]) 73.6% <- SCORED as the texcoords; see the retraction below (i16[6], i16[7]) 76.6% <- the near-constant 4096/0 pair **`(6,7)` scores higher and is not a texcoord.** It is the near-constant @@ -2800,3 +2800,42 @@ coordinate produces in 12.4 fixed point, which is where the earlier texcoord reading came from and why it looked convincing on the records that are flat. Asserted in `tie_vertex_regions_split_between_vif_and_flat`. + + +## RETRACTED: the tie texcoord field is at `i16[4]`/`i16[5]` + +The 73.6% figure above, and the claim that slot pair is the texcoord, do not +survive. Two separate problems. + +**It was measured on a reading that has since been retracted.** The 73.6% was +computed across all records at a 16-byte element stride. `e5cd3df` established +that the stride is not 16 -- half the records are VIF packets and half are flat -- +so the numbers describe neither population cleanly. + +**And on the flat records, the fixed-point reading fails.** The question that +separates a 12.4 fixed-point texcoord from anything else is how many of a slot's +distinct values are multiples of 4096 at all. For a texcoord it is all of them. +Measured on the **flat** records only, levels 0-2, 930 records and 47,909 +vertices: + + slot distinct of which are multiples of 4096 + i16[4] 1,488 16 + i16[5] 1,261 16 + i16[6] 966 4 + i16[7] 489 5 + +One percent. The dominant *pairs* do look like UV corners -- `(0,0)` 5,773, +`(0,4096)` 5,500, `(4096,4096)` 5,059, `(4096,0)` 4,521 -- and that is exactly +why the claim was persuasive. But it is a statement about the most frequent +values, not about the field, and 1,472 of the 1,488 values in `i16[4]` are not +multiples of 4096 at all. + +This is the same failure shape as the moby class-ID artifact, one level down: a +small set of dominant values that happen to satisfy the test, scored as though +the whole population did. The 73.6% is the arithmetic being right about the +popular values and the conclusion being wrong about the field. + +So: on a flat record, `i16[4]`/`i16[5]` are **not identified**, and the texcoord +slot of a tie vertex is unknown. What survives from the original section is the +boundary work -- `vert_ofs + vert_size + scissor_size` is the region length -- and +the LOD1/LOD2 sharing result, which is stride-insensitive. diff --git a/docs/roadmap.md b/docs/roadmap.md index d02582f..0294665 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -315,12 +315,26 @@ Phase 1 hands over the extents; this phase works out what each one contains. `0..=254` inside the ordinary layout, whose high byte is the layout tag (93.4% of elements are `0x00`, 5.6% are `0x03`, 146 selector values in all). Asserted. -- [x] The tie **texcoord field is located**: `i16[4]`/`i16[5]` of the 16-byte +- [~] The tie **texcoord field is no longer located.** It was recorded at + `i16[4]`/`i16[5]` on a 73.6% "both multiples of 4096" score, but that score + is contaminated twice over: it was computed on the 16-byte reading that + `e5cd3df` retracted, and measured on all records rather than the flat ones. + Restricted to the **flat** records, and asking the discriminating question + -- how many of the slot's distinct values are multiples of 4096 at all -- + gives **16 of 1,488** for `i16[4]` and 16 of 1,261 for `i16[5]`. A 12.4 + fixed-point texcoord would be *all* of them. The dominant values do look + like UV corners (`(0,0)`, `(0,4096)`, `(4096,4096)`, `(4096,0)`), which is + why it read as convincing; that is a statement about the most frequent + values, not about the field -- the same shape as the 305x class-ID + artifact. The texcoord slot in a flat tie record is **not identified**. + The earlier note it supersedes read: `i16[4]`/`i16[5]` of the 16-byte element, scoring 73.6% for 12-bit fixedness over 36,501 level-0 vertices, against 1.1% for `(0,1)` and 4.8% for `(2,3)`. The `(6,7)` pair scores *higher* at 76.6% and is **not** a texcoord -- it is the near-constant `4096, 0` pair, which is trivially two multiples of 4,096. -- [x] `i16[3]` **selects the texcoord encoding**, and it is specifically the +- [~] `i16[3]` was recorded as selecting the texcoord encoding; that rested on + the same 16-byte reading and is withdrawn with it. See the note above. + The original text read: it is specifically the **high byte**. Grouped across 95,612 vertices on levels 0-2: high byte `0x00` covers 89,341 vertices (93.4%) at 92% 12-bit fixed, while **every** other high byte scores 0%. The split is on the byte, not the value -- `i16[3]` of 1