Genesis (simulator)
Last reviewed
May 16, 2026
Sources
10 citations
Review status
Source-backed
Revision
v1 ยท 3,654 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
May 16, 2026
Sources
10 citations
Review status
Source-backed
Revision
v1 ยท 3,654 words
Add missing citations, update stale details, or suggest a clearer explanation.
Genesis is an open-source, generative physics simulation platform for robotics and embodied AI, released on December 19, 2024 after a roughly 24-month collaboration involving more than 20 academic and industrial research labs. The project was led by Zhou Xian, a robotics PhD candidate at Carnegie Mellon University advised by Katerina Fragkiadaki, with co-authors and contributors from MIT, Stanford, NVIDIA, Tsinghua University, Imperial College London, Georgia Tech, the University of Pennsylvania, the University of Hong Kong, IBM Research, and several other institutions. Genesis pitches itself as three things rolled into one piece of software: a from-scratch universal physics engine, a fast pythonic robotics simulator, and a generative data engine that can turn natural-language prompts into simulation-ready scenes and trajectories.
The headline numbers that drove the launch were unusually loud for a simulator release. Genesis claimed up to 43 million frames per second on a Franka manipulation scene with a single NVIDIA RTX 4090, which the authors converted into a real-time-equivalent figure of roughly 430,000 times faster than reality. The team also reported training a locomotion policy that transferred to a real robot in about 26 seconds on the same GPU, and solving inverse kinematics for 10,000 robot arms in parallel in under two milliseconds. Those claims attracted huge attention on social media in the days after the December 2024 release, alongside a wave of follow-up benchmarking from third parties that produced a more nuanced picture of where Genesis is fast and where it is not.
Genesis is distributed under the Apache 2.0 license, written entirely in Python with Taichi as its underlying compiler and runtime, and supports Linux, macOS, and Windows on NVIDIA GPUs, AMD GPUs, Apple Metal, and CPU backends. The physics engine and most simulation tooling were open-sourced at launch, while the generative engine, which the team calls the .generate() API, was announced as a staged future release with reduced or no public access at the time of the announcement. The result is a project that sits in an interesting place: a polished, ambitious open-source simulator with a growing user community, real adoption in academic robot-learning work, and a credible critique track record that has pushed the team to tighten its benchmarks and claims.
Physics simulators have been one of the quiet bottlenecks of modern robotics research. Most of the recent progress in reinforcement learning for legged locomotion, dexterous manipulation, and humanoid control has come from massively parallel simulation on GPUs, where thousands of robot instances run in lockstep to produce enough data for policy gradients to converge. The dominant tools in this space before Genesis are well known. MuJoCo, originally developed by Emo Todorov, became the de facto reference engine for contact-rich rigid body simulation after DeepMind acquired it and re-released it under an open-source license; its JAX-based variant MJX brought GPU acceleration to the same API. NVIDIA Isaac Gym, and later NVIDIA Isaac Lab, pushed end-to-end GPU simulation into mainstream robot learning. PyBullet, Gazebo, Brax, ManiSkill, and SAPIEN each carved out their own niches around realism, parallelism, sensor fidelity, or developer ergonomics.
The pain points that drove the Genesis project are recognizable to anyone who has tried to build a research codebase on these tools. Most simulators specialize: one is good at rigid-body contact but poor at deformables, another is fast on GPU but only supports a narrow set of joint types, a third has photorealistic rendering but compiles slowly and depends on a heavy C++ build system. Cross-physics scenarios such as a robotic gripper picking up cloth, or a fluid pouring over a soft object, often require stitching multiple simulators together or accepting reduced fidelity. Differentiable physics, which is increasingly important for trajectory optimization and system identification, is supported only patchily across the ecosystem. And the API surface is fragmented enough that switching simulators is a real engineering project, not a configuration change.
The Genesis team set out to address those pain points with a single design bet: rebuild everything from scratch, in Python, on top of Taichi for GPU compilation, and unify rigid bodies, soft bodies, fluids, cloth, and other phenomena under one solver framework. The argument, paraphrased from the project page and the launch thread by Zhou Xian, is that a unified pythonic engine can be both faster than existing GPU stacks and simpler to use, and that this combination is what unlocks the next stage of generative data for embodied AI. Whether Genesis fully delivers on the speed half of that promise is a question that benchmarks are still settling. The accessibility half is easier to evaluate, and the consensus among early users is that installation and API ergonomics are genuinely better than the alternatives.
The Genesis project page lists numbered affiliations next to author names, and coverage in IEEE Spectrum, MarkTechPost, and other outlets has consistently described the collaboration as involving more than 20 labs. The table below lists institutions explicitly identified on the project page or in the launch announcement by Zhou Xian. It is not exhaustive, since some affiliations cover multiple labs within the same university.
| Institution | Country | Notes |
|---|---|---|
| Carnegie Mellon University | United States | Lead institution; Robotics Institute; Zhou Xian's PhD home |
| MIT (including CSAIL) | United States | Multiple authors |
| Stanford University | United States | Multiple authors |
| NVIDIA | United States | Industry contributor; Jim Fan among contributors |
| Tsinghua University | China | Multiple authors |
| Imperial College London | United Kingdom | Robotics contributors |
| Georgia Institute of Technology | United States | Robotics and ML contributors |
| University of Pennsylvania | United States | GRASP Lab affiliation |
| University of Hong Kong | Hong Kong SAR | Robotics contributors |
| Columbia University | United States | Multiple authors |
| University of Maryland | United States | Multiple authors |
| University of Utah | United States | Graphics and physics contributors |
| University of Washington | United States | Robotics contributors |
| University of Michigan | United States | Robotics contributors |
| University of Texas at Austin | United States | Robotics contributors |
| IBM Research | United States | Industry contributor |
| Liquid AI | United States | Industry contributor |
| Taichi Graphics | China | Maintainers of the underlying Taichi compiler |
The spread of institutions is notable for two reasons. First, it reflects a deliberately international and academic-led release, in contrast with simulators like Isaac Lab that are anchored to a single vendor's hardware and software stack. Second, the inclusion of Taichi Graphics, the company behind the Taichi DSL that Genesis is built on, signals that the project is tightly coupled to that ecosystem rather than being a thin wrapper over an existing C++ engine. The downstream consequence is that the long-term health of Genesis depends partly on the long-term health of Taichi.
Genesis is structured as a Python package with a unified scene abstraction at the top level and a set of pluggable physics solvers underneath. A user writes simulation code that looks roughly like other Python robotics libraries: import the package, create a scene, add entities with chosen materials and geometry, attach sensors or cameras, build, and step. The implementation behind those calls is where the project diverges from prior simulators.
The back-end is written using Taichi, a domain-specific language embedded in Python that compiles to GPU kernels at runtime. Taichi handles the heavy lifting of generating CUDA or Metal code from high-level Python definitions, which lets the Genesis authors keep the entire codebase in Python without paying a typical interpreter tax. The same code path runs on NVIDIA GPUs, AMD GPUs through HIP, Apple Metal on macOS, and CPU via Taichi's CPU backend, with no separate C++ build required. Installation reduces to a pip install genesis-world command for most users, which is genuinely unusual in this space, where compiling MuJoCo bindings or Isaac Gym's dependencies has historically been a meaningful onboarding cost.
On top of Taichi, Genesis integrates several physics solvers in a single simulation loop. Rigid body dynamics use an articulated body solver with optimized collision detection, contact island management, and an auto-hibernation mechanism that freezes objects when they are at rest to save compute. Deformable simulation uses the Material Point Method, which is well-suited to large-deformation phenomena like soft tissue and snow, and which the team highlights as the first solver to support differentiability inside Genesis. Smoothed Particle Hydrodynamics, Position-Based Dynamics, the Finite Element Method, and a stable fluid solver round out the supported phenomena. The rendering layer is a path-traced renderer designed for photorealistic camera output, with an emphasis on view-consistent video generation for training perception models.
Differentiable physics is a design goal rather than a uniform feature. At the December 2024 launch, the MPM solver and a tool solver supported differentiability end-to-end, while the rigid body solver did not. The roadmap promised differentiability for the remaining solvers in subsequent versions, with rigid body cited as the next target. By the v0.4 series in early 2026, the engine had matured significantly and gained additional solver coverage and stability fixes; the project's documentation tracks 23 releases across that timeline.
The generative engine sits on top of all of this and is the most distinctive piece. The idea, presented in the launch thread and the project page, is that natural-language prompts can be turned into fully simulated 4D scenes: a kitchen with a robot arm pouring water into a cup, a humanoid walking through a forest, a quadruped traversing a sandy hill. Under the hood, the team describes a pipeline that combines vision-language models for scene proposal, asset retrieval and generation, layout sampling, physics-aware refinement, and task specification. At launch this pipeline was demonstrated through curated videos and was not fully open-sourced. The accompanying public release covered the physics engine, the simulation API, and the rendering layer.
Genesis advertises a long list of supported materials and phenomena, with the explicit goal of avoiding the multi-simulator workflows that researchers often have to assemble manually. The table below summarizes the headline physics capabilities and the solvers responsible for them.
| Capability | Solver | Notes |
|---|---|---|
| Articulated rigid body dynamics | Rigid body solver with auto-hibernation | Robot arms, legged platforms, vehicles |
| Cloth and thin shells | PBD and FEM | Garments, ropes, banners |
| Soft elastic and plastic bodies | MPM and FEM | Tissue, putty, foam, snow |
| Granular materials | MPM | Sand, gravel, powders |
| Liquids | SPH and a stable fluid solver | Pouring, splashing, low-viscosity flow |
| Smoke and gas | Stable fluid solver | Volumetric effects |
| Muscle-actuated soft robots | MPM muscle model | Soft robotics and biomechanics |
| Coupled rigid and soft | MPM with rigid coupling | Grippers grasping deformables |
| Character motion | Skeletal animation with physics | Humanoid characters and animals |
| Differentiable simulation | MPM and tool solver at launch | Other solvers planned |
| Photorealistic rendering | Built-in ray tracer | View-consistent video generation |
| Sensor simulation | Cameras and depth | Lidar and tactile planned in roadmap |
The practical implication is that scenarios that previously required custom couplings between rigid and soft simulators, such as a robot manipulating dough or a humanoid sitting on a deformable cushion, can be expressed in a single Python script. The fidelity of those coupled scenarios is still an open question for many use cases, since multi-physics coupling is hard and edge cases are common, but the API surface is unusually complete for an open-source release.
The headline performance numbers from the launch are worth listing precisely, because they shaped the initial reaction and the subsequent debate.
| Claim | Value | Conditions |
|---|---|---|
| Peak simulation FPS | 43 million | Single Franka arm scene, RTX 4090, minimal substeps |
| Real-time speedup | 430,000 times | Derived from peak FPS divided by real-time stepping |
| Locomotion training time | About 26 seconds | Sim-to-real-transferable policy, RTX 4090 |
| Parallel inverse kinematics | 10,000 arms in under 2 ms | Batched solve on a single GPU |
| Speedup over Isaac Gym and MJX | 10 to 80 times | Per-scene, varies by configuration |
| Speedup over CPU simulators | Substantially higher | Single-threaded CPU baselines |
The nuance came quickly. Stone Tao, a robotics researcher who maintains the ManiSkill benchmarks, published a detailed analysis showing that the 43 million FPS figure was achievable only under specific conditions: a single physics substep, disabled self-collisions, idle robot motion for most of the test, and aggressive object hibernation. Under more realistic settings with multiple substeps, active motion, and full collision checking, the throughput dropped to around 0.29 million FPS in his measurements, which put Genesis roughly on par with or slower than existing GPU simulators on equivalent workloads. He also reported that Genesis ran 3 to 10 times slower than SAPIEN-based ManiSkill on contact-rich manipulation, with some simulation instabilities such as cubes slipping through grippers.
The Genesis team responded with a more comprehensive report in January 2025 that reproduced several of the criticisms and refined the comparative numbers. The updated figures showed that the peak claim was specific to the minimal benchmark, with throughput around 27 million FPS once random actions were added, still high but not the universally applicable number that the launch had implied. The exchange is a reasonable case study in how to handle benchmarking critiques in an open-source project: the team neither retracted the original claim nor doubled down, but instead republished a more detailed methodology that lets users decide what is relevant to their workload.
Where Genesis appears genuinely strong is in workloads that match its assumptions: small, repetitive scenes with minimal contact complexity, where the Taichi back-end can keep the GPU busy and auto-hibernation can trim idle compute. Where it has been less competitive in early benchmarks is in heavy contact manipulation with high physics fidelity requirements, and in rendering-heavy pipelines where the path-traced output has not yet been optimized to the same level as Isaac Lab's RTX renderer.
Genesis is released under the Apache 2.0 license, the same permissive license used by TensorFlow and many other major open-source AI projects. Apache 2.0 allows commercial use, modification, and redistribution, requires preservation of copyright and license notices, and includes an explicit patent grant from contributors to users. For a robotics simulator that is likely to be embedded in commercial training pipelines, this license choice is meaningful, since restrictive or non-commercial licenses would have ruled out a significant fraction of the intended audience.
At the December 2024 launch, the team open-sourced the physics engine, the simulation platform, and the rendering layer. The generative .generate() engine, which produces scenes and trajectories from natural-language prompts, was held back and described as something the team planned to roll out in stages. By 2025 and into 2026, components of the generative pipeline began appearing in releases alongside ongoing solver improvements, although the full pipeline shown in the launch videos has not been fully reproduced as a single open-source artifact at the time of this writing.
A separate but related company, Genesis AI, was founded around the same group of contributors and announced a $105 million seed round in mid-2025 to commercialize a universal robot foundation model built on top of the simulator. The open-source Genesis project and the commercial Genesis AI company are distinct entities, although they share key people and code. This split mirrors the pattern of other AI infrastructure projects where an open core is maintained alongside a commercial offering.
Simulators are usually chosen for fit to a specific workflow, not as drop-in replacements for each other. The table below summarizes how Genesis compares to commonly used alternatives across criteria that matter in practice. The descriptions reflect each project's positioning in published documentation and third-party reviews; precise rankings on any single metric depend heavily on the scenario.
| Simulator | Language | Multi-physics | GPU parallelism | Differentiable | License |
|---|---|---|---|---|---|
| Genesis | Pure Python on Taichi | Rigid, soft, fluid, cloth, MPM, SPH, PBD, FEM | Yes, native | Partial, MPM and tool solver at launch | Apache 2.0 |
| MuJoCo and MJX | C++ with Python and JAX bindings | Rigid focus, limited soft | Yes via MJX | Yes via JAX | Apache 2.0 |
| NVIDIA Isaac Lab | Python on top of PhysX | Rigid focus, some deformables | Yes, native | No | BSD-3 plus NVIDIA EULA components |
| PyBullet | Python on top of Bullet | Rigid focus | Limited | Limited | Zlib |
| SAPIEN and ManiSkill | Python on PhysX | Rigid focus | Yes | No | MIT |
| Brax | JAX | Rigid focus | Yes | Yes | Apache 2.0 |
| Gazebo | C++ with Python bindings | Rigid focus, pluggable | Limited | No | Apache 2.0 |
A few observations follow from the table. Genesis is unusual in trying to be both fully multi-physics and fully pythonic; most alternatives accept one or the other. Its closest cousin in design philosophy is MuJoCo MJX, which similarly aims for differentiable GPU simulation with a familiar API, but MJX is anchored in rigid-body workloads and has a smaller multi-physics scope. Isaac Lab brings the strongest commercial backing and the deepest tooling for sensor simulation and rendering, at the cost of being tightly coupled to NVIDIA hardware and the broader Omniverse stack. PyBullet remains popular for teaching and prototyping but is no longer competitive on speed. Brax is the natural choice for teams that already live in JAX. ManiSkill on SAPIEN is currently a strong choice for contact-rich manipulation, particularly after the early Genesis benchmarks suggested some weaknesses in that exact regime.
No single simulator dominates across the board, and most serious robotics labs maintain familiarity with two or three. Genesis enters this landscape as a credible candidate for projects where multi-physics breadth and Python-first ergonomics outweigh raw rigid-body contact performance.
The initial reception in December 2024 was extraordinarily enthusiastic. The launch thread by Zhou Xian on X drew tens of thousands of likes and reposts within days, and the GitHub repository accumulated stars at a rate normally reserved for foundation model releases. MarkTechPost, Interesting Engineering, Yahoo News, and a long tail of substack newsletters covered the project, generally framing it around the 430,000-times-faster-than-reality claim and the open-source release of a multi-physics simulator with photorealistic rendering. Jim Fan from NVIDIA, one of the listed contributors, publicly noted that his contribution was a small part of the project, which was widely read as a signal that the work was substantively academic rather than a vendor-led release.
The technical reception was more mixed. Within a few weeks, Stone Tao's benchmarking analysis began circulating, alongside discussion in the robotics community about whether the headline FPS number was useful as a comparative metric. A common thread in this critique was that simulation throughput is meaningful only relative to a target physics workload, and that benchmarking choices in the original announcement had been generous to Genesis on dimensions like substep count and collision detection. The Genesis team's January 2025 response was generally seen as constructive, and subsequent releases have included more carefully labeled benchmark scripts.
Academic uptake has been steady rather than explosive. By 2025, Genesis was being used in papers on legged locomotion, soft-body manipulation, generative scene synthesis, and sim-to-real transfer for humanoid policies. The pythonic API and easy installation are repeatedly cited as reasons to choose Genesis for new projects, especially in groups that do not have dedicated robotics infrastructure engineers. At the same time, established labs with significant investment in Isaac Lab or MuJoCo pipelines have continued to use those tools for their main workloads, with Genesis used as a complementary option for specific scenarios.
Industry reception has split along similar lines. The standalone Genesis AI company, with its $105 million seed round announced in mid-2025, signaled that investors viewed the underlying technology as a credible foundation for a commercial robotics platform. At the same time, large robotics companies with their own simulation stacks, particularly NVIDIA-aligned shops using Isaac Lab and Omniverse, have continued to invest in those ecosystems. The result is a market with more, not fewer, viable simulators, and a healthy debate about which approach scales best for the next generation of robot foundation models.
The debate about Genesis is in many ways a debate about how to evaluate simulators in general. Throughput on a minimal benchmark is easy to measure and easy to misinterpret. Coverage of physics phenomena, accuracy under stress, sim-to-real transfer rates, and developer ergonomics are harder to put on a single chart. Genesis has helped surface those tensions in a public way, and the community is arguably better off for the resulting methodological scrutiny.