Newton Alpha Announcement

[momo-van]

Newton is now Alpha
We are excited to announce that Newton has moved from pre-release to its Alpha stage. Newton is an open-source, GPU-accelerated, and extensible physics engine purpose-built for robot learning.

Highlights

• Solvers available in Alpha: MuJoCo Warp, Featherstone, VBD, Semi-Implicit Euler, Implicit MPM, XPBD, and Style3D.
• MuJoCo Warp as the primary solver for rigid body dynamics.
• Unified API for models, states, solvers, actuators and sensors.
• USD asset ingestion and cloning across thousands of parallel environments.
• Newton basic viewer for debugging and visualization.
• Quick-start guide and examples to help you get up and running.
• Multi-physics examples (one-way coupling and interactive):
  • Cloth manipulation with a Franka arm
  • Locomotion of an ANYmal quadruped on sand

Experimental Isaac Lab Integration

• A developer preview of Newton support in Isaac Lab is available in a dedicated feature branch, with tools and documentation to enable early testing and integration. See isaac-sim/IsaacLab at feature/newton.
• Documentation covers installation, training environments, solver transitioning, Sim-to-Sim/Sim-to-Real workflows, and limitations. See Newton physics integration docs.
• MuJoCo Warp is used as the primary solver for training and inference, validated with Sim-to-Real transfer for both quadruped and biped robot locomotion tasks.

Collaboration
We invite you to explore Newton, provide feedback, and contribute to its evolution. Development velocity is high, and the API is still subject to change, your input at this stage is especially valuable.

What’s next
Our next milestone will center on verifying and tuning MuJoCo Warp for manipulation tasks, improving robustness and performance at scale, and extending multi-physics examples.

[PerFrivik]

Exciting! 🎉

[ZimengZeng-THU]

First of all, I must commend this project for its excellent work—both the code quality and feature implementation are truly impressive! I’m particularly interested in its multiphysics simulation capabilities, and I’d like to learn more about the compatibility of different solvers. For instance, in the Cloth Manipulation example, the current setup uses a combination of the Featherstone solver and VBD solver. I’m wondering if it’s possible to replace this with a MuJoCo + VBD combination for simulation? If feasible, are there any special adaptations or modifications required? I look forward to your response. Thank you!

[eric-heiden]

@AnkaChan can provide more details here but it is definitely possible to use the MuJoCo solver in-place of Featherstone. In fact, we tried this out before but noticed a slight drop in performance so we decided to stick with Featherstone for now. It should be only a matter of tuning the MuJoCo solver (reducing iterations, skipping contact resolution, etc.) to achieve comparable performance though.

[ZimengZeng-THU]

Thank you so much for your explanation earlier. I have a few more questions regarding multi-physics simulations that I'd be grateful if you could help clarify:
Why do multi-physics examples typically often require multiple solvers? I understand that tools like MuJoCo also support cloth simulations, so why isn't MuJoCo used directly for such simulations? Additionally, does the combination of multiple solvers lead to increased simulation errors?
I appreciate you taking the time to help with these questions. Thank you very much for your patience!

[romesco]

Congratulations!!

It's looking great so far 😊!!

[zhwhong]

Exciting news! 🎉🎉🎉

[zhwhong]

（系统自动回复）您好！    您的邮件我已收到，我会尽快给你回复，谢谢！Hello!    I have received your mail, I will give you a reply as soon as possible, thank you!

[mottosso]

Thanks for sharing, some initial impressions, 32-core AMD CPU, NVIDIA 3090 GPU, on Windows, from the perspective of building an end-user robotics-based product out of it.

Pros

1. Installation process was very smooth, took about 2 mins
2. Examples being written in Python is 👍
3. Utilising the GPU is 👍
4. UI in ImGui is 👍

Cons

1. Boot-up time for the application was a pain, minutes on first launch, about 6 seconds on subsequent launches
2. Simulation performance is poor, worse than CPU PhysX/Bullet/Jolt; the below scene would run 2-5x faster with other CPU solvers
3. Simulation quality is poor; persistent intersections abound, unclear what the actual collision geometry is
4. Simulation stability is poor, as seen in the below video
5. Having to compile each "kernel" was a pain, you never know which are about to be compiled or whether you have already compiled the ones you need
6. Having to re-compile whenever you update your graphics drivers makes sense but is needless friction

warpookk.mp4

[mmacklin]

Thanks a lot for the feedback @mottosso - I've added an issue to improve the default USD assets here: #696.

We're also looking at compile / startup times on both the Warp and MuJoCo Warp sides.

Regarding runtime perf. it is common for GPU engines to have higher fixed cost - we are very focused on RL workloads and total throughput for for thousands of environments, so it is somewhat expected that MuJoCo Warp would not be competitive for small numbers of environments. Right now we are fairly confident that Newton perf. with MuJoCo is roughly on-par with PhysX for these types of workloads.

Cheers,
Miles