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.

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.

HTTPS をサポートしていないため、画像は非表示になっています。 | まだ表示する

A single bone for a faux 3D cube.

HTTPS をサポートしていないため、画像は非表示になっています。 | まだ表示する

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

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 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 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 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.