Zero-CPU Crowd Animation: 1,000 Animals, One Draw Call, No Skeletons

We built a GPU-driven crowd animation platform into Tinqs Engine that doesn't use skeletons at all. It bakes every animation frame into a bone-matrix palette texture once, and the GPU drives every instance's playback from then on. 1,000 animals at 60 FPS on integrated graphics. Each plays its own clip at its own speed and phase. Zero per-frame CPU cost. This is how AAA engines do crowds — and now it runs in our Godot fork.

Why not skeletons?

The standard approach — one skeleton per character, one AnimationPlayer, one draw call — breaks at crowd scale. Computing global_pose for 1,000 skeletons at 60 bones each is 60,000 matrix multiplications per frame on the main thread. Each is its own draw call. Each AnimationPlayer ticks independently. No CPU can keep up.

Vertex animation textures (VAT) can solve this — bake every vertex position into a texture and sample it in the shader. But that stores vertices × frames, not bones × frames. A 2,500-vertex animal with 500 animation frames needs 14 MB of VAT data. For 30 animal types: 426 MB. That doesn't fit on a Steam Deck. And VAT can't blend frames for smooth playback, can't skin normals for correct lighting, and locks you into one animation per bake.

Our answer: bone-matrix palette. Bake every bone pose into a texture, keep the skinning in the shader. The GPU samples the bone matrices and skins the mesh itself — same 4-bone linear blend as a real skeleton, same correct normals and tangents. But the CPU never touches a bone.

How it works

At load time, we play every animation clip on a temporary skeleton and record the bone matrices for every frame into a single texture. A Goat with 9 clips at 30 fps produces 496 frames:

Texture: 212 × 496 pixels, RGBA32F
VRAM: 212 × 496 × 16 bytes = 1.6 MB

That's every frame of every clip — walk, run, idle, attack, death, eat, sleep — in 1.6 MB. Across 30 animal types: 48 MB total. Compare to VAT at 426 MB. Bone-matrix is 9× smaller because bones ≪ vertices.

After the bake, the skeleton is destroyed. It never runs again.

Each MultiMesh instance gets 4 numbers packed into INSTANCE_CUSTOM:

.x = which clip (start row in the palette)
.y = how many frames in this clip
.z = playback rate (baked-fps × ground speed — foot-sync)
.w = phase offset (golden-ratio spread — no two adjacent animals share the same frame)

The vertex shader computes each instance's current frame from TIME:

float fpos = mod(TIME * INSTANCE_CUSTOM.z + INSTANCE_CUSTOM.w * INSTANCE_CUSTOM.y,
                 INSTANCE_CUSTOM.y);
int f0 = int(fpos);
int f1 = int(mod(float(f0) + 1.0, INSTANCE_CUSTOM.y));
float fr = fpos - float(f0);

// Blend between two adjacent frames for smooth playback
int r0 = int(INSTANCE_CUSTOM.x + 0.5) + f0;
int r1 = int(INSTANCE_CUSTOM.x + 0.5) + f1;

// For each bone, reconstruct mat4 from 4 texels, blend, weight by skin influence
mat4 m0 = mat4(texelFetch(tex, ivec2(b*4+0, r0), 0), /* ... 3 more columns */);
mat4 m1 = mat4(texelFetch(tex, ivec2(b*4+1, r1), 0), /* ... */);
skin += (m0 * (1.0 - fr) + m1 * fr) * weight;

The blend between two adjacent frames means we can bake at a low fps and stay smooth — the shader interpolates. The golden-ratio phase spread means every animal in a herd reads a different frame. One draw call per animal type. Zero CPU. Per-instance clip, speed, and phase — all in the GPU.

The numbers

Measured on an M1 Pro MacBook Pro (integrated GPU), not a desktop gaming rig:

| Agent count | FPS |

|————|—–|

| 100 | 60 |

| 500 | 60 |

| 1,000 | 60 |

| 10,000 | 8 (with CPU-side culling, pre-optimization) |

VRAM: 1.6 MB per animal type. 30 types = 48 MB total. A Steam Deck with 1 GB shared memory fits the entire roster with room for colonists, terrain, vegetation, and UI.

Draw calls: One per animal type. 30 types = 30 draw calls for every animated animal on screen. Add colonists, same deal — one draw call per colonist look.

The engine change

The module lives in modules/agent_skinned/ inside Tinqs Engine — our fork of Godot 4.6. The core is two classes:

MultiSkinnedMeshInstance3D — the data plane. Holds the bone-matrix palette. API: set_max_bones(), set_max_instances(), set_instance_pose_bones(). At bake time, we fill one row per animation frame. At render time, it sits idle — the texture is static.

MultiSkinnedInstance3D — the renderer. A MultiMeshInstance3D subclass. Points its multimesh at the skinned mesh and its data_source_path at the data plane. refresh() uploads the bone texture into the shader's uniform once. The MultiMesh handles instance transforms. The shader handles the rest.

The shader uses INSTANCE_CUSTOM to pick the palette row — not INSTANCE_ID. This is the key: the texture's rows are baked animation frames, not per-instance slots. Many instances share the same rows (a synchronized airborne flock) or each pick their own (a varied herd). One abstraction, two behaviors.

The engine change is 40 lines of shader code in multi_skinned_instance_3d.cpp. Engine version: 4.6.5.

The production pipeline

In Ariki, AnimalHerdRenderer.cs groups sim ViewerState.animals by type, feeds world positions and yaw rotations to skinned_herd.gd — the reusable per-type herd backend. The herd bakes the palette once at setup, then set_positions() updates transforms each sim tick. set_clip_for_state() switches the active clip block in the custom data when the sim FSM changes state (idle → walk → flee → attack). set_speed_scale() adjusts the per-instance playback rate to match ground speed — feet stay planted.

Bird flocks use the same system. BirdFlock.cs runs boid flocking on top of skinned_herd, sharing the palette with synchronized phases (airborne flapping in unison is intentional). 25 bird species migrated from the Low Poly Bird Ultimate Pack, each a single draw call.

The sim owns all behavior — 30 data-driven animals with per-animal senses, diet, combat stats, and FSM states. The client just renders. The same system will drive thousands of colonists at launch.

Where we stand vs the industry

The bone-matrix palette technique is the same architecture used by Assassin's Creed Unity, Total War: Warhammer, and Hitman for their crowd systems. We're using the same core idea, in a Godot fork, with smaller VRAM (our low-poly animals keep textures tiny).

The platform supports three tiers by distance:

• Crowd tier (palette) — baked poses, GPU-driven, zero CPU. Thousands of agents.
• Hero tier (real rigs) — AnimationTree + SkeletonIK3D + PhysicalBone3D for the nearest few. Smooth gait blends, foot-lock, look-at, ragdoll.
• Impostor tier (2D billboards) — sprite atlas indexed by view-angle and animation-frame, driven by the same (clip, frame, speed, phase) packet. For very far agents.

The same abstraction — (clip, count, speed, phase) — drives every tier. One packet, three detail levels.

Get the build

Pre-built editor binaries with agent_skinned and the GPU-driven palette baked in:

| Platform | Binary |

|———-|——–|

| macOS ARM64 | tinqs.macos.editor.arm64.mono |

| Windows x64 | tinqs.windows.editor.x86_64.mono.exe |

All builds at tinqs/builds. Engine source at tinqs/engine (private).

The game's animal_perf_test.tscn spawns 10/100/1,000/10,000 animals and reports live FPS. The animal_viewer.tscn lets you inspect any animal type, toggle clips, and switch between single and herd mode.

---

Related: GPU-Skinned Herds — the original agent_skinned module design. Fork, Don't Build — why we modify existing platforms. Streaming a 12km Archipelago in Godot 4 — the terrain and vegetation layers.