From 922248a4ecbc9e3e9102bfa3b1616b85e5018009 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Tue, 13 Oct 2026 06:53:22 +0200 Subject: [PATCH] Tie: the element layout differs by i16[3] high byte, and (6,7) is a real pair Two results, one of them a correction. 1. "(6,7) is just the constant 4096/0 pair, not a texcoord" -- wrong. It looked like an artifact because a constant is trivially a pair of multiples of 4096. But partitioned by i16[3]'s high byte it is a genuine fixed-point pair in its own right: i16[3] high byte ZERO (n = 89,341) divisor rate by slot pair pair /1 /4 /16 /256 ( 0, 1) 100.0% 11.5% 4.6% 3.3% baseline ( 2, 3) 100.0% 11.0% 4.5% 3.3% baseline ( 4, 5) 100.0% 92.9% 92.0% 91.8% the texcoords ( 6, 7) 100.0% 89.5% 87.3% 86.5% a SECOND fixed-point pair If (6,7) were a constant it would score 100%, not 89.5%. The constant is the common case WITHIN it, not the whole of it -- which is exactly the distinction the constant-artifact lesson is about, and I applied it backwards last time. So the ordinary element carries TWO fixed-point pairs, (4,5) and (6,7), with (0,1) and (2,3) at baseline. What (6,7)'s role is remains open -- second UV set, normal, or a zero-heavy fixed-point pair all fit. 2. The element LAYOUT differs between the three cases. Scoring all four slot pairs within the non-zero high-byte group, no pair stands out: i16[3] high byte NON-ZERO (n = 6,271) pair /1 /4 /16 /256 ( 0, 1) 100.0% 4.6% 3.5% 0.7% ( 2, 3) 100.0% 2.0% 0.6% 0.0% ( 4, 5) 100.0% 1.9% 0.3% 0.1% ( 6, 7) 100.0% 7.5% 5.7% 4.5% Best is 7.5% against a 2-5% baseline. So for those 6,271 vertices the 16 bytes are not laid out as position/texcoord/normal at all -- a different element shape, selected by the high byte. This also explains why the global slot-pair score looked ambiguous to begin with: pooling the two layouts averages a 92% pair and a 7% pair into one number that describes neither. Fourth time this session that partitioning produced the answer rather than merely bounding it. --- docs/formats/core-data-regions.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 1726b44..5f9d89c 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -1774,6 +1774,27 @@ Within the all-zero case there is a third distribution: `i16[3] == 0` exactly high 0x00, low 1..255 83,490 the ordinary case, 92% at 1/4096 high non-zero 6,271 0%, an encoding this reading does not see +### The element layout differs between those cases + +Scoring all four slot pairs within the non-zero high-byte group, **no pair +stands out** -- the best is `(6,7)` at 7.5% for a divisor of 4, against a 2-5% +baseline: + + i16[3] high byte NON-ZERO (n = 6,271) + pair /1 /4 /16 /256 + ( 0, 1) 100.0% 4.6% 3.5% 0.7% + ( 2, 3) 100.0% 2.0% 0.6% 0.0% + ( 4, 5) 100.0% 1.9% 0.3% 0.1% + ( 6, 7) 100.0% 7.5% 5.7% 4.5% + +So for those 6,271 vertices the 16 bytes are **not laid out as +position/texcoord/normal** at all -- none of the four pairs carries fixed-point +coordinates. Whatever they are, it is a different element shape, selected by the +high byte of `i16[3]`. + +This also settles why the global score looked ambiguous: pooling the two layouts +averages a 92% pair and a 7% pair into one number that describes neither. + **Not established:** what any of those three cases means. Whether `i16[3]` is a texture index, a normal index, a flag or a combination is still open -- but it is now a field whose *role* is known, which is more than "packed word".