Isaac Lab vs MuJoCo vs ManiSkill vs Genesis For Policy Evaluation

The Short Answer

For robot policy evaluation, the simulator is usually chosen by the benchmark you need to report. LIBERO and RoboCasa run on MuJoCo through robosuite, SimplerEnv runs on SAPIEN and has a GPU-parallel port in ManiSkill3, and the RoboCasa, LIBERO and RoboLab-style task suites in Isaac Lab-Arena run on Isaac Lab. Beyond that, pick Isaac Lab when you need RTX ray-traced cameras and NVIDIA's evaluation tooling, MuJoCo when you need published-comparable LIBERO and RoboCasa numbers or CPU-only portability, ManiSkill3 when you want thousands of rendered environments per GPU on Linux, and Genesis when your tasks need deformables, fluids or non-NVIDIA hardware.

Versions move quickly, so everything below is current as of October 2026: Isaac Lab 3.0 Early Access (released September 16, 2026, with general availability targeted for the end of October 2026), MuJoCo 3.14.0 (September 22, 2026), ManiSkill 3.0.1 (April 21, 2026) and Genesis World 1.4.3 (September 30, 2026).

Feature Matrix

Every row below was checked against the project's own repository or documentation.

Why The Benchmark Usually Decides

A success rate means something only next to other success rates measured the same way. That requires the same task logic, the same assets, the same physics engine and version, and the same camera pipeline. If you want to say your policy beats a published LIBERO number, you need to run LIBERO where LIBERO runs, which is MuJoCo through robosuite.

Ports are useful, but they are new benchmarks. Lightwheel's RoboCasa tasks on Isaac Lab-Arena use higher-fidelity assets with refined collision geometry than the original MuJoCo version, according to Lightwheel's own performance study. That is an improvement for many purposes, and it also means a score on the port and a score on the original are not the same measurement.

Rendering conventions matter as much as physics. We found that the most widely used LIBERO training datasets store images mirrored relative to the simulated scene, a side effect of how MuJoCo returns OpenGL buffers and how conversion scripts corrected for it (the full write-up is here). Moving a policy between simulators multiplies the number of places a convention like that can drift.

Isaac Lab

Isaac Lab is NVIDIA's robot learning framework, built on Isaac Sim. Its full-featured workflows use PhysX for physics and RTX for rendering, and its TiledCamera sensor collects camera data from every parallel environment through a single render product, which is what makes rendered evaluation across thousands of environments practical (camera docs). The framework is described in Mittal et al., 2025.

Isaac Lab 3.0 Early Access changes the shape of the stack. It introduces one task API across multiple physics, rendering and visualization backends, selected at launch (physics=isaacsim_physx, physics=ovphysx or physics=newton_mjwarp, and renderer=isaacsim_rtx, renderer=ovrtx or renderer=newton_renderer), plus kit-less execution that does not install or launch Isaac Sim (release notes). Supported backend combinations remain task-specific.

The hardware constraint is the one that catches teams. Isaac Sim's requirements state that GPUs without RT cores, including the A100 and H100, are not supported, with a GeForce RTX 4080 as the minimum and an RTX 5080 recommended. If your cluster is H100s, RTX-rendered Isaac Lab evaluation needs separate hardware.

For evaluation specifically, Isaac Lab-Arena (Apache 2.0) is the layer to look at. NVIDIA co-developed it with Lightwheel, and it compiles environments from independent object, scene, embodiment and task blocks (NVIDIA Technical Blog). Lightwheel has built more than 250 tasks for it across the Lightwheel-RoboCasa-Tasks and Lightwheel-LIBERO-Tasks suites. The 0.3 alpha release on September 10, 2026 added 31 Kitchen Benchmark environments for DROID manipulation, 38 RoboLab-inspired tasks generated from natural-language prompts, environment variation sweeps, multi-node evaluation through OSMO, and a policy server for GR00T, pi0.5 or your own policy (release announcement).

Use Isaac Lab when you need photorealistic ray-traced cameras, you are evaluating on Isaac Lab-Arena tasks, your policy targets NVIDIA's GR00T stack, or you need large numbers of parallel rendered environments and have RTX hardware to run them.

MuJoCo, MJX And MuJoCo Warp

MuJoCo is the physics engine underneath most of the manipulation benchmarks VLA papers report. LIBERO pins robosuite 1.4.0, and RoboCasa uses robosuite 1.5. RoboCasa365, released February 18, 2026, has 365 tasks and more than 2,500 kitchen scenes. Both benchmarks step the standard MuJoCo library on CPU, so evaluation throughput comes from running many processes rather than from GPU parallelism.

MuJoCo's documentation states that its simulation pipeline is entirely deterministic, with the caveat that exact reproducibility is only guaranteed within a single version and on the same architecture (computation docs). For evaluation that is a useful property, because a run on a fixed version and machine type can be repeated exactly.

The GPU side of MuJoCo has grown into three related projects:

• MJX provides a JAX API for MuJoCo. Its JAX implementation runs on NVIDIA and AMD GPUs, Apple Silicon and Google Cloud TPUs, and it can also use MuJoCo Warp as a backend.
• MuJoCo Warp is a GPU implementation for NVIDIA hardware, maintained by Google DeepMind and NVIDIA as part of the Newton project. It includes a GPU batch renderer that ray-traces MuJoCo scenes across many parallel worlds. It is also the physics behind Isaac Lab 3.0's Newton backend.
• MuJoCo Playground is a suite of GPU-accelerated environments built with MJX, covering dm_control classics, quadruped and biped locomotion, and non-prehensile and dexterous manipulation, with vision support through the MuJoCo Warp batch renderer.

mjlab sits between the two worlds. It pairs Isaac Lab's manager-based API with MuJoCo Warp under Apache 2.0, and needs an NVIDIA GPU for training.

The catch for policy evaluation is that LIBERO and RoboCasa have not moved to these GPU backends in their official releases. MJX and MuJoCo Warp make new GPU-native tasks fast, but they do not speed up the existing benchmarks unless someone ports them.

Use MuJoCo when you need numbers comparable with published LIBERO or RoboCasa results, you want bit-exact repeatability on a fixed version, or you need to run on CPUs, Macs or non-NVIDIA accelerators. Use MJX or MuJoCo Warp when you are writing new GPU-parallel tasks and want to stay in the MuJoCo model format.

ManiSkill3

ManiSkill3 is built on SAPIEN, which runs PhysX on the GPU by placing every parallel environment in its own sub-scene of one shared physics scene. Its paper reports that simulation with rendering runs 10 to 1,000 times faster with 2 to 3 times less GPU memory than other platforms, reaching more than 30,000 FPS in benchmarked environments (Tao et al., 2024), and the README cites RGBD plus segmentation collection at more than 30,000 FPS on an RTX 4090. It also supports heterogeneous simulation, where every parallel environment has a different scene.

The platform limits are specific. GPU simulation works only on Linux with NVIDIA GPUs; Windows and macOS get CPU simulation and rendering, and WSL gets neither GPU simulation nor rendering. Rendering needs a Vulkan driver. The default shader is a rasterizer, and ray-traced shader packs (rt, rt-med, rt-fast) are available when you need more realistic images.

For evaluation, ManiSkill3's main draw is SimplerEnv, the real-to-sim benchmark for Google Robot and WidowX Bridge policies. The original SimplerEnv runs on SAPIEN and the CPU-based ManiSkill2, and its Bridge environments have been integrated into ManiSkill3 with GPU parallelization. ManiSkill describes its real-to-sim environments as evaluating real-world policies 100 times faster through GPU simulation. RoboTwin 2.0, a bimanual benchmark, also builds on SAPIEN directly.

Read the license before you build on it. Rigid body environments are Apache 2.0, but ManiSkill's assets are CC BY-NC 4.0, which rules out commercial use of those assets.

Use ManiSkill3 when you are evaluating on SimplerEnv, you want the highest rendered-environment throughput per GPU on a Linux NVIDIA machine, or you need every parallel environment to hold a different scene.

Genesis

Genesis World (Apache 2.0) is the broadest physics engine of the four. One scene can combine rigid, FEM, MPM, PBD and SPH particle, IPC and SAP solvers sharing one state, which matters for tasks involving cloth, food, liquids or soft objects. Its Quadrants compiler lowers Python kernels to CUDA, AMD ROCm, Apple Metal, Vulkan, x86 and ARM64, so the same scene code runs on NVIDIA, AMD and Apple hardware. Rendering comes through three camera sensor paths: Nyx, Genesis's in-house renderer for robotics, the Luisa ray tracer, and the Pyrender rasterizer.

The gap is benchmark coverage. None of LIBERO, RoboCasa or SimplerEnv run on Genesis natively, so evaluating on it today mostly means authoring your own tasks and success criteria. That is fine for internal evaluation and harder for results you want to compare with the literature.

Use Genesis when your tasks need deformable or fluid physics, you are not on NVIDIA hardware, or you are building a custom evaluation suite and do not need parity with published benchmark numbers.

Should You Evaluate On More Than One?

A policy that holds up across two physics engines and two renderers is a stronger result than one that holds up on one. Contact models, friction, solver tolerances and image pipelines all differ, and a policy that has overfit to one simulator's quirks tends to show it when moved. NVIDIA's own benchmarking research makes a related argument for measuring how well simulated performance predicts real performance rather than assuming it does (Yang et al., 2025).

The cost is integration work. Each simulator has its own observation format, action space conventions, camera conventions and reset semantics, and each benchmark defines success differently. Our guide on how to evaluate a VLA policy covers the reproducibility checklist that applies once you run more than one, and the companion post on evaluating robot policies in simulation at scale covers how to make the rollout counts affordable.

Where Manifold Fits

Manifold is Bifrost's robot policy evaluation platform. It runs one harness across NVIDIA Isaac Sim, Unreal Engine, MuJoCo, ManiSkill and Genesis, with native support for NVIDIA's Isaac Lab Arena, and covers academic benchmarks including LIBERO, LIBERO-Plus, RoboLab, RoboCasa, RoboMimic, CALVIN, SIMPLER, RoboTwin 2.0, RoboMemory and RLBench. Rollouts are sharded across GPUs, and every run gets a manifold:// URI that pins the policy checkpoint, simulator version, benchmark version and seeds, so a result on one simulator can be rerun exactly.

If you only need one simulator and already have a working harness, the open tooling above is enough. If you want the same policy scored on several of them without maintaining a harness per simulator, Manifold is in early access, and you can join the waitlist on the Manifold page.

Sources

• Isaac Lab: repository, 3.0 Early Access release notes, paper
• Isaac Sim: system requirements
• Isaac Lab-Arena: repository, 0.3 release, NVIDIA blog
• MuJoCo: repository, MJX docs, MuJoCo Warp, MuJoCo Playground, mjlab
• ManiSkill3: repository, paper, SimplerEnv
• Genesis World: repository
• Benchmarks: LIBERO, RoboCasa, RoboTwin 2.0
• Lightwheel: Isaac Lab-Arena performance study