Animation optimization - Keyframes or Duration?

TorQue[MoD]

Hey all,
So for game design, specifically, I've heard people say that the number of keyframes in an animation will affect performance but do they really mean the number of keyframes or do they mean the total number of frames in an animation; IE its duration? For example, would a 30 frame animation with a keyframe every frame be less performant than the same animation with only 6 keyframes?

Thanks!

RN

The more nodes that have to be animated the slower it will be, so simple skeletons will animate faster than more complex ones.

An educated guess, I believe having one keyframe on every frame --that is, baking the animation onto each frame of the sequence, and setting all tangent types to constant-- is slightly faster than having keyframes spread apart, as there'll be no interpolation involved.
The game engine samples the animation curves of each animated node, so when there's one keyframe on each frame of the sequence, it will directly use the values in the keyframes instead of having to interpolate between two neighboring keyframes and having to calculate ease in/out with the curve tangents. 

This will cost more memory though, because of all that extra information: having two keyframes that span 100 frames is more memory-efficient than having 100 keyframes of course. But if there's simulations involved (like hair dynamics during a non-interactive cinematic) then you have no choice but to bake that simulation into keyframes, unless you're having the simulations happen in real time.

I see no reason why the duration of sequences would impact performance. The cost is per-frame after all, the engine is thinking "how many nodes do I have to animate on this here frame?"

You should consult the documentation of your game engine. Unity's, for example: https://docs.unity3d.com/Manual/MecanimPeformanceandOptimization.html

TorQue[MoD]

Thanks for the reply...

Okay, so I see that it's not a simple 1 answer for every situation... So generally fewer keyframes would be less memory expensive but the total number of frames in a file, you don't think would affect performance. If for example, I have an animation that is 5000 frames long and only 1 keyframe every 5 frames, you don't think that would affect performance? I mean, I'm not sure how an engine handles animations, if the file size matters as it does for textures for example. I would assume it does make a difference but I'm not really sure.

It was more of a general question rather than engine specific one but checking the documentation is definitely a good idea

Obscura

I don't think you should do this by hand,especially not in 2020... Game engines can auto compress animations if it becomes a bottleneck. But honestly, haven't really seen many scenarios where the animation was too heavy and had to be optimized because of this. 

If you have a heavy skeletal mesh (say 500 bones), it doesn't matter how long/short or dense/sparse anim you put on it, it will be still heavy.

TorQue[MoD]

So the animation itself doesn't impact performance as much as the skeleton? I mean I know a complex skeleton isn't good, I just thought the animations themselves would also be something to consider.

Obscura

The animation is just a list of vectors. Imagine like three vectors (position and rotation and scale) per bone per key. Even if you write this into a text file, it won't be heavy, even if its long. Its really just a few mbs of memory or usually much less. The problem with skeletal meshes is that the bone update is processed on the cpu(as far as i know, and this is why vertex anim texture is like 100X cheaper than bones). So its the skeletal mesh itself that can cause the whole thing to be heavy. The more bones you have, the worse it is. 

Alembic files on the other hand, they can indeed use a lot of memory, but depending on the implementation, other than memory footprint, they can be cheaper than regular bone based animation. Vertex texture anim, same thing, its more memory but its way faster to spit out an update than with bones.

There are animation compression strategies, but these usually happens under the hood. Like rounding the animated bones to some lower precision(which does make it lighter), and not much to do with manually removing frames and such.

TorQue[MoD]

Obscura said:

The animation is just a list of vectors. Imagine like three vectors (position and rotation and scale) per bone per key. Even if you write this into a text file, it won't be heavy, even if its long. Its really just a few mbs of memory or usually much less. ...

Awesome! Thanks so much for the explanation. I wonder why some people talk about the keyframes being a factor in performance issues then? I swear one of the guys from Epic mentioned this during one of the UE4 dev blogs but maybe I misunderstood.
Either way, your explanation is just what I was hoping for

Obscura

So to be clear, a longer or more dense animation will use more memory, indeed. But since only bone transforms are stored, and not vertex positions for every frame (difference between alembic and skeletal anim), even a fairly long sequence with a lot of bones will end up using little amount of memory. The expensive part is to actually apply those transforms. And the mesh update that makes it expensive, and the number of bones directly affects this, and not the number of keys (because one frame of data will be applied at the time anyways). 

The memory part of this may have been an issue in the past, like 10-15 years ago, but nowadays, even regular users has a bunch of memory in their computers, so it couldn't be an issue anymore. The mesh itself will probably use more memory than its animations.Mobile devices are a somewhat different story, but they are also getting better.

TorQue[MoD]

Cool. I appreciate the clarification. Thanks so much!

RN

I believe having one keyframe on every frame --that is, baking the animation onto each frame of the sequence, and setting all tangent types to constant-- is slightly faster than having keyframes spread apart, as there'll be no interpolation involved.

Let me confirm that guess, the Unreal docs do mention that animation interpolation (how keyframes are interpolated) impacts performance:

From Engine -> Animation -> Optimization:

(...) we recommend moving toward ~15Hz and under Update Rates at appropriate distances for many characters, as well as disabling interpolation.

So in order to still get nuanced/subtle animation without using interpolation, you'll have to bake your animation to all frames and use constant interpolation (i.e. no interp at all).
You can then do a clean pass, removing any redundant keyframes (keyframes that make no change from the previous one).

PolyHertz

If you need more performance you should lower the bone count, and/or change the type of interpolation used (linear is always faster then any kind of smoothed interpolation, and I'd presume curves with adjustable tangents will be slower still in most engines). If you turn off interpolation entirely it's the same as using 'step mode' in a typical animation package, which looks terrible.

Generally the only time you'd optimize your animation by baking all the keys and turning off interpolation is when you know exactly which framerate your game will run at (game runs at 60 fps so bake 60 keyframes per second of animation), or maybe for objects that will only be seen from a great distance. But even then, it's something you'll probably want to avoid as it may cause issues if the game is ever ported to other more powerful hardware in the future where framerate locking is considered unacceptable (PC).