このサイトを正しく表示するには、最新のブラウザを使用し、Javascriptを有効化してください。

Spine animation on Unity 2018 shows too many verts

GuapoMan

Hello, I'm doing my first Spine animation for my Unity game, but I don't know if it's normal to have too many verts or if I did something wrong.

I have this in Spine:

Then, when I added my animation to Unity (I'm using Unity 2018), the stats goes from this:

To this, when the Spine object is active but without playing any animation:

And when the animation is running:

Resume:

Spine - Verts on the project = 3,899
Unity - Verts without my 'Spine animation' / 'game object' in the scene = 376
Unity - Verts with my Spine animation in the scene and no animation playing = 9.8k
Unity - Verts with my Spine animation in the scene and the animation playing = between 70k and 98k

Is that normal? I'm sorry if there is a discussion like this; I found nothing related on the forum.

Extra info when importing the Spine project to Unity:

It created 4 material objects, three normal and one multiply.
I have three assets, 2048 x 2048.

GuapoMan

I'm using the Runtime spine-unity-4.2-2024-05-17.unitypackage

Nate

Yep, that's a lot of vertex transforms. The plus 248 bones, 78 constraints, 139 visible attachments -- all that makes a pretty heavy skeleton. That may be OK, after doing basic optimizations, depending what else you are doing at the same time and the devices you are targetting.

The first thing to do is use prune. Also see this section (both whole pages really):
https://esotericsoftware.com/spine-metrics#CPU-usage

That will reduce your vertex transforms. You can look at reducing the number of bones. If you have extremely detailed sections of the skeleton that don't actually need, redo them to use fewer vertices/bones/etc.

13 clipping polygons is very likely to be unnecessary. Clipping is very CPU expensive. You want to use as few clipping vertices as possible, which is 3. The size does not matter, making it huge is fine, but use 3 vertices. Next you want to clip as few vertices as possible. That means clip as few attachments as possible and those attachments should have as few vertices as possible. Simplify the clipped parts of your skeleton.

Even better: remove the clipping attachments except for what you absolute must have. You can duplicate meshes and cut them differently, then swap between them to simulate clipping. Otherwise you can hide images behind others instead of using clipping.

Lastly, your metrics don't show it, but it's a common mistake so I'll mention it: avoid deform keys in most cases (see the linked docs). Use mesh weights instead, where you key a bone that affects the mesh instead of keying the deform for the mesh.

GuapoMan

Hey, thank you! Your response was really helpful!

I did a quick test removing the clipping, and my verts stopped changing in Unity. Also, they are not growing to 98k!

When I turned off the clipping (by disabling the slots for that function), my verts went from 9.8k to around 30k because now all the hidden slots are being shown, but the verts remain at that amount, so the game is not lagging anymore.

I never thought the clipping was that demanding to use because I don't have any problem using Unity's mask functions, but now that I know the Spine mask functions (clipping) are a terrible choice for the Spine animations, I will avoid them on Spine. I still need to update my animations because now that I removed the clipping option, they don't look how they should look.

Regarding deforming keys, I should say that I thought it was a good option when creating animations, but luckily for me, I took a course in which the teacher said it was a terrible thing to do, so I discarded the idea and didn't do it.

Note: I still need to use the prune and try the options in the link you shared with me. After doing all that, I will share the results here.

Nate

Glad you already found reasonable performance, even before doing all the easy optimizations (eg prune).

Clipping can be used, it just has a cost. There's a big different between clipping a handful of triangles using a 3 vertex clipping attachment and clipping 500+ triangles with 13 clipping attachments. 🙂

Deform is similar. It's absolutely fine to use when needed, but it's wasteful if overused and often can be avoided by using weights.

Everything has a cost, it's just a matter of staying under the threshold where the sum of all the costs become too much. Spine doesn't try to force you to be efficient, so it's good to figure out how to keep things reasonable before having created tons of rigging and animation that may need to be adjusted.

For the most part it's pretty straightforward: use fewer bones and vertex transforms and be wary of clipping and deform keys. Often you can use weights where at first it might seem like bones are needed. Like these tips:

The 5 cream toppings use only weights, no bone for each one.
Loading Image

A single bone for a faux 3D cube.
Loading Image

More tips here:
http://esotericsoftware.com/spine-tips

GuapoMan

Hello, I was testing the animation without the clipping when I accidentally found/encountered a new situation.

When my Spine GameObject is loaded the first time, I have 4.8k verts, and it keeps that amount when running or not the animation. Still, when I hide attachments, it doesn't matter if I did it through Spine' skins, C# coding (slot.Attachment = null; or setting the alpha color to zero), or Unity's inspector (Advanced/Debug/Slots); my verts increases:

All attachments enabled:

After disabling some attachments:

After enabling the attachments again:

I need to change the visibility of some attachments while playing the game, but what can I do to avoid or fix that situation?

Misaki

GuapoMan Hmmm, this is very strange. I checked with the example scene that comes with the spine-unity runtime, and the number of verts decreases when the attachments are hidden, and then returns to the original verts value when the attachments are shown again, as expected. Are you able to reproduce that problem with the example skeleton like Spineboy?

GuapoMan

Extra note: when I disabled attachment visibility through skins and duplicated the Spine GameObject on Unity, the new Spine GameObject has its verts number 3.4k (closest to the original amount of 4.8k), which is more realistic because the GameObject is displaying fewer images.

GuapoMan

Thanks for your answer. I can't reproduce the problem with the example skeletons, but I noticed some other differences between my skeleton and the raptor example:

Batches only increase 1 point with Raptor, but 63 with mine.
Trials only increase 500 points with Raptor, but 2.7k with mine.

However, I can't even hide one slot of my skeleton without having that strange situation, look:

And then:

GuapoMan

After 6 hrs of trying to make it work, the only way I found was to use combined skins:
1- Add all the skins I want to show with the slots I want (omit the skins with the slots I need to hide)
2- Add the default skin to the combined skins.
3- Put my Sata.DefaultSkin = to my new combined skin.
4- Make a clone of my GameObject and use this object because this new object displays only the verts it should show.
5- Disable the original GameObject or delete it because this one has a weird amount of verts.

GuapoMan

It seems to be a problem with Unity 2018. I updated to Unity 2021 on other of my workstations, and it doesn't have the same problem when enabling/disabling attachments.

However, there are another two other problems in both versions (2018 and 2021):

If I set my Spine GameObject to display inside Unity masks, my object's materials grow strangely, going from 4 materials to around 70 materials, and I don't know if that will affect the game performance.

Mask interaction: None:

Mask interaction: Visible inside mask:

The way some lights affect my Spine GameObject is wrong. I set my Materials (excluding the Multiply) to Spine/Skeleton Lit to make my object be affected by light in a similar way to a Sprites/Diffuse material, and my object is almost okay, but when it's receiving a light type 'point' or 'spot' the colors look like this:

But it should look like this:

This problem happens to Unity's sprites if I'm playing with a low-resolution setting and I use those light types, but the problem disappears if I play with a high-resolution setting; I don't know if I should do something to tell my Spine GameObject to receive the lights in a high-resolution mode or I need to do something more.

Harald

GuapoMan It seems to be a problem with Unity 2018. I updated to Unity 2021 on other of my workstations, and it doesn't have the same problem when enabling/disabling attachments.

Glad to hear, thanks for letting us know.

GuapoMan If I set my Spine GameObject to display inside Unity masks, my object's materials grow strangely, going from 4 materials to around 70 materials, and I don't know if that will affect the game performance.

This is very strange. Could you please send us a minimal Unity project which still shows this issue? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.

GuapoMan The way some lights affect my Spine GameObject is wrong. I set my Materials (excluding the Multiply) to Spine/Skeleton Lit to make my object be affected by light in a similar way to a Sprites/Diffuse material, and my object is almost okay, but when it's receiving a light type 'point' or 'spot' the colors look like this:

This looks like you receive lighting per-vertex (evaluated at vertices and interpolated between vertices) but want to have lighting per-pixel. If you're using the Built-in Render Pipeline and not URP, you could use the Spine/Sprite/Pixel Lit shader to receive lighting per-pixel. For more info, check out the documentation here.

GuapoMan

Harald This looks like you receive lighting per-vertex (evaluated at vertices and interpolated between vertices) but want to have lighting per-pixel. If you're using the Built-in Render Pipeline and not URP, you could use the Spine/Sprite/Pixel Lit shader to receive lighting per-pixel. For more info, check out the documentation here.

My project uses the URP. I installed the package for that but don't know what to do with it. When I set the materials of my Spine Game Object to 'Universal Render Pipeline/Spine/Sprite' or 'Universal Render Pipeline/2D/Spine/Sprite', the Game Object just isn't visible anymore or is all purple.

Harald This is very strange. Could you please send us a minimal Unity project which still shows this issue? You can send it as a zip package to [contact@esotericsoftware.com](mailto:contact@esotericsoftware.com), briefly mentioning this forum thread URL so that we know the context.

Yes, I can do a project only with the animation, but I warn you my Spine object is NSFW.

GuapoMan

GuapoMan My project uses the URP. I installed the package for that but don't know what to do with it. When I set the materials of my Spine Game Object to 'Universal Render Pipeline/Spine/Sprite' or 'Universal Render Pipeline/2D/Spine/Sprite', the Game Object just isn't visible anymore or is all purple.

Updates! I learned using the "Spine Universal RP Shaders/4.2.33/Examples/2D/URP 2D Shaders."

Now I know I need to add in "Project Settings/Graphics/Scriptable Render Pipeline Settings" the "Example 2D URP Asset" to make it work.

That allows me to use the material "Universal Render Pipeline/2D/Spine/Skeleton Lit" in the materials of my Spine animation (excluding the Multiply material), and now the animation is affected well with the custom and new 2D lights objects:

The new problem was that all my previous content was displayed in purple, so I needed to update the main material I used for my sprites.

My material was this:

I needed to update to this:

Now, the new problem is that I had only old lights like this one:

And it seems I will need to update them to this other light style:

Unless there are another options to make my old lights affect the new materials.

Harald

GuapoMan Updates! I learned using the "Spine Universal RP Shaders/4.2.33/Examples/2D/URP 2D Shaders."

Glad to hear you've figured it out.

Now I know I need to add in "Project Settings/Graphics/Scriptable Render Pipeline Settings" the "Example 2D URP Asset" to make it work.

You can also use a different RenderPipelineAsset, you don't have to use the ones provided by the Spine URP package. These do however e.g. setup blue rim lighting as a demo effect in the case of Example 2D URP Asset.

You have to be sure of course to use the proper shaders with the corresponding 2D or 3D renderer asset. So as the documentation reads:

Shaders for URP with 2D Renderer (do not use with URP (3D) Forward Renderer)

list of shaders starting with Universal Render Pipeline/2D/Spine/

Shaders for URP with 3D Forward Renderer (do not use with URP 2D Renderer)

list of shaders starting with Universal Render Pipeline/Spine/

GuapoMan The new problem was that all my previous content was displayed in purple, so I needed to update the main material I used for my sprites.

Please note that Unity provides multiple render pipelines. The Built-in Render Pipeline, Universal RP with a 3D Renderer and Universal RP with a 2D Renderer. Every pipeline requires different shaders, as does SkeletonGraphic (UI) regardless of the render pipeline which always requires a Spine/SkeletonGraphic/* shader (since it uses a CanvasRenderer to render to the UI).

GuapoMan Now, the new problem is that I had only old lights like this one:

When using URP with a 2D Renderer, you have to use different lights than with 3D renderers, see the Unity documentation. It seems that you are not yet familiar with the different render pipeline types, and what benefits each provides. It is highly recommended to get to know the Unity internals first before adding a layer of complexity on top by adding the spine-unity runtime to your project.

Thereafter, please be sure to read the following documentation sections:
https://esotericsoftware.com/spine-unity-rendering#Shaders
https://esotericsoftware.com/spine-unity-rendering#URP-Shaders-Extension-Package

GuapoMan

I appreciate the attention and care you guys (the staff) provide. It's truly awesome!

Harald When using URP with a 2D Renderer, you have to use different lights than with 3D renderers, see the Unity documentation. It seems that you are not yet familiar with the different render pipeline types, and what benefits each provides. It is highly recommended to get to know the Unity internals first before adding a layer of complexity on top by adding the spine-unity runtime to your project.

Yes, you're right. Since I have only worked with Unity 2017 and 2018 for seven years, those 2D light features are new to me.

I will give you a look at it; thanks!

Harald

GuapoMan Thanks for your kind words, glad it helped!

The different render pipelines and renderers can be confusing for sure. Just make sure to evaluate which is actually the best fit for your project, as even for a 2D project you might perhaps prefer URP with a 3D Renderer to URP with a 2D Renderer if e.g. you also have some 3D objects in your scenes or need shadow-casting and don't need the 2D lighting features. Especially casting shadows is something which can more easily (or at all) be done with the 3D renderers.