Robotics has a data problem that language models never had. LLMs train on internet-scale text; a robot has to learn what happens when a cup slips, a cable bends, or a gripper hits an object at the wrong angle — and collecting that experience in the real world is slow, expensive, and sometimes destructive. That gap is why simulation has quietly become one of the most consequential layers of the embodied-AI stack, and a new overview published by five NVIDIA authors on Hugging Face is the clearest public map yet of how that layer is being rebuilt in 2026 — largely in the open.
The piece, posted July 21, is nominally a survey of simulation engines. Read closely, it is something more interesting: a snapshot of the robot-sim ecosystem mid-recomposition, with a new Linux Foundation-governed physics engine at the center and NVIDIA’s own flagship framework deliberately loosening its dependency on NVIDIA’s stack.
Simulation moved from debugging tool to training infrastructure
The authors frame the shift bluntly. Earlier robotics simulators were used to debug geometry, test controllers, or visualize motion. Today, simulation sits inside the model development loop itself: teams use it to generate perception datasets, train reinforcement learning policies, collect teleoperated demonstrations, augment real-world data, benchmark models, and stress-test policies against rare or adversarial scenarios. By teleoperating robots in simulation and scaling collection through GPU parallelism, developers can generate thousands of hours of robot experience at a fraction of real-world cost.
NVIDIA formalizes this as a three-computer paradigm: a training computer (a large GPU cluster for foundation models), a simulation computer (a GPU workstation or cluster generating robot experience and sensor data with accelerated physics and RTX rendering), and an on-robot computer (an edge device like a Jetson AGX Thor-class system running the trained policy). Each leg has different latency, throughput, and accuracy requirements — which is exactly why no single simulation engine has won.
The engine landscape: MuJoCo, MuJoCo Warp, Isaac Sim
For humanoids and dexterous two-arm manipulation, the overview names Isaac Sim and Isaac Lab, MuJoCo, PyBullet, Drake, and Genesis as the most popular options, then walks through the trade-offs.
MuJoCo — Multi-Joint dynamics with Contact — remains the reference for physical correctness: a deterministic pipeline, well-defined inverse dynamics with contacts, and generalized-coordinate simulation built for robotics, biomechanics, and control research rather than visual spectacle. Its limitation is the flip side of its design: it was not built for photorealistic rendering or massive GPU-parallel workloads.
MuJoCo Warp (MJWarp) is the answer to that limitation — a GPU-accelerated reimplementation of MuJoCo written in NVIDIA Warp, the Python framework for CUDA-accelerated differentiable kernels. Where classic CPU MuJoCo optimizes single-step latency, MJWarp optimizes throughput: simulating many worlds in parallel, cutting CPU-GPU transfer bottlenecks, and scaling contact-heavy tasks for reinforcement learning.
Isaac Sim covers the opposite end of the fidelity spectrum. Built on Omniverse with OpenUSD as its scene layer, it provides PhysX physics, photorealistic RTX rendering, and sensor simulation spanning cameras, depth, lidar, radar, and segmentation — with asset ingestion from CAD, URDF, MJCF, USD, and real-world reconstruction pipelines for digital-twin work.
Isaac Lab 3.0’s quiet strategic move
The most significant architectural news in the piece concerns Isaac Lab 3.0. In the authors’ words: “We have decoupled the Isaac Sim and omniverse dependency, and made Isaac Lab a lightweight, multi backend Robot learning framework.”
That sentence is worth pausing on. Isaac Lab — NVIDIA’s open-source, GPU-accelerated framework for training and evaluating robot policies at scale — no longer requires NVIDIA’s own simulator underneath. The new architecture separates backend-specific code from the core API, so developers choose per-workload: Isaac Sim with PhysX and RTX rendering when they need photorealistic, sensor-rich simulation, or lightweight headless Newton physics when they need raw throughput across a very large number of environments. Photoreal sensors can be added via the standalone OVRTX renderer, or vision-based RL tasks can lean on the Newton renderer instead.
For a company often criticized for building moats around CUDA, decoupling its flagship robot-learning framework from its own simulation product is a notable concession to how researchers actually work — mixing engines per experiment rather than committing to one vendor’s stack.
Newton: three rivals, one physics engine
The engine making that decoupling possible is Newton, and its governance is as interesting as its architecture. Newton is an open-source, GPU-accelerated, differentiable physics engine developed jointly by NVIDIA, Google DeepMind, and Disney Research, and managed through the Linux Foundation. It is built on NVIDIA Warp and OpenUSD, and it integrates MuJoCo Warp as a key physics backend — meaning DeepMind’s physics lineage and NVIDIA’s GPU tooling now converge in a single, openly governed layer.
Rather than prescribing one numerical method, Newton ships a family of solvers: SolverMuJoCo and SolverFeatherstone for articulated rigid bodies in generalized coordinates; SolverSemiImplicit, SolverXPBD, and SolverKamino in maximal-coordinate formulations; SolverVBD as an implicit solver spanning rigid bodies, particles, cloth, and soft bodies; SolverImplicitMPM for particle-based continuum materials; and SolverStyle3D specialized for cloth. Capabilities differ across solvers — articulation support, deformables, contacts, differentiability — so the right choice depends on the physical system being modeled. In Isaac Lab, the MuJoCo-Warp solver is currently the primary focus for high-throughput robot-learning experiments.
The older guard still has clearly assigned niches in the authors’ telling: PyBullet as a CPU baseline for quick prototyping, DART and ODE as Gazebo backends, Drake as “the gold standard” for contact-implicit trajectory optimization and rigorous numerics. But none of them, the piece notes dryly, answers the request that defines modern robot learning: “I need 4,096 humanoids on one GPU.”
Why the open governance matters more than the benchmarks
The overview’s conclusion makes an argument that should resonate well beyond robotics labs. The interesting question in 2026 is no longer which engine is fastest, but which pieces of the stack become shared infrastructure that everything else builds on. The ecosystem, the authors write, is “fragmenting and recomposing into a layered stack, where different tools specialize, interoperate, and sometimes compete to define the abstractions others will build on.”
What is unusual — and worth celebrating regardless of which engine you reach for — is where that recomposition is happening: in open-source projects with open governance, accessible to anyone with a consumer GPU. A physics engine co-developed by NVIDIA, DeepMind, and Disney Research would once have been a proprietary crown jewel. Housing it at the Linux Foundation, with MuJoCo Warp as a backend and Isaac Lab as a consumer, puts the foundational layer of physical AI on a very different trajectory than the closed foundation-model race happening one floor up the stack.
NVIDIA says this overview is the first in a series, with the next installment going deeper into Warp and MuJoCo Warp specifically. For anyone building in physical AI — or deciding which simulator to learn this year — the layered-stack framing is the practical takeaway: pick the engine per workload, because the abstractions underneath them are converging.
If you want to evaluate the stack yourself, the entry points are all public: the Newton repository on GitHub, Isaac Lab 3.0’s multi-backend releases, and MuJoCo Warp’s batched examples. A consumer RTX-class GPU is enough to run meaningful reinforcement-learning experiments across thousands of parallel environments — which, more than any single benchmark, is the change that makes 2026 feel different from every previous robot-simulation cycle.
