Checkpoint — LocalTransform & the hierarchy

01why

Why is transform data one component rather than three separate Position, Rotation and Scale components?

1. aFewer components is always faster in ECS
2. bThe grouping rule is one access-pattern per component, not one concept — position, rotation and scale are universally read together, so splitting them multiplies memory streams and chunk lookups without reducing bytes
3. cThree components would exceed the archetype limit
4. dUnity's API historically used a single Transform class

02how

A 4x4 matrix is what rendering ultimately consumes. Give the memory argument against storing it in the component.

1. aMatrices cannot be stored in IComponentData
2. bA 4x4 of floats is 64 bytes versus 32 for TRS with uniform scale — doubling the size of the most universally present component in the world, permanently, to avoid a conversion Burst vectorizes
3. cMatrices require managed memory
4. dThere is no memory difference; the argument is purely about readability

03why

There is a second argument against storing the matrix, and it is about correctness rather than speed. What is it?

1. aMatrices lose precision over time
2. bA matrix is a bad thing to interpolate — blending two rotation matrices component-wise produces something that is not a rotation, while blending quaternions produces a rotation, so any system that lerps transforms needs the decomposed form
3. cMatrices cannot represent rotation correctly
4. dThe GPU rejects interpolated matrices

04why

Why is uniform scale the default rather than three-component scale?

1. aNon-uniform scale is rarely useful in games
2. bNon-uniform scale doesn't compose cleanly through a rotated hierarchy — scale a parent non-uniformly, rotate a child, and the shape shears, forcing a full matrix — so it lives in a separate opt-in component while the cheap common case stays 32 bytes
3. cUniform scale is faster to multiply
4. dThe quaternion cannot represent non-uniform scale

05why

What property, relied on since Module 1, does a parent link destroy?

1. aType safety of component access
2. bOrder-independence — a child's world transform is a function of its own data AND its parent's result, so entities can no longer be processed in any order on any core
3. cThe ability to Burst-compile the system
4. dChunk contiguity

06how

Given the dependency graph, why must transform updates sweep top-down by depth?

1. aBecause chunks are ordered by depth in memory
2. bA child's world transform requires its parent's world transform as input, so roots compute first (depending on nothing), then depth 1, then depth 2 — the ordering constraint is the graph's edges and no chunk layout removes it
3. cBecause the Child buffer is sorted
4. dTo minimize cache misses

07why

Ten thousand entities parented flat to one root, versus two hundred entities in a chain twelve deep. Which costs more per frame, and why?

1. aThe ten thousand, because cost scales with entity count
2. bThe two hundred, because cost is driven by depth — twelve sequential barriers where cores idle waiting for the level above, versus a couple of passes that parallelize beautifully across ten thousand entities
3. cThey cost the same
4. dNeither has a per-frame cost once baked

08why

Why does the system maintain a Child buffer on the parent when the child's Parent component already encodes the relationship?

1. aFor convenience in the Inspector
2. bThe Parent component points up, but the transform system must walk down — with only upward links, finding a parent's children means scanning every entity per parent, which is quadratic per frame
3. cBecause Parent components are unreliable
4. dTo support multiple parents

09how

You set Parent on an entity and immediately read its world position in the same system. What do you get?

1. aThe new position, computed immediately
2. bThe old position — the two representations haven't been reconciled and the world transform hasn't been recomputed; the relationship becomes real when the transform system next runs
3. cAn exception
4. dZero

10why

Grouping a thousand static props under an empty 'Props' root to tidy the hierarchy. Assess it.

1. aGood practice — organization aids maintainability at no runtime cost
2. bIt adds a depth level and a Parent component to a thousand entities for no spatial relationship — the authoring model's organizational habit leaking into a runtime model that Module 5 established is optimized against it
3. cHarmless, since empty roots are stripped at bake time
4. dIt improves cache locality by grouping related entities