Article summary — original

The Evolving Landscape of Simulation and Physics Engines for Physical AI Physical AI development relies heavily on physics simulation to overcome real-world data collection bottlenecks, driving the evolution of specialized, GPU-accelerated engines and modular infrastructure. Simulation addresses physical AI data shortages by scaling synthetic data generation across a three-computer paradigm: training clusters, simulation workstations, and on-robot edge devices. Classic physics engines like MuJoCo have expanded into GPU-accelerated implementations like MuJoCo Warp, while Isaac Lab 3.0 has decoupled from Omniverse to support multiple backends. The open-source Newton engine, developed by NVIDIA, Google DeepMind, and Disney Research, provides an extensible, differentiable physics layer with a diverse set of specialized numerical solvers. The robotics simulation landscape is transitioning from single-engine performance comparisons toward open-source, layered shared infrastructure that supports massive parallelization. The Need for Simulation and the Three-Computer Paradigm Physical AI systems require robots to learn real-world consequences, such as slips and contact forces, which cannot be acquired through static web-scale datasets alone. Because real-world data collection is expensive, slow, and potentially destructive, simulation bridges the gap by producing physically grounded data across thousands of hours via GPU parallelism. Modern workflows operate under a three-computer paradigm: a training cluster to process foundation AI models, a simulation cluster or workstation executing GPU-accelerated physics and rendering, and an on-robot edge system such as NVIDIA Jetson AGX Thor to run policies during deployment. Key Simulation Platforms and Architecture Decoupling While classic MuJoCo provides accurate contact-rich dynamics and generalized-coordinate simulation on CPUs, MuJoCo Warp brings these dynamics into a batched GPU environment using NVIDIA Warp to scale policy training. NVIDIA Isaac Sim serves as an OpenUSD-based framework delivering PhysX physics and RTX sensor simulation. Isaac Lab 3.0 further decouples the framework from direct Isaac Sim and Omniverse dependencies, transforming into a lightweight, multi-backend system that allows users to alternate between photorealistic RTX rendering and lightweight, high-throughput Newton physics. Newton and Multi-Solver Physics Acceleration Newton is an open-source, GPU-accelerated, and differentiable physics engine developed by NVIDIA, Google DeepMind, and Disney Research under the Linux Foundation. Built on OpenUSD and Warp, Newton serves as a modern physics layer for frameworks like Isaac Lab and MuJoCo Playground. Rather than relying on a single numerical approach, it incorporates diverse solvers: SolverMuJoCo and SolverFeatherstone for generalized coordinates, maximal-coordinate formulations such as SolverXPBD and SolverKamino, SolverImplicitMPM for continuum materials, SolverVBD for implicit dynamics, and SolverStyle3D for cloth simulation. Ecosystem Specialization and Open Infrastructure Other simulation tools maintain dedicated roles, such as PyBullet for rapid CPU prototyping and Drake for contact-implicit trajectory optimization, though they do not address high-capacity parallel workloads like simulating thousands of humanoids on a single GPU. The broader simulation domain is shifting from evaluating raw single-step speeds toward establishing layered, interoperable shared infrastructure. An increasing portion of this core tooling is open-source, governed collaboratively, and accessible on consumer GPUs.

Article summary — zh

物理AI仿真技术全景:从算法验证到具身智能核心底座 不同于依赖互联网级数据集的大语言模型,物理AI需要理解物理交互后果,而真实数据采集高危且昂贵。仿真已从早期的调优工具转变为贯穿感知生成、强化学习及策略评估的模型研发核心环节。 物理AI开发依赖“训练-仿真-端侧”三计算机协同范式 经典物理引擎与GPU加速框架正加速融合以应对大规模并行需求 Isaac Lab 3.0解耦底层依赖,向轻量多后端框架演进 Newton物理引擎通过多求解器架构统一机器人学习底层 物理AI的仿真需求与三计算范式 构建物理AI系统的首要瓶颈在于数据获取困难,真实世界采集不仅成本高昂,还伴随硬件损耗风险。GPU并行加速仿真通过合成物理对齐的交互数据弥补了这一短板。当前具身AI形成了三计算机协同范式:大规模GPU集群负责基础模型训练;仿真工作站或集群利用GPU物理模拟与RTX渲染生成经验与传感器数据;端侧设备(如Jetson AGX Thor类系统)则专用于部署并运行推理策略。 主流仿真引擎与GPU加速架构 MuJoCo以高精度动力学、强接触建模和确定性管线著称,但传统CPU版本受限于吞吐量;基于NVIDIA Warp重构的MuJoCo Warp(MJWarp)将关节体物理引入GPU批处理环境,专为高并发强化学习降低CPU-GPU传输开销。与此同时,基于OpenUSD构建的Isaac Sim在PhysX物理模拟与RTX高保真传感器渲染上表现突出,支持从CAD、URDF等资产快速构建数字孪生环境。 Isaac Lab 3.0解耦与Newton多求解器生态 Isaac Lab 3.0解耦了对Isaac Sim及Omniverse的强制依赖,转变为轻量级、多后端的机器人学习框架,允许按需调度不同渲染器或无头物理后端。作为由NVIDIA、Google DeepMind和Disney Research共同开发并由Linux基金会管理的开源库,Newton基于Warp与OpenUSD,集成了MJWarp等多种解算器,涵盖广义坐标求解器(SolverMuJoCo、SolverFeatherstone)、最大坐标求解器、隐式软体/布料求解器及连续介质MPM求解器,以适配差异化的物理仿真任务。 开源协同与基础设施重构 早期诸如PyBullet、DART、ODE与Drake等工具各有专长,但在单GPU承载数千机器人实例的极高吞吐场景下遇到瓶颈。仿真领域的关注焦点已由单一引擎速度竞赛转向模块化共享基础设施的构建。大量可微分物理引擎与训练管线转向开源治理与消费级GPU支持,大幅降低了具身智能研发的准入门槛。

Saved original article

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. The primary challenge in building physical AI systems is data availability. Large language models (LLMs) and vision-language models (VLMs) can be trained on internet-scale datasets, but robotics and physical AI systems do not have the same advantage. To train a physical AI system, a robot must learn the consequences of interacting with the physical world. For example, 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 kind of 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 use Isaac 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 out there yet but a few candidates seem plausible from where we sit. The ecosystem 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 we do feel confident saying is that an unusual amount of this work is being done in the open-source, openly governed, and available to anyone with a consumer GPU. A growing share of the core infrastructure physics engines, differentiable simulators, and training pipelines is emerging in the open, with open-source projects, open governance, and GPU-accessible tooling lowering the barrier to entry and accelerating iteration. That alone is worth celebrating, regardless of which engines you end up reaching for. Looking Ahead: From Concepts to Practice This article takes a step back to map that landscape in 2026: what exists, how the major engines relate, and why these shifts matter for anyone building in Physical AI. The next article in this series goes one layer deeper and looks at Warp and MuJoCo Warp itself, what it is, and how to drive it. From there, we will work our way up, and by the end of the series we will have a practical end-to-end robotics example, trained on a GPU using a software stack that did not exist two years ago. If you build something with the tools described here, whichever ones you pick, we would love to see it. Open an issue on any of the linked repositories, or reach out to us on Discord Nvidia Omniverse . Further Learning Resources Practical Implementation : If you want to go deeper alongside this series, you can follow NVIDIA’s SO-101 sim-to-real course , which walks through the full pipeline from simulation to physical deployment with Isaac Sim, Isaac Lab, and GR00T. The Big Picture : For a broader view of the space, NVIDIA’s Physical AI learning paths provide structured guidance across simulation, robotics, and embodied AI workflows.