Game Transform Systems

Use this skill to make transform code explicit, composable, testable, and consistent across gameplay, rendering, physics, and tools.

Primary source: Geometry for Programmers by Oleksandr Kaleniuk (https://www.manning.com/books/geometry-for-programmers), transformed and paraphrased, especially chapter 4. Additional source: Khronos glTF 2.0 specification transform and coordinate-system conventions (https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html).

Core Workflow

1. List every coordinate space involved: model, local, parent, world, view,

clip, screen, texture, grid, or field space.

1. Define conventions once: handedness, up axis, units, row/column vectors,

matrix memory layout, multiplication order, angle units, and quaternion order.

1. Name transforms by direction, such as localtoworld and worldtoview.
2. Compose transforms in one place and cache composed matrices when reused.
3. Use inverse transforms to move queries into simpler spaces, especially for

picking, SDFs, fields, and object-local collision.

1. Keep camera construction explicit: position, target or forward vector, up

vector, field of view, aspect ratio, near/far planes.

1. Verify with round-trip tests and debug axes before tuning gameplay behavior.

Design Rules

• Treat transforms as first-class data, not hidden side effects in helper

methods.

• Prefer one canonical transform chain for rendering and gameplay. Add adapters

at engine or asset boundaries.

• Use homogeneous coordinates when translation, projection, and matrix

composition must live in one pipeline.

• Use affine transforms for ordinary rotation, translation, scale, and shear.
• Use projective transforms when perspective, projection, or planar warping is

part of the problem.

• Apply the inverse transform to an SDF or field input instead of rewriting the

field's formula for every object transform.

• Transform normals with the inverse transpose when nonuniform scale or shear

is possible.

Camera And Projection Checks

• A camera needs enough constraints to define orientation. A position and target

still leave roll ambiguous without an up/right/down vector or equivalent.

• Near and far planes should fit the playable range; sloppy values harm depth

precision.

• Projection and unprojection should be tested with known points at screen

center, viewport corners, near plane, and far plane.

• Screen-space y direction and pixel-center conventions must be documented for

picking and UI/game interaction.

Transform Debug Checklist

• Draw local axes for selected objects.
• Draw camera frustum and near/far planes.
• Log transform direction in variable names.
• Assert matrices are finite before submitting to rendering or physics.
• Test identity, translation-only, rotation-only, scale-only, parent-child, and

inverse round trips.

• Test nonuniform scale if normals, collision, or child transforms are affected.

Common Mistakes

• Mixing row-major memory layout with row-vector math assumptions.
• Multiplying transforms in a plausible but wrong order.
• Recomputing inverse matrices inside tight per-point loops.
• Forgetting that w = 0 represents a direction in homogeneous coordinates,

while w = 1 represents a point.

• Applying object transforms to an SDF output instead of inverse-transforming

the query point.

• Fixing a camera roll bug by changing asset orientation instead of camera

constraints.