Steel: Scaling Simulation Across Robots, Tasks, and Worlds

Together with NVIDIA, we're introducing Steel (Scalable Throughput-optimized Engine for Embodied Learning), a GPU-accelerated rigid-body dynamics solver for the open-source Newton Physics Engine to accelerate robot learning in NVIDIA Isaac Lab. Across 20 robot-learning benchmarks in our measured configurations, Steel delivers 3.8× PhysX's simulation throughput on geometric mean, with each engine at its best measured batch size, and is faster on 19 of the 20 tasks. On heterogeneous batches combining different robot tasks, the advantage reaches 13.0× PhysX's peak measured throughput.

Steel goes beyond homogeneous workloads - it is designed to efficiently simulate different robots, tasks, and physical worlds together.

Try it in your browser. steel-webgpu is a WebGPU implementation of Steel's solver. The scenes below run on your own GPU, right in this page: pick one, pull objects around and change the solver settings while it runs.

1. From Scaling Simulation to Scaling Diversity

GPU simulation has transformed reinforcement learning for locomotion and whole-body control. Thousands of copies of the same robot can practice in parallel, with domain randomization over terrain, dynamics, and disturbances helping policies transfer to real hardware. Skild's physical self-play shows how far scalable interactive learning in simulation can go.

Manipulation presents a different challenge. A seemingly simple instruction like "clean the table" can require an entirely different sequence of actions as objects, layouts, or constraints change. More broadly, manipulation spans everything from assembly and tool use to dexterous grasps and long-horizon combinations of skills. Different tasks also favor different hardware: a parallel gripper, dexterous hand, and humanoid each bring different capabilities. Scaling general-purpose robot learning therefore means scaling experience across both diverse tasks and diverse embodiments.

That breadth creates two demands on simulation. Individual scenes must handle more interacting bodies, articulated mechanisms, and changing contacts; batches must simultaneously accommodate increasingly different scenes and robot structures. Yet many GPU simulation architectures are most efficient when they replicate one structured workload thousands of times. Dense articulation factorizations grow expensive as robots become more complex, while padded representations waste work and memory when environments differ substantially.

Steel was built for this combination of complexity within environments and heterogeneity across them.

2. Built for Heterogeneity

A robot arm reaching in free space, a dexterous hand reorienting a cube, and a manipulator working through a cluttered bin have different numbers of joints, constraints, and active contacts. Even a single scene's workload changes from step to step as contacts appear and disappear. Treating all three as though they require the same amount of computation leaves much of the GPU's work poorly allocated.

Steel organizes dynamics and constraints per environment, groups articulations with similar joint counts for efficient GPU execution, and routes contact-solving work according to each environment's current demands. Grouping articulations and routing work per environment reduces padding and unnecessary solve work in heterogeneous batches.

Under the hood, Steel combines reduced-coordinate articulation dynamics with projected Gauss-Seidel constraint solving. It reuses the factorization of each articulation's joint-space mass matrix across its contacts, without constructing a dense matrix of pairwise constraint interactions. Together, these design choices let one solver handle workloads with widely different articulation and contact structures efficiently.

3. Performance at Scale

All numbers in this section are simulation-only throughput on one NVIDIA RTX PRO 6000 Blackwell GPU, with each engine at its best measured batch size unless noted.

The most distinctive result appears when those workloads are mixed. We evaluated batches combining 5, 10, 15, and 20 different task types, including humanoids, quadrupeds, arms, and dexterous hands. Across those mixtures, Steel achieved 9.2× to 13.0× PhysX's peak measured throughput, with each engine evaluated at its own best batch size.

For the 20-task mixture, Steel reached 3.90 million environment steps per second at 245,760 environments, compared with 300,000 for PhysX at 61,440 environments. At the matched batch size of 61,440 environments, Steel ran at 3.61 million environment steps per second, 12.0× PhysX's 300,000, and used about 62% less GPU memory (approximately 11 versus 29 GiB).

The benefit isn't limited to heterogeneous batches. Across 20 single-task benchmarks, Steel was faster than PhysX on 19 of the 20 tasks, with 3.8× geometric-mean throughput. On the same 20 tasks, Steel achieved approximately 1.3× MuJoCo Warp's throughput. The gains cover locomotion, classic control, articulation-heavy manipulation, and contact-rich workloads: on the 23-joint Kuka–Allegro lift task, for example, Steel reached 6.7× PhysX's throughput and approximately 1.8× MuJoCo Warp's.

4. Built into Newton, Open to Everyone

Steel is developed directly within Newton and is intended to integrate with NVIDIA Isaac Lab, an open-source, modular framework for training and refining robot policies. It shares Newton's model representation and collision infrastructure rather than requiring researchers to adopt a separate physics stack. That matters as tasks move beyond rigid objects on empty tables to cloth, cables, soft bodies, granular materials, and other coupled physical interactions.

We're contributing Steel to the open-source Newton ecosystem so researchers can inspect, reproduce, extend, and improve it. Steel is available in Newton as newton.solvers.SolverSteel.

Get started: Steel on GitHub · Newton on GitHub · Isaac Lab

5. Scaling the Diversity of Robot Experience

The broader goal is not simply to make existing physics workloads faster. In our work on S1, we have seen robot capabilities improve as we scale pretraining experience. For increasingly general policies, however, what that experience covers matters alongside how much of it we collect. Different tasks require different interactions, and different embodiments offer different ways to solve them. As explored in our omni-bodied work, we want a shared robot intelligence that can learn across that breadth rather than treating every body as an isolated problem.

Real-world data remains essential for grounding policies and validating transfer, but physical collection is expensive and difficult to scale across every possible task and recovery scenario. Simulation offers repeatable, on-policy exploration, including alternative actions from the same starting state, failures, and recoveries. Steel addresses one piece of making that approach practical: the cost of simulating increasingly diverse tasks and robot embodiments together.

The next step is to learn what happens when the diversity of simulated experience scales alongside its volume. Steel gives us a faster foundation on which to explore that question.