YAML prefab serialization example

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 &11866470
PrefabInstance:
  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 stripped
Transform:
  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 &6949479575104989305
GameObject:
  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 &1188189139150009913
Transform:
  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 &9179429690634107675
PrefabInstance:
  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 stripped
Transform:
  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 &5365984487090290000
PrefabInstance:
  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.

Additional resources

YAML serialization of prefabs

YAML Class ID reference