#animation rigging

[ramdroidrigs]

I've been really trying to up my eye expressiveness with my recent rigs ^-^) It helps to allow the eyebrow tracking to affect the eye shapes!

[askagamedev]

Are there any differences between an A-pose and a T-pose, or is it really just a modeler's personal preference?

It's more of a rigger/animator preference than modeler. The two poses have some tradeoffs to each other. The A pose is about making the characters bend and deform as naturally as possible. It reduces UV stretching around the high deformation stress points because the model’s arms are much closer to their resting position and don’t have to rotate as far. A poses have angled arms and often slightly bend the elbow as well, which means that the arm bones are a little more difficult to rig.

T poses require additional edge loops around the high deformation stress points like shoulders and hips in order to keep them from getting too ugly when those bones move too far. This is done to counteract the UV stretching mentioned above. The benefit of the T pose is that it’s much easier for the rigger to align the bones because the arms are in a straight line parallel to a major axis. Everything lines up much more easily and cleanly along the major axes without needing to do additional work.

Ultimately, the differences are small and up to the animation leadership’s preferences. Some prefer it one way, others prefer it the other, and a lot of times a project is just going with it because that’s how it was started and there’s been too much tech work done to switch to another and have to redo it all.

PS. These differences also apply to the rig’s default leg positions. Straight down? Angled? If angled, how big an angle? And so on...

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Can you explain the math behind IK?

Distilling a few semesters of upper division university math into a single blog post is kind of hard, but I’ll give it my best shot. IK is short for Inverse Kinematics, so we’ll start with that.

Kinematics is the branch of mechanics that describes motion without considering force. It describes what happens when you hold your wrist and fingers still and then move your elbow. Your wrists, forearm, and fingers all move without any application of force on them directly, because they’re inheriting the motion from your elbow. Your elbow moves and all of the parts of your body that are attached to it move with it.

Inverse Kinematics is starting from the extremities and then working our way backward. If our foot gets placed on a solid object (like a stair step), it cannot go any further. This places a constraint on the bones further up in the hierarchy - our ankle can’t move because our foot can’t move, our knee can’t move because our ankle can’t move, and our hip can’t move because our knee can’t move. Each of these joints has an maximum range of motion, so by enforcing these ranges of motion as we go up the hierarchy, we end up with a legitimate pose for the skeleton where the foot cannot penetrate the stair step.

The math comes in when we’re figuring out the position and orientation for each of our bones. Our foot bone has a set transformation because we know it can’t move any farther than where it collided with the stair step. The ankle bone exists somewhere relative to the foot bone and has built constraints for how far and what angles it can move (e.g. a normal ankle can’t bend more than maybe 150 degrees in any direction), so we can figure out where the ankle should be relative to the foot bone. From there, we continue to go up the chain to the knee bone which has a position relative to the ankle bone that will inherit the new ankle bone position and take the knee bone’s set of constraints into account (e.g. knees can’t bend more than 180 degrees). The knee bone is connected to the hip bone, the hip bone is connected to the base of the spine, and so on up until the bone you’re supposed to move doesn’t need to move because everything under it is within the hierarchy constraints.

The IK math comes in when using these constraints and expected transformations relative to the child bone’s transform to calculate the transforms for bones further up in the hierarchy, until the displacement transformation from the foot not being able to step through the stair step is distributed among the bones constraints. In principle, we’re distributing the spatial difference between where we want the foot bone to be and where the foot bone has to be across all of the bones above it in the hierarchy - the ankle, knee, hip, etc.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Hi gamedev! In reference of your IK explanation. Is that why we see those flailing arms/legs bugs? E.g. A leg is positioned in an invalid angle but cannot find any valid one (maybe it is positioned in a way that would break the leg in the real world) so it tries a bunch of random transformations?

That’s not usually because of IK. What you’re looking at is what’s known as ragdoll. Ragdoll is when we apply physics forces (like gravity) to bones in the animation rig (skeleton) and let the physics simulation take its course. Typically the rig’s bones are still constrained the same way as before - you rarely see bones bending the wrong way, but they often fall into positions that ends up looking unnatural when the skeleton is taken as a whole. This is usually a combination of things like rig bone constraints being much more simplistic than the actual bones and joints that we’ve all spent all of our lives becoming familiar with.

Here’s an example - the W-sit position (above) can be fairly uncomfortable for a lot of adults. This is primarily because of the way that our knees and hips are constrained by the muscles, tendons, and other physical bits. Our adult legs just don’t like bending this way as we get older. If our legs are folded and pointed in the same direction, we have fewer problems when sitting with our legs and feet pointing in the same direction:

This is generally a much more comfortable position for most people than the W-sit position. But it isn’t comfortable for everyone, and not everyone is as flexible with their hips and their knees. 

By contrast, In most animation rigs we don’t model the same subtle physical constraints on our hips or knees because we don’t need to. The hip bones in animation rigs tend to be ball-and-socket joints that are completely independent of each other. There aren’t any tendons or muscles or fat deposits to collide with in game animations. A character standing straight up on one leg while the other leg is in half of a W-sit position is a totally legitimate pose because the legs are usually independent of each other. It would look absolutely ridiculous, but it would be a legitimate pose within the rig’s constraints.

Normally, we use hand-authored or motion captured animations so the animators naturally avoid any weird movements or poses in order to make the motion believable. However, when we let gravity and physics take over, this can move the limbs into unnatural-looking combinations of positions, because these are the resulting positions that only take the rig’s simplified constraints into consideration.

Take a look at this memed example of ragdoll in action:

None of the character’s individual bones are actually moving in a way that breaks them. It’s more of a contextual thing - a human being with human muscles, bones, and tendons would not move this way, and we’re totally expecting him to behave like a human because he looks like one. But his shoulder doesn’t actually dislocate. His elbow doesn’t bend the wrong way. It’s just the aggregation of every little thing working together that makes it look weird. That’s probably what you’re remembering when you think about flailing limbs.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Animation Primer (Part 3): It’s Automagic!

[When last we left off], I had given a quick explanation of how the move to 3D animation allowed animators the ability to create a motion and then view it from many different angles thanks to the combined power of math and the CPU. This would work just fine for things like television and film, because the media always play the exact same way each time viewed. There are, however, other issues that come up when we have to animate things in real time, such as in video games. Here’s what I mean.

Observe Ryu throwing a hadouken from SF3: Third Strike. It isn’t just his arms and legs moving, but also his clothing, belt, and headband. These were all hand-drawn animations that took all of that motion into account, and the entire animation is one single piece. Early on, 3D animators would do the same thing - animate all of the secondary motions the same way each time. However, as the movements become more complex, this became less and less feasible.

In Legend of Zelda: Breath of the Wild, Link can perform many actions while running. He can draw his melee weapon or bow, he can attack, he can aim his bow, he can transition to many other motion states, and he can turn. If he turns a little, he’ll look in the direction he’s turning. His hair will bob and move slightly with the motion he’s performing. Sometimes he will cry out as he attacks or takes damage. When this occurs, his mouth will open and his expression might change. If animators had to animate each one of these states as a separate motion, it would take decades to complete them all. There are just far too many permutations - running + looking left + drawing bow, walking + looking left + drawing bow, standing + looking left + drawing bow... A lot of this is mostly-redundant motion, and that’s a lot of system resources needed to load all those different animations. It just isn’t feasible to animate in real time this way.

This is where the software engineers come in. Rather than keep the movement as one contiguous whole, they can break it up into pieces that are controlled by some sort of internal (automated) logic. Instead of having an animator move every bone in the rig, one animator can work exclusively on facial animations - expressions, lip sync, looking at stuff, etc. while another animator works on lower-body walking and running animations, while a third animator works on upper body animations like drawing a weapon or aiming. Then, through the magic of an internally-enforced set of logic, the game can automatically choose the correct animation pieces to play together, resulting in a cohesive-looking whole made up of many parts put together. 

This entire hierarchy of separately-created motions is usually called an animation layering system. The logic that governs this usually sets priorities for each and is usually the product of collaboration between the animation leads and animation programmer leads. It’s because of layering systems like this that allow for Nathan Drake to talk, wince from damage, and run to the left while reloading the rifle he is carrying at the same time. At any given time in gameplay, Drake can be playing anywhere from one to dozens of different full or partial animations at the same time depending on a multitude of factors.

As you may have guessed, animating is a huge amount of work. There’s so much work that goes into building all of these that some of the biggest advances in animation have come because we are trying to offload the work from the humans to the machines. By having the CPU animate the busy stuff for us, we can task the humans with higher priority stuff to make it look better. This extends to animating things like clothing, dangly bits, foot placement, and so on. The three main elements of procedural (auto-generated) animation I’ll talk about are Inverse Kinematics, Animation Blending, and Physics simulation.

You may have heard the term “IK” or “Inverse Kinematics” before and wondered what it was. The term “kinematics” means the behavior of objects without reference to the forces that act on them. Inverse kinematics means the opposite of that - describing the behavior of an object in terms of the force acting on it. This means that outside force acting on a bone will translate up the hierarchy, allowing for “automatic” placement of the feet and legs when standing on slopes or uneven ground. Remember, 3D models don’t have any automatic sense of collision with the environment unless we tell them to, and IK is one of the more common ways of telling them that they have touched something solid. Using IK to govern things like foot placement allows the riggers to control the way the legs and feet (and to a lesser extent, other parts of the body like hands and knees) behave when touching “solid” objects in the world. So, as an example, the walking animation tries to place the foot somewhere in the world, but the world geometry says “You can’t bypass me, this is as low as you go”, so the downward motion stops and the rig figures out how to handle the placement of the legs from there.

Another common means of procedural animation is animation blending. While animators can author very specific timing curves for the movement of the bones, sometimes you don’t need such tight controls of something. In those situations, you can have the computer come up with something “good enough” in between over time, generating a motion curve for a set of bones that starts at one position and ends at another. This is often used for transition animations from one state to another, as well as an optimization trick for objects further away from the camera. That way, instead of having to load and play all of the data from a high-fidelity animation, the system can load the key frames only and just figure out how to get from point A to point B on its own. It doesn’t look as good as it would up close, but it doesn’t have to - it’s far away and hard to notice.

Finally, the third major use of procedural animation comes from physics simulation. When game physics get mentioned, most gamers think of how forces like explosions or gravity act on objects, causing them to fall, fly, or bounce in a more-or-less realistic manner. However, the physics simulation can also be applied to held, worn, and dangling objects as well. The physics system can animate clothing, hair, equipment, anything that isn’t rigidly attached to the body. This is done via the rig - specific bones are given physics data - weight, mass, material, etc. and then the movement of those bones is calculated by the physics engine during runtime. This means that they will automatically behave as if they are separate objects that are attached to whatever model. This means that artists can simply attach a new piece of equipment with little dangly bits, and as long as the rig has those dangly bones set up to use with the physics engine, they will be able to flop, bounce, and jiggle without an animator explicitly moving them. If you’re wondering what happens when you make all of the bones on a rig controlled by the physics simulation, that’s exactly what ragdoll is.

These are several ways that software engineering has helped to make animation work better, and these behaviors can all be flipped on or off like a switch at the animator or engineer’s discretion. The primary goal in animation programming is to harness the power of the CPU to do more of the busywork in order to keep the animators working on stuff that the CPU cannot do by itself, and to be able to dynamically craft believable additive motion that reads well in all sorts of situations. By harnessing the power of procedural animation generation and intelligently breaking down animation into smaller component parts that can be played in tandem, we can create a much larger variety of motion on the fly.

Previous Animation Primer entries:

[Part 1: Core Principles]

[Part 2: The Third Dimension]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[askagamedev]

Animation Primer (Part 2): The Third Dimension

[When last we left off], I went over twelve principles of animation put together by the Frank Thomas and Ollie Johnston gleaned over decades of working at Disney. These principles were developed as guidelines while drawing still frames on paper repeatedly, and they still apply. However, technology and understanding of the medium have continued to evolve. The field of animation has steadily moved into the third dimension and brought a whole new way of crafting movements with it.

Principles of 3D

When you’re dealing with 2D animation, any sense of angular change is an illusion. Artists use perspective, shading, foreshortening, and a host of other visual tricks to make you think that the drawn image has depth. Unfortunately, this sort of content creation is incredibly labor-intensive. Viewing angle and composition was set in stone quite early on for traditional 2D animation because any little change made to the character like a different costume or a change in viewing angle could necessitate huge amounts of content being redrawn. This is a major reason why palette swaps became the norm in sprite-based video games - it was an efficient way to reuse all of the sprite animations in new content. 

In the mid to late 1990s, engineering advanced to the point where programs could utilize mathematics and software engineering to represent three-dimensional space on computers. This was a huge leap forward in the potential for games and movies, because we could finally separate the viewer from the object being viewed. Because engineers could mathematically represent objects in three-dimensional space on the computer, it meant that we could move the viewport (i.e. what the camera sees) independently of the character or object being viewed and the computer could recalculate what that character or model would look like. That meant that we could create a single set of animation data (e.g. a punch), move the camera, and view that same animation data from multiple different angles without having to redraw every individual frame. This was a huge advancement over traditional 2D animation in terms of potential application, because animators no longer needed to redraw every frame for a new camera angle or costume change.

At its core, these sets of 3D animation data are a bunch of numbers. If an animator wants to make an object move, the computer must know which parts of the object are moving, where those parts are in space, and at what time they are there. Then, by placing the parts of the object in those positions at those times, the viewer’s brain would stitch them together to form movement. We’ll talk more about how this actually works in a different post, when I talk about the engineering aspect of animation.

Breaking Down Bones

In the early days of 3D, animators would move all the appropriate vertices (the corners of the polygons) themselves but this became unfeasible as the polycount of models continued to increase at a geometric rate. There were just too many vertices, and the entire model would need to incorporate animation principles like squash and stretch, secondary motion, etc. in order to look good. There needed to be some sort of simplification in order to reduce the amount of work; hand-animating vertices grew even more labor-intensive than drawing still frames.

The solution to this came from the invention of a skeletal animation system with a hierarchy. The idea here was that you’d have a simplified set of joints that can move in certain directions, and that the vertices on the model would each be mapped to a specific joint (or set of joints) to inherit motion from its parent. Thus, when arm joints moved, all of the vertices associated with the arm would move with them. Foot joints would inherit movement from knee joints, the knee would inherit from the hips, and so forth. These joints were named “bones” and the entire skeleton itself was called the “rig”. By moving the bones in the rig, the vertices of the model would follow the bones’ movements appropriately.

The invention of the rig system also brought some really useful other effects as well. Because the rig itself was just data, it was actually entirely possible to reuse the same rig with different models. After all, the collection of vertices just needed to be assigned to specific bones in the rig, and then any animation that played on the rig could be used to play on any model the rig worked with. This meant that things like costume changes were no longer a huge workload - you could have somebody build a very similar model but with a different skin, and then apply the same rig to it and it could make the exact same movements.

This also created a fundamental split in how animation work was divided. Some animators became experts in building the rig itself - they mastered how the vertices of the model would move relative to the bones in the rig, and continue to update and improve the rig in order to provide the animators the ability to create complicated motions without too much difficulty. These experts today are called “Riggers”, “Technical Animators”, or “Technical Directors (of animation)” because they are the experts when it comes to the rig. They are the ones who make sure that all of the appropriate vertices move to the motion when a finger, a toe, or even clothing moves, as well as applying the rigs to multiple models.

Other animators became experts in moving these bones around to create good-looking motion. These are the 3D animators you’re probably most familiar with. These artists work primarily with time and these bones, placing them where they want in time, and adjusting the bones’ movement curves. When it comes to movement, the human brain responds well to arcs and curves (principle #7), so there is always a lot of work done on adjusting movement as a factor of time in order to make it look and feel smoother. The animators usually work by going either from pose to pose or from shot to shot, in order to create a self-contained section of motion and movement that is pleasing and readable to the viewer.

Capturing Motion

Part of the problem with animating humans in particular is that there’s an awful lot of subtle secondary motions that come from all of the bones, muscles, and organs all moving in addition to the primary movements. When a human stands up, hamstrings and quadriceps contract and expand, arms move, legs move, fingers move, feet move, heads move, and everything in between. On top of this, humans are basically primed to see and expect all of these motions because we’ve been seeing other humans move for our entire lives. Hand-drawn 2D animation often took this into account by using a technique called Rotoscoping - filming a person moving, and then drawing the animated characters on top of the filmed movement in order to pick up all of those subtleties of movement. Don Bluth made heavy use of this technique for films like Anastasia and is often associated with it. 

Technology improved over time, however, and rotoscoping evolved into using motion capture. Sensors are placed on an actor’s body who performs the motions while computers record the sensors’ positions and orientations in three-dimensional space. That data is then processed and mapped by animators onto a rig so that it can be used in the final product. By capturing the motion of the actor, animators could capture all of the small secondary motions inherent in the primary movement. Conceptually motion capture bypasses the 12 principles of animation, because it isn’t trying to emulate actual motion and uses actual motion instead.

You might think that this process must seem pretty easy, but I cannot overstate this enough - the amount of work it takes to transform motion capture data into usable animation assets is by no means trivial. People don’t use motion capture because it saves time - it really doesn’t. What it does, however, is provide more natural-looking motion because the sensors can pick up all of the little secondary motions. It takes a lot of effort to clean up the motion captured data so that it is in a usable state. All of the movement from each sensor must be mapped to the movement of a bone in the rig, plus animations may need manipulating in order to make the motion actually fit within the space and dimensions needed in the final product. This requires a lot of fine detail work in order to ensure that things move properly and aren’t twisted in funny directions or pop from one position to another while things are in motion.

This is basically how 3D animators work today, both in film and games. Some are constructing and improving rigs, others use those rigs to create scenes and motion through good posing and visuals, and yet others work on cleaning motion captured data and converting it into something usable for the final product.

Part 1: [Animation Primer (Part 1): Core Principles]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent questions: The FAQ

[pocket-illust]

practice shot for my Diglett rig, as part of my anim 2 film project!

[lanaflowerz]

Punch animation test