Hacker News new | past | comments | ask | show | jobs | submit login
Game Engine: How I Implemented Skeletal Animation (vladh.net)
153 points by vladharbuz 7 days ago | hide | past | favorite | 28 comments

This is nice but ... the real "fun" of animation is handling all the variations of how to mix the data. It's easy to take a full set a bone animation data and apply it to matrices. The challenge, not sure challenge is the right word, maybe "the work" is in the all the tools and systems for using it. You can't just interpolate between frames, you need to be able to interpolate between multiple animations. You need some animations to apply to only parts of the skeleton (like allowing the character to run and shoot) which means you're some what back to sparser data ... though there are still ways to make it arrays.



In other words, getting a single animation to play will take a day. Getting an entire animation system ready for use in a modern 3d game can possibly take much much longer (exporters, animation editors, timelines, skeleton editors, state machine editors, etc... etc...)

But on the other hand, many games work just fine with simple linear interpolation and simple cross-blending between animations, and it's probably more important to compress and efficiently stream the animation data instead of working with a too granular set of small partial-animation snippets (for instance, not every game needs Assassin's-Creed-level dynamic climbing - but the "big engines" need to provide general solutions which enable this sort of thing).

You can also go down the rabbit hole of using ML in animation. It's really a gamechanger.

[0] https://montreal.ubisoft.com/en/introducing-learned-motion-m...

[1] https://cascadeur.com/help/autoposing

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.

Absolutely! If you have any more resources on this topic (e.g. interpolating between animations), I'd love to take a look at them.

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

You can use 4x3 bone matrices instead of 4x4, saves 25% of GPU bandwidth, also vertex shader will be slightly faster. They don't need projection component anyway.

This is a a great tip. I also saw someone on the Graphics Programming Discord doing this. Time to chuck out that last row!

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.

Nice, I was just reading how to solve the same problem using geometric algebra: https://www.jeremyong.com/klein/case_studies/ga_skeletal_ani...

unfortunately, IIUC, GA doesn't handle scaling. It's ironic the picture of a T-POSE in that article is a cartoon like character. Cartoon animation is full of "squash and stretch" which means lots of animation of scale.

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.

So have I. I can assure you there is scaling in every game and VFX I've worked on since the late 90s

You may have scaling in your tools, but under the hood the transformation pipeline treats the result as a translation. Scales cause physics and dynamics issues, which are linked to too many related systems. That's why tools that scale have a "bake" operation afterwards, that baking is transforming scales into translations so runtime and scene logic can use a uniform coordinate space.

Not my experience. Have shipped several AAA games with scaling, no baking.

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!

You should try triangulating geometric algebra too! ;)

:kiss: MWAH :heart:

You probably want projective geometric algebra.


Perfect! Thank you so much!

Although it says that it's solving the problem using geometric algebra, I really can't see how GA makes the problem easier (in terms of both conceptual simplicity or implementation). You can replace the term 'motor' in the article with 'dual quaternions' and the whole thing doesn't get any more simple or complex.

> With this in mind, I wrote a small function to traverse the hierarchical tree and convert it to this simple array. Then we yeet the hierarchical data out of existence.

This is the classic AoS vs SoA [1]? SoA can be composed arbitrarily and feels more natural to design. But SoA is usually optimal for the hardware.

[1] https://en.wikipedia.org/wiki/AoS_and_SoA

This is still AoS. SoA would be if the author had several arrays for each member/component of the original bones.

Very cool! What file format did you find easiest to work with? I've been doing some work on skeletal animations and the most common format I've come across is BVH [0], but that only captures animation and bone hierarchy.

[0] https://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Je...

I didn't know about BVH! Right now I'm using COLLADA (.dae). I'd like to decide on a single file format and write my own parser for it, but I feel like there must be a slightly less complex format than COLLADA that still does everything I need. I'll probably spend some time comparing it to e.g. FBX.

It's amazing how simple the skinning shader is.

i like how it's entirely possible to read and understand this without thinking of a quaternion as more than just a rotation.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact