Note in the roadmap that shrub header fields are checked, not just reported

This commit is contained in:
2026-10-11 02:38:44 +02:00
parent 7107f395d0
commit 39c364e874
+5 -3
View File
@@ -206,9 +206,11 @@ Phase 1 hands over the extents; this phase works out what each one contains.
- [ ] `tie` — instanced environment geometry, fat vertices - [ ] `tie` — instanced environment geometry, fat vertices
- [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at
32 still gives 231 sane-looking entries of 358, which is the hazard). 32 still gives 231 sane-looking entries of 358, which is the hazard).
Geometry header self-identifies at two points: `+0x24` equals the entry's Geometry header parsed and both fields **checked**, not merely reported:
own `o_class` on all 358 spans, and `+0x2c` is an in-span data offset on `+0x24` equals the entry's own `o_class`, and `+0x2c` is an in-span data
all 358. Shrub does **not** use moby's part-table format. Rest undecoded. offset, on all 358 spans. Shrub does **not** use moby's part-table format.
The body past `+0x2c` is not decoded — it tiles at no stride consistent
with the count at `+0x28`.
- [x] `moby` — per-class model geometry. A class span opens with a `u32` - [x] `moby` — per-class model geometry. A class span opens with a `u32`
pointing at a part table of 16-byte records; parts tile exactly, with pointing at a part table of 16-byte records; parts tile exactly, with
`vertex_offset + 16 * vertex_count == next_part` holding for **43,467 of `vertex_offset + 16 * vertex_count == next_part` holding for **43,467 of