Aurigan

Screen Shot 2020-06-20 at 8.07.35 AM.png


So, completely new to using Spine and hoping someone can tell me if this setup makes sense ... I have this little guy, each of the 6 legs rotate as he walks, the antennae wiggle, the body squishes, the shadow scales smaller as he jumps up.

11 bones total, walk/attack/death animations have ~40 keys, ~12 timelines each. Does that all sound/look 'normal'?

Also - I'm using the SkeletonAnimation component, have 'Use Single Submesh' and 'Immutable Triangles' checked, tried enabling GPU instancing. Stress testing using this setup in Unity with ~1500 of these bugs running around the place it's incurring ~1.5x the frame time penalty vs. using the traditional Unity Animator.

Frankly, I was surprised it was that close but is this just an inevitable price to pay for the added benefits? Or, is there any way to make a simple Spine animation setup as fast as the Unity default without baking it?
You do not have the required permissions to view the files attached to this post.
Aurigan
  • Posts: 4

Harald

11 bones total, walk/attack/death animations have ~40 keys, ~12 timelines each. Does that all sound/look 'normal'?
That sounds reasonable, yes. The vertex count would be interesting (and whether everything is on a single atlas page texture), although I assume that it will be reasonable as well.
Aurigan wrote:[..] tried enabling GPU instancing.
GPU instancing will not provide you any benefits with Spine skeletons, as described here:
SortingGroup
[..]it's incurring ~1.5x the frame time penalty vs. using the traditional Unity Animator.
By "traditional Unity Animator", do you mean a non-Spine asset workflow without any Spine component, a baked Spine skeleton (baked via the Skeleton Baking Window in Unity), or a SkeletonMecanim component?
Or, is there any way to make a simple Spine animation setup as fast as the Unity default without baking it?
We have some performance improvements on the roadmap, unfortunately it will take some time until we will get to this ticket.

The above setup you have described looks quite optimal under the current conditions. Depending on the requirements of your project, you might want to be using Universal Render Pipeline (if you are not doing that already). Just mentioning since it's better to consider that at the start than migrating later.
User avatar
Harald

Harri
  • Posts: 2075

Aurigan

The vertex count would be interesting
Vertex count and transforms are 40, 20 triangles ... which I guess is expected with 10 attachments/sprites, everything is packed on one atlas.
By "traditional Unity Animator", do you mean a non-Spine asset workflow without any Spine component,
Yup, that.
The above setup you have described looks quite optimal under the current conditions.
This is good to confirm, thank you.
Depending on the requirements of your project, you might want to be using Universal Render Pipeline (if you are not doing that already).
Is there an assumed/expected performance benefit using URP? If so ... where's that coming from?
Aurigan
  • Posts: 4

Harald

Aurigan wrote:Is there an assumed/expected performance benefit using URP? If so ... where's that coming from?
Sorry for the vague sentence above.

It's nothing Spine-specific, and the Spine skeletons will most likely not benefit performance wise from URP shaders or URP-batching.
It's just that your non-Spine asset performance might benefit from URP. Also, the general 2D lighting pipeline seems more configurable, thus more easily adjustible for lower end devices. Nevertheless, some reports complain about bad performance on mid-tier mobile devices, so I guess (as always) it depends.

I would just recommend to do some real-life tests with placeholder assets early on to decide the target pipeline at the beginning, rather than having to migrate everything later.
User avatar
Harald

Harri
  • Posts: 2075


Return to Unity