Genesis Simulator vs MuJoCo Playground vs Isaac Lab: GPU Robot Simulation for Sim-to-Real

A quadruped that learned to walk in five minutes of wall-clock time sounds like marketing, yet it is a documented result: the MuJoCo Playground paper reports a Unitree Go1 joystick policy trained in about five minutes on two RTX 4090 GPUs. The Genesis simulator headlines a different number, “over 43 million FPS” for a Franka arm on one RTX 4090. Isaac Lab, meanwhile, has just been re-architected around pluggable physics backends. Three projects, three philosophies, and three very different kinds of evidence.

This matters now because robot learning has become a throughput problem. Reinforcement learning (RL) needs billions of environment steps, and the simulator decides whether an experiment takes an afternoon or a month. But fast simulation only pays off if the policy survives contact with real hardware. Raw frames per second tell you nothing about that.

You will leave with a mechanism-level model of how GPU physics batches thousands of robots, a worked throughput calculation, an honest reading of each project’s published evidence, a decision matrix, and a list of failure modes that bite teams in practice.

What this covers: how batched GPU simulation works, how Genesis, MuJoCo Playground and Isaac Lab differ architecturally, what each has actually demonstrated on hardware, where the benchmarks mislead, and how to choose.

Context and Background

Before 2021, most robot learning ran on CPU simulators, with one environment per core and perhaps a few hundred parallel workers across a cluster. Training a locomotion policy took hours to days. The shift came when researchers moved the entire loop (physics, observations, rewards, resets and the policy network) onto the GPU, so that thousands of environments share one device and no data crosses the PCIe bus per step. NVIDIA’s Isaac Gym popularized this pattern, and its successor Isaac Lab is now the most widely used framework in the field.

Two other lineages matter. DeepMind’s MuJoCo, long the favorite of control researchers for its accurate contact model, gained a JAX port called MJX, and MuJoCo Playground packages MJX with ready-made robot environments and training recipes. Separately, Genesis arrived as a new, Python-native platform that integrates several physics solvers (rigid body, material point method, smoothed particle hydrodynamics, finite elements, position-based dynamics) and claims extreme speed.

A fourth actor now ties the lineages together. Newton is an open-source GPU physics engine built on NVIDIA Warp, co-developed by Google DeepMind and NVIDIA, with MuJoCo Warp as its primary backend. MuJoCo Warp is Apache 2.0 licensed and installable as mujoco-warp, and Isaac Lab 3.0 can use it as a physics backend. That convergence is the most important structural fact in this comparison, and we return to it below.

If you are new to why simulation-trained policies fail on real robots, read our guide to sim-to-real transfer and domain randomization in Isaac Lab first. The present article focuses on the simulator choice that sits underneath that pipeline. For primary sources, the MuJoCo Playground paper (arXiv:2502.08844) and the Isaac Lab documentation are the documents to keep open.

A note on scope and honesty. Facts below were checked against primary pages on 2026-11-02. Where a number is my own derivation or an illustrative configuration, it is labeled. Where a vendor claim has no published methodology, I say so rather than repeat it as established.

How GPU Physics Simulation Actually Works

Direct answer: GPU physics simulation advances thousands of independent copies of a robot world in lockstep. State for all copies lives in GPU memory as batched arrays, one kernel launch steps every world, and observations and rewards stay on the device as tensors that feed the policy network directly. Speed comes from batching and zero host-device copies, not from a faster single simulation.

Figure 1: The shared architecture. All three frameworks load a robot description, hand it to a physics core, keep thousands of world states on the GPU, and feed tensors to an RL trainer that updates the policy.

Figure 1 shows the common skeleton. The differences lie in the physics core and in how each framework keeps data on the device. In the diagram, the trainer and the physics core exchange tensors in GPU memory, which is why a modern setup can run a full PPO update without the CPU touching a single observation.

The batching model

A single simulated robot is a poor fit for a GPU. A 12-joint quadruped has a tiny state vector and sequential dependencies between contacts, so one world cannot fill thousands of cores. The trick is to simulate N worlds at once. With N = 4,096, each kernel operates on 4,096 copies of the same operation, and the hardware stays busy.

Here is a worked example using an illustrative, commonly used configuration (not a measurement). Suppose 4,096 environments, a policy running at 50 Hz, and an episode of 20 seconds. One control step across all environments yields 4,096 transitions. At 50 Hz and four physics substeps of 5 ms each, one second of simulated time costs 200 physics substeps per environment. A PPO rollout of 24 control steps therefore collects 4,096 x 24 = 98,304 transitions per iteration. At one billion total steps, that is roughly 10,170 iterations. If your simulator sustains 1 million policy-level steps per second, a billion steps takes about 1,000 seconds, or 17 minutes. At 3.3 million steps per second the same budget takes about five minutes. That last figure is the scale implied by the Go1 result, though the paper does not state its step count in the passages I verified, so treat it as an order-of-magnitude derivation.

Where the time actually goes

The MuJoCo Playground paper gives a rare honest breakdown for vision-based training. For a simple cart-pole balance task with pixel observations, physics, rendering and inference account for only 9 percent of training time; for the Franka manipulation environment they account for 43 percent. Most of the rest goes to updating the convolutional policy. The same paper reports that Franka physics costs more than 20 times the cart-pole’s, and that Madrona rendering reached about 403,000 pixel-based environment steps per second for cart-pole versus about 37,000 for the Franka task.

The lesson: once physics is fast, the learner becomes the bottleneck. A simulator that is 10 times faster speeds up end-to-end training by far less than 10 times when the policy update takes half the wall clock. This is Amdahl’s law applied to RL, and it should temper any comparison based on raw simulation FPS.

Contact is the hard part

Rigid-body contact is what makes robot simulation expensive and fragile. A solver must find forces that prevent interpenetration, obey friction cones and respect joint limits, simultaneously, every substep. MuJoCo solves a convex relaxation of the contact problem, which gives smooth, stable behavior and explains its popularity in control research. PhysX, the default Isaac backend, uses a different formulation and a projected Gauss-Seidel family of solvers on the GPU. The practical consequence is that the same URDF can behave differently across engines: friction, damping and actuator models do not map one-to-one.

There is also a static-shape problem on the JAX side. The Playground authors note that JAX requires arrays of fixed shape, so MJX computes contact work proportional to the number of possible contacts rather than active ones. They also report just-in-time (JIT) compilation of one to three minutes on Playground tasks, and point to Warp and Taichi as alternatives that avoid the static-shape constraint. That observation is part of why MuJoCo Warp exists.

The Three Contenders in Detail

Genesis

Genesis presents itself as a physics platform for robotics and embodied AI, bundling a physics engine, a robotics simulator, a rendering system and a planned generative data engine. As of the project page I checked, only the physics engine and simulation platform are open source (Apache 2.0); the generative framework is described as being rolled out gradually.

Its distinguishing technical feature is breadth of physics. The documented solvers cover rigid bodies, material point method (MPM), smoothed particle hydrodynamics (SPH), finite element method (FEM), position-based dynamics (PBD) and a stable-fluids solver, with coupling between them. Backends include CPU, NVIDIA and AMD GPUs and Apple Metal across Linux, macOS and Windows. Installation is pip install genesis-world on Python 3.10 to 3.13 after installing PyTorch. Differentiability currently covers only the MPM and Tool solvers, with others listed as planned.

The headline claim is “over 43 million FPS when simulating a Franka robotic arm with a single RTX 4090”, described as 430,000 times faster than real time. The arithmetic is internally consistent: 43 million frames per second at a 10 ms step is 430,000 simulated seconds per wall-clock second. What the project page does not give, in the text I read, is the batch size, contact density, whether the arm was interacting with objects, or whether rendering and policy inference were included. A Franka alone in free space with few contacts is an easy workload. Treat this number as an upper bound on what the kernel can do, not as a prediction for your task.

The latest release I could verify from the project’s README is v0.3.0, dated 2025-08-05. I could not retrieve a later release listing in this run, so check the repository for newer versions before pinning one. Maturity also deserves scrutiny: several associated papers are listed as under submission, and I found no peer-reviewed sim-to-real hardware study for Genesis comparable in scope to the Playground paper. That is an absence of evidence in what I could verify, not proof that none exists.

MuJoCo Playground

MuJoCo Playground, by Zakka, Tabanpour, Abbeel, Tassa and colleagues from UC Berkeley, Google DeepMind, Toronto and Cambridge, is built on MJX and installed with pip install playground. It ships environments for DM Control suite tasks, quadrupeds, humanoids, dexterous hands and arms, with reference training scripts, mostly using Brax PPO and SAC, and with RSL-RL as an alternative that the authors found gave comparable results on Go1.

Its strength is the evidence trail. The paper documents hardware transfers with numbers:

Unitree Go1: joystick policy trained in about 5 minutes on 2x RTX 4090 on flat ground, then fine-tuned for rough terrain; handstand, footstand and fall-recovery policies transferred without extra fine-tuning.
Berkeley Humanoid: flat-ground policy in under 15 minutes.
Unitree G1 (29 DoF) and Booster T1 (23 DoF): under 30 minutes each on 2x RTX 4090, with zero-shot stable walking and turning on indoor floors.
LEAP hand cube reorientation: under 30 minutes on 2x RTX 4090; over 10 trials the median was 3.5 consecutive rotations and the mean 7.1, with a range of 1 to 27.
Franka non-prehensile block reorientation: 10 minutes on 16x A100; over 35 hardware trials the median success was 100 percent and the mean 85.7 percent with a standard deviation of 12.2 points.
Vision-based Franka pick-cube: a 64×64 RGB policy trained in 10 minutes on one RTX 4090, with 100 percent success in 12 real trials and up to 250 ms of randomized gripper delay.

Notice the honesty of the dexterous result: a mean of 7.1 rotations with a range of 1 to 27 is a high-variance outcome, and the authors attribute failures to the cube wedging between fingers and palm. Also notice the small trial counts (10, 12, 35). Those are credible demonstrations, not statistically tight reliability estimates.

The paper also reports that LeapCubeReorient took about 2,080 seconds on one RTX 4090 versus about 670 seconds on 8x H100, roughly a threefold reduction with identical hyperparameters. Hardware scaling is thus real but sublinear: eight H100s bought about 3x, not 8x.

The framework’s declared limitations are specific: one to three minutes of JIT compile time, contact cost scaling with possible rather than active contacts, and vision training with the Madrona batch renderer described as early stage. The newer path is MuJoCo Warp, maintained by Google DeepMind and NVIDIA as part of Newton. Its README lists unsupported features, including the PGS solver and the IMPLICITFAST integrator, flags flex deformables as experimental, and states that differentiability through Warp is not yet available. It also says JAX users can reach MuJoCo Warp through MJX.

Isaac Lab

Isaac Lab is NVIDIA’s open-source robot learning framework, historically built on Isaac Sim and PhysX with RTX rendering and USD scene description. It has the largest ecosystem: many robot assets, sensors (cameras, ray casters, IMUs, contact sensors), teleoperation tooling and integration with several RL libraries.

The release situation changed in early 2026. A development update posted on 2026-01-06 announced that the main branch would freeze and development move to a develop branch supporting both PhysX and Newton, with multi-renderer support. The release notes I fetched on 2026-11-02 show the 3.0 line in beta: v3.0.0-beta, then beta2, then beta2.patch1, which updates to Isaac Sim 6.0.1. The last release on the former main line was v2.3.2, and v2.3.0 was built on Isaac Sim 5.1.

Version 3.0 introduces multi-backend physics (PhysX as default, Newton, and an experimental OVPhysX), three renderers (Isaac RTX, OVRTX and Newton Warp), and visualizers (Kit, Newton, Rerun and Viser). Data properties are Warp-native, with conversion to PyTorch via wp.to_torch(). Two breaking changes matter for anyone with existing code: quaternion order moves from WXYZ to XYZW, and write methods split into _index and _mask variants. Python is pinned to 3.12 and PyTorch to 2.10.0 in beta2. The Newton backend runs in “kit-less” mode without Isaac Sim, but it is still under active development and some features, including surface gripper workflows, remain backend-specific or unsupported.

The development update also says decoupling from RTX rendering opens support for more recent NVIDIA compute GPUs such as H100, H200 and B200. For practitioners, the sharpest takeaway is that Isaac Lab 3.0 is still beta in the notes I read, so a production pipeline should pin a version and budget migration time.

Head-to-Head: What Differs and What Matters

The three projects look similar from a distance and diverge sharply on four axes: physics core, programming model, rendering, and evidence of real-world transfer.

Physics core and programming model

Genesis compiles its own kernels from Python, so adding a solver or modifying contact logic is a Python-level exercise. Its PyTorch-friendly interface suits teams that already write policies in PyTorch. MuJoCo Playground inherits MJX’s functional JAX style: environments are pure functions of state, which makes jit and vmap natural, and JAX users get multi-device scaling almost for free. The cost is the JIT latency and static-shape contact cost mentioned earlier. Isaac Lab leans on PyTorch tensors and, in 3.0, Warp arrays, with a manager-based or direct environment API.

A small, flagged-as-untested sketch shows the Genesis flavor of batching. The calls below follow the project’s documented Python API as I recall it; verify names against the current docs before use.

# UNTESTED sketch -- check against current Genesis docs
import genesis as gs

gs.init(backend=gs.gpu)
scene = gs.Scene(show_viewer=False)
scene.add_entity(gs.morphs.Plane())
franka = scene.add_entity(
    gs.morphs.MJCF(file="xml/franka_emika_panda/panda.xml")
)
scene.build(n_envs=4096)   # 4096 parallel worlds on one GPU
for _ in range(1000):
    scene.step()

The Isaac Lab equivalent is a task registered under a gym ID and launched through its unified entry point; the 3.0 notes describe train and play commands that dispatch across rsl_rl, rl_games, skrl, sb3 and rlinf. Playground’s flow is the reverse of both: load a registered environment, jit its reset and step, and hand them to Brax PPO.

Rendering and perception

Vision is the largest practical split. Playground’s Madrona batch renderer offers a CUDA ray tracer and a Vulkan rasterizer, with lighting, shadows and textures, but the paper itself calls vision-based training early stage. Isaac Lab inherits RTX rendering, which is far richer in materials and sensors, and 3.0 adds OVRTX and a Newton Warp renderer. MuJoCo Warp’s README describes a batch ray-tracing renderer supporting meshes, textures, heightfields and Gaussian splats, with “millions of frames per second” claimed on NVIDIA GPUs and benchmark scenes run nightly; no specific figures appear on the page, so treat the claim as unquantified. Genesis lists a rendering system, but I found no published throughput comparison for batched camera observations.

Soft bodies, fluids and cloth

If your task involves granular material, liquids, cloth or soft grippers, Genesis’ multi-solver design is the differentiator on paper. Newton, and therefore Isaac Lab’s Newton backend, also lists MPM for granular and deformable materials, cloth and rigid bodies, but the Isaac Lab notes say deformable support is still being filled in. MJX and MuJoCo Warp are strongest for articulated rigid bodies, with experimental flex deformables in Warp.

Reading Throughput Claims Without Being Fooled

Throughput numbers are the most quoted and least comparable figures in this field. Four variables dominate, and any claim that omits them cannot be compared to another.

First, what is being stepped. A Franka in free space is trivial; a humanoid with 29 degrees of freedom and many foot-ground, hand-ground and self contacts is orders of magnitude harder. The Playground paper’s own data show a more than 20x physics cost gap between cart-pole and Franka environments.

Second, what the FPS counts. Physics substeps per second, control steps per second and rendered frames per second differ by large factors. If a controller runs at 50 Hz with four substeps, a “physics FPS” number is four times the policy-step rate.

Third, batch size and GPU occupancy. Throughput typically rises with the number of environments until the GPU saturates, then flattens. A number quoted at 30,000 environments may not be reachable at the 1,024 you can afford once you add cameras.

Fourth, what else is in the loop. Rewards, resets, observation computation, domain randomization writes and policy inference all take time. As the earlier Playground breakdown shows, the learner can consume more than half the wall clock.

A worked sanity check

Take the Genesis claim at face value: 43 million frames per second. Suppose, hypothetically, a locomotion task in which each policy step requires 4 physics substeps, and suppose the engine reached only one tenth of its headline speed on a contact-rich legged robot. That would be 4.3 million substeps per second, or about 1.08 million policy steps per second. Collecting a billion steps would take roughly 930 seconds, about 15.5 minutes, before counting policy updates. This is a thought experiment built on stated assumptions, not a Genesis measurement. Its purpose is to show that even a tenfold haircut on a headline number remains useful, and that the question to ask is how much haircut your own task deserves. Run your task, measure, and compare.

Benchmark methodology checklist

When you benchmark candidates for your own robots, hold these constant: the same robot model converted faithfully (masses, inertias, joint limits, actuator gains), the same control rate and substep count, the same observation set, the same reward, the same PPO hyperparameters, identical GPU and driver, warm-up excluded, JIT or kernel compile time reported separately, and at least five random seeds. Report both steps per second and wall-clock to reach a fixed return threshold. The second metric captures solver differences that change learning dynamics, such as softer contact making a task easier or harder to learn.

Sim-to-Real: What the Evidence Supports

Speed is a means. The goal is a policy that works on metal. Figure 2 shows the loop that every one of these frameworks supports, with the simulator choice affecting only part of it.

Figure 2: The sim-to-real loop. Randomized parallel training produces a checkpoint, a holdout test with unseen parameters estimates the gap, and real-robot failures feed back into wider ranges or a corrected model.

Domain randomization is what moves the needle

Playground’s vision example is instructive. The 64×64 RGB pick policy used domain randomization over lighting, shadows, camera pose and colors, plus up to 250 ms of stochastic gripping delay, and it reached 100 percent in 12 hardware trials. The delay randomization matters: real actuators and communication stacks have latency, and a policy trained on instantaneous torque commands often oscillates on hardware. For a deeper treatment of ranges, curriculum and system identification, see our sim-to-real and domain randomization article.

Actuator and contact models decide transfer more than the engine

Most failed transfers I have seen documented trace to actuator modeling, not solver choice. A position-controlled servo with a current limit, gear backlash and a communication delay behaves very differently from an ideal PD joint. Isaac Lab ships explicit actuator models; in MuJoCo-based stacks you tune kp, kv, force limits and damping in the MJCF. Whichever framework you use, identify the real actuator by logging commanded versus measured joint positions and fitting gain, delay and saturation. Compliance matters too; if your hardware relies on force or impedance behavior, see our primer on impedance and admittance control for compliant manipulation for what the simulator must model and what the real controller will add.

Zero-shot transfer is the exception to plan against

The Playground humanoid results (G1 and T1 walking and turning zero-shot on indoor floors) are striking, but they involve well-characterized commercial robots with good proprioceptive sensing and small command spaces. Dexterous in-hand manipulation shows the other end: LEAP’s mean 7.1 rotations with a 1-to-27 range is a working but unreliable result. Plan for iteration on hardware, a safety-limited first deployment, and a logging pipeline that captures state and action at control rate so you can replay and diagnose failures.

Figure 3: A decision flow. Vision at scale and USD workflows point to Isaac Lab, JAX-native teams to Playground, and soft-body or multi-physics needs to Genesis.

Decision Matrix

The matrix below reflects the evidence I could verify on 2026-11-02, with ratings that are my judgment, not measurements.

Criterion	Genesis	MuJoCo Playground	Isaac Lab
Physics breadth	Rigid, MPM, SPH, FEM, PBD, fluids with coupling	Rigid-body focus; MJX and MuJoCo Warp	PhysX default; Newton backend adds MPM, cloth
Published hardware sim-to-real evidence	Not found in my review	Extensive, with trial counts (Go1, humanoids, LEAP, Franka)	Large body of community and NVIDIA work; ecosystem-wide
Vision and sensor rendering	Rendering system exists; batched throughput unverified	Madrona, described as early stage	Mature RTX; 3.0 adds more renderers
Programming model	Python kernels, PyTorch interop	JAX functional, jit and vmap	PyTorch and Warp tensors
Maturity signal	v0.3.0 (2025-08-05) verified; newer unknown	Paper plus open recipes	3.0 in beta; 2.3.x stable line
License	Apache 2.0 (source)	Apache 2.0 family	Open source; check repo license
Hardware	NVIDIA, AMD, Apple Metal, CPU	NVIDIA GPU or TPU via JAX	NVIDIA GPUs
Best for	Soft-body and multi-physics research, cross-platform	Fast rigid-body RL with documented transfer	Production pipelines needing sensors, USD and tooling

The license cells for Playground and Isaac Lab are stated loosely because I did not verify exact license text for each in this run; check the repositories directly before relying on them.

Newton and the Convergence Story

The architectural story of 2026 is that two of the three contenders are converging on shared infrastructure. Newton’s MuJoCo Warp backend gives Isaac Lab a MuJoCo-family solver without Isaac Sim, and the MuJoCo Warp README names both Isaac Lab and mjlab as downstream users. In practice this means that a policy trained under Playground’s MJX and one trained under Isaac Lab’s Newton backend can share an actuator model and a contact formulation, narrowing a difference that previously forced teams to pick a physics worldview with their framework.

For decision-makers, this reduces lock-in risk. If you write assets in MJCF and keep rewards and observation logic modular, moving between MJX, MuJoCo Warp and Isaac Lab’s Newton backend becomes a porting task rather than a rewrite. The Isaac Lab notes still caution that Newton is under active development, so treat that portability as a direction of travel, not a guarantee.

Deeper Look: A Training Run from Reset to Deployment

Figure 4 traces one full cycle at the data level, which is where bugs hide.

Figure 4: One training cycle. The trainer resets N environments with randomized parameters, steps them in a loop with tensors resident on the GPU, runs a PPO update, then deploys the frozen policy and logs real rollouts for gap analysis.

On reset, the trainer writes randomized friction, mass, gains and delays into batched state. This is cheap on GPU but easy to get wrong: a common bug is randomizing parameters only at construction, so every episode in a long run sees the same world. During the stepping loop the policy emits actions, the simulator applies them through the actuator model, substeps contacts and integrates, and returns observations and rewards without leaving device memory. The PPO update consumes the whole rollout buffer. Deployment freezes the network, usually exports it as a TorchScript or ONNX graph (or a JAX-exported equivalent), and runs it at the training control rate.

Three timing details deserve attention. First, observation noise and latency in simulation should match hardware: if your real state estimator introduces 20 ms of delay, simulate it. Second, the policy rate must match: a policy trained at 50 Hz and run at 100 Hz will see velocities and histories it never trained on. Third, resets in a batched simulator are asynchronous, so environments end at different times; reward bookkeeping must handle partial resets correctly, or learning silently degrades.

Trade-offs, Gotchas, and What Goes Wrong

Headline speed hides the learner bottleneck. As the Playground breakdown showed, once physics costs 43 percent or less of the loop, a faster simulator yields diminishing returns. Profile before you migrate. If CNN updates dominate, buy a faster GPU for the learner or shrink the network rather than change simulators.

Hardware scaling is sublinear. The same paper’s LeapCubeReorient run took about 2,080 seconds on one RTX 4090 and about 670 seconds on 8x H100. Roughly 3x for eight datacenter GPUs is a reminder that communication, synchronization and the serial parts of PPO cap scaling. Budget accordingly.

Version churn is real. Isaac Lab 3.0 changes quaternion ordering from WXYZ to XYZW and splits write methods into index and mask variants. A silent quaternion convention mismatch between a simulator, a state estimator and a controller produces policies that look fine in simulation and fall over instantly on hardware. Write an explicit unit test that rotates a known vector through every frame boundary.

Model fidelity is not engine fidelity. Converting a URDF to MJCF or USD can drop or reinterpret inertias, collision meshes, joint damping and armature. Compare simulated and real free-swing responses before training anything. A policy that exploits a missing joint friction term will exploit it on the robot too, and the robot will pay for it.

Reward hacking scales with compute. When you can run a billion steps in minutes, optimizers find every loophole in your reward and every numerical artifact in the contact solver: vibrating feet that gain energy, penetration that generates thrust, or exploiting a coarse collision mesh. Inspect rollouts visually and with logged contact forces, not just returns.

Non-determinism and seeds. GPU reductions are often non-deterministic, so two runs with the same seed can diverge. Evaluate with many seeds and report intervals, as the Playground paper does with five seeds on DM Control tasks.

Portability limits. MuJoCo Warp lists unsupported features such as the PGS solver and certain actuator and sensor plugin types. Genesis differentiability covers only MPM and Tool solvers. If your method needs differentiable rigid-body dynamics, check support before committing; I did not find a verified answer for Genesis rigid-body gradients in this run.

Not every problem is an RL problem. For well-modeled, constrained tasks, optimization-based control often beats learned policies on safety and sample efficiency. A GPU simulator can still help by validating a controller across thousands of parameter perturbations. See our article on model predictive control with digital twins for where constraint-aware control fits.

Practical Recommendations

Start from the task, not the logo. If you are doing fast rigid-body locomotion or manipulation research and want a documented path from simulation to hardware, MuJoCo Playground has the strongest published evidence in this comparison, with trial counts and honest failure analysis. If you need camera sensors, USD scenes, a large asset library and a vendor-backed toolchain for a product pipeline, Isaac Lab is the safer choice, as long as you pin a version and treat 3.0 as beta until the release notes say otherwise. If your research involves soft bodies, fluids, cloth or cross-platform development (including AMD GPUs and Apple Silicon), Genesis is the one to prototype in, but demand your own benchmarks and expect to do more validation work yourself.

For teams hedging, keep robot descriptions in MJCF or URDF, isolate reward and observation code from the simulator API, and watch Newton: it is the layer most likely to reduce switching cost. Also remember that a policy algorithm choice interacts with simulator speed; if you experiment with newer group-based or verifiable-reward methods, our explainer on GRPO and RLVR covers the mechanics, though those techniques originated in language models and need adaptation for continuous control.

A short checklist for your first two weeks:

Reproduce one published locomotion result in your chosen framework before touching your own robot.
Convert your robot model and compare free-swing, step-response and contact-drop tests against hardware.
Log real actuator command versus measured position and fit gain, delay and saturation.
Randomize friction, mass, center of mass, latency and observation noise per episode, not per run.
Benchmark on your task: steps per second, time to a fixed return, five or more seeds.
Add a hardware safety layer (torque, velocity and position limits) before the first deployment.
Pin simulator, driver, CUDA and Python versions in a container.

Frequently Asked Questions

What is the Genesis simulator?

Genesis is an open-source (Apache 2.0) physics platform for robotics and embodied AI that combines rigid-body, MPM, SPH, FEM, PBD and fluid solvers behind a Python interface. It runs on NVIDIA and AMD GPUs, Apple Metal and CPU. The project claims over 43 million FPS for a Franka arm on one RTX 4090, a figure published without full methodology, so validate speed on your own workload.

Is MuJoCo Playground faster than Isaac Lab?

There is no fair published head-to-head I could verify. Playground reports minutes-scale training on specific tasks, such as about five minutes for a Go1 joystick policy on two RTX 4090s, while Isaac Lab results depend on task, backend and hardware. Compare them yourself using identical robots, control rates, rewards and seeds, and report time to a fixed return rather than raw frames per second.

Can Isaac Lab use MuJoCo physics?

Yes, in the 3.0 line. Isaac Lab adds a Newton physics backend, powered by MuJoCo Warp, alongside PhysX as the default. The release notes describe a kit-less mode that runs without Isaac Sim, but also say Newton is under active development and some features remain backend-specific or unsupported. Check the notes for your version before relying on it.

Do policies trained in these simulators transfer to real robots?

They can. The Playground paper documents hardware transfer on Go1, Berkeley Humanoid, Unitree G1, Booster T1, a LEAP hand and Franka arms, including a median 100 percent success over 35 Franka trials. Results vary: the LEAP cube task averaged 7.1 rotations with a range of 1 to 27. Domain randomization and accurate actuator models matter more than the simulator brand.

Which GPU do I need for GPU robot simulation?

The Playground results used consumer RTX 4090s for most tasks, with 16x A100 for one manipulation run, so a single modern NVIDIA GPU is enough to start. More memory allows more parallel environments. Genesis also lists AMD and Apple Metal backends. Isaac Lab targets NVIDIA hardware, and its development notes mention H100, H200 and B200 support through decoupling from RTX rendering.

Should I wait for Newton to stabilize before choosing?

Not necessarily. Build assets in portable formats and keep task logic separate from the simulator API, then start now with whichever framework fits your use case. Newton is converging infrastructure across MuJoCo Warp and Isaac Lab, so portability should improve. But Isaac Lab 3.0 is beta in the notes I read, so avoid betting a production schedule on unreleased behavior.

Genesis vs MuJoCo Playground vs Isaac Lab: GPU Robot Simulation for Sim-to-Real (2026)