game-transform-systems

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 local_to_world and world_to_view.
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.