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.

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.

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

Pharan wrote: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."

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.

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

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

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.

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.

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.

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.

Nate wrote: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.