fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the 8 values per asteroid are index, quaternion, position

Browse Source 
Measured over every Frame_*Asteroid* record on the disc - 384 records, 37518
items (6253 per language pack x 6; the remaining 380 per pack belong to the
seven record-less Alpha frames, the same 57-vs-64 split as before).

  slot 0    equals the running index 0..N-1   37518 / 37518, max 587, and the
            largest FrameCount is 588, so the last index is N-1
  slots 1-4 a unit quaternion                 37518 / 37518 within 1e-4 of 1.0
            (min 0.999999, max 1.000001)
  slot 4    sign of the real part             min +0.001, never negative -
            canonical w-last, so the order is (x, y, z, w)
  slots 5-7 position in metres                -163858..+79572, -114308..+76422,
            -105224..+110263 - inside the +/-250 km half-extent of
            mapmesh_box_500km

len(anonymous fields) == 8 * FrameCount on 384 of 384, zero mismatches.

The unit-norm test is the control: an arbitrary 4-tuple has no reason to sit on
the unit sphere and every one of the 37518 does. Two further cross-checks fell
out - the maximum index is exactly max(FrameCount) - 1, and every position lies
inside the 500 km box the corpus already knows (world unit = 1 metre).

There is no scale slot: an asteroid's size comes from its group's
AsteroidModelName, which is why a group is one model plus one placement list.

Not settled: whether the quaternion is object->world or world->object and its
handedness - a norm test cannot separate those; and why S28_p1 has an asteroid
volume with no definition.

All fifteen artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-28 02:03:23 +00:00
parent da71897d03
commit 01fbb42eb6
3 changed files with 63 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/re/BACKLOG.md
View File

@@ -5793,3 +5793,35 @@ a discrepancy, **read how the corpus routine calls it** — the prefix list was
🟡 Not settled: what the 8 values per asteroid are (position/rotation/scale is the
obvious reading, untested — [[regn-map-grid]] has the neighbouring work); why
`S28_p1` has an asteroid volume and no definition.
---
## ✅ 2026-08-28 — the 8 values per asteroid: index, quaternion, position
Item (a). Measured over every `Frame_*Asteroid*` record on the disc — **384
records, 37 518 items** (6 253 per language pack × 6; the remaining 380 per pack
belong to the seven record-less `Alpha` frames, which is the same 57-vs-64 split
as before).
| slot | test | result |
|---|---|---|
| 0 | equals the running index `0…N−1` | **37 518 / 37 518**, max **587** — and the largest `FrameCount` is **588**, so the last index is `N−1` |
| 1–4 | a **unit quaternion**? | **37 518 / 37 518 within 1e-4 of 1.0** (min 0.999999, max 1.000001) |
| 4 | sign of the real part | min **+0.001**, never negative — canonical w-last, so `(x, y, z, w)` |
| 5–7 | position in metres | −163 858…+79 572, −114 308…+76 422, −105 224…+110 263 — inside the ±250 km half-extent of `mapmesh_box_500km` |
`len(anonymous fields) == 8 × FrameCount` on **384 of 384**, zero mismatches.
**The unit-norm test is the control**: an arbitrary 4-tuple has no reason to sit
on the unit sphere, and every one of the 37 518 does. Two further independent
cross-checks fell out — the maximum index (587) is exactly `max(FrameCount) − 1`,
and every position lies inside the 500 km box the corpus already knows
([[regn-map-grid]], world unit = 1 metre).
🔑 **There is no scale slot.** An asteroid's size comes from its group's
`AsteroidModelName` — which is why a group is *one model plus one placement
list*, and why the group table needed both fields.
🟡 Not settled: whether the quaternion is object→world or world→object, and its
handedness — a norm test cannot separate those. And still: why `S28_p1` has an
asteroid volume with no definition.