- Modifié
Issue with Bloated/Oversized Prefab due to SPINE Mesh Data?
Hi! After updating to SPINE 4.x+
, I've noticed a new issue appear revolving around Mesh data and how it's seemingly (?) saved into prefabs that contain instances of SkeletonAnimation
.
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 general sizes (SPINE 3.8
) of around 1-5 mb to 50-90 mb now. I wasn't sure what the problem was and didn't know why 1,500,000 lines were being added to the .prefab
file when checking the diff for prefabs on GitHub, but a few things tipped me to the idea that it may likely have to do with SPINE.
I'm finding that the Mesh
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 (relating to the NPC prefab based on the guid
) like these:
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1388]
value: 463
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1389]
value: 462
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1390]
value: 460
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1391]
value: 461
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1392]
value: 459
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1393]
value: 461
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1394]
value: 460
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1395]
value: 458
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1396]
value: 459
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1397]
value: 460
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1398]
value: 442
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1399]
value: 459
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1400]
value: 458
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1401]
value: 444
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1402]
value: 442
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1403]
value: 458
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1404]
value: 443
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1405]
value: 454
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1406]
value: 457
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1407]
value: 455
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1408]
value: 457
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1409]
value: 454
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1410]
value: 456
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
propertyPath: m_Triangles.Array.data[1411]
value: 455
objectReference: {fileID: 0}
- target: {fileID: 993508108996568647, guid: 59eecd1c5cc9e44bd99528cfa1581e21,
type: 3}
A look at the NPC prefab in question shows a new dropdown that I haven't seen before-I assume it's a new SPINE 4.x
addition or a new addition to Unity 2021 LTS
(was working via 2020 before).
A look at an example Town prefab that has jumped in size due to millions of new lines of seemingly redundant (?) data also is reflected with this strange dropdown. Each mesh applies a couple hundred thousands of lines of yaml data to the .prefab
file.
A look at the inspector when clicking one of the mesh data items in the dropdown shows this:
Is there a setting or option that I'm missing somewhere within the SPINE 4.x
setup? I've looked through the documentation and forum for potentially similar issues but have yet to find something similar to this one. I'm not sure if the +50-90mb bloat affects the gameplay performance that much (I haven't noticed major drops in play), but I can only assume that so many redundant lines being added to existing prefabs (only on save, by the way!) is probably not the intended behavior? If this is not a SPINE issue, please let me know! ??
Ah! I would also like to note that one of our larger towns went from a prefab size of 20 mb to 232 mb after trying to save the prefab with the existing SPINE that were present in the town. It also takes 1-2 minutes to save the prefab now, compared to the 5-10s that it took before. Any advice or things to try out would be greatly appreciated! ??
Oh dear, very sorry for the troubles! I assume that you are using the latest spine-unity 4.1 runtime, is that correct? Unfortunately I was not yet able to reproduce why your prefab file size has increased so dramatically, nevertheless some of the prefab-related changes below must have introduced this issue on your end. I'm listing all relevant sections below in order to hopefully resolve the problem as quickly as possible for you, while trying to reproduce your exact problem.
spine-unity 4.0 has started adding the generated skeleton Mesh to the prefab as a nested Mesh asset in order to provide preview images and thumbnails in the Project panel in the Unity Editor. Usually the mesh size of a few KB is usually dwarfed by a single atlas texture of 100x the size, which was why we decided to use this solution to enable prefab previews and live with the slight storage size drawback.
For reference: This has been tracked under this issue ticket.
The relevant lines of code are SetupSpinePrefabMesh
:
SpineEditorUtilities.cs : L111.
Which is called whenever a Prefab is saved:
SpineEditorUtilities.cs : L108
In order to remove any unnecessary overhead Mesh assets from the actual build, a SpineBuildProcessor
class has been introduced which removes the generated meshes in PreprocessBuild
, and re-adds them in PostprocessBuild
:
SpineBuildProcessor.cs : L95.
That is, if the Spine Preferences setting Optimize Preview Meshes
is enabled, which may be preferred to have it disabled to save build time during quick intermediate builds.
Nevertheless, I could not make a single .prefab file increase in size so much, since the Mesh is listed in the Inspector as in your screenshot as having e.g. 5.2 KB of vertex data, however this did not end up being saved in the .prefab
file itself (admittedly, I wonder why!).
In order to address the issue that Prefabs always list the MeshFilter
as "override" (changed), there was the option introduced to remove the MeshFilter
component automatically from any Prefabs:
SkeletonRenderer.EditorUpdateMeshFilterHideFlags()
, SkeletonRenderer.cs : L86-L122. The setting Fix Prefab Overr. MeshFilter
can be globally set in the Spine Preferences window, and additionally overwritten at each Skeleton Renderer
component in Advanced - Fix Prefab Overr. MeshFilter.
The issue ticket regarding prefabs always listing the MeshFilter as override can be found here, it's still unresolved since no solution has been found yet which does not have any drawbacks.
If you could share any details about how we can reproduce the problem (necessary steps), or a few lines of diff of the newly added lines that were added to your prefabs. Also, if you could send us a minimal Unity project that still demonstrates the issue, that would help us a lot. You can send us a minimal Unity project as a zip package to contact@esotericsoftware.com (briefly mentioning this forum thread URL so that we know the context). Sorry again for the troubles and thanks for reporting!
Harald
Hi Harald! Sorry for the delayed response, but I just wanted to let you know that after a lot of investigation and conversation with the people at Unity, this is not a SPINE bug but rather a bug with the URP Lighting system!
Thank you for taking the time to look at this issue! It helped guide us towards the right path.
Right now, this is a known bug in Unity LTS 2021 and will be fixed hopefully in the coming weeks. For you (or others who may reach this point), the main forum post can be found here:
Unity Forum Link (Bug Case: IN-38390)
@JulianRice No need to apologize. Thanks a lot for getting back to us and for filing a bug with Unity, looking forward to the fix!