Transform conventions

How the runtime turns the data in [[technical/format/field-models]] into something on screen. Getting these wrong produces a model that is recognisably the right model and visibly wrong, which is harder to debug than a model that does not draw at all.

Rotation order is YXZ

Bone rotations, part placement, entity orientation — the game applies Euler angles in YXZ order throughout. Applying them XYZ gives limbs that are subtly off and a figure that looks disjointed only at certain poses.

Models transform through a software GTE

The PlayStation's Geometry Transformation Engine survived the PC port as a software implementation, and it — not a conventional graphics pipeline — is what the game uses to transform models. Fixed-point arithmetic and its rounding behaviour are part of the observable result, which matters when the goal is matching the original output rather than merely producing plausible output.

Validation for this is visual and blunt: transforming retail Cloud through these conventions renders him pixel-for-pixel recognisable.

Fields have their own camera matrix

Each field map carries a camera matrix in its camera section. That matrix is what places the pre-rendered background and the 3D models in the same space — project the walkmesh through it and walkable edges, walls, gateways and door triggers land exactly on the art.

This is the practical test of whether the convention is right: an overlay that lines up on one map and drifts on another means the matrix is being read, not applied, incorrectly.

Status

Marked draft rather than verified. The conventions above are measured and used, but this note summarises them rather than laying out the arithmetic; a verified note would carry the matrix layout and the fixed-point rules explicitly.