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.
ReaperOfVeriod
ca42793e48