← Back to devlog

Art

The sword draw, in eight directions

Two weeks ago I wrote that the right answer was to split the jobs: 3D moves, 2D draws. I was wrong. The answer was to stop patching.

Leo drawing his sword, seen from all eight directions at once in a four-by-two grid
Leo drawing his sword, seen from all eight directions at once in a four-by-two grid

This is the hardest animation in the character, finished, in all eight directions:

Leo drawing his sword, seen from all eight directions at once

Fifty frames, two seconds, eight cameras. He pulls the sword, settles the shield and drops into guard. From the front:

Leo drawing from the front, animated: the blade leaves the scabbard, rises and comes down to guard as the shield settles

And from behind, which is where this gets hard: the sword comes out from behind the body, the shield crosses the torso, and nothing can be solved by “covering it up” because there is no face to look at.

Leo drawing seen from behind, animated

To get here I had to admit that what I wrote in the previous entry was wrong.

What I said two weeks ago

That the solution was to split the jobs: 3D supplies the movement and the finish is repainted in 2D, frame by frame. I laid it out in detail, with its reasons, and it looked solid.

It was not. That route fell revision after revision, always for the same thing: the drawing held in one frame and drifted in the next. A colour line splitting the tabard. The shield arm flickering. A pale gap beside the sleeve outline. Boots that recovered their finish and lost it two revisions later.

Every fix was a patch on a patch: freeze a piece, anchor a hand, lock the face, bring a scrap of the render across to cover a crossing. And every patch covered one problem and opened two.

The turn

Instead of painting better on top of the 3D, make the 3D good enough that nothing needs painting on top of it.

Everything is resolved inside Blender now: the pose, the grips, what covers what. The sword is bound to the fist, the shield to its hold, the scabbard to the belt. And the two inner shield straps, which had been trouble for months, stopped being a drawing and became actual geometry, anchored to the shield.

The rule went into writing, in these words, so it cannot creep back:

Occlusion comes from the geometry: do not add external heads, per-frame retouching, or patches of colour to hide crossings.

What comes out of the render is quantised to a shared palette, with no dithering, binary alpha and a pixel outline. Not a single frame is retouched by hand. And it holds up at full scale:

Close-up of the draw at native size: the pixel grid, the hair in strands, the shield rim and the blade leaving the scabbard

The casualty

Something had to be cut to get here, and it was the thing that had caused the most trouble: the model no longer has a scarf.

If you have followed these entries, the scarf is an old acquaintance. In June the first concept’s cape went because it was loose cloth next to the arms. In September a whole turnaround was rejected because the scarf tail took up 35 % of the figure. Only the tucked tip survived, and even that kept showing up in every defect list for four months.

It is gone now. And the character has lost nothing: he reads the same.

The numbers

The approved design is revision 227, from 6 October. Revisions have been numbered from the start, so the number says plenty on its own about what it cost.

Eight cameras — south, south-east, east, north-east, north, north-west, west, south-west — rendered on the GPU at 32 samples, on a 450 × 540 canvas, with a transparent background, at 24 frames per second. Each direction is exported as individual PNGs, APNG and GIF, and all eight get reviewed: grips, occlusions, canvas bounds and continuity.

What is missing

The draw is approved; the rest of the animations are not. Next is walking with sword and shield equipped, and there is a walk test on a different rig that I have not signed off. A pipeline working for one action does not mean it works for all of them, and I am not assuming that again.

What I take from it

That I wrote a firm conclusion with two weeks of evidence behind it, and it was the wrong one.

Not because the reasoning was silly — splitting the work between what each tool does well is a reasonable idea — but because there was an option I was not looking at: that the problem should not be split, but removed. I spent weeks polishing how to cover the crossings instead of asking why there were crossings.

And one detail does not escape me: the previous entry closed by saying the tool cannot end up being the design. I was right in the headline and wrong in the diagnosis, which is the most uncomfortable way to be right.

← Back to devlog