Esoteric Software

[Hoperin]

Hello. We recently upgraded to spine 4.0 and I just discovered that now our unity builds are broken -- always crashing, with an out of temporary memory error (image attached, sorry for the bad quality).

I tracked it down to a spine build preprocessing call in SpineBuildProcessor.cs, that once I disabled let us move on just fine with building. But I have no idea what disabling this will do or why it was causing crashes in the first place, and am pretty concerned about this either being caused by a problem with out spines or the runtime itself.

This is the problematic chunk:

internal static void PreprocessBuild () {
isBuilding = true;
#if HAS_ON_POSTPROCESS_PREFAB
var assets = AssetDatabase.FindAssets("t:Prefab");
foreach(var asset in assets) {
//string assetPath = AssetDatabase.GUIDToAssetPath(asset);
//GameObject g = AssetDatabase.LoadAssetAtPath<GameObject>(assetPath);
//if (SpineEditorUtilities.CleanupSpinePrefabMesh(g)) {
// prefabsToRestore.Add(assetPath);
//}
}
AssetDatabase.SaveAssets();
#endif
}

Thanks!

[Harald]

We are sorry for the troubles. We have just submitted a commit to the 4.0 branch on git which fixes a problem in this regard, hopefully it resolves your issue as well.

A new spine-unity 4.0 unitypackage is available for download:
Spine Unity Download

[Hoperin]

wonderful, thank you for the speedy fix!

---

Hi again, we've updated to the newest spine 4 package but we are still seeing this issue and getting build crashes unless i comment out the same above lines.

[Harald]

Oh dear, sorry to hear that!

I have uploaded another update which improves the situation in a different way and fixes another potential problem (however I'm not sure it fixes yours):
Spine Unity Download
Please let me know if the issue still persists. If so, could you please share another screenshot, just to be sure the call stack is still the same and the problem still occurs at the same line of code. Could you then please also create a minimal Unity project that still shows this issue, and send it as a zip package to contact@esotericsoftware.com (briefly mentioning this forum thread URL so that we know the context)?

---

Replying here on the forum to your email so that others can also benefit.

I'm sorry to hear that the problem still persists, thanks for reporting!

I found that if I comment these chunks entirely, we have no problems with build, and it looks like everythign is fine, but I don't actually know what this preprocess step does and if it is a problem that we are disabling it. Can you tell me what this code is for and what the effects of just commenting it out would be, and if it is essential, do you have any ideas on how we can fix this issue?

Both methods PreprocessSpinePrefabMeshes and PreprocessSpriteAtlases are non-critical, it only reduces build size by removing unnecessary Mesh and Texture reference which is needed for the Unity Editor only, and not in the build.

The first method PreprocessSpinePrefabMeshes clears the saved procedural Mesh at a SkeletonRenderer prefab. The procedural mesh is only saved at the prefab so that Unity does not display the prefab as "modified" all the time. Clearing the mesh should reduce the build size, removing this method should thus only have the effect of increasing the build size slightly by the mesh size.

The second method PreprocessSpriteAtlases clears the generated Editor Sprite Atlas Texture at a SpineSpriteAtlasAsset, which is rarely used anyway. This texture is again only generated and assigned at a Material for use in the Unity Editor, and not used in the build. Thus as above, removing this method will only increase the build size if you are using SpineSpriteAtlasAsset (which I don't assume) bu the size of the generated editor atlas texture.

We will have a look at the issue again and will let you know once we have an update to offer which cleanly resolves this problem.

[Hoperin]

Thank you! Good to know that they are uncritical, so I can keep them disabled for the time being so our builds can run smoothly. Build size is definitely a concern for us though longterm so I will bring this to my team and weight the pros and cons. And of course any extra changes on spines end to optimize this would be greatly appreciated so will keep an eye on this thread, thanks!

[Harald]

We have now likely fixed the first method's problems (in this commit), a new 4.0 spine-unity unitypackage has been released. It will be merged to 4.1-beta soon.
Spine Unity Download
Could you please test if this latest spine-unity 4.0 package fixes the issue? If it does, and the second method still causes a crash, could you please send us an updated crash report stack trace of the second method, as seen in the first screenshot on top of this thread?

I have now created an issue ticket for better tracking here:
https://github.com/EsotericSoftware/spine-runtimes/issues/2047

[Suraim]

Hi.
I have a similar problem and came across this topic.


I was having a problem with Build time being about 10 times longer when used with UnityVisualScripting.
The more assets you have, the longer the build time, so I did some research and came across SpineBuildProcessor.cs.

I commented out the relevant section as the topic poster did, and the above problem went away.

I did not experience any memory crashes in my environment, whether it was a matter of PC specs or not.

[Harald]

Sorry to hear you've encountered similar problems. Which version of the spine-unity runtime (name of the unitypackage, also listed in Assets/Spine/version.txt) are you using?