Unit — Baking

01why

State the argument for baking in one step: given two data models and a conversion, why must the conversion be offline?

1. aBecause runtime conversion is technically impossible
2. bBecause the conversion of authored content is a pure function of that content — the answer never varies by player machine — so computing it at load time recomputes a knowable value on every launch, at a cost dominated by per-object structural change
3. cBecause Unity's licence requires a build step
4. dBecause GameObjects cannot be loaded at runtime

02how

Which constraint does NOT follow from baked output being cached and shipped?

1. aBakers must be deterministic — no time, no unseeded randomness, no hardware queries
2. bBakers cannot depend on runtime state like elapsed frames or player input
3. cBakers must run on a background thread
4. dChanging an authored value must invalidate exactly the affected baked output

03why

Why would making conversion an ordinary C# function have made incremental re-baking undecidable?

1. aFunctions execute too fast to instrument
2. bFree C# could read anything — a sibling component, a referenced asset, a static field — with no way for tooling to determine what it touched, forcing the pipeline to conservatively re-bake everything
3. cC# functions cannot return entities
4. dOnly classes can be serialized

04why

Rank these three by how they fail: an untracked baker read, a false [ReadOnly] on a job container, and a Burst no-alias violation.

1. aAll fail loudly at compile time
2. bAll fail silently — each is a system optimizing on a declaration you made, where an incomplete or false declaration yields incorrect results with no error; only the symptom differs (stale data, race, wrong values)
3. cOnly the Burst one fails silently
4. dThey fail at bake, schedule, and compile time respectively, all with clear errors

05why

Why is loading a baked entity scene fundamentally different work from replaying CreateEntity calls?

1. aIt uses a faster serialization format for the same operations
2. bBaking precomputed memory layout, not just values — the serialized chunk is already in final form, so loading is a byte copy with zero archetype computation, chunk allocation, or per-component writes
3. cIt runs on the GPU
4. dIt skips validation that CreateEntity performs

06why

A designer places 40,000 static rocks. Your teammate loads them by instantiating a rock prefab 40,000 times at startup. What is wrong, in the vocabulary of this course?

1. aNothing — instantiation is the standard approach for authored content
2. bIt converts a byte copy into 40,000 structural changes on the main thread — the same category of mistake as doing structural changes inside a per-frame loop. Authored content should be baked and streamed; instantiate only what is genuinely dynamic
3. cThe rocks should be GameObjects instead
4. d40,000 exceeds the entity limit

07why

Why do raw component values survive serialization untouched while Entity references need a remapping pass?

1. aEntity references are compressed and values are not
2. bA float is meaningful in isolation, but an Entity is an index-plus-version into a specific world — the loading world already has entities at those indices, so the stored index means something different or nothing
3. cValues are stored in the header and references in the body
4. dRemapping is optional and only used for debugging

08why

Derive it: instantiation needs a source entity, but a source entity in the world would be rendered and simulated. What resolves this, and why is it free?

1. aA disabled entity, which costs a boolean per entity
2. bA zero-size Prefab tag component that queries exclude by default — the entity is fully baked and instantiable while being unmatched, and tags carry no data so it costs nothing per chunk
3. cStoring the prefab outside the world in a managed list
4. dRebuilding the archetype in C# at runtime

09how

You must debug why spawned enemies are missing a component. Why does inspecting live enemies not help?

1. aLive enemies are not queryable
2. bThe fault is in the prefab entity, which is excluded from queries by default — so it is invisible to every diagnostic you would naturally write. Debug it by explicitly including Prefab in the query
3. cSpawned entities are copies and cannot be inspected
4. dThe component is added after the frame you are inspecting

10how

Three independent reasons rule out a raw pointer for shared blob data. Which is NOT one of them?

1. aA managed reference cannot live in an unmanaged component or be touched by Burst
2. bA raw address is meaningless after serialization, so a baked scene of pointers is garbage on load
3. cA pointer gives the job safety system nothing to reason about for read/write analysis
4. dPointer dereferencing is slower than offset arithmetic

11why

Why does position-independence — relative offsets instead of absolute addresses — matter so much for blobs?

1. aIt reduces the blob's size on disk
2. bIt makes the blob valid wherever it lands in memory, since every internal reference means 'so many bytes from here' — which is precisely what allows structured, linked data to be serialized and loaded to any address
3. cIt allows the blob to be modified in place
4. dIt lets multiple blobs share one allocation

12how

You have a 4 KB nav grid read by 10,000 agents. Give the full case against putting it in a component.

1. aIt is only a memory concern; iteration is unaffected
2. bChunk capacity collapses to roughly three entities per 16 KB chunk, destroying density and prefetch benefit while the loop pays a cache miss per entity — and 40 MB is stored to represent 4 KB of information
3. cComponents cannot exceed 1 KB
4. dIt works fine as long as no job reads it in parallel

13why

Why is blob immutability the thing that makes sharing safe, rather than a restriction to work around?

1. aImmutable data can be cached more aggressively by the CPU
2. bA writable shared blob referenced by 10,000 entities across parallel jobs would be a data race by construction — read-only data has no write to overlap, so all readers parallelize freely, exactly the [ReadOnly] argument applied to an asset
3. cIt prevents designers from editing the data
4. dMutable blobs cannot be serialized

14howmeasure

In a Baker, `GetEntity(TransformUsageFlags.None)` versus `TransformUsageFlags.Dynamic` on a million static props. What did you actually measure in the lab?

15why

A colleague says 'baking is just an optimization — the same game would work with runtime conversion, only slower.' What is the strongest correction?

1. aIt is correct; baking is purely a speed optimization
2. bBaking is a change of representation, not a speedup of the same work: it produces serialized chunk memory that loads as a byte copy, which is why references need remapping, why bakers must be deterministic, and why runtime code cannot reach the authoring objects at all
3. cRuntime conversion is not implementable in C#
4. dBaking mainly reduces build size