From c4ba84232aa14f4d8086b1f9b2ad629e625ba290 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Sun, 11 Oct 2026 02:34:54 +0200 Subject: [PATCH] Record that tie does not reuse moby's part table Checked the obvious hypothesis -- that tie, being the other class-geometry table, would share moby's part-table format -- and it does not. The tiling rule vertex_offset + 16 * vertex_count == next_part holds for 0 of 25,024 records across the 1,864 tie spans, against 43,467/43,467 for moby. Tie's second field also reads as an absolute offset rather than a span-relative one, which is the first sign the record shape differs. Past the verified 0x48-byte header the bytes are f32-shaped rather than the expected VIF marker, but they are not a fixed array either: the run of consecutive plausible floats varies from 1 to 6 across spans (822 spans have 6, 455 have 1, 373 have 2). So there is more header past 0x48 and it is not one array of distances -- the floats after that point are a different population from the LOD distances before it, including negative values. Recorded so the next attempt starts from that rather than re-trying the moby template. --- docs/plan/level-assets.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 9352053..9f5b56d 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -854,3 +854,24 @@ The header does self-identify in two places, both exact across all 358 spans: constant marker and carries no structural weight. The header is otherwise undecoded: the first 0x20 bytes are packed data rather than floats, despite `+0x10` landing exactly on 5.0. + +## Tie geometry (2026-10-11) + +Tie does **not** reuse moby's part-table format. The rule +`vertex_offset + 16 * vertex_count == next_part` holds for **0 of 25,024** +records tried across the 1,864 tie class spans, against 43,467/43,467 for +moby. Tie's second field also reads as an absolute offset rather than a +span-relative one, which is the first sign the record shape differs. + +At `+0x48`, where the verified header currently ends, the bytes are f32-shaped +(10.0, 40.0, 50.0, 4.0, -100.0, -25.0, 5.0, 3.125), not a VIF marker as +expected. They are not a fixed-size array either: the run of consecutive +plausible floats varies from 1 to 6 across spans, with 822 spans having 6, +455 having 1 and 373 having 2. So there is more header past `0x48`, and it +is not a single array of distances. + +Note the LOD distances already decoded sit *before* this point (12.0, 25.0, +40.0 at `+0x10`), and the floats after `0x48` are a different population -- +negative values, and a repeated leading 40.0. + +Unresolved. The packet geometry remains the open question, unchanged.