Technical Art Coordinate Transformation Systems

pavelzosim:~/atlas_●SYS.ONLINE / UTC+3

01 Coordinate-space pipeline

A 3D point has meaning only inside a coordinate space. During rendering, a vertex moves through a sequence of spaces: from the model's local frame to the world, then to the camera, clip space, and finally the image.

Vertex transformation pipeline from model coordinates through world, view, clip, and image coordinates
The same vertex expressed in successive coordinate spaces.
[ SPACE_PIPELINE // REFERENCE ]
SpaceRelative toTypical use
Local / objectThe object's pivot and axesModeling, rigging, procedural deformation
WorldThe scene originPlacement, physics, object-to-object queries
View / cameraThe active cameraLighting and view-dependent effects
Clip / NDCThe camera frustumClipping and projection
ScreenThe viewport or imagePixels, UI, post-processing
 
world = modelMatrix * localPosition
view  = viewMatrix  * world
clip  = projectionMatrix * view
ndc   = clip.xyz / clip.w

Debugging rule: label the space of every position, vector, normal, and matrix. Most transformation bugs begin when two values from different spaces are combined as if they shared one basis.

02 Handedness and interchange

A coordinate system is right-handed or left-handed according to the orientation of its basis vectors. Handedness changes how positive directions, rotations, triangle winding, and cross products are interpreted. The mathematics remains valid in either convention; the danger is an incomplete conversion between them.

Comparison of left-handed and right-handed 3D coordinate systems
Left- and right-handed bases. Axis labels alone are insufficient; their orientation as a set defines the convention.

When moving an asset between a DCC, an engine, and a graphics API, verify the complete exchange contract:

03 Local, world, and hierarchy

Local space makes an object's data independent of scene placement. A child transform is evaluated through its parent hierarchy, so moving a character also moves the prop attached to the character's hand.

\[ M_{child}^{world} = M_{parent}^{world} M_{child}^{local} \]
Several model spaces placed inside a shared world coordinate system
Each object keeps its own model space while the scene supplies a shared world space.

A point uses homogeneous coordinate w = 1, so translation affects it. A direction uses w = 0, so translation is ignored. Normals need special treatment under non-uniform scale: transform them with the inverse-transpose of the relevant linear transform, then normalize.

04 Transformation order

Matrix multiplication is not commutative. Applying scale, rotation, and translation in a different order changes the result—especially when scale is non-uniform or the pivot is away from the origin.

Object shown near its local origin before a change in transformation order Object displaced after applying transformations in a different order

The same transforms composed in different orders produce different positions and orientations.

// Column-vector convention: the rightmost operation runs first.
modelMatrix = translationMatrix * rotationMatrix * scaleMatrix;
worldPosition = modelMatrix * localPosition;

Convention matters: the expression above assumes column vectors. Row-vector systems write the composition in the opposite order. Confirm the convention before copying matrix code between tools or APIs.

05 Dot and cross products

Dot and cross products answer different spatial questions. Both assume that the input vectors are expressed in the same coordinate space.

[ VECTOR_OPERATIONS // QUICK_REFERENCE ]
OperationReturnsTechnical-art use
dot(a, b)A scalarAngles, facing tests, projection, diffuse lighting
cross(a, b)A perpendicular vectorNormals, tangent frames, side tests, orientation
\[ a \cdot b = \lVert a \rVert \lVert b \rVert \cos\theta \qquad \lVert a \times b \rVert = \lVert a \rVert \lVert b \rVert \sin\theta \]
Two input vectors and the perpendicular vector produced by their cross product
The cross product produces a vector perpendicular to the plane of the two inputs; its sign follows the coordinate convention and input order.

06 Euler angles and quaternions

Euler angles are readable and useful for authoring, but they represent a sequence of axis rotations. Their order matters, and certain orientations align two axes, causing gimbal lock and the loss of one effective degree of freedom.

Three-axis gimbals demonstrating yaw, pitch, and roll Gimbals with two axes aligned in a gimbal-lock configuration

Independent gimbal axes at left; two aligned axes and one lost degree of freedom at right. Animation credit: Mark Hughes.

A unit quaternion stores an orientation as four components. For a normalized axis u = (ux, uy, uz) and rotation angle θ:

\[ q = \left(\cos\frac{\theta}{2},\; u_x\sin\frac{\theta}{2},\; u_y\sin\frac{\theta}{2},\; u_z\sin\frac{\theta}{2}\right), \qquad \lVert q \rVert = 1 \]
Axis-angle rotation represented by a vector and angle theta
Axis-angle is the bridge between an intuitive rotation description and quaternion components.

Quaternions avoid the singularity of Euler-angle parameterization and support smooth spherical interpolation. They do not make rotation order commutative: quaternion multiplication still depends on order. Normalize accumulated rotations when numerical drift is possible.

07 Debugging checklist

  1. Write the source and destination space beside every transformation.
  2. Test with a point on each positive axis, not only at the origin.
  3. Visualize basis vectors and normals in the viewport.
  4. Inspect every parent matrix when a child appears offset.
  5. Use a non-uniformly scaled test object to expose order and normal errors.
  6. Verify handedness, units, winding, UV origin, and rotation order at import boundaries.
  7. Compare intermediate values before debugging the final image.

Practical takeaway: transformations become easier to reason about when space, convention, and multiplication order are treated as part of each value's type—not as undocumented context.

08 References

// END OF ARTICLE // COORDINATE_TRANSFORMS // EOF