zigzatom

I have been debugging a problem we are seeing with our spine implementation on unity(Unity 5.6.3 and a fairly recent spine version.

We have 2 sets of spine characters made by 2 different sources. One version does not have any problems. This version has a set of body parts and animations and the body parts just move around as normal

The second set has multiple facings for an iso character where there are say 8 copies of the head for each facing. This second one is the one which exhibits the problem. When the animation is changed it appears that a big rebuilding of the spine animation happens. I have placed one of the previously mentioned(working fine) spine animations in place of this one and the problem goes away.

Does anyone know what might have been done in the creation of these spines or something in code I can do to help with this problem? I have attached a screenshot of a profile capture of where the time is being spent.
The most suspicious thing is the aprox 600k function calls in TrackEntry.HasTimeline()

I also tracked 2 seconds in profiler attributed to the skeleton animation.awake for 2 guys(so 1 second each)

I have attached the spine files as well.
Attachments
chibi_ace.zip
(447.72 KiB) Downloaded 25 times
sping.jpg
zigzatom
Posts: 3

Pharan

It's normal to have a spike in the calls whenever your animations change. But the numbers involved are normally so small that it shouldn't cause any frame stutter.

170k calls to PropertyID property in a frame is not normal.
1000 calls to HasTimeline is sorta crazy too, I guess? It's more plausible but it does suggest you possibly have some crazy animation data.

So...

1. Make sure you are using the animation Clean up function. (Key Frames - Spine User Guide: Clean Up)
I don't think this fixes the problem but not addressing the number of timelines/keys you have does exacerbate the underlying problem if you really are pushing the limits. And it's just a good idea.

2. Things like 2D 8-direction characters are currently best animated using one skeleton per uniquely-looking facing, and you swap the Spine GameObjects out depending on the direction. It's a bit of extra code but it is more performant.

But if you had no choice but to do it all in one skeleton, your Setup Pose slots should be empty, so that you are never keying a lot of slots null unnecessarily.

3. Are you doing some sort of manual manipulation of the track timescales, or mix durations?
User avatar
Pharan

Pharan
Posts: 4444

zigzatom

No I am doing nothing with the spine api other then calling set animation. I will forward these thoughts onto our animator and see if he can split the bones into seperate animations per facing.
Thanks for your super fast response. I will let you know what happens and if you have any other ideas let us know as well.

(You can look at the attached spine files if that helps)
zigzatom
Posts: 3

Pharan

Ah, I thought that attachment was just an image. We'll take a look at it.

-- 05 Oct 2017 6:52 am --

Just based on the animation data on the json, it does look like you have a LOT of unnecessary keyed items.
I know this is can be a habit carried over from 3D animation software which may do some cleaning up on its own, as well as non-game workflows. But it does cause serious performance problems at runtime.

Also note to the animator:
CTRL + SHIFT +L is the shortcut for keying all currently-keyed values (while not adding unnecessary ones).
This is useful for when you need a part or your whole character to hold a pose.
User avatar
Pharan

Pharan
Posts: 4444

zigzatom

After making changes as mentioned the file size came way down and time to switch animations got much better. The load time is still a little high(but there are about 25 animations in there) so I am going to have them split them and then load on the fly only. It was taking about 80ms to load one or 3 frames.
zigzatom
Posts: 3


Return to Unity