Transforms / coordinate spaces

A transform is position, rotation, and scale bundled into one matrix. The catch is that those numbers are always relative to something. A point starts in local space (relative to its own object's origin), gets multiplied up through its parents into world space (relative to the scene), then into view space (relative to the camera), then into clip space (the flattened box the GPU turns into pixels). That chain is the model-view-projection matrix every vertex shader applies.

Almost every 'my object is in the wrong place' bug is a space mismatch. A child at position 0,0,0 sits wherever its parent is, not at the scene origin. A raycast hit comes back in world space and looks wrong if you assign it straight to a nested object's local position. A physics body and a rendered mesh disagree because one carries the parent's offset and one does not. When two things will not line up, ask which space each number lives in before touching the math.

Gotcha: order matters and it is not commutative. Rotate-then-translate puts an object somewhere completely different from translate-then-rotate, which is why the pivot point (where the origin sits inside the mesh) decides how something spins. Non-uniform scale is the other landmine. Lighting survives it when normals go through a proper inverse-transpose normal matrix, which renderers do for you, so it only wrecks shading where something transforms normals the naive way. What it reliably complicates is tangent bases, physics colliders, and any code that decomposes a matrix back into position, rotation, and scale. It also compounds through parents, so a 0.01 scale on a group plus a 100 scale on a child leaves you a chain nobody can reason about.