Tie vertex slot 3 is a byte-sized index, not a coordinate

Splitting the 95,612 elements of levels 0-2 by i16[3]'s HIGH byte, which is the
layout selector:

    0x00   89,341   93.4%
    0x03    5,344    5.6%
    144 other selector values   927    1.0%

146 selector values in all. Not a two-way switch, and the second case is not 0x01.

Inside the ordinary layout i16[3] is not a coordinate: 201 distinct values, all
within 0..=254, with 0 most common. That is an index. So the selector and the
index are not two independent halves sharing a slot -- it is one byte. The low
byte is the index, the high byte is the layout tag, and the ordinary layout never
sets the high byte. Asserted.

Nearly got this wrong twice, both times the same way, which is why they are in
the commit message:

1. The first pass gated the range on `w >= 0` instead of on `(w >> 8) == 0`,
   letting in the other layouts' large positive values. That reported "564
   distinct values in 0..=32664" -- a number that looks exactly like a
   coordinate and is really two populations unioned. The selector byte is the
   filter. The filter is part of the claim.

2. Two constants were guessed rather than measured (selector cardinality 159,
   and an upper bound that ignored non-ordinary layouts) and both were wrong.
   The cardinality is 146. Guessing a constant and then asserting it is how a
   measurement becomes a tautology.

Quantified the i16[6]/i16[7] question while I was in here, because "both are
multiples of 4096" has been sitting in the docs as a fixed-point signal:

    both %4096==0 in 86.5% of elements
    expected if the two residues were independent: 84.3%
    enrichment 1.0x -- exactly chance

They look like a fixed-point pair only because their dominant values, 4096 and 0,
are both multiples of 4096. Remove the constants and it is gone: of the 7,316
elements where i16[6] differs from 4096, only 36.7% are still multiples, and of
the 9,905 where i16[7] differs from 0, ONE is. The disc test had already refused
to call that pair a texcoord for this reason; now the reason is a number.

Remaining slots in the ordinary layout, recorded: i16[0..2] read as position but
are unproven (10.7k-13.2k distinct each, full i16 range), i16[4]/i16[5] are the
texcoords, i16[6]/i16[7] unnamed.

Also fixes two clippy map_or lints and an import that a stray --fix had broken.
238 tests, clippy clean.
This commit is contained in:
2026-10-13 07:18:13 +02:00
parent 1fa1913e38
commit 06cf2fd46d
3 changed files with 137 additions and 4 deletions
+4
View File
@@ -290,6 +290,10 @@ Phase 1 hands over the extents; this phase works out what each one contains.
- [x] The tie **vertex element is 16 bytes**, measured over 95,612 vertices on
levels 0-2 and settled by comparison: a 12-bit-fixed texcoord hit rate of
**82.5%** at 16 bytes against 47.8% at 8 and 44.8% at 12.
- [x] `i16[3]` is a **byte-sized index**, not a coordinate: 201 distinct values in
`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
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