Why your 3D character looks wrong

First: what a 3D character actually is

Three separate things, and almost every “bad animation” problem is really one of them being blamed for another's mistake.

Try this mental test. If a character looks stiff, ask: is the pose boring, or is the skeleton unable to do the thing you want? We spent two entire passes writing better poses for a rig that physically could not twist. Adding more animation to a skeleton that cannot express it is wasted work.

Lesson 1 — a face is a drawing, not a lump

“The faces look like blobs.”

Our first faces were built the obvious way: a white ball for the eye, a dark ball for the pupil, a small box for the eyebrow, all stuck onto the head. It seems reasonable. It looks terrible, and for three separate reasons — which is why “make the eyeballs nicer” could never have worked.

1. Every ball has its own shadow. Our characters are lit in hard bands (the cartoon look). A ball stuck on a cheek gets its own band, so it reads as a lit sphere sitting on a face rather than as an eye.
2. Every ball gets its own outline. The black outline round our characters is made by drawing the model again, slightly bigger, inside-out. Do that to twelve little balls and the face becomes a cluster of outlined blobs.
3. Nothing can be thinner than a triangle. Eyelash lines, the crease of a lid, a highlight — all of those are thin. As geometry they cost real triangles, so they simply got left out. A face without them is a mask.

The fix is what Arc System Works do, and they say it plainly: shape the head first, then draw the face onto it as a texture. We put a small curved patch on the front of each head and paint it with ordinary 2D drawing commands when the game loads.

The rule. Detail that is marks on a surface belongs in a texture. Detail that changes the silhouette — a muzzle, an ear, a horn — belongs in the mesh. Ask which one you are making before you build it.

Lesson 2 — knees only bend one way

“The legs still look a little like <>.”

This one is lovely because the description is the diagnosis. < and > point opposite ways — the front knee was bending forwards and the back knee was bending backwards.

Why? A pose stores each bone as a direction. Someone had built the right leg by mirroring the left, and mirroring means flipping left-and-right — but they also flipped front-and-back. One axis too far. The thigh ended up pointing backwards and the shin forwards, which is a knee bending the wrong way. It was in 66 different poses.

The interesting part is where we fixed it. Not in the 66 poses. Sixty-six hand-edited numbers is not a fix, it is sixty-six chances to get it wrong again — and it does nothing for the sixty-seventh pose someone writes next month. “A knee bends forwards” is a fact about legs, not a style choice, so it belongs in the code that drives the skeleton. Now every pose gets it for free, including ones that do not exist yet.

The rule. When lots of hand-made records break the same rule, fix the rule in code — not the records.

And the trap we fell into fixing it. Our first attempt used a stored “which way is this character facing” value that was set once when the character was created and never updated. So it corrected the knee the wrong way for whichever fighter was facing left. We only caught it because the test checks both facings. If you test one direction, a direction bug passes every time.

Lesson 3 — why feet skate

A walk cycle is a short loop of poses. The obvious way to play it is by time: advance the loop a bit every frame. Do that and the character glides, because the loop has no idea how fast the body is actually moving. Slow them down and the legs keep pedalling at the same speed.

Play it by distance travelled instead — advance the loop in proportion to how far the character actually moved — and the feet plant. Nothing else changes. It is a one-line difference and it is the single biggest improvement we made to walking.

The rule. Drive a cycle by the thing it is supposed to represent. A walk represents ground covered, so phase it on ground covered.

Lesson 4 — everything must not happen at once

Our punches were stiff and we assumed we needed more keyframes. We did not. The problem was that every joint arrived at the same instant, which nothing alive does.

Art Babbitt, a Disney animator, called it successive breaking of joints: in any action the hips lead, the chest follows a beat later, then the shoulder, the elbow, the hand. On the way back the head moves last, because it is heavy. We implemented it as one subtraction — each bone reads the same animation a few frames in the past.

But not on the hit. Our first version delayed everything by a fixed amount, which meant that on a fast punch the fist was still winding up when the damage happened — you pressed the button and saw nothing. In a fighting game the contact pose is what sells the hit, so the lag now ramps to zero at the moment of impact and returns on the follow-through. Style must not eat the thing the player is actually reading.

Lesson 5 — the pile of limbs

“After repeated attacks it collapses into a mangled pile of limbs.”

This one took three attempts, and each wrong answer is worth more than the right one.

Attempt 1 — the fall was applied twice

Our knocked-down bodies are simulated with a simple physics model. It aimed every bone at a true direction in the world — the body was already lying down — and then also asked the character to lean over by 81°. The code obediently leaned it a second time, folding the ribs back over the hips.

The rule. If something already describes the final result, do not also ask for the movement that got it there.

Attempt 2 — nothing knew what a knee was

The physics held the body together with distance rules: the shin stays this far from the thigh. Nothing in a distance rule stops a joint folding completely flat. Measured on a settled body: the neck at 171° — the head folded down into the chest — and a knee at 168°, the shin doubled back through the thigh.

The fix is a classic: to limit the angle at a joint, limit the distance between its grandparent and its child. Constrain hip-to-foot and you have constrained the knee.

Attempt 3 — it was not the physics at all

The owner sent another screenshot, on a different character. This time the cause was the code that stops feet sinking through the floor. It lifts the whole body up by however much it needs — but it was measuring the body's position through a stale copy that already included last frame's lift.

That makes it a feedback loop, and feedback loops have a personality:

Our code used a strength that scaled with frame time, and it reached exactly 1.0 whenever the game dropped below 20 frames per second. At 60fps everything looked fine. On a slower phone, the entire body flipped between 1.56 m and 0.14 m above the floor every single frame, with the feet pinned in place — so the legs stretched a metre and back, forever. That is the pile.

The rule. Any code that measures something and then changes it must measure the current value. And the frame rate is part of the test — this bug is perfectly stable at 60fps and never stops below 20.

Lesson 6 — how to know you actually fixed it

Every bug on this page was found by a person looking at a screen, not by a test. So we wrote tests. Then the tests started lying to us, which taught us more than the bugs did.

And the one that keeps catching us: a test that measures a deadline passes things that only just scrape in. We required a hand-over to happen “within the knockdown”, and a broken version squeaked in one frame before the end — technically correct, invisible on screen. The bar has to be the budget: the deadline minus the time the thing actually needs.