In my third year of university, I joined a 48-hour game jam with two classmates. We called ourselves "Team Bento" because we ate bento boxes for every meal during the jam and by hour 36 the name had stopped being funny and started being accurate. Our game was a dungeon crawler where you played as a goblin who could swallow enemies whole and grow larger with each one. The goblin needed to stretch. His stomach needed to swell. His jaw needed to unhinge like a snake. I was the only person on the team who knew how to use Blender, which meant I was the animator, the rigger, the technical artist, and the person who would be awake at 4 AM trying to fix a vertex that had decided to exist in two places at once.

I chose vertex animation because it seemed obvious. The goblin needed to deform in ways that bones could not handle. Skeletons do not have a "stomach swelling to twice its normal size" bone. Vertex animation stores every vertex position for every frame — you animate the goblin swelling, the engine replays the vertex positions, done. I spent twelve hours hand-animating a single swallow animation. Every vertex. Every frame. By hour twelve I could see the goblin's wireframe when I closed my eyes.

The Problem I Did Not See Coming

The swallow animation worked. It was beautiful. The goblin's jaw unhinged, his throat bulged, his stomach expanded to double size, and then — because this was a game jam and I was twenty years old and had seen exactly one GDC talk — I decided the goblin should also be able to walk while swallowing.

Skeletal animation can blend. Walk + swallow = a character who walks and swallows at the same time. The engine does it automatically by combining bone transforms. Vertex animation cannot blend. Every state the goblin could be in — walking, swallowing, walking while swallowing, running while swallowing, swallowing while jumping — required its own complete vertex animation file. I had twelve hours left in the jam. I had exactly one animation.

At the final presentation, the goblin could swallow enemies while standing perfectly still. If you tried to move while swallowing, the goblin snapped into a T-pose for one frame and then resumed swallowing. I described this as "a deliberate artistic choice representing the disorientation of consumption." The judges nodded politely. We did not place.

What Skeletal Animation Actually Feels Like

Two years later, I was working on a different project — a small indie game with a wolf protagonist — and I rigged the wolf with a full skeleton. Forty-two bones. Spine, neck, tail, four legs, jaw, ears. The ears had their own bones because I had learned, by then, that ears are important.

The first time I watched the wolf walk, turn its head, and flatten its ears simultaneously, I laughed out loud. Not because it was funny. Because it worked. Three animations — walk, look, ear-flatten — running at the same time, blending smoothly, no T-poses, no snapping, no "deliberate artistic choices." I had spent two weeks vertex-animating a goblin for a 48-hour jam and now I could make a wolf do three things at once by pressing play. I felt like an idiot. I felt like I had been given a cheat code and nobody had told me.

That is what skeletal animation is: a cheat code. It lets you animate once and combine forever. The tradeoff — and there is always a tradeoff — is that you cannot animate anything that does not have a bone. Liquids do not have bones. Explosions do not have bones. A goblin's stomach swelling does not have a bone, which is why I chose vertex animation in the first place, which is why I lost the game jam, which is also why I was right.

The Swarm of Bees

In 2024, I needed to render a swarm of bees. Two thousand bees. Each bee needed to fly along its own path, with its own wing flutter, and they all needed to exist on screen simultaneously without dropping below 60 frames per second.

I tried skeletal animation first — a single bee rig with wing bones, instanced two thousand times. The CPU melted. Two thousand skeletal meshes, each requiring per-frame bone transforms. The frame rate dropped to 11 FPS and my laptop fan sounded like a jet engine preparing for takeoff.

I switched to vertex animation. I baked the bee's wing flutter into a vertex animation texture — 128 frames of wing positions stored in a texture that the GPU could sample directly. The CPU saw two thousand static meshes. The GPU did all the work. Frame rate: 72 FPS. Laptop fan: silent. I sat there looking at two thousand bees flying smoothly across the screen and I thought about my goblin from six years earlier. The goblin was the wrong choice for the wrong project. The bees were the right choice for the right project. The difference was six years of making mistakes.

Vertex animation is a battering ram. It does one thing with tremendous force. Skeletal animation is a multitool. It does many things with moderate force. You cannot open a can with a battering ram and you cannot break down a door with a multitool. The trick is knowing which problem you have before you reach for the tool.

What the Tools Do Not Tell You

Here is something that no documentation mentions: the real cost of vertex animation is not memory. It is iteration speed.

When you skeletal-animate a character and the designer says "can you make him lean forward a little more when he runs?", you adjust one bone. Five seconds. When you vertex-animate a character and the designer says the same thing, you re-export every frame of the animation because every vertex position has changed. Fifteen minutes. Maybe an hour. The designer asks for three more iterations. You lose an afternoon. You start to resent the character. You start to resent the designer. You start to resent vertex animation, which has done nothing wrong except exist as the wrong tool for an iterative workflow.

I burned an entire Saturday once tweaking the timing of a vertex-animated door opening because the designer kept saying "a little faster — no, that's too fast — can we try something in between?" With skeletal animation, the door has one bone and you rotate it. With vertex animation, the door has four thousand vertices and you re-bake every single one of them for every single frame.

I no longer vertex-animate doors.

The Gord Mimic and the Thing I Still Cannot Do

There is a monster in the game Gord called the Mimic. It starts as a resource node — a lump of swamp material — and morphs into a combat form. It stretches. It flows. It changes shape in ways that a skeleton would find insulting. The developers used vertex animation textures for this. They had no choice. Skeletons cannot do that.

I know this because I tried. In 2022, I spent three weeks trying to rig a shapeshifting creature with a skeletal system. I added extra bones for stretching. I added helper bones for deformation. I added bones that controlled other bones that controlled vertices that were weighted to three different bone chains. The creature looked like a puppet being operated by a drunk octopus. It twitched. It folded in on itself. At one point its arm passed through its own torso and emerged from its back, which was technically the correct mathematical result of the bone transforms and also the worst thing I have ever seen in a game engine.

I scrapped the rig. I vertex-animated the creature in four days. It flowed like water. It was the first time in my career that I understood why both techniques exist: not because one is better than the other, but because they solve different problems that share zero overlap.

What I Actually Do Now

Today, when I start a new character, I ask myself three questions before I open Blender:

Does this character need to do more than three things at the same time? If yes, skeletal.

Does this character need to change shape in a way that no bone could describe? If yes, vertex.

How many times is the designer going to ask me to tweak this? If more than twice, skeletal. Always skeletal.

The third question is the one I learned the hard way. It is not a technical question. It is a survival question. Vertex animation is a commitment. You commit to a motion and you live with it. Skeletal animation is a conversation. You adjust, the designer adjusts, the character adjusts, and nobody loses an afternoon re-baking forty-seven frames of a door opening.

For crowds, I use vertex animation textures baked from skeletal rigs — the AnimToTexture workflow. Animate once with bones, bake to a texture, instance ten thousand times on the GPU. Best of both. The only thing I lost was my goblin game jam, which is a fair trade.

The goblin still exists on an old hard drive somewhere. I opened the project file last year, just to see. The swallow animation still works. The goblin still snaps into a T-pose if you try to move while swallowing. The judges were right not to believe my "deliberate artistic choice" explanation. But I was also right, in a way I could not explain at twenty years old. Vertex animation was the right technique for a stretching, swelling, jaw-unhinging goblin. The mistake was not the technique. The mistake was trying to make that goblin the main character of a game instead of the one monster in a dungeon that swallows you whole.