# Genesis World: a Python physics platform for robotics simulation > Genesis World puts rigid bodies, FEM, MPM, SPH and PBD under one scene state and one Python API. It is aimed at robotics and embodied AI research, and the install path is a pip package with optional backends. **Genesis-Embodied-AI/genesis-world** — Simulation platform for general-purpose robotics & embodied AI learning. - Repository: https://github.com/Genesis-Embodied-AI/genesis-world - Website: https://genesis-world.readthedocs.io - Stars: 29,970 · Forks: 2,865 - Language: Python - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/genesis-embodied-ai-genesis-world ## What Genesis World is for Genesis World is a simulation platform for physical AI development. The README describes it as combining a unified multi-physics engine, a photo-realistic renderer called Nyx, and a cross-platform compiler called Quadrants behind a Pythonic simulation interface. The stated goal is to scale from a single laptop kernel to datacenter-grade GPUs while staying readable and embeddable in research code. The audience is narrow and identifiable. This is for people building robotics environments, machine learning pipelines, data generation runs, or agentic simulation, in Python. If your work is a game physics engine, a CAD tool, or a browser demo, the four-layer stack described in the README is more machinery than you need. The project was previously named Genesis, started as an academic project in December 2024, and its development is now supported by Genesis AI. ## One scene, one state, many solvers The architecture is the interesting part. The README names four layers inside a dashed box: Simulation Interface, Physics, Render, Compiler. Above them sits whatever you build; below sits whatever compute backend you have. The Physics layer is where the design differs from a typical engine. It integrates Rigid, FEM, MPM, Particle (PBD and SPH), uipc, an explicit coupler, and SAP, and the README states that all of them share one scene and one state. That is the mechanism behind the coupling examples in the repository: examples/coupling/ contains cloth on rigid, rigid plus MPM attachment, sand and wheel, SPH with MPM, and a cut-dragon demo. Sharing state is what makes a cloth-on-rigid scene a configuration problem rather than a data-transfer problem between two engines. The Render layer plugs three paths in as camera sensors: Nyx, which the README calls an in-house renderer designed for robotics; Luisa, a DSL ray tracer; and Pyrender, a rasterizer. The Compiler layer, Quadrants, lowers Python kernel code to CUDA, AMD ROCm, Apple Metal, Vulkan, x86, and ARM64, and carries the autodiff, GPU graph and fastcache machinery. The Simulation Interface handles asset parsing for URDF, MJCF, OBJ, GLB and USD, plus entity accessors, controllers, sensors, parallel and heterogeneous environments, and a GUI. The consequence of this layout is that portability comes from the compiler rather than from hand-written per-backend kernels. The cost is a dependency on Quadrants, pinned in pyproject.toml at quadrants==1.3.0. ## Installing Genesis World and running a first example The package is on PyPI as genesis-world. Python must be 3.10 or newer and below 3.14, per the requires-python field in pyproject.toml. A plain install gets the core: ```bash pip install genesis-world ``` For development work, the README says most scripts run end-to-end after an editable install with the dev extra, which is the path to use if you want the examples directory in front of you: ```bash pip install -e ".[dev]" ``` Demos that depend on optional backends need the extras listed in the README's Optional extras section. The README calls out the IPC and Nyx examples specifically. So the practical first run is a rigid-body demo, which is the least demanding category: ```bash python examples/rigid/franka_cube.py ``` That script sits under examples/rigid/ alongside the collision demos in examples/collision/. If a window opens and the cube behaves, your core install is sound. If it does not, the failure is almost always in the graphics stack rather than in the physics, because pyproject.toml pins pyglet with exclusions and PyOpenGL is required for the Pyrender path. Note that pyglet is constrained to >=1.5,!=2.1.8, and the comment in pyproject.toml explains that 2.1.8 breaks headless windowing used in the interactive viewer tests. If you are installing into an environment that already has pyglet 2.1.8, that is the first thing to check. ## Where the documentation stops The README is a catalogue, not a manual. It presents the demos in tables with thumbnails, organized into Physics, Rendering and Simulation Interface, and points to the readthedocs site for actual documentation. That is a reasonable split, but it means the repository front page tells you what exists rather than how to tune it. Concretely, the README does not document solver parameters, accuracy characteristics, or how to choose between MPM and SPH for a given material. It does not give performance numbers, and I have not run any benchmarks. The speed_benchmark directory exists in examples/, which suggests the project has its own measurement scripts, but the README does not present results from them. The dependency list also reveals how much surface area you are taking on. Beyond numpy and pydantic, pyproject.toml pulls in mujoco, trimesh, pymeshlab, numba, libigl, pycollada, pygltflib, xacro, av, moviepy, py-cpuinfo and psutil. Several carry pinned exclusions with comments explaining which version broke what. That is honest maintenance, but it also means a Genesis World install is a large environment, and conflicts with an existing robotics or graphics stack are plausible. The pyproject.toml comment that libigl 2.6.2 has no pre-compiled wheels on Windows is a specific example of a platform where the default resolution can fail. ## When Genesis World is the wrong tool If your problem is a single rigid-body arm picking up boxes, Genesis World is overkill. The multi-solver coupling that justifies its dependency footprint is not doing anything for you, and you would be carrying FEM, MPM, SPH and PBD code paths plus a compiler toolchain for no benefit. If you need deterministic, bit-reproducible results across machines, be careful. The Compiler layer targets CUDA, ROCm, Metal, Vulkan, x86 and ARM64, and the README does not claim that results are identical across those targets. Cross-backend numerical agreement is exactly the kind of thing the README would need to state explicitly, and it does not. If you need a stable API surface for a long-lived product, the release cadence is a consideration. The releases listed are v1.3.2 on 2026-08-07, v1.3.3 on 2026-08-13, and v1.4.0 on 2026-09-06, with the last push to the repository on 2026-09-10. That is a fast-moving project, which is good for feature velocity and awkward for pinning. The version in pyproject.toml is 1.4.1, ahead of the most recent release tag. Finally, if your team is not comfortable in a Python-plus-GPU environment, the setup burden is real. The optional extras for IPC and Nyx are separate installs, and the README does not document a rollback path if an extra breaks your environment. ## Genesis World compared with Isaac Sim The comparison people search for is Genesis World versus Isaac Sim, and the difference in approach is visible in the README without needing to run either. Isaac Sim is built around NVIDIA's Omniverse stack: USD as the scene description, PhysX for rigid-body physics, and an application layer that assumes NVIDIA hardware. Genesis World parses USD among other formats (URDF, MJCF, OBJ, GLB) but does not make it the center of the design, and its compiler targets AMD ROCm, Apple Metal, Vulkan, x86 and ARM64 in addition to CUDA. The second difference is solver breadth. Isaac Sim's physics is primarily rigid-body with some deformable support. Genesis World's Physics layer lists Rigid, FEM, MPM, Particle (PBD and SPH), uipc, an explicit coupler, and SAP sharing one scene and one state. If your research involves sand, cloth, soft bodies or their interaction with a robot, that breadth is the reason to look at Genesis World. If your work is locomotion and manipulation on rigid bodies, the extra solvers are weight you will not use, and a narrower engine with a longer track record may serve you better. ## Conclusion Adopt Genesis World if you are doing robotics or embodied AI research in Python and need deformables, fluids or granular media in the same scene as rigid bodies, since that coupling is the part most engines do not offer. Do not adopt it if you need a mature, narrowly scoped rigid-body simulator with years of third-party tooling, or if you cannot install optional backends on your machine. Verify three things before committing: that your Python is 3.10 through 3.13, that the specific example you care about runs after pip install -e ".[dev]" and the extras it needs, and whether the solver you plan to use is documented well enough for your accuracy requirements, because the README catalogues demos rather than solver parameters. ## FAQ ### What is Genesis World used for? The README describes it as a simulation platform for physical AI development, used for robotics environments, machine learning pipelines, data generation and agentic simulation. It combines a multi-physics engine, the Nyx renderer and the Quadrants compiler behind a Python interface. ### Is Genesis World free? The repository is licensed Apache-2.0, so the source is available under that licence. The README notes development is now officially supported by Genesis AI, and the licence text is the authority on what that permits. ### Who created Genesis World? The README states it was previously named Genesis and started as an academic project in December 2024, and that its development is now officially supported by Genesis AI. The repository is hosted under the Genesis-Embodied-AI organization. ### What is Genesis World? It is a simulation platform for general-purpose robotics and embodied AI learning, with a unified multi-physics engine, a renderer called Nyx, and a cross-platform compiler called Quadrants. The Python package is named genesis-world. ### How does Genesis World compare with Isaac Sim? The README does not compare them directly. The structural differences are that Genesis World lists Rigid, FEM, MPM, PBD, SPH, uipc, a coupler and SAP sharing one scene and one state, and its compiler targets CUDA, ROCm, Metal, Vulkan, x86 and ARM64 rather than one vendor's stack. ## Sources - [Genesis-Embodied-AI/genesis-world on GitHub](https://github.com/Genesis-Embodied-AI/genesis-world) - [License: Apache-2.0](https://github.com/Genesis-Embodied-AI/genesis-world/blob/main/LICENSE) - [Project website](https://genesis-world.readthedocs.io) - [README](https://github.com/Genesis-Embodied-AI/genesis-world/blob/main/README.md) - [Releases](https://github.com/Genesis-Embodied-AI/genesis-world/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/genesis-embodied-ai-genesis-world