Checkpoint — conversion & bakers

01why

Why can't the authoring model and the runtime model just be the same representation?

1. aThey could be, but Unity chose not to for historical reasons
2. bThey optimize for contradictory goals — authoring needs identity, references and per-object heterogeneity for human manipulation; runtime needs homogeneous, reference-free contiguous packing for cache throughput. Every want of one is a cost in the other
3. cThe runtime model is simply a compressed version of the authoring model
4. dGameObjects are deprecated, so the question is moot

02why

Converting GameObjects to entities at scene load is the intuitive design. Why is it wrong?

1. aRuntime conversion is impossible to implement
2. bIt repeatedly pays a multi-second cost — allocation, pointer chasing, per-object structural change — to recompute a value that is a pure function of the authored scene and was already knowable at save time
3. cIt uses too much disk space
4. dManaged objects can't be read at runtime

03why

Someone proposes: convert at runtime, but cache the result so it only happens once. What has that design actually become?

1. aAn optimal solution that avoids build-time cost
2. bAn offline conversion step with cache invalidation bolted on, running on the player's hardware instead of yours — offline baking, but worse and unverifiable before shipping
3. cA completely different architecture with no relation to baking
4. dThe approach Unity actually ships

04why

Why is a Baker a class you register by type parameter rather than a function you call?

1. aClasses are faster than functions in C#
2. bRegistration by type lets the pipeline run it per authoring instance, and making every authored read a Baker method turns the conversion's input set into something the pipeline can observe — which is what makes incremental re-baking decidable
3. cIt's an arbitrary API style choice
4. dFunctions can't add components

05how

Inside a Baker, `GetComponent<Rigidbody>()` and `authoring.GetComponent<Rigidbody>()` return the same object. What is the difference?

1. aNo difference; they're aliases
2. bThe first is tracked — the pipeline records that this conversion depends on that Rigidbody, so editing it re-bakes. The second is an ordinary Unity call the pipeline never observes, so editing it re-bakes nothing
3. cThe second is faster
4. dThe first only works in play mode

06why

Why does an untracked read in a Baker usually look fine in the editor and only break in a build?

1. aBuilds use a different Baker implementation
2. bIn the editor some other change frequently triggers a re-bake that recomputes the stale value incidentally; a clean build bakes from scratch in a different order, so nothing masks the missing dependency
3. cThe editor validates dependencies and the build doesn't
4. dIt's random

07why

An untracked baker read, a false [ReadOnly], and lying to Burst about aliasing share one structure. What is it?

1. aAll three are compile errors
2. bA system optimizes based on what you declared, and an incomplete or false declaration produces incorrect results with no error — the pipeline trusts declared inputs exactly as the job system trusts declared access
3. cAll three only affect mobile platforms
4. dThey're unrelated; the resemblance is superficial

08why

Why does `GetEntity` require TransformUsageFlags instead of always adding transform components?

1. aTo support older Unity versions
2. bComponents cost chunk space, and chunk space is throughput — an entity that never moves and is never spatially queried shouldn't carry a LocalTransform, so the baker declares intended usage and the pipeline derives the minimal archetype
3. cTransforms are optional in Unity generally
4. dIt's only needed for physics objects