From ca42793e48d24386e2b9dc9623bd1cb235896b4a Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Thu, 15 Oct 2026 03:31:19 +0200 Subject: [PATCH] Frustum search: bounded with a proper filter, not found e7eec01 located R and the camera; the remaining operand is the frustum. Searched with the same shape of filter that found the camera -- structural invariant first, differential second. First attempt discarded: scanning for a perspective-matrix signature returned 11,846 hits, which is noise and means the filter was worthless. Recorded because the number looks like a result. Second attempt, the right filter: unit-length 3-vectors at 16-byte alignment, the invariant that identified the camera matrices. 9,514 found, 188 forming clusters of four or more. The six-vector cluster at 0x189e20 is a frustum's exact shape -- six planes, 96 bytes -- and it is not one. It reads as three orthonormal basis vectors plus a zero affine row at 0x30 stride, with a translation at 0x189ea0 near the camera: a table of positioned things. So the frustum is not located, and I am not picking the six-vector cluster because six is the number a frustum has. That is rule 4's failure with an exact number attached to make it feel earned, which is what I have already committed twice in this investigation. What the search did establish: the structured regions near the camera are the nine matrices at 0x18aa70, orientation records at 0x189e20, and larger clusters at 0x1793f0 and 0x18b260. The frustum is not among them as planes. Which points at the next search, and it is a different one: guard_band's signature is Frustum { near, far, tan }, not six planes. If the frustum is stored as near/far/tan scalars, the search should be for a stable float pair with a plausible ratio, not for normals at all. 294 passing, clippy clean. --- docs/plan/level-assets.md | 49 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md index 10a1254..a3ab57b 100644 --- a/docs/plan/level-assets.md +++ b/docs/plan/level-assets.md @@ -2902,3 +2902,52 @@ selected, and a table selected by an index fits. The nine-legal-orientations-on- 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. + +### Frustum search: bounded, not found + +`e7eec01` located `R` and the camera. The remaining operand is the frustum -- +`near`, `far`, `tan`. Searched with the same shape of filter that found the +camera: a structural invariant first, a differential second. + +**First attempt, discarded.** Scanning for a perspective-matrix signature (a +nonzero `col3` in row 2 with zero elsewhere) returned **11,846 hits**. That is +noise, and the filter was worthless. Recording it because the number looks like a +result and is not. + +**Second attempt, the right filter.** Unit-length 3-vectors at 16-byte alignment -- +the same invariant that identified the camera's matrices. 9,514 of them, of which +188 form clusters of four or more within 256 bytes: + + 0x1793f0 .. 0x1796d0 36 vectors, 736 bytes + 0x189e20 .. 0x189e80 6 vectors, 96 bytes + 0x18a550 .. 0x18a580 4 vectors, 48 bytes + 0x18aa70 .. 0x18ac90 27 vectors, 544 bytes <- the nine camera matrices + 0x18b260 .. 0x18b640 49 vectors, 992 bytes + +**The six-vector cluster at `0x189e20` is a frustum's shape** -- six planes is the +right count and 96 bytes is the right size -- and it is not one. It reads: + + 0x189e20 [-0.4106, 0.9118, 0.0001] |x|=1.0000 + 0x189e30 [-0.9118, -0.4106, 0.0001] |x|=1.0000 + 0x189e40 [ 0.0001, -0.0001, 1.0000] |x|=1.0000 + 0x189e50 [ 0.0000, 0.0000, 0.0000 ] w=1.000 + ... repeats at 0x30 stride ... + +Three unit vectors and a zero affine row: an orthonormal basis with no +translation, which is an orientation record, not a plane set. A translation sits +at `0x189ea0` = (246.857, 193.205, 49.891) -- near the camera position, so this +region is a table of positioned things. + +**So the frustum is still not located, and I am not going to pick the six-vector +cluster because six is the number a frustum has.** That would be rule 4's failure +with an exact number attached to make it feel earned, which is the specific thing +this project keeps warning about and the thing I have already committed twice in +this investigation. + +**What the search did establish:** the camera-adjacent structured regions in EE +RAM are the nine matrices at `0x18aa70`, orientation records at `0x189e20`, and +larger clusters at `0x1793f0` and `0x18b260`. The frustum, if it is stored as +planes, is not among them. If it is stored as `near`/`far`/`tan` scalars -- which +is what `guard_band`'s signature suggests, since it takes `Frustum { near, far, tan }` +rather than six planes -- then the search should be for a stable float pair with a +plausible ratio, not for normals at all. That is the next search, and it is cheap.