We have a one pager here: Metrics view - Spine User Guide: Performance

We'll need more information about your skeletons. And did I understand right, you have one atlas per animation? You don't share an atlas across most of your skeletons? That will incure GPU side stalling, which is very bad for performance.

Alexees a écrit

P.S.: I was searching the esoteric page for something related to performance optimizations and could find nothing but forum threads. A one pager would be nice

The one-pager exists here, we even placed the Performance subsection in the FAQ section so that it's hopefully easier to find.
spine-unity Runtime Documentation: Performance

Hi, Just passing by.

I saw from the screenshot that most of the works done by MathUtils functions and wonder if lookup table is used to speed up things so I just took a inside that class and found that there is indeed code using LUT optimization. However, the flag USE_FAST_SIN_COS_ATAN2_APPROXIMATIONS is actually commented. May be enabling it would help? :think:

I wonder how this spine project with 12 UpdateWorldTranform() yield 5916 Bone.Update() calls.
Must have a lots of bones. :upsidedown:

Yes, all bones are updated because the skeleton doesn't know which bones are important to your animations, rendering, or other code that may use a bone for something. You could use skin bones to control which bones are updated

bones in a skin that is not active are not updated. If you have some other way of knowing which bones don't need to be updated, you could modify the runtime to skip those bones.

Here is the part of the runtime that controls which bones are updated:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.0/spine-libgdx/spine-libgdx/src/com/esotericsoftware/spine/Skeleton.java#L169
The skeleton creates a list called updateCache that is all the bones and constraints that need to be updated, sorted so parent bones are updated first, constraints are applied at the right time, and bones constraints affected are updated afterward.

The logic there for skin bones is a little tricky, but bone.data.skinRequired is true when the bone is in a skin. When sorted is true, the bone will be skipped

it won't be added to updateCache.

You can modify the bones a skin has to control which bones are updated, just be sure afterward that you call updateCache() on the skeleton to rebuild the list.

Please also note that you are using a clipping polygon with two triangles, which is expensive computation-wise. When using Unity you might instead want to use one of Unity's mask components (RectMask2D or SpriteMask). Apart from that it is often possible to use a single, very large clipping triangle instead of two to achieve the same effect. The size of the triangle does not matter computation wise, just the number of clipping triangles.

Oh good point Harald! Clipping is very CPU heavy, try avoiding it completely. If you must use it, use a 3 vertex triangle for the clipping polygon and clip as few vertices as possible.

Glad to hear, thanks for getting back to us! 8)