Game Engine: How I Implemented Skeletal Animation

I found the source of the Cal3d library quite readable, taught me a lot about basic blending and sparse key frames back in the day

Motion matching isn't really ML by the way, it just does simple pose searching from a motion database every frame with a heuristically designed cost function. And the problem is that it requires a good amount of raw motion capture data beforehand to exceed the quality of traditional hand-made state machines, and as a result is mostly viable for huge game companies with dedicated motion capture studios and professional actors. (For most indies, even just renting out a motion capture studio for their game is out of the picture.) In order to really get the benefits of it, you'll have to plan out something called a "dance card" for your actors (https://www.youtube.com/watch?v=_Bd2T7uP9VA), which are a sequence of actions designed to sufficiently capture enough range of the motions that the character can take. And you also need some manual labeling/tagging of those motions afterhand in order to really get good transitions. The resulting animations can be incredibly good (such as the one we see in games like For Honor and The Last of Us 2), but for most indies and small gamedev studios this isn't really economically viable, and a state machine will probably get you far enough.

And learned motion matching is when you simply approximate a motion matching controller using a neural network to save memory and computation time (if you've read the paper). But it requires you to already have a well-made motion matching controller beforehand, so I don't know if it's a technology that can be applied to the majority of gamedevs.

> If you have an animation of walking and one for drinking, Motion Matching will not be able to produce a scene where the character is walking while drinking. Motion Matching will only play back the data you provide it.

ML in animation doesn't actually do anything useful according to friends in production at Ubisoft. As the paper says itself

> Naturally, searching a larger database means poorer runtime performance too. This is why we say Motion Matching scales poorly in terms of data.

It's a neat experiment but ATM AFAIK has not been used in a production title because of its limits.

Saw that approach in GTA 5. Once upon a time, a client wanted to collect non-trivial amount of data from the running game. That’s how I’m familiar with the way they render stuff.

I’m still only circling geometric algebra – could you give me some leads on GA not handling scaling? I’ve understood it such that it did, but I’d love to dig into it however it is :) Thanks!

Squash and stretch is not implemented with scaling. In fact, for any rational animation system (meaning one that a non-engineer digital artist can actually use) the use of scaling is simply not available in the system. Scaling in a hierarchical animation system is a guaranteed method to fuck up an untold large number of additional systems such as the physics/dynamics associated with the scaled character as well as any geometry attached to the character, as well as any sub-systems which use the now-scaled character for decision triggers. There are simply too many inter-dependent systems that rely on aspects of the environment, such as the scale of objects, to remain consistent for the entire illusion of a consistent world to be maintained.

Speaking from experience: I've written dozens of 3D animation systems for games and film VFX. I've been writing 3D animation systems since the 80's.