It seems like the issue you're experiencing with the material disappearing after an animation could be related to how materials are managed in Unity with Spine. One possibility is that the material is being reset to the original shared material after the animation completes. This can happen if the SkeletonAnimation component reassigns materials based on active attachments, which might reset any custom material assignments you have made. To address this, you can use the SkeletonAnimation.OnMeshAndMaterialsUpdated callback to re-assign your desired material after the animation updates. This ensures that your custom material remains assigned even after the animation changes. You can find more information on managing materials in the Spine-Unity documentation here: Changing Materials Per Instance.

bycool I think the cause of the material problems is most likely an implementation issue in Unity and not related to the settings at the time of exporting the animation. Check the note sections in the "Changing Materials Per Instance" section linked by Spinebot, and make sure there that your implementation method does not contradict the note that says not to do it this way.

bycool Then could you send us via email a minimal Unity project that can reproduce the problem?: contact@esotericsoftware.com
Please include the URL of this forum thread in the email so we know the context. Then we can take a look at what's wrong.

bycool Thanks for sending us your skeleton files! It appears that the material is excluded simply because all attachments are hidden at the middle of the animation. This should be a generally desirable condition to avoid unnecessary draw calls. What problems do you actually have with material being removed?

bycool Hmmm, I would have recommended you to use our handy module to reduce texture size, which is available in the latest spine-unity runtime, but the version of spine-unity runtime in your project is 3.8, which is very old, so I am sorry it is not available in your case.

Anyway, to prevent the material from being removed, the simplest workaround would be to edit the animations so that one or more attachments remain visible. Instead of making the attachment invisible, you can set the slot's alpha color to 0. The skeleton will then disappear visually, but the attachment will still be drawn, so the material will not be removed. You may want to set the curve for the slot color key to the stepped curve.

bycool

Can you give me an approximation about how much the size would be reduced? If that is ideal, I will report that and see if we are going to upgrade it.

It's hard to answer this in general, as I think it's case by case. It's easy to test according to the documentation on GitHub, so I suggest you create a new Unity project, install spine-unity4.2 and try it yourself.

And just to confirm, the problem happens because the animation team made one or more attachment invisible when they are making this animation, right?

There seems to be a misunderstanding here. I meant that the problem can be avoided if one or more image attachments are visible (active in a slot), rather the problem is that none of the attachments are visible, so the material is automatically removed to reduce unnecessary draw calls.
I don't think this is a bug, because if you don't need to show image attachments in this skeleton, you shouldn't need any material. It is common in game projects to want to temporarily hide skeletons. And if you have a large number of skeletons that you have hidden, but you are generating draw calls for them, you generally want to avoid that.

bycool

First, I want to confirm, by visible, do you mean enable/disable the attachment, rather than set the alpha of the image to 0, right?

Yes, your understanding is correct.

If that is the case, our animation team didn't make any attachment invisible/disable any attachment (at least, that's what they told me) at the last frame of the animation (where the material misses).

Even if you don't have a Spine license, you can use the Spine trial version to import the skeleton data and see the animation timeline for yourself. I checked the skeleton data you provided again just to be sure, and the image attachment was hidden by the slot attachment animation, not the slot color.

bycool Can you give me an approximation about how much the size would be reduced? If that is ideal, I will report that and see if we are going to upgrade it.

Sorry for the late reply. Please note that the spine-addressables and on-demand-loading UPM extension packages are mainly intended to provide delayed loading, not to provide different compression. So regarding your question: image size of your texture is not reduced, the download is just moved to a different package and therefore to a later point in time, when it's actually needed.

If you have to use e.g. formats like webp for your downloads, you could however derive your own on-demand-loading module though and write code which adds loading textures from the compressed images. Note that you then won't be able to utilize GPU-accelerated texture compression formats (see here under Format and here) as you likely don't want to (or can't) compress textures on the fly after downloading. So you end up saving download package size but potentially increase size in RAM after loading.