The State of Simulation for Physical AI: An Overview

Why Simulation

Figure 1: Humanoid robot locomotion simulation. The robot’s pose is represented by tracked body keypoints (green markers), while successive robot instances illustrate its movement through time. Directional arrows indicate commanded motion, demonstrating the use of a physics-based simulation environment for training and evaluating robot locomotion and control policies.

Building physical AI systems faces a single major hurdle: data. Large language models (LLMs) and vision-language models (VLMs) train on internet-scale datasets, but robotics lacks this advantage. A physical AI must learn the consequences of interacting with the physical world. It needs to understand what happens when a cup slips, a cable bends, or a gripper contacts an object at the wrong angle.

Collecting this data in the real world is slow, expensive, risky, and sometimes impractical due to the destructive nature of the tasks. Simulation provides a bridge by enabling developers to generate large amounts of photorealistic, physically grounded data. By teleoperating robots in simulation and scaling data collection through GPU parallelism, developers can generate thousands of hours of robot experience at a fraction of the cost of real-world collection.

Earlier robotics simulators were often used primarily to debug geometry, test controllers, or visualize robot motion. Today, simulation has become part of the model development loop. Teams use it to generate perception datasets, train reinforcement learning policies, collect demonstrations, augment real-world data, benchmark models, and test policies against rare or adversarial scenarios. This shift is why industrial research labs and academic groups are increasingly contributing to, or developing, simulation engines that can meet these new requirements.

These requirements can be understood through a three-computer paradigm:

• Training computer: A large GPU cluster used to process data and train foundation AI models.
• Simulation computer: A GPU workstation or cluster using GPU-accelerated physics and RTX rendering to generate robot experience, sensor data, and simulated interactions.
• On-robot computer: An edge device, such as a NVIDIA Jetson AGX Thor-class system, that runs the trained policy or model during deployment.

Figure 2: A physical system (Earth and robot) continuously exchanges data with its virtual representation (digital model), enabling monitoring, analysis, prediction, and control through a bidirectional feedback loop.

Each computer plays a different role depending on the task’s latency, throughput, accuracy, and deployment requirements.

Many simulation engines are available today, each targeting different use cases such as humanoid robots, aerial vehicles, ground robots, autonomous vehicles, quadrupeds, and dexterous manipulators. These engines also differ in their support for reinforcement learning, batched simulation, contact-rich physics, photorealistic rendering, and sensor simulation. Refer to Figure 2 for a categorization of simulation engines by robot domain and acceleration profile.

Which Simulation Engine Should I Use?

Developers often struggle with which simulation engine to use for the use case they are tackling. Oftentimes, this falls on a few fundamental questions, such as

• Do I need scalable synthetic data generation workflows?
• Do I need to do reinforcement learning?
• What kind of sensor support does a given simulation engine have?
• What kind of 3D asset formats does the simulation engine support?
• What environmental fidelity and scale are required?

These factors would help developers in deciding which simulation engine to use for their development needs.

NVIDIA Isaac Sim and Isaac Lab, MuJoCo, PyBullet, Drake, and Genesis are some of the most popular simulation engines for humanoids and two-arm dexterous manipulation. Each of these simulation engines is unique to specific use cases such as scaling reinforcement learning, generating synthetic data, testing algorithms and/or models in simulation. Here we will provide a quick overview of MuJoCo, MuJoCo Warp, NVIDIA Isaac Sim, and Isaac Lab.

MuJoCo

MuJoCo, short for Multi-Joint dynamics with Contact, is a fast, accurate, open-source physics engine built mainly for robotics, biomechanics, reinforcement learning, control, and simulation of articulated systems. Unlike engines focused mostly on games or visual realism, MuJoCo is designed around precise dynamics, contact-rich motion, and model-based optimization. MuJoCo emphasizes speed, accuracy, and modeling power for systems where physical correctness matters.

Figure 3: Robotic manipulator simulated in MuJoCo. The figure illustrates a multi-joint robotic arm with a parallel gripper operating in a physics-based simulation environment. MuJoCo is used to model the robot’s dynamics, kinematics, and contact interactions, enabling the development and evaluation of motion planning, manipulation, and control algorithms prior to real-world deployment.

While MuJoCo is not always the best choice for photorealistic rendering or massive GPU-parallel simulation, but some of the core features that MuJoCo is well known for are a deterministic pipeline, well-defined inverse dynamics with contacts, strong contact modeling, and generalized-coordinate simulation.

MuJoCo Warp

MuJoCo Warp, also called MJWarp, is a GPU-accelerated implementation of MuJoCo written in NVIDIA Warp, a Python framework for writing high-performance CUDA-accelerated differentiable kernels – tailored for robot learning and physics simulation.

It brings MuJoCo-style articulated-body physics, contact-rich simulation, and robot dynamics into a batched GPU setting, making it well suited for reinforcement learning and large-scale policy training. Compared with classic CPU MuJoCo, MJWarp is aimed more at throughput than single-step latency: it is designed to simulate many worlds in parallel, reduce CPU-GPU transfer bottlenecks, and scale contact-heavy robot tasks more efficiently for learning workloads.

Isaac Sim

Isaac Sim is an open-source robotics simulation framework built on NVIDIA Omniverse. It uses OpenUSD as its core scene and data layer, allowing robots, environments, sensors, materials, lighting, and physics properties to be represented as USD prims and schemas. Isaac Sim provides high-fidelity physics through PhysX, photorealistic RTX rendering, and robotics-focused sensor simulation for cameras, depth, lidar, radar, segmentation, and synthetic data generation workflows. It can ingest assets from CAD, URDF, MJCF, USD, and real-world reconstruction pipelines, enabling robots to be tested in realistic digital-twin environments.

Isaac Lab

NVIDIA Isaac Lab 3.0 is an open-source, GPU-accelerated, agent-ready simulation framework for robot learning, designed to train and evaluate robot policies at scale. This direction supports agent-assisted workflows for building environments, tuning physics, debugging, profiling, sim-to-sim transfer, and sim-to-real deployment. Its modular manager-based and direct workflows support reinforcement learning, imitation learning, motion planning, data collection, and policy evaluation.

How Isaac Lab 3.0 Relates to Isaac Sim and Newton

With Isaac Lab 3.0.0 – We have decoupled the Isaac Sim and omniverse dependency, and made Isaac Lab a lightweight, multi backend Robot learning framework.

The new architecture separates backend-specific code from the core Isaac Lab API. Developers can select to useIsaac Sim with PhysX and RTX rendering for photorealistic, sensor-rich workflows, or run light-weightheadless Newton physics for high-throughput simulation. Additionally, developers can add photoreal sensors via the standalone OVRTX renderer, or leverage the Newton renderer for vision-based RL tasks that require a very large number of environments.

Modern GPU-Accelerated Physics for Robotics

Modern robotics simulation frameworks are powered by numerical physics: rigid-body and soft-body dynamics, contact and friction models, joint constraints, actuators, sensors, and time integration. At each simulation step, the engine estimates how bodies move under forces, torques, collisions, gravity, constraints, and controller inputs. For robot learning, this physics must be fast, stable, repeatable, and scalable enough to run thousands of parallel environments, while also being accurate enough to transfer learned behavior from simulation to real robots. To address these, the Newton library is created.

Newton

Newton is an open-source, GPU-accelerated, extensible, and differentiable physics engine developed 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. In the broader simulation ecosystem, Newton acts as a modern physics layer for robot learning frameworks such as Isaac Lab and MuJoCo Playground, giving researchers a path toward scalable, differentiable, simulator-agnostic physics. In Isaac Lab specifically, Newton is currently an active integration path, with the MuJoCo-Warp solver used as a primary focus for high-throughput robot-learning experiments. Figure showcases breakdown on how different application frameworks communicate with GPU accelerated physics libraries and simulation engines. Newton provides multiple solver implementations rather than prescribing one numerical method for every problem.

SolverMuJoCo

and

SolverFeatherstone

use generalized coordinates for articulated rigid-body systems.

SolverSemiImplicit

,

SolverXPBD

, and the

SolverKamino

use maximal-coordinate formulations.

SolverVBD

is an implicit solver supporting rigid bodies, particles, cloth, and soft bodies, although its joint support remains limited.

SolverImplicitMPM

targets particle-based continuum materials, while

SolverStyle3D

specializes in cloth simulation. Because capabilities differ between solvers—including support for articulations, deformable bodies, contacts, and differentiation—the appropriate solver depends on the physical system being modeled.

Figure 4: The Newton Physics Engine is an open-source, GPU-accelerated simulation engine built upon NVIDIA Warp, designed for roboticists and simulation researchers.

Other Simulation Engines

PyBullet remains a useful CPU baseline for quick prototyping; DART and ODE are still Gazebo back-ends; Drake is the gold standard if you need contact-implicit trajectory optimisation and rigorous numerics rather than throughput. Each has a niche. None of them is the answer to “I need 4,096 humanoids on one GPU.”

Conclusion

Robot simulation has quietly become one of the most important layers in the modern embodied AI stack. As models move from static datasets into physical interaction, the ability to generate high-quality, scalable, and diverse simulated experiences is no longer optional, it is foundational. Simulation is where policies are stress-tested, where data is amplified, and increasingly, where entire training pipelines begin.

For a long time, the robot-simulator conversation has focused on “which engine performs the fastest” and for many workloads this statement still holds true. What we find more interesting in 2026 is a different question: which pieces of the stack are likely to become the shared infrastructure that different engines would build on top of? There is no definite answer.

What it means

Engineers no longer need to choose between speed