YAML prefab serialization example

Read time 6 minutes

Last updated 25 days ago

This page demonstrates annotated YAML excerpts of prefab instances, nested prefabs, and prefab variants from Unity project files. The excerpts are trimmed for readability: the original files contain more

m_Modifications

entries than this page shows. For a description of the data model that these excerpts follow, refer to YAML serialization of prefabs.

The page covers the following concepts:

Prefab instance in a scene
Nested prefab
Prefab variant

Prefab instance in a scene

The following excerpt is from a scene file that places an instance of a rock prefab into the scene. The instance overrides the rock's position, rotation, and name.


--- !u!1001 &11866470PrefabInstance:  m_ObjectHideFlags: 0  serializedVersion: 2  m_Modification:    serializedVersion: 3    m_TransformParent: {fileID: 1122852772}    m_Modifications:    - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3}      propertyPath: m_LocalPosition.x      value: 39.341      objectReference: {fileID: 0}    - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3}      propertyPath: m_LocalPosition.y      value: 4.425      objectReference: {fileID: 0}    - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3}      propertyPath: m_LocalPosition.z      value: 26.527      objectReference: {fileID: 0}    - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3}      propertyPath: m_LocalRotation.w      value: 0.69781095      objectReference: {fileID: 0}    - target: {fileID: 8354524949365800270, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3}      propertyPath: m_Name      value: Rock_05_Prefab (4)      objectReference: {fileID: 0}    m_RemovedComponents: []    m_RemovedGameObjects: []    m_AddedGameObjects: []    m_AddedComponents: []  m_SourcePrefab: {fileID: 100100000, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3}--- !u!4 &11866471 strippedTransform:  m_CorrespondingSourceObject: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3}  m_PrefabInstance: {fileID: 11866470}  m_PrefabAsset: {fileID: 0}

Key points in the excerpt:

The
```
PrefabInstance
```
element with fileID
```
11866470
```
represents the instance. Its
```
m_SourcePrefab
```
field references the rock prefab asset (by
```
guid
```
) through the prefab asset handle (fileID
```
100100000
```
).
```
m_Modification.m_TransformParent
```
references a
```
Transform
```
component in the same scene file, making the prefab instance a child of that scene object in the hierarchy.
Each entry in
```
m_Modifications
```
contains one property override. The
```
target
```
identifies the object inside the source prefab by
```
guid
```
and
```
fileID
```
, and a combination of
```
propertyPath
```
and
```
value
```
specify the overridden property and its value.
The stripped
```
Transform
```
element (element with the
```
stripped
```
attribute) at fileID
```
11866471
```
is a placeholder for the
```
Transform
```
component on the prefab instance's root GameObject. Other objects in the scene use this placeholder whenever they reference the prefab instance's root, for example in the
```
m_Children
```
list of the parent scene object's
```
Transform
```
component.

The original

m_Modifications

list in the source file also contains the other rotation components and euler-angle-hint overrides; they're omitted here for readability.

Nested prefab

The following example is the complete prefab file that nests one other prefab inside it.


%YAML 1.1%TAG !u! tag:unity3d.com,2011:--- !u!1 &6949479575104989305GameObject:  m_ObjectHideFlags: 0  m_CorrespondingSourceObject: {fileID: 0}  m_PrefabInstance: {fileID: 0}  m_PrefabAsset: {fileID: 0}  serializedVersion: 6  m_Component:  - component: {fileID: 1188189139150009913}  m_Layer: 0  m_Name: Stone_01_Prefab  m_TagString: Untagged  m_Icon: {fileID: 0}  m_NavMeshLayer: 0  m_StaticEditorFlags: 2147483647  m_IsActive: 1--- !u!4 &1188189139150009913Transform:  m_ObjectHideFlags: 0  m_CorrespondingSourceObject: {fileID: 0}  m_PrefabInstance: {fileID: 0}  m_PrefabAsset: {fileID: 0}  m_GameObject: {fileID: 6949479575104989305}  m_LocalRotation: {x: 0, y: 0, z: 0, w: 1}  m_LocalPosition: {x: 0, y: 0, z: 0}  m_LocalScale: {x: 1, y: 1, z: 1}  m_ConstrainProportionsScale: 0  m_Children:  - {fileID: 8712595929885449456}  m_Father: {fileID: 0}  m_RootOrder: 0  m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}--- !u!1001 &9179429690634107675PrefabInstance:  m_ObjectHideFlags: 0  serializedVersion: 2  m_Modification:    serializedVersion: 3    m_TransformParent: {fileID: 1188189139150009913}    m_Modifications:    - target: {fileID: 919132149155446097, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3}      propertyPath: m_Name      value: Stone_01_Mesh      objectReference: {fileID: 0}    - target: {fileID: 4742473837712756890, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3}      propertyPath: m_FadeMode      value: 1      objectReference: {fileID: 0}    - target: {fileID: 4742473837712756890, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3}      propertyPath: m_AnimateCrossFading      value: 1      objectReference: {fileID: 0}    m_RemovedComponents: []    m_RemovedGameObjects:    - {fileID: -1027982724379016789, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3}    m_AddedGameObjects: []    m_AddedComponents: []  m_SourcePrefab: {fileID: 100100000, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3}--- !u!4 &8712595929885449456 strippedTransform:  m_CorrespondingSourceObject: {fileID: -8679921383154817045, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3}  m_PrefabInstance: {fileID: 9179429690634107675}  m_PrefabAsset: {fileID: 0}

Key points in the example:

The outer prefab's root is serialized as two separate YAML elements: a
```
GameObject
```
element (fileID
```
6949479575104989305
```
) and its
```
Transform
```
component element (fileID
```
1188189139150009913
```
). Unity writes them both directly into the file, the same way it writes any non-prefab GameObject.
The
```
m_Children
```
field on the outer
```
Transform
```
component element lists the fileID of the stripped
```
Transform
```
placeholder element for the nested instance (
```
8712595929885449456
```
). This reference places the nested prefab's root as a child in the outer prefab's hierarchy.
The
```
PrefabInstance
```
element with fileID
```
9179429690634107675
```
represents the nested prefab instance. Its
```
m_SourcePrefab
```
field references a different prefab asset (the
```
Stone
```
source prefab), identified by
```
guid
```
.
The
```
m_Modification.m_TransformParent
```
field on the nested
```
PrefabInstance
```
references the outer
```
Transform
```
component element. As a result, the nested instance is placed under the outer prefab's root in the hierarchy.
The stripped
```
Transform
```
placeholder element at fileID
```
8712595929885449456
```
is the target that the outer
```
Transform
```
component's
```
m_Children
```
field points to. Its
```
m_CorrespondingSourceObject
```
field identifies the specific
```
Transform
```
component inside the source
```
Stone
```
prefab that this placeholder represents.
The
```
m_RemovedGameObjects
```
list contains one entry, which indicates that one child GameObject from the source prefab is removed from this nested instance. The
```
m_RemovedComponents
```
and
```
m_AddedGameObjects
```
lists are empty.

The original

m_Modifications

list in the source file contains additional transform and static flag overrides, they're omitted here for readability.

Prefab variant

The following excerpt is from a prefab variant file. The variant is a horizontally flipped version of a base door prefab.


%YAML 1.1%TAG !u! tag:unity3d.com,2011:--- !u!1001 &5365984487090290000PrefabInstance:  m_ObjectHideFlags: 0  serializedVersion: 2  m_Modification:    serializedVersion: 3    m_TransformParent: {fileID: 0}    m_Modifications:    - target: {fileID: 1262770979034925880, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3}      propertyPath: m_Name      value: DoorFusuma_100x200_01_Prefab (38) Variant      objectReference: {fileID: 0}    - target: {fileID: 1727893522013754926, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3}      propertyPath: m_LocalScale.x      value: -1      objectReference: {fileID: 0}    - target: {fileID: 1761800793405478535, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3}      propertyPath: m_LocalScale.x      value: -1      objectReference: {fileID: 0}    - target: {fileID: 7660580366407964633, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3}      propertyPath: m_LocalScale.x      value: -1      objectReference: {fileID: 0}    m_RemovedComponents: []    m_RemovedGameObjects: []    m_AddedGameObjects: []    m_AddedComponents: []  m_SourcePrefab: {fileID: 100100000, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3}

Key points in the excerpt:

The root YAML element of the variant file is a
```
PrefabInstance
```
, which has class ID
```
1001
```
. A non-variant prefab file, by contrast, starts with a
```
GameObject
```
element.
The
```
m_Modification.m_TransformParent
```
field is
```
{fileID: 0}
```
. The
```
PrefabInstance
```
element has no parent transform because it's the root of the file. This is characteristic of prefab variants.
The
```
m_SourcePrefab
```
field references the base prefab that the variant inherits from.
The entries in the
```
m_Modifications
```
list contain the property overrides that make this variant distinct from the base. In this example, the negative
```
m_LocalScale.x
```
property values on three
```
Transform
```
components flip the door geometry horizontally.

The original file contains additional transform and position overrides that complete the flipped layout, they're omitted here for readability.

Documentation

Development

User Acquisition

Monetization

Industry

Unity Engine

User Manual

Script Reference

Unity Engine

YAML prefab serialization example

Prefab instance in a scene

Nested prefab

Prefab variant

Additional resources