AGENTSOLVER · THE TOOLS · PART 2 OF 4

Nobody should
have to
read my C++.

A solver nobody can configure is just an expensive crash. These are the tools that sit between the maths and a human: painting muscles onto a rig, watching a creature learn, launching training without babysitting it, and getting the result back into the viewport in one click.

WHERE Unreal Editor
BUILT FOR Humans (mostly me)
GOAL No config files by hand
// 01 · painting muscles

Turning a skeletal mesh into a physical creature.

A skeletal mesh knows where its bones are. It has no idea what any of them weigh, or how hard they can pull. My solver needs both, so I built an editor workflow for painting mass and muscle onto the rig.

The bit I care about: muscles use authored extension/flexion strength curves, not one constant torque value. Real muscle is weakest at the ends of its range — try holding a dumbbell with your arm fully straight versus at 90°. A single torque number throws that away and gives you a creature with the same strength in every pose, which looks exactly as wrong as it sounds.

MUSCLE / MASS AUTHORING TOOL
// 02 · watching it learn

Debugging from raw numbers is a nightmare.

So I built an easier way to see everything, in-engine curves for the different rewards and general data. I also added support for TensorBoard for more in-depth case studies and, last but not least, a window that shows every muscle activation in real time for the currently displayed run.

Of course to make everything fit in one video it's a bit messy here, but having two screens makes it way easier to analyse. You can see the TensorBoard in the bottom left corner, the activated muscles in the top left corner and the general tool inside of Unreal on your right.

TRAINING / SIMULATION TOOL
// 03 · the training panel

A remote control, not a trainer.

Training runs entirely outside the editor. The editor panel is a remote control: it launches the headless run, tails its log, draws the training curves, and can stop it. Close the editor and training carries on. The panel even writes out a .bat that reproduces the identical run with no editor involved.

THE EDITOR IS A REMOTE CONTROL, NOT THE TRAINER

Each run pins its own config to disk, and two hashes stop me lying to myself: one covers the observation layout and the rig, the other the full physics and reward setup. A checkpoint that doesn't match refuses to resume. I added those after losing time to a run that was quietly training against settings I'd since changed.

// 04 · play run

From a finished run to the viewport.

Any finished run can come straight back into the engine: pick it in the panel, hit Play Run, and it exports and plays in the viewport — MLP or Mamba, running in C++. The MLP path has a test asserting C++ and PyTorch agree to 1e-4. The Mamba executor is brand new; an offline replay of a real export matched PyTorch to 1.2e-7, and the in-engine version still has to prove the same. Otherwise I'd be watching a subtly different creature from the one that trained, and never know it.

TRAINED IN PYTORCH · PLAYED BACK IN C++

// next

That's the surface. Now the maths.

Every button on this page ends up calling a solver I wrote from scratch. If you want to know how that part actually works, it's all under the hood.

Next: under the hood →