Newton: a GPU physics engine for robotics, built on NVIDIA Warp

What Newton replaces, and who it is for

Newton is a GPU-accelerated physics simulation engine for roboticists and simulation researchers. The README states that it extends and generalizes Warp's deprecated warp.sim module, and that it integrates MuJoCo Warp as its primary backend. That sentence is the whole pitch: if you were using warp.sim, the module you depended on is deprecated, and Newton is where that work continues. The project was initiated by Disney Research, Google DeepMind and NVIDIA, and it is a Linux Foundation project under Apache-2.0. The audience is narrow on purpose. This is not a game physics engine and not a general rigid-body library for web demos. The stated emphasis is GPU computation, OpenUSD support, differentiability and user-defined extensibility, which maps onto people who train policies in simulation, who need gradients through the simulator, or who already keep their assets in USD and do not want a conversion step in the middle of a robotics pipeline.

How Newton sits on Warp, MuJoCo Warp and USD

The dependency chain is visible in pyproject.toml and it explains most of the project's behaviour. The only required runtime dependency is warp-lang>=1.17.0. Everything else is optional and grouped: a sim extra pulls mujoco-warp~=3.12.0 and mujoco~=3.12.0, an onnx extra pins a specific warp-nn commit for neural actuator and RL policy inference, and an importers extra brings in requests for downloading meshes plus scipy for mesh processing used by ModelBuilder.approximate_meshes. So the core is a thin layer over Warp, and the MuJoCo path is opt-in rather than baked in. That layering matters when something breaks: a contact-solver problem and a mesh-import problem live in different extras and different repositories. The build backend is uv_build, the package requires Python 3.10 or newer, and the classifiers list CUDA 12 and CUDA 13 environments. OpenUSD support is named in the README as a design emphasis; the README does not spell out the conversion path from a USD stage to a simulation model, so treat that as something to read the documentation site for rather than something to assume.

Installing Newton and running your first example

The README gives a two-line quickstart. Installing with the examples extra is the fastest way to confirm that Warp, the driver and your GPU agree with each other, because the examples ship with the package.

pip install "newton[examples]"
python -m newton.examples

The first command installs Newton plus the example assets. The second launches the example runner; the README does not state what the runner prints when invoked with no example name, so expect a list or a prompt rather than a specific output. To run one example directly, pass its name:

python -m newton.examples basic_pendulum

That runs the pendulum example, which is the smallest scene in the basic set and the one to use when you are checking that a GPU context is created at all. Other basic examples in the README are basic_urdf, basic_viewer, basic_shapes, basic_joints, basic_conveyor, basic_heightfield, recording and replay_viewer. If you work from a source checkout with uv instead of an installed wheel, the README says to use a different invocation:

uv run --extra examples -m newton.examples basic_pendulum

The difference is not cosmetic. The pip path runs against the installed package; the uv path runs against the checkout, which is what you want when you are editing the engine rather than using it. The requirements section lists Python 3.10+, an NVIDIA GPU of Maxwell or newer, driver 545 or newer for CUDA 12, and no local CUDA Toolkit installation. Linux covers x86-64 and aarch64, Windows covers x86-64, and macOS runs on CPU only.

The macOS and non-NVIDIA cases are not edge cases, they are exclusions

The requirements list is unusually blunt, and it is the first thing to read before you plan anything. macOS is CPU only. If your team develops on Apple laptops and deploys to a GPU cluster, every performance assumption you form locally is wrong, and the examples will run but they will not tell you anything about throughput. There is no AMD or Intel GPU path in the requirements. Driver 545 or newer is a hard floor for the CUDA 12 line, and the README does not describe what happens on an older driver beyond the requirement itself. The second limitation is the backend situation. MuJoCo Warp is described as the primary backend, not the only one, and it lives in an optional extra. The README does not document rollback or a fallback path if you hit a MuJoCo Warp bug, and it does not document what the engine does without the sim extra installed. The third is versioning. pyproject.toml carries version 1.7.0.dev0, and the README points to a separate compatibility guide for versioning and deprecation policy. A project whose predecessor module was deprecated out from under its users is telling you something about how to plan: pin your Newton version and read the compatibility guide before upgrading, rather than tracking main.

Newton against MuJoCo Warp and Isaac Lab

The honest comparison is with MuJoCo Warp itself. MuJoCo Warp is the GPU-accelerated MuJoCo, and Newton uses it as a backend rather than competing with it. If your models are MJCF and your workflow is already MuJoCo, going straight to MuJoCo Warp removes a layer; Newton adds value on top when you want OpenUSD assets, a differentiable path, or the extensibility hooks that Warp's kernel model gives you for custom solvers and user-defined components. The second comparison is with Isaac Lab and the Isaac Sim stack. Both target GPU robotics simulation, but they start from different assumptions: Isaac Sim is built around Omniverse and USD as the authoring environment, while Newton is a Python package you pip install, with USD support named as a feature rather than as the platform you live inside. That makes Newton lighter to embed in an existing Python training loop and heavier to use if you want a full visual authoring environment. The README does not publish benchmark comparisons against either, so treat any performance expectation as something you measure on your own scenes.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-22. Recent releases in the changelog include v1.6.0 on 2026-09-10, v1.5.2 on 2026-09-11 and v1.5.1 on 2026-08-28. Two releases eight days apart, one of them a patch published after the minor that precedes it in the list, is normal for a project at this stage and also a signal: the surface is still moving. On licensing, the code is Apache-2.0 and the documentation is CC-BY-4.0, with additional and third-party license texts under newton/licenses. The pyproject.toml declares license-files covering LICENSE.md and newton/licenses/**/*.txt, which means the wheel carries the third-party notices with it. The practical implication for a commercial robotics product is that Apache-2.0 is permissive, but the bundled third-party texts are the ones to read if you redistribute, because Newton sits on Warp, MuJoCo and MuJoCo Warp, each with its own terms. This is not legal advice; the license files are in the repository. Upgrade cost is dominated by the compatibility guide, not by the install command.

Editorial conclusion

Adopt Newton if you are simulating robots on Linux with an NVIDIA GPU and you want a differentiable, USD-aware engine that sits on top of Warp and MuJoCo Warp. Do not adopt it if your only machine is a Mac and you need GPU acceleration, or if you need a stable API you will not have to touch for a year: the package version in pyproject.toml is 1.7.0.dev0 and the compatibility guide is the document that governs breakage. Verify first that your driver is 545 or newer, that your GPU is Maxwell or newer, and that the examples extra installs cleanly on your Python version before you build anything on top of it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. newton-physics/newton on GitHub
3. Project website
4. README
5. Releases