Very bad memory leak in SkeletonAnimation

nicmar

When our player is equipping a specific skin, which is made of various parts, the allocation goes up with 6-10Mb/second, and after about 1.5 minute, the Unity editor crashes.
When debugging this, i tried disabling SkeletonAnimation in the inspector, and with that, the allocation increase stopped. So it seems the memory leak is happening within SkeletonAnimation, but I'm not sure if we're doing something wrong when combining the skins, but we're doing it the HairMixAndMatch way.

We have other skins and combinations, that this doesn't happen with, so I'm not sure what is special with this one. Our rig is very complex with many different skins that we combine into clothes/equipment.

Also i tried to update spine runtime to the latest, (We had 2023-12-12 and tried 2024-02-07) but didn't make a difference.

We really need to find a fix for this as soon as possible.

See the attached video. Btw, we're using Graphy to monitor the mem usage.

Harald

Sorry to hear you're having troubles!

nicmar So it seems the memory leak is happening within SkeletonAnimation, but I'm not sure if we're doing something wrong when combining the skins, but we're doing it the HairMixAndMatch way.

What are you referring to with HairMixAndMatch? That's not an example component known to me at least.

nicmar We've localized this to happen for all hats in the game, and for the hats, i believe we use clipping attachments. I remember reading that this might be memory intensive, but not that it would be a memory leak that would crash the editor. I hope this helps you localize what the issue is.

Thanks for the additional info. Could you please send us a minimal Unity project that shows this issue? You can send it to contact@esotericsoftware.com as always, briefly mentioning this forum thread URL so that we know the context. Then we will have a look at right away.

nicmar

EDIT: We've localized this to happen for all hats in the game, and for the hats, i believe we use clipping attachments. I remember reading that this might be memory intensive, but not that it would be a memory leak that would crash the editor. I hope this helps you localize what the issue is.

nicmar

On another note, is the "Clipping" filter broken in the Tree view? Cause nothing happens when i click it, and the only way to find my clippings is that they luckily is named "clipping", like you see in the start of the video. Seems to be the same with Paths and Points. I'm on Spine 4.1.14, so it might be fixed in later versions, but I don't dare to upgrade now since we're late in production. (Unless it fixes the memory leak..)

Harald

nicmar n another note, is the "Clipping" filter broken in the Tree view? Cause nothing happens when i click it, and the only way to find my clippings is that they luckily is named "clipping", like you see in the start of the video. Seems to be the same with Paths and Points. I'm on Spine 4.1.14, so it might be fixed in later versions, but I don't dare to upgrade now since we're late in production.

Thanks for the info. Strangely I could neither reproduce this behaviour with Spine 4.1.14, nor when using the latest version. Perhaps there is something specific with your project which triggers this incorrect behaviour. I assume that this issue is no longer present with the latest 4.2 beta Editor version. If you should encounter this issue again when using the latest 4.2-beta version, please don't hesitate to let us know.

nicmar

I also tried changing the clipping to use only 3 vertices, but it didn't seem to make a difference regarding memory allocation.

Harald

@nicmar Just one quick question: Do you see any warning messages when exporting your problematic problect which causes clipping to create a huge memory leak?

nicmar

Thanks for the quick response!
Sorry, i mean "Mix and Match" which is referenced here https://en.esotericsoftware.com/spine-examples-mix-and-match and that is the concept we use.
I didn't get any error on export, unless it's hidden somehow, and i can try the beta, and always go back in case it would cause any problems.
Setting it up in a minimal project is pretty complex, due to the many parts, but i will try that as well if Beta doesn't solve it.

Harald

nicmar Setting it up in a minimal project is pretty complex, due to the many parts, but i will try that as well if Beta doesn't solve it.

I mentioned trying 4.2-beta only regarding the clipping attachment filter issue, not your main issue of the memory leak with the clipping attachments. Regarding the clipping attachment, I assume that it's only an issue on the spine-unity runtime end, or its usage, not the Spine Editor. Sorry if that was misleading.

nicmar

Also, is beta safe to use or will it become stable soon? Just so we don't get any new unexpected bugs, since it's a bit of work re-exporting all rigs (if we need that).

nicmar

We decided to go for another solution where we add a mesh to head and hair, and then modify that with an animation, if the hat is worn. That should also be more performant than using clipping anyways, right?

I hope this helps someone else having problems with clipping attachments. 🙂

Harald

nicmar We decided to go for another solution where we add a mesh to head and hair, and then modify that with an animation, if the hat is worn. That should also be more performant than using clipping anyways, right?

Glad to hear you've got a workaround in place, thanks for sharing! Yes, avoiding clipping attachments is generally advised wherever possible.

If at a later stage the stress level is lower and you have some spare time and can reproduce the memory-leak with a minimal project, we would be happy to fix the issue where possible of course. We fully understand however that you have more pressing tasks to attend to at the moment.

nicmar

Thanks, we will not go back to using the clipping attachments, so unfortunately we won't come back to that specific issue. But i have another issue that i'm posting in a separate thread, thanks 🙂