Esoteric Software

[Nate]

Prior to Spine 3.5, applying animations at runtime generally required a lot of extra keys to be set at the start of every animation. Now that the new AnimationState in 3.5 solves this problem, we have added a new feature to clean up your animations. Starting in 3.5.38, there is a Clean Up button when selecting an animation in the tree:


Clicking the button deletes unnecessary keys, ie keys that do not affect how the animation looks. Fewer keys means less data, which is always good, but it can also mean fewer timelines which translates to using less CPU to apply the animation at runtime.

Here's the raptor walk animation before:


And after:



You can select multiple animations and then click Clean Up to do them all at once. It's easy for a skeleton with a few animations to have thousands of unnecessary keys and hundreds of unnecessary timelines! Here's 22 animations from the 2D Anim Heroes project:


During normal designing of your animations, it's common to end up with some extra keys. Trying to be efficient with your keys in the beginning of a new animation can be painful, so now you can key liberally and use Clean Up later.

There may be some rare times you don't want to use Clean Up, such as when not using AnimationState at runtime or maybe if you programmatically find some key and change its value. For most people though, Clean Up should be used.

---

Please note: While we have tested it extensively, this is a new feature that deletes keys in your animations. Make a backup before giving it a try, and verify after Clean Up that your animations still work correctly both in Spine and your applications.

[Erikari]

Very interesting and useful feature! I remember you were adding the possibility to delete unnecessary vertices in meshes but this is useful on a whole new level!

[Pharan]

Note the benefits:
1. A cleaner dopesheet so you understand what's actually changing.
2. Fewer stuff for the runtime to crunch, so it costs less performance to have more and more of your characters/skeletons at any time.

When not to use it:
1. If you have a multi-track animation setup, and you specifically keyed certain bones to override the movement of bones, and parts of the override pose happen to be setup pose.
2. If you added timelines with only setup-pose keys for any deliberate reason.
3. If you added more than 2 keys repeating the same value/pose for any deliberate reason.

[Nate]

Very good point Pharan about animations intended to be applied on AnimationState tracks > 0. We'll be sure to include that in the docs.

[Majicpanda]

This is fantastic.. we never used SetUpToPose and thus keyed a lot of extra bs. Will abuse this and let you know the results once it's out.

---

Working good so far.

1045 keys cleaned up in our main character, lol.

If you build things around known problems "safely".. they will fix it

3. If you added more than 2 keys repeating the same value/pose for any deliberate reason.

So if we fluffed the end of an animation by copying all the frames at say.. 20 and copied them to 25, this would "clean" them off? That could pose some issues for sure if so.. didn't spot it right away but we hold positions sometimes with this "trick."

[Crocodilum]

Sounds very promising

[Pharan]

@Majicpanda.
No, it doesn't remove ending keys.
It doesn't remove holds. It does remove keys between two similar keys though. But just two similar keys together won't trigger it.

[Nate]

Actually, it would remove a hold key at the end of an animation, which could reduce the animation duration. In 3.5.41 we've updated Clean Up to leave one otherwise unnecessary key if needed so the animation duration doesn't change.

[BinaryCats]

a new record?

main character


It breaks any animations which turn something off at the end of the animation, but other than that. e.g. the sword attachment being left visible when dropped or thrown(keyed off)

maybe this has changed in a new-er version of the runtime. maybe it is a bug, our version of the runtimes are a bit up in the air at the moment and I don't have an opportunity to look into this/put keys back in. Ill revert for now, but wow now I don't need to take out 25k keys out by hand

[badlogic]

You win a broken animation!

[BinaryCats]

I was editing the post as you wrote that , and its not actually that bad except from attachments

---

main enemy:

[Nate]

Damn, 24k keys is a lot!

It breaks any animations which turn something off at the end of the animation, but other than that. e.g. the sword attachment being left visible when dropped or thrown(keyed off)

What Spine version does this happen? Can you show a .spine file that has keys which are deleted by Clean Up which you don't think should be deleted?

[BinaryCats]

3.5.38

investigating further, it seemed like we relied on the next animation keying things off.

i.e. We would play and animation which key'ed the visibility of the sword attachment on (Attack_throwSword at the start) but then would key it off in the Idle animation (the next animation to play, which Attack_throwSword would return to). But the clean up, I assume, would delete because the sword_attachment is off in setup pose the key is redundant.

---

and we use a lot of one frame, animations which key attachment(s) on and off

[Nate]

3.5.41 has Clean Up improvements, so I suggest using that.

Clean Up assumes AnimationState is being used without any customization, which is how it can make assumptions about what keys are unnecessary. If you're doing something else, you may need to write a tool to do clean up on JSON data specific to your needs.

[BinaryCats]

I think it would be easier just to re-add the keys that go wrong great tool

---

v3.5.41

---

Performance gain
(unity)

Idle cleanup removes 222 keys.

Single spine object, playing one idle looping animation:

Idle animation Without cleanup:
SkeletonAnimation.update: ~7% to ~9% of frametime


Idle animation With cleanup:
SkeletonAnimation.update: ~6.3% to ~7.5% of frametime

[Nate]

Sweet! The biggest gains come from removing unnecessary deform keys, especially when the entire deform timeline can be deleted.

[BinaryCats]

hmm, we don't really mesh deform on the player character. let me try with a enemy

---

One character:

Idle animation (82 keys removed) arms and legs are mesh deformed.

Without cleanup ~8%-~10%

with: ~7%-8%

much less keys removed here, but still gains are made.

[Abelius]

Hi there,

I'm using 3.6.09-beta, and when I click "Clean Up" all my attachment off keys get erased... Is this intended behavior? Because I don't feel that's useful at all.

I'm using those keys at frame 0 to tell Spine which attachments should be off in a specific animation, no matter what the setup pose says...

Thank you.

---

Hate to auto-bump but...

Bump?

[badlogic]

Can you send us your project file? contact@esotericsoftware.com.

[Abelius]

Sorry I didn't replied before.

Mmm... I don't understand why you'd need the project file (?).

My question was more about if what I've described is intended behavior on Spine editor's part or not.

Sooo... is it, by chance, implied by your request that 'attach off' keys at frame 0 should not be cleared, so something must be bad in my project? (therefore your need to see it?)

Thank you!

[Nate]

We can't tell if the keys are being deleted for a good reason without seeing your project. Attachment (and other instant keys, like draw order) are deleted at the beginning on an animation if they are the same as the setup pose. Also, keys that are the same as the previous keys are deleted.

[Abelius]

...are deleted at the beginning on an animation if they are the same as the setup pose.

This!

My setup pose indeed has those attachments hidden by default. So it's intended behavior...

I was using those keys to make sure they were not active at animation start, because I've being observing that attachments that are not part of a skin or the setup pose tend to 'magically' disappear when I use SetupEmptyAll at runtime.

This opens up new questions, but as they're not related to the OP, I'll shut up here and make a new thread when I have some spare time and a clear head.

Thank you guys!

[Nate]

Great, I can always appreciate when there is no bug. Hopefully the behavior works for you. Assuming you are using AnimationState, when animations are no longer playing they should result the values they changed back to the setup pose, so you should not lose your setup pose attachments.

[Abelius]

Great, I can always appreciate when there is no bug. Hopefully the behavior works for you. Assuming you are using AnimationState, when animations are no longer playing they should result the values they changed back to the setup pose, so you should not lose your setup pose attachments.

Well, to be honest my problem is just the opposite...: my heroine loses her hard earned... erm... face "attachment" (lol) if I let the setup pose take over at some point in the animation flow.

But.. yeah, maybe not the place to discuss this.

---

Aaand... it seems that all the info I need about this problem of mine is in here: 3.5+ Attachments And Mixing

Mmm... ok.