2026-11-01 13:30 MST

Motion between the poses

Running NVIDIA's MotionBricks model inside Evil Engine, aimed at poses from the animation packs I own, on any GPU or the CPU. What works, what it costs, and what it isn't yet.

Right now every person in Evil Engine moves by playing clips. A clip plays the same way every time, so a walk, a stop or a vault always looks exactly like the last one.

Then NVIDIA dropped MotionBricks, a model from SIGGRAPH 2026 that does inbetweening, and honestly my first reaction was “Nvidia cooked once again”. You give it four poses of where a body has been and one to four poses of where it should end up, and it fills in everything between them, 0.6 to 1.9 seconds of motion at 30 frames a second, picking the length itself. It’s about 200M parameters, trained on 700 hours of ground motion, and it only knows its own skeleton, SOMA, which has 77 joints.

So I wanted to know two things: could poses from the animation packs I already own drive it, and could it run inside the engine on hardware that isn’t mine.

My packs on its skeleton

First I retargeted clips from Ultimate Traversal, one of my packs, onto SOMA. Read back through MotionBricks’ own loader, every limb, foot and clavicle bone points the same way as the original clip on every frame, to 0.00°.

Then I tried a chain: idle, run, lazy vault, run, idle, 13 m in all. The blue poses come from the pack, and every orange pose between them comes from the model, not a clip. Each generation’s last frame lands on its target to 0.0 cm.

Pack poses in blue at idle, run, lazy vault, run and idle, with the model’s generated poses in orange filling the 13 m between them

Getting it off TensorRT

NVIDIA’s demo runs the model through TensorRT, which only runs on NVIDIA cards. Evil Engine has to run on whatever GPU you’ve got, so that was out.

Their exporter rebuilds the model file they ship byte for byte from the released weights, so I started from that same graph and rewrote the operations that wouldn’t run on WebGPU until all of it did. It runs through Microsoft’s ONNX Runtime and its WebGPU plugin, which reaches Vulkan, Metal and D3D12, with the CPU as the fallback. I checked it against TensorRT’s output on the three backends I have:

The RTX 4070 Ti: 13.8 ms per generation
The Ryzen 9 7900X’s CPU: 23.6 ms
The Radeon integrated graphics on the same chip, through Mesa: 127 ms

Building the model files is one command, from NVIDIA’s weights at pinned versions, and it gives the same bytes every time.

Picking the targets

There’s no way I’m hand-picking target poses for every clip of every mounted game, so the targets get picked automatically. My rough idea was a triangle from the two hands to the hips, picking the frames where that triangle changes the most over a sliding window. It ended up as each frame scored by how fast the body’s shape is changing: that hands-to-hips triangle, another from the feet to the hips, plus the hips’ height and which way they face. The triangles are measured by their side lengths, so where the body is and which way it’s facing don’t count. A clip’s targets are its first frame, its last, and its highest-scoring frames in between, five at most. On a run that lands one target per step, and on a jump it finds the takeoff, the flight, the landing and the settled end.

The rough idea and what it became on the same 87-frame platform jump: the hands-and-hips triangle alone puts all four picks in the takeoff and nothing in the flight, landing or end, while both triangles plus the hips’ height and heading pick the start, takeoff, flight, landing and settled end

I tested it on two runs, one from Kubold’s Movement Animset Pro (walking, running through curves, stopping, crouch walking) and one from Ultimate Traversal (a vault, a fence jump, a stop). All 45 generations landed on their picked targets, and the picks did better than hand-picking one frame per clip on both foot slide and how smoothly the segments join.

Feet

The model’s raw output slides its feet. It does that on NVIDIA’s own sample clips too, a planted foot moving 16 to 22 cm a second where the clips move it less than half a centimetre.

It does predict when each heel and toe is on the ground though, so a contact step after it holds those feet in place and bends the leg to reach them. If holding a foot would drag the leg too far, it lets go and takes a small step instead, and any toe that ends up under the floor gets lifted back onto it. Planted feet went from sliding about 8 to 10 cm a second at the median to not sliding at all, and toes went from up to 10 cm under the floor to above it.

The left toe’s height and ground speed over both test runs, the model’s output in orange and after the contact step in black, with planted stretches shaded blue

In the engine

All of the above got proven in Python first, then ported to the engine’s C# and checked against it:

Turning poses into what the model reads, and what it makes back into poses, gives the same numbers as NVIDIA’s own runtime
The contact step matches the Python version to within 0.008 mm, at 16 to 23 µs a frame for one person
One person’s motion plans and plays frame for frame the same as the Python run
Everyone’s requests go to the model together on a background thread, and each person asks early enough that their next stretch of motion is ready before they need it
When it isn’t ready, or when someone drops out of the people allowed generated motion, they fade back to their ordinary clips over a third of a second instead of snapping

Turning it on runs a quick benchmark that picks the CPU or a GPU, whichever fits the most people while the GPU spends at most a tenth of its time on it. On my machine that’s 52 people on the 4070 Ti, 11 on the CPU and 1 on the integrated graphics. Your own player always gets it, then the people nearest you.

How it’ll work

It’s an experimental setting, off by default, and while it’s off none of it loads. It only changes what your own screen shows. Per client is really the ideal for something like this, I couldn’t imagine the netcode nightmare of having the server sync it… So nothing about it is sent over the network, two players can see the same person move differently, and the server’s hitboxes always come from the clips. The model files are about 770 MB, so they’ll be a free, optional download rather than part of the base install.

It only replaces what the model is good at: walking, running, stopping, turning, crouching and jumping. Ladders, swimming and anything a Plugin plays stay as clips, and so do fingers and faces, which the model doesn’t have.

What’s next

Nothing in the engine drives a body with it yet, so the images here are from the test runs, not the game. It still needs the clip layer, the movement controller and the retarget onto real characters, which are next. The goal after that is Kleiner walking, running, stopping and turning around gm_construct on generated motion, every segment landing on its target and his planted toes sliding no more than the clips’ own.