ManiSkill 3: a GPU-parallelised manipulation simulator built on SAPIEN

What ManiSkill 3 solves, and who it is actually for

Collecting manipulation data on real robots is slow and expensive, and a single arm can only produce so many grasps per hour. ManiSkill 3 attacks that bottleneck directly: it is a simulator and benchmark whose stated purpose is GPU parallelised visual data collection and GPU parallelised state-based synthetic data collection. The README claims that on the high end you can collect RGBD plus segmentation data at 30,000+ FPS on a 4090 GPU. That figure comes from the project, not from any independent measurement, and it is a high-end number rather than a baseline.

The audience is narrower than the topic list suggests. If you are doing reinforcement learning on manipulation tasks, imitation learning such as behaviour cloning or diffusion policy, or evaluation of vision-language-action models, the repository already ships tuned baselines for exactly those. The README lists PPO and SAC for RL, behaviour cloning and Diffusion Policy for imitation learning, and Octo, RDT-1B and RT-x among the VLA baselines. A team that only wants a physics engine for a custom non-manipulation scene is not the target reader.

One design point deserves attention before anything else: heterogeneous simulation, where every parallel environment has a completely different scene or set of objects. That is the feature that separates ManiSkill from simulators that assume all parallel workers share one scene, and it is the reason the task-building API exists in the form it does.

SAPIEN underneath, and why the task API is object oriented

ManiSkill is powered by SAPIEN, and the README is explicit that most of the platform constraints come from what the SAPIEN package supports. That single sentence explains nearly every limitation in the support table. When GPU simulation is missing on a platform, it is not a ManiSkill policy decision so much as an inherited boundary.

The mechanism the project advertises is a task-building API that abstracts away much of the complex GPU memory management code through an object-oriented design. Anyone who has written GPU simulation code knows the failure mode this addresses: tensors must live on the right device, be the right shape, and be batched across environments, and getting that wrong produces either a crash or silently wrong physics. Wrapping environments as objects moves that bookkeeping into the framework.

The data flow is conventional for this class of tool. You define or select a task, the simulator steps it in parallel across environments, and observations come back batched, with RGBD and segmentation available when rendering is enabled. Rendering is the part that depends on Vulkan, which is why the installation instructions treat Vulkan setup as a separate step rather than part of the pip install. The repository ships example scripts under examples/baselines and examples/tutorials, and the documentation points to a demos index for the full list.

Installing ManiSkill on Linux and running a first environment

The README calls installation extremely simple: a pip install plus a compatible torch build, followed by Vulkan setup for rendering. The package name on PyPI is mani_skill, and setup.py in the repository pins the current version at 3.0.1.

# install the package
pip install --upgrade mani_skill
# install a version of torch that is compatible with your system
pip install torch

That is the whole install command set the README gives. It does not pin a torch version, so the choice is yours, and the README points to the documentation for installing from source and for troubleshooting. Vulkan is the step people skip: the README links to a dedicated installation page for it, and without it rendering is the part that fails. If you only need state-based simulation, the dependency list in setup.py still pulls in imageio with ffmpeg and trimesh, so the package is not lightweight either way.

Before installing anything locally, the project offers a Colab quickstart notebook that the README says runs entirely on the Colab free tier and lets you try GPU parallelised simulation without your own hardware. That is the cheapest way to confirm the API suits you. For a local run, the documentation's quickstart page is the entry point, and the demos index lists the example scripts.

One dependency detail worth knowing: sapien is constrained by platform in setup.py. Linux requires sapien>=3.0.3, Windows requires sapien>=3.0.0.b1, and Darwin requires sapien>=3.0.2. A comment in that file notes that until SAPIEN is uploaded to PyPI with Mac support, Mac users need to install it manually from a release wheel. The README also notes that ManiSkill2 users can find the old codebase at the v0.5.3 tag.

Platform support is the real constraint, not the API

The support table is the most useful page in the README and the most sobering. Linux with an NVIDIA GPU is the only row with all three capabilities: CPU simulation, GPU simulation and rendering. Windows with an NVIDIA GPU gets CPU simulation and rendering but no GPU simulation. Windows with an AMD GPU is the same. WSL gets CPU simulation and nothing else, meaning no GPU simulation and no rendering. macOS gets CPU simulation and rendering but no GPU simulation.

Read that as a set of hard boundaries. If your lab standardises on Windows workstations, you can build tasks and render them, but the parallelised throughput that justifies choosing ManiSkill over a CPU simulator is unavailable. WSL is worse than it looks: rendering is listed as unsupported, so a WSL-based CI runner cannot produce visual observations at all. The README says the project best supports Linux and that there is limited support for Windows and macOS, with most constraints stemming from SAPIEN.

The second limitation is licensing, and it is not a technical one. The README states that all rigid body environments in ManiSkill are licensed under fully permissive licences such as Apache-2.0, while the assets are licensed under CC BY-NC 4.0. The repository carries both a LICENSE and a LICENSE-3RD-PARTY file. Non-commercial asset licensing is a real constraint for anyone building a commercial product on top of the bundled scenes, and it is easy to miss because the top-level repository licence is Apache-2.0.

ManiSkill versus MuJoCo and the Isaac family

The honest comparison is about where the parallelism lives. MuJoCo is a CPU physics engine with a well-earned reputation for accuracy and a small dependency footprint; it is the right tool when you need a handful of accurate rollouts, or when you are on a platform where ManiSkill cannot give you GPU simulation anyway. ManiSkill's answer is breadth of parallel environments plus GPU rendering, including heterogeneous scenes, which is a different problem than single-environment fidelity.

Against Isaac Sim and Isaac Lab, the split is about stack and licence rather than raw capability. Both target GPU-parallelised robot learning, and the practical differences for a reader are which physics backend you are willing to depend on, which platforms you must support, and how the task API fits your existing code. ManiSkill's own framing is that it is built on SAPIEN and that its constraints follow from SAPIEN, so evaluating it means evaluating that dependency too.

Genesis is the newer entrant in this space. The README does not discuss it, and the repository contains no comparison, so any claim about how the two differ in practice would be speculation. What can be said from what is here is that ManiSkill ships tuned baselines for PPO, SAC, TD-MPC2, behaviour cloning, Diffusion Policy, Octo, RDT-1B and RT-x, and that its benchmark framing is published as a paper at RSS 2025. If your decision hinges on Genesis specifically, this repository will not settle it.

Maintenance, versions and what an upgrade costs

The last push to the repository was on 2026-08-04, and the repository is not archived. Release cadence in the recent history is uneven: v3.0.0b21 in May 2025, v3.0.0b22 in December 2025, then v3.0.1 in April 2026. The beta sequence before the 3.0.1 release suggests the 3.0 line stabilised gradually rather than landing in one step.

The upgrade cost is dominated by the SAPIEN dependency, because setup.py pins different minimum versions per platform and the Mac path requires a manual wheel install until SAPIEN is published to PyPI with Mac support. A version bump in ManiSkill can therefore force a SAPIEN bump, and on macOS that may mean changing how you install rather than just changing a number. The package also pulls in mplib==0.1.1 on Linux only and pytorch_kinematics==0.7.6, both pinned exactly, so dependency resolution is stricter than a loose requirements file would be.

On licensing, the split between Apache-2.0 for rigid body environments and CC BY-NC 4.0 for assets is the thing to check against your own use. This is not legal advice, and the README's own wording is the authoritative statement here. If your use is commercial, read LICENSE and LICENSE-3RD-PARTY in the repository before you build on the bundled scenes.

Editorial conclusion

Adopt ManiSkill 3 if you are training or evaluating manipulation policies and have a Linux machine with an NVIDIA GPU, because GPU simulation and rendering are both supported there and nowhere else in the support table. Do not adopt it if you need GPU simulation on Windows, macOS or WSL, or if you plan to ship the bundled assets commercially, since the README states the assets are under CC BY-NC 4.0. Verify Vulkan rendering on your target machine and check which environments you actually need before committing, because the rigid body environments are Apache-2.0 while the assets are not.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mani-skill/ManiSkill on GitHub
3. Project website
4. README
5. Releases