ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Retract the tie texcoord field: a dominant-value artifact, one level down

Browse Source 
Picked the tie flat encoding to close, since e5cd3df left it as the largest
unidentified field. What came out was a retraction of my own earlier claim.

The texcoord slot was recorded at i16[4]/i16[5] on a 73.6% "both multiples of
4096" score. Two problems, either of which would be enough.

First, that 73.6% was computed on the 16-byte element reading that e5cd3df
retracted. Half the records are VIF packets and half are flat, so the figure
describes neither population cleanly.

Second, and decisive on its own: measured on the FLAT records only -- levels 0-2,
930 records, 47,909 vertices -- 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.

    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 precisely why
the claim was persuasive. But it is a statement about the most frequent values,
not about the field: 1,472 of the 1,488 values in i16[4] are not multiples of 4096
at all.

This is 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
arithmetic was right about the popular values and the conclusion was wrong about
the field. The retraction commit itself warned about exactly this shape, which
makes the repeat more useful than the original claim was.

So the texcoord slot of a flat tie record is NOT identified. What survives is the
boundary work -- vert_ofs + vert_size + scissor_size is the region length -- and
the LOD1/LOD2 sharing result, which is stride-insensitive and survives the stride
retraction.

Both docs updated: the roadmap's two [x] claims about the texcoord field and about
i16[3] selecting its encoding are now [~] with the evidence, and the format file
has a retraction section giving the table above.

I did not find a replacement reading for i16[4..7]. Three discriminators were
tried -- LOD sharing, multiple-of-4096 rate, value-set size -- and each came back
ambiguous or negative. That is worth recording as the state rather than
generating a fourth hypothesis.

258 tests.
This commit is contained in:
ReaperOfVeriod
2026-10-14 02:56:57 +02:00
parent 1e90c7de6d
commit 4ab30e1f4d
2 changed files with 56 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/formats/core-data-regions.md
+40 -1
View File
@@ -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.
docs/roadmap.md
+16 -2
View File
@@ -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