ProtoMotions: one humanoid training codebase across five physics engines

The README calls it ProtoMotions 3, the repository does not

Small naming detail first, because it will trip up anyone searching. The repository is `NVlabs/ProtoMotions` and the GitHub description calls it ProtoMotions, a GPU-accelerated simulation and learning framework for training physically simulated digital humans and humanoid robots. The README's title is ProtoMotions 3, and the overview paragraph calls it ProtoMotions3. The same split shows up in the retargeting notes, which refer to v3 as a real boundary in the project's history.

There are no GitHub releases behind that version number, so v3 exists in the README's prose and in the code rather than as a tag you can check out. That matters more than it sounds for a framework of this kind, where a physics engine version or an observation signature will silently change behavior between commits. Pin a commit.

The two characterisations also differ in emphasis. The repository description leads with digital humans and humanoid robots, which is the broader of the two. The README leads with simulated humanoids and frames the mission as a fast prototyping platform for animation, robotics and reinforcement learning. The README also states the three values it optimizes for, modularity, extensibility and scalability, and describes the project as community-driven and permissively licensed under Apache-2.0, which the LICENSE.md file and the license badge both agree with.

Two different documentation URLs are in play, which is the kind of detail that only surfaces when you read carefully. The homepage field points at nvlabs.github.io, while the docs badge on the README points at protomotions.github.io. Both are live documentation, and the quick start, retargeting and deployment tutorials all live under the second one.

Five simulators, one of them badged untested

The badge row is the most information-dense part of the README, because each badge pins a version and one of them admits a limitation in its own label.

Newton is pinned to 1.0.0 on PyPI. IsaacLab is pinned to 3.0 and, unusually, to a specific commit hash rather than a release. IsaacGym is labelled Preview_4. MuJoCo requires 3.0 or newer. Genesis is labelled untested, in grey, and the rest of the project is at least as current. A project that badges one of its own backends as untested, in a badge, is being more careful than most, and it also tells you exactly where to look first if you were planning to use Genesis.

The repository backs that split up. There is a `Dockerfile.isaacgym` and a `Dockerfile.newton`, and separate requirements files for Genesis, IsaacGym and IsaacLab. Genesis has neither a Dockerfile nor a badge claiming support, which lines up with the untested label rather than contradicting it.

IsaacLab being pinned to a commit hash is the detail that tells you how seriously the project takes reproducibility. Isaac Gym is itself a preview build, and Preview 4 is what you get, so the badge set as a whole reads as an attempt to freeze a moving set of dependencies rather than track the latest of each.

The last badge is worth mentioning because of its label. DeepWiki is linked with the parenthetical unverified AI generation, so the project is explicit that its AI-generated repository documentation is not something it stands behind. Having a badge that labels itself unverified is unusual enough to be worth crediting.

The framework sits among peers that search results associate with it, including MaskedMimic, MimicKit and DeepMimic, and the README points at MimicKit as its own sibling repository for lightweight motion imitation learning.

Retargeting the whole of AMASS onto a robot in one command

The retargeting story is the piece most likely to be useful to you, because it is the step everything else depends on. ProtoMotions takes the public AMASS human animation dataset, more than 40 hours of it, and transfers the whole set to a target robot using a built-in optimizer based on PyRoki.

One note in the README explains a change you would otherwise trip over in older material: as of v3 the retargeting uses PyRoki, and earlier versions used Mink. If you are following a tutorial written against the older line, the optimizer named there will not be what the current code calls. The repository carries a `pyroki/` directory, which is consistent with the switch.

The payoff is stated as a single command-line argument. To train a different robot you change one flag and prepare retargeted motions:

--robot-name=smpl
--robot-name=h1_2

The claim attached to it is that a robot learns AMASS motor skills in 12 hours. Whatever you think of the framing, the useful part is that the humanoid swap is a configuration change rather than a rewrite, and the README links a retargeting tutorial that walks through preparing the motions for your own target.

The documentation for that workflow lives on the protomotions.github.io site rather than in the README, so the front page tells you the capability and the tutorial tells you the mechanics. The `legal/` directory in the tree is worth a glance if you plan to work with AMASS-derived data, since the dataset has its own licensing terms separate from this repository's Apache-2.0.

Sim2sim treated as a routine check rather than a research result

The most useful design decision in the framework is that changing physics engine is a flag. The README describes one-click sim2sim testing by switching the simulator argument:

--simulator=isaacgym
--simulator=newton
--simulator=mujoco

Train a policy in one engine, evaluate it in another, and if the behavior diverges you have found a policy that overfit to the simulator rather than the task. That is a cheap and genuinely informative test, and the reason it is cheap is that the observation pipeline is shared rather than reimplemented per engine.

The constraint the README attaches to its own demos is the important part. It states that the policies shown only use observations you could actually get from real hardware. That is a much stricter bar than most simulation results clear, and it is what makes the sim2real claim plausible rather than decorative, because an observation vector full of privileged simulator state cannot be reproduced on a robot no matter how good the policy is.

So the three pieces reinforce each other: shared observations, multiple engines, and a hardware-realisable observation set. If you are evaluating whether the framework's abstractions hold up, sim2sim is where you would find out, and the answer is one argument away rather than a research project.

Sim2real through a single ONNX file with observations baked in

The deployment story is described in more specific terms than the rest of the README, and it is the part to read if you are considering real hardware.

ProtoMotions trains one General Tracking Policy across the entire BONES-SEED dataset, around 142,000 motions, and the README reports transferring it directly to a Unitree G1 humanoid zero-shot. The deployment pipeline exports a single ONNX model with the observation computation already baked into the graph, so a deployment framework only has to supply raw sensor signals and never needs to reimplement observation functions or match training internals.

That is a real engineering decision rather than a convenience. Observation computation living inside the exported graph means the thing you deploy and the thing you trained cannot drift apart, which is the most common way a working policy fails on hardware. The reported validation was on the Unitree G1 through the RoboJuDo framework, with one policy file added and no mandatory changes to RoboJuDo core, and a full deployment tutorial is linked from data preparation through to the robot.

The sibling datasets are worth naming because they explain the scale. BONES is on Hugging Face, and the multi-GPU section reports training with 24 A100s at 13,000 motions per GPU using that dataset in the SOMA skeleton format, with SOMA-X as the format's own project.

Rendering for evaluation is a separate feature with an honest caveat. IsaacSim 5.0 or newer can load rendered Gaussian splatting backgrounds through Omniverse NuRec, and the README states plainly that this rendered scene is not physically interactable yet. For evaluating a policy's appearance that is enough; for anything involving contact it is not.

Compute claims, forks, and what is not versioned

Two performance numbers anchor the README. Training a character on the full AMASS dataset, more than 40 hours of motion, is claimed to take 12 hours on 4 A100s. Scaling up, the project reports 24 A100s with 13,000 motions each on BONES in SOMA format. Both are specific enough to be checkable, which is rarer than the usual phrasing, and both assume a GPU cluster, so the framework's practical audience is research groups rather than individual experimenters.

Motion authoring is covered too, through Kimodo, NVIDIA's text-to-motion generation model, generating a motion from a prompt and using it in the pipeline. That is the one part of the README that leans on a companion system rather than something in this repository, so treat it as an integration point rather than a feature you can evaluate here.

The repository's shape reflects a research codebase. At 2,386 stars it has 459 forks, roughly one fork for every five stars, which is a high ratio and tells you people are vendoring this code rather than only reading it. There are 14 open issues against 2,386 stars. The tree includes `docs/`, `examples/`, `deployment/`, `data/`, `pyroki/`, a `MANIFEST.in`, a `.gitleaks.toml` secret-scanning config, and a `.license-header.txt` that suggests headers are enforced across files, backed by `.pre-commit-config.yaml`.

The last push was on 2026-09-16 and the repository is not archived, so work is landing. With no releases to pin and five engines each at a different level of support, the practical starting point is the Quick Start page on protomotions.github.io, which is where the install path that matches your chosen simulator will be, and the retargeting tutorial after that.

Editorial conclusion

ProtoMotions is worth reading for the shape of its claims rather than the size of its star count, because the interesting claim is structural: the same policy is meant to run in Newton, in IsaacGym, in MuJoCo, and on a Unitree G1 without anyone rewriting the observation functions. The README supports that with a sim2sim switch and an ONNX export that bakes observation computation into the graph, and it is refreshing that the rendering section says outright that the Gaussian splatting background is not physically interactable yet. Two caveats to carry in. Genesis carries a badge marked untested and no Dockerfile while the other engines have both, and the version 3 that the retargeting notes refer to exists in prose only, because the repository has no tagged releases. Start from the Quick Start page, then run the retargeting workflow for your own robot before training anything.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. NVlabs/ProtoMotions on GitHub
4. Project website
5. README