Bug Sudden Prefab Size Bloating (2021.3 LTS)

Hello everyone!
We've been working hard on polishing the visuals for a number of Towns in our game (Unity 2D / URP), but a recent update from 2020 LTS to 2021.3 LTS has led to a strange prefab size bloating issue that we haven't been able to find any solutions or hints for! I posted a similar issue on the SPINE (Esoteric Software) forums thinking it was initially an issue with SPINE (third-party animation software), however after more playtesting, experimenting in prefab editing mode, and more, I think it may have to do with Unity (which then has its effect on SPINE)... and so here I am!

Our game has a complex prefab system for managing towns and other environments—each town has a number of NPCs, each NPC being its own prefab variant (of a baseline NPC) that has most of its settings saved to the prefab variant (exceptions being position in the town, etc., which are saved in the town prefab).

When saving an existing Town prefab, the file size of the prefab jumps 30-50x, from pre-update sizes of around 1-5 mb to 50-90 mb now (in one specific case, 30 mb to 600 mb...;w. I wasn't sure what the problem was and didn't know why 1,500,000-10,000,000 lines were being added to the .prefab file when checking the diff for prefabs on GitHub

I'm finding that a prefab's data's triangle, position, color, indices etc data are all being saved into the parent prefab (town), and this seems to be the cause of the prefab file size bloat. Within the Town prefab, I'm seeing millions of lines (with the `guid` corresponding to a prefab) like this:

Code (yml):

1. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
2.     type: 3}
3.   propertyPath: m_Triangles.Array.data[1388]
4.   value: 463
5.   objectReference: {fileID: 0}
6. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
7.     type: 3}
8.   propertyPath: m_Triangles.Array.data[1389]
9.   value: 462
10.   objectReference: {fileID: 0}
11. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
12.     type: 3}
13.   propertyPath: m_Triangles.Array.data[1390]
14.   value: 460
15.   objectReference: {fileID: 0}
16. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
17.     type: 3}
18.   propertyPath: m_Triangles.Array.data[1391]
19.   value: 461
20.   objectReference: {fileID: 0}
21. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
22.     type: 3}
23.   propertyPath: m_Triangles.Array.data[1392]
24.   value: 459
25.   objectReference: {fileID: 0}
26. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
27.     type: 3}
28.   propertyPath: m_Triangles.Array.data[1393]
29.   value: 461
30.   objectReference: {fileID: 0}
31. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
32.     type: 3}
33.   propertyPath: m_Triangles.Array.data[1394]
34.   value: 460
35.   objectReference: {fileID: 0}
36. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
37.     type: 3}
38.   propertyPath: m_Triangles.Array.data[1395]
39.   value: 458
40.   objectReference: {fileID: 0}
41. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
42.     type: 3}
43.   propertyPath: m_Triangles.Array.data[1396]
44.   value: 459
45.   objectReference: {fileID: 0}
46. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
47.     type: 3}
48.   propertyPath: m_Triangles.Array.data[1397]
49.   value: 460
50.   objectReference: {fileID: 0}
51. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
52.     type: 3}
53.   propertyPath: m_Triangles.Array.data[1398]
54.   value: 442
55.   objectReference: {fileID: 0}
56. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
57.     type: 3}
58.   propertyPath: m_Triangles.Array.data[1399]
59.   value: 459
60.   objectReference: {fileID: 0}
61. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
62.     type: 3}
63.   propertyPath: m_Triangles.Array.data[1400]
64.   value: 458
65.   objectReference: {fileID: 0}
66. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
67.     type: 3}
68.   propertyPath: m_Triangles.Array.data[1401]
69.   value: 444
70.   objectReference: {fileID: 0}
71. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
72.     type: 3}
73.   propertyPath: m_Triangles.Array.data[1402]
74.   value: 442
75.   objectReference: {fileID: 0}
76. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
77.     type: 3}
78.   propertyPath: m_Triangles.Array.data[1403]
79.   value: 458
80.   objectReference: {fileID: 0}
81. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
82.     type: 3}
83.   propertyPath: m_Triangles.Array.data[1404]
84.   value: 443
85.   objectReference: {fileID: 0}
86. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
87.     type: 3}
88.   propertyPath: m_Triangles.Array.data[1405]
89.   value: 454
90.   objectReference: {fileID: 0}
91. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
92.     type: 3}
93.   propertyPath: m_Triangles.Array.data[1406]
94.   value: 457
95.   objectReference: {fileID: 0}
96. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
97.     type: 3}
98.   propertyPath: m_Triangles.Array.data[1407]
99.   value: 455
100.   objectReference: {fileID: 0}
101. - target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
102.     type: 3}
103.   propertyPath: m_Triangles.Array.data[1408]
104.   value: 457
105.   objectReference: {fileID: 0}

I noticed that this is only bloats the overarching prefab's size when smaller prefabs (in this case, visuals - trees) are added. Each tree prefab is only 5 kb, yet adding one and saving increases the overall prefab's size by 1-2 MB.



I'm not sure how reproduction works for this, but it definitely began happening after the update to 2021.3 LTS. Here are some more notes:

• We're using URP.
• All the visual prefabs (the 5 kb ones that bloat the parent by 1-2 MB) are static and contain two or more instances of URP's `Light2D` to work with the 2D lighting system we have with.
• Deleting the visual prefab from the parent prefab reduces the size by 1-2 MB.
• All visual prefabs are marked as static.
• The only overridden details for a visual prefab are the in-world position and the sorting layer / order in layer for the Sprite Renderer.

If there's any other information that I should supply to help make this easier to understand/resolve, please let me know! If this can be resolved, we'll be able to speed up prefab saving times from the current 1-3 minutes to the original 10-25 seconds...!!

 

Bump! Is there any more detail needed to draw any ideas as to why this issue is happening?

 

Another bump!

 

Hi, apologies for the late follow up! After a lot of testing and experimenting, I think the root cause comes down to overridden properties of the URP `Light2D` component being serialized/saved in such a way that causes the massive redundant lines to occur. It's strange because this didn't happen before our version up from 2020 LTS to 2021 LTS.

Our prefab, which has its size get multiplied is only 2 kb as a default prefab ("LightRay"):

Code (CSharp):

1. %YAML 1.1
2. %TAG !u! tag:unity3d.com,2011:
3. --- !u!1 &3229529769903841699
4. GameObject:
5.   m_ObjectHideFlags: 0
6.   m_CorrespondingSourceObject: {fileID: 0}
7.   m_PrefabInstance: {fileID: 0}
8.   m_PrefabAsset: {fileID: 0}
9.   serializedVersion: 6
10.   m_Component:
11.   - component: {fileID: 3888023561761034477}
12.   - component: {fileID: 8984987226688656336}
13.   m_Layer: 0
14.   m_Name: LightRay
15.   m_TagString: Untagged
16.   m_Icon: {fileID: 0}
17.   m_NavMeshLayer: 0
18.   m_StaticEditorFlags: 0
19.   m_IsActive: 1
20. --- !u!4 &3888023561761034477
21. Transform:
22.   m_ObjectHideFlags: 0
23.   m_CorrespondingSourceObject: {fileID: 0}
24.   m_PrefabInstance: {fileID: 0}
25.   m_PrefabAsset: {fileID: 0}
26.   m_GameObject: {fileID: 3229529769903841699}
27.   m_LocalRotation: {x: -0, y: -0, z: -0, w: 1}
28.   m_LocalPosition: {x: -6.31, y: 6.79, z: 0}
29.   m_LocalScale: {x: 4, y: 4, z: 4}
30.   m_Children: []
31.   m_Father: {fileID: 0}
32.   m_RootOrder: 0
33.   m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0}
34. --- !u!114 &8984987226688656336
35. MonoBehaviour:
36.   m_ObjectHideFlags: 0
37.   m_CorrespondingSourceObject: {fileID: 0}
38.   m_PrefabInstance: {fileID: 0}
39.   m_PrefabAsset: {fileID: 0}
40.   m_GameObject: {fileID: 3229529769903841699}
41.   m_Enabled: 1
42.   m_EditorHideFlags: 0
43.   m_Script: {fileID: 11500000, guid: 073797afb82c5a1438f328866b10b3f0, type: 3}
44.   m_Name:
45.   m_EditorClassIdentifier:
46.   m_LightType: 2
47.   m_BlendStyleIndex: 0
48.   m_FalloffIntensity: 0.5
49.   m_Color: {r: 0.86627805, g: 0.9716981, b: 0.9608571, a: 1}
50.   m_Intensity: 1
51.   m_LightVolumeOpacity: 0
52.   m_ApplyToSortingLayers: ed38399b0000000067f7e282679444fc19fcaf57733e98c1f55a7776410f6aeb49f6dcd2
53.   m_LightCookieSprite: {fileID: 21300000, guid: fb0337c89564f204e941df1f2bf3e0b0,
54.     type: 3}
55.   m_UseNormalMap: 0
56.   m_LightOrder: 0
57.   m_AlphaBlendOnOverlap: 0
58.   m_ShadowIntensity: 0
59.   m_ShadowVolumeIntensity: 0
60.   m_PointLightInnerAngle: 360
61.   m_PointLightOuterAngle: 360
62.   m_PointLightInnerRadius: 0
63.   m_PointLightOuterRadius: 1
64.   m_PointLightDistance: 3
65.   m_PointLightQuality: 1
66.   m_ShapeLightParametricSides: 5
67.   m_ShapeLightParametricAngleOffset: 0
68.   m_ShapeLightParametricRadius: 1
69.   m_ShapeLightFalloffSize: 0.5
70.   m_ShapeLightFalloffOffset: {x: 0, y: 0}
71.   m_ShapePath:
72.   - {x: -0.5, y: -0.5, z: 0}
73.   - {x: 0.5, y: -0.5, z: 0}
74.   - {x: 0.5, y: 0.5, z: 0}
75.   - {x: -0.5, y: 0.5, z: 0}
76.  

Whereas any adjustments to properties in Light2D seem to produce the a gajillion entries for:
- m_Triangles.Array (3000+)
- m_Vertices.Array (1200+) (uv.x, uv.y, color.a, etc.)

I made a copy of the overarching prefab that was 200+ mb and reset the overrides for a number of lights, and the prefab size dropped by 50 mb within 10 minutes of work. However, it doesn't make sense to me that the lights would punish us (with bloat) for customizing their colors or intensities, and it also probably wouldn't make sense to make a new prefab for every single overridden light that is prepared.

Because this seems to be more of a (potential) URP issue, would it make more sense to open a new issue on their end of the forums, or is there more we can discuss/troubleshoot in this thread?

Thank you!

PS: Only 2 fields are overridden in the Light2D component, and we acknowledge that probably not all 9 sorting layers should be selected (but modifying that doesn't affect the prefab bloat).

 

@Mads-Nyholm Hello! Here's the case number:

CASE IN-38390

Thank you for taking a look at this and letting me know the next steps.

 

Hey! I've noted the bug fix has been implemented a while ago, and while reproduction isn't an issue, the fix applied by Unity doesn't seem to easily resolve existing issues regarding over-serialization of light/vertex data, meaning that all of the environments we have in our game can't be easily fixed without rebuilding the entire environment (which isn't plausible based on our timeline/the scale).

Is there a way the Unity team can implement a fix that also fixes prefabs that have been impacted by this nasty bloating bug? I was able to find a way to bring our largest town/environment from 800 MB to 600 MB, but it's still too large (and it used to be 20-30 MB before the bloating bug was discovered/released)

Thank you!