SerializeUtility is responsible for writing entire Worlds to disk. It is written specifically for serializing Subscene Sections to disk in the editor, and then for streaming¹⁾ them in efficiently during runtime. It can support other use cases, but it is not designed to.

SerializeUtility supports two modes for deserialization:

• Blocking (DeserializeWorld)
• Async (BeginDeserializeWorld/EndDeserializeWorld).

But only a blocking mode for serialization (SerializeWorld). This is reasonable because it's edit-time functionality, and runs via a background ScriptedImporter.²⁾

There are two types of baking:

1. Full Rebakes
2. Incremental Bakes (EntityDiffer) ³⁾

A full rebake is triggered when:

• A subscene is opened.
• An assembly containing Baker classes is modified. ⁴⁾

Incremental bakes are triggered when:

• Open subscenes are modified.

Subscenes are serialized to the binary format in several spots:

1. When closing an opened, dirty SubScene.
2. After modifying an assembly with bakers, triggering a full rebake.
3. When making a player build⁵⁾.

Serialization uses a ScriptedImporter called SubSceneImporter. This importer is injected into the AssetDatabase directly, rather than using the normal attribute. The subscene unity files (ie. my_subscene.unity) do not get imported by this importer, rather, it operates on an in-memory “asset” representing the baked scene.

SubScene serialization can be debugged by placing breakpoints within SerializeUtility.SerializeWorld, and attaching to the Unity Import Worker process via the Rider “Attach to Unity Process…” dialogue.

These systems stream Sections of entities scenes⁶⁾ into a World. It's intended for use at runtime, but will also be used in the editor when Entity Subscenes are “Closed for Edit” in the Hierarchy.

The AsyncLoadSceneOperation and associated jobs use the Async Mode of SerializeUtility (see above).