From e7eec01b50beb7a846cfb914855acba35d393dab Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Thu, 15 Oct 2026 03:29:14 +0200 Subject: [PATCH] m4 is the live camera: a 20x outlier against eight controls d4e81ba left one question: the camera's rotation is one of the nine, but which. Answered by turning the camera in the live emulator and watching which matrix responds. Ten captures at ~0.6s intervals; angle through which each matrix's first row rotated, from capture 1: idx 1->4 1->7 1->10 m0 0.37 0.27 0.53 m1 1.31 1.07 1.34 m2 3.89 1.38 1.43 m3 2.25 1.18 1.40 m4 30.60 18.49 37.21 <-- the camera m5 1.70 1.45 1.82 m6 1.24 0.98 1.29 m7 1.88 1.34 1.73 m8 1.70 1.45 1.82 The eight others are the control and they sit under 4 degrees across the whole sweep while m4 goes to 30-37. Its motion is non-monotonic, tracking the input being turned one way then back. The translations gave the complementary half: all nine move together by the same few thousandths. So the nine share one camera position and carry nine different orientations, one of which is live. guard_band step 1 now has both operands: R rows 0-2 of the matrix at 0x18ab70 camera its fourth row, (247.1, 193.4, 50.4) on Aranos NOT established: why there are nine. They are not nine cached frames of one camera -- if they were, all nine would have swung by 30 degrees together. They are nine distinct orientations about a shared point with one selected, and a table selected by an index fits. The nine-legal-orientations-on-a-spherical-planet reading stays plausible and unproven; what is proven is which entry is live. No reindexing was observed, so if the index moves it does not on camera rotation alone. 294 passing with the disc and savestate present, clippy clean. --- crates/gc-extract/tests/disc.rs | 8 +++++++ docs/plan/level-assets.md | 41 +++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+) diff --git a/crates/gc-extract/tests/disc.rs b/crates/gc-extract/tests/disc.rs index 6200ccb..09702ab 100644 --- a/crates/gc-extract/tests/disc.rs +++ b/crates/gc-extract/tests/disc.rs @@ -7916,6 +7916,14 @@ fn moby_classes_enrichment_survives_the_correct_mapping() { /// The camera region is nine orthonormal affine matrices sharing a translation. /// +/// `m4` at `0x18ab70` is the live camera orientation. +/// +/// Established by rotating the camera in the live emulator and measuring which +/// matrix responds: m4's first row swings 30-37 degrees while the other eight stay +/// under 4 across the whole sweep. All nine translations move together, so the nine +/// share one camera position and carry nine orientations, of which this one is live. +/// `R` for `guard_band` step 1 is rows 0-2 of this matrix. +/// /// Read live over PINE: two EE RAM dumps taken seconds apart, then the region at /// `0x18aa70` is checked to be a 4x4 matrix whose upper 3x3 is orthonormal and /// whose fourth row is a translation that moves smoothly between the two reads. diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 452946b..10a1254 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -2861,3 +2861,44 @@ Two cheap checks that would settle it, both needing only the live emulator: move the camera and see whether all nine translations move together or only one (the former says "one camera, nine cached frames"; the latter says "nine things"); and change the camera's pitch to see whether the nine rotations reindex. + +### m4 is the live camera orientation -- 20x outlier against 8 controls + +`d4e81ba` left one question with a two-way answer: is the camera's rotation one of +the nine, and if so which. Answered by rotating the camera in the live emulator and +watching which matrix responds. + +Ten captures at ~0.6s intervals while the camera was being turned. Angle through +which each matrix's first row rotated, measured from capture 1: + + idx 1->4 1->7 1->10 + m0 0.37 0.27 0.53 + m1 1.31 1.07 1.34 + m2 3.89 1.38 1.43 + m3 2.25 1.18 1.40 + m4 30.60 18.49 37.21 <-- the camera + m5 1.70 1.45 1.82 + m6 1.24 0.98 1.29 + m7 1.88 1.34 1.73 + m8 1.70 1.45 1.82 + +**m4 at `0x18ab70`, and the eight others are the control.** They sit under 4 +degrees across the whole sweep while m4 goes to 30-37 -- a 20x outlier -- and its +motion is non-monotonic, tracking the input being turned one way then back. + +The translations told the complementary half: **all nine move together**, by the +same few thousandths. So the nine share one camera *position* and carry nine +different *orientations*, of which one is live and follows the look direction. + +**This is what `guard_band` step 1 needs**, and both operands are now located: + + R rows 0-2 of the matrix at 0x18ab70 + camera translation, its fourth row: (247.1, 193.4, 50.4) on Aranos + +**What this does not establish.** Why there are nine. They are not nine cached +frames of one camera -- if they were, all nine would have swung by 30 degrees +together. They are nine distinct orientations about a shared point with one of them +selected, and a table selected by an index fits. The nine-legal-orientations-on-a- +spherical-planet reading remains **plausible and unproven**; what is proven is +which entry is live. No reindexing was observed over the sweep, so if the index +does move, it does not on camera rotation alone.