The previous commit said i16[3] selects the texcoord encoding. That was right but
loose -- it is specifically the HIGH BYTE, and the low byte is a separate thing.
Grouped by the high byte across the same 95,612 vertices on levels 0-2:
i16[3] high byte n % / 16 % / 256
0x00 89,341 92.0% 91.8%
0x03 5,344 0.0% 0.0%
0x04 71 0.0% 0.0%
0x40 58 5.2% 0.0%
0x02 47 2.1% 2.1%
0x19, 0x05, 0x20, ... the remaining 73
A high byte of zero is the ordinary case -- 89,341 of 95,612, 93.4% -- at 92%.
EVERY other high byte scores at or near zero. The split is on the byte, not on the
value: i16[3] of 1 and of 771 differ only in the high byte and behave completely
differently.
Within the all-zero case there is a third distribution: i16[3] == 0 exactly (5,851
vertices) scores 62% at 16 and 61% at 256, against 92% for 1..255.
So three cases, selected by the high byte and then the low:
high 0x00, low 0x00 5,851 a third distribution, 62% at 1/16
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 6,271 matches the figure quoted last commit for "vertices using an encoding
this reading does not see", and the two group counts sum consistently with the
committed test's 95,612 -- so this refines the finding rather than changing it.
A measurement trap worth recording: the all-zero case is a SUBSET of high byte
0x00, so summing the per-high-byte groups double-counts it. An intermediate total
came out at 100,792 against the true 94,941 for those groups; the committed test's
figure is the one to trust.
ReaperOfVeriod
ed3e85a0f2