# SuperDex: a contact-first physics engine and robotics stack for dexterous manipulation

> Project SuperDex bundles four modules (Physics, Robotics, Studio, Lab) behind a Python API for manipulation research. It is a v1.0.0 release from Meta's research org with a Linux-first toolchain and a simulation module still marked early preview.

**facebookresearch/project_superdex** — SuperDex brings together a purpose-built physics engine, robotics authoring tools, and a scalable reinforcement learning interface in a unified simulation platform, with VR-based teleoperation and additional capabilities planned for future releases.

- Repository: https://github.com/facebookresearch/project_superdex
- Website: https://projectsuperdex.com
- Stars: 688 · Forks: 76
- Language: C++
- License: Apache-2.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/facebookresearch-project-superdex

## What SuperDex is for, and who it is aimed at

Dexterous manipulation research keeps running into the same wall: general-purpose physics engines approximate contact, and contact is the whole problem when a hand is rolling a screw thread or squeezing a sponge. SuperDex is Meta's answer, packaged as one platform rather than a library you bolt onto an existing simulator.

The README frames it as a unified platform for dexterous manipulation research, and the gallery is the tell. Threaded screw, fruit bag, cereal box, rope braid, puzzle cube, soft fingertips. These are tasks where penetration depth and friction cone accuracy decide whether a policy learns anything. The stated audience is manipulation researchers, and the four building blocks map onto the four jobs that group does: simulate, describe the robot, author the assets, train the policy.

It is not a general robotics simulator with a manipulation demo attached. SuperDex Physics is described as contact-first and purpose-built for tactile manipulation, which is a narrower claim than most engines make. If your task is a mobile robot navigating a warehouse, nothing here is aimed at you.

## The four modules and how they connect

The architecture is a stack, and the division of labour is explicit in the README.

SuperDex Physics is the simulation backbone. It owns contact and sensing. SuperDex Robotics sits on top: robot definitions and composition, controllers, sensors, actuators, and the framework that aggregates them into complete simulation configs. SuperDex Studio is the desktop GUI that turns raw CAD and robot descriptions into native SuperDex Assets, which the README names as bots, prefabs and scenes. SuperDex Lab is the harness that abstracts the Markov decision process and the dynamics-constrained-optimization underpinning RL, MPC and system identification, exposed through a Gymnasium-style API.

The dependency direction matters. Assets flow from Studio into the Robotics layer, which composes them into configs that Physics executes and Lab wraps as an environment. That is why the install extras are split the way they are in pyproject.toml: `core` pulls lab, physics and robotics, `gui` adds mesh-cli, the physics debugger and Studio, and `fp64` swaps in double-precision builds of physics and robotics. You can take the simulation without the GUI, which is the right default for a training cluster.

One structural gap: Lab is labelled an early preview in the README itself, and the project says it will receive substantial improvements. Treat the RL interface as moving.

## Installing SuperDex with uv and running a first example

The README's quickest path is `uv` plus PyPI wheels. Clone the `stable` branch, which the README says always matches the latest published release, then create a virtual environment and install the `superdex` distribution.

```bash
git clone --branch stable https://github.com/facebookresearch/project_superdex.git
cd project_superdex
uv venv
uv pip install superdex
```

On Linux, the GUI components need more than the wheel. Studio and the Physics Debugger require an available X11 display (native X11 or XWayland), a driver supporting OpenGL 4.1, and a set of runtime libraries. Ubuntu and Debian users install them with the command the README gives:

```bash
sudo apt install libgl1 libx11-6 libx11-xcb1 libxcb1 libxext6 libxrandr2 libxinerama1 libxcursor1 libxi6 zenity
```

Fedora and RHEL have an equivalent `dnf` line in the README. Skip this if you only want the physics and robotics Python modules.

With the environment in place, the README's first real examples are two scripts. The `--no-project` flag is required, and the README is explicit about why: without it, `uv run` builds from source inside the repository instead of using the installed wheel.

```bash
uv run --no-project superdex_physics/examples/example_tendon_comparison.py
uv run --no-project superdex_robotics/examples/control/example_osc_jsc_control.py
```

The first exercises the physics engine through a tendon comparison, the second runs an operational-space and joint-space control example. To open the authoring GUI:

```bash
uv run --no-project superdex-studio
```

If you need float64, the README says to set `SUPERDEX_PRECISION=double` before running; otherwise single precision is the default. That switch matters for contact-heavy work, where accumulated single-precision error in a solver can change whether a grasp holds.

## Building from source, and why the Clang requirement bites

Source builds are a different proposition. The README lists CMake 3.26 or newer, Ninja, `uv` for the Python build, and on Linux Clang 17 or newer. The repository's `pyproject.toml` mirrors that with a `build` extra pinning `cmake>=3.26`, `ninja>=1.5` and `scikit-build-core>=1.0`.

The Clang requirement is where most first attempts fail. Ubuntu and Debian ship older Clang, so the README points at the official LLVM repository and a versioned install:

```bash
wget https://apt.llvm.org/llvm.sh
chmod +x llvm.sh
sudo ./llvm.sh 22
```

Fedora and RHEL users get `sudo dnf install clang`. The README then warns that the executable may be versioned rather than plain `clang`, and tells you to set `CC` and `CXX` to whichever binary you verified with `clang --version` before configuring CMake. That is a real constraint, not boilerplate: a mixed GCC/Clang toolchain will produce link errors that look like source bugs.

One detail worth noting for anyone packaging this internally: the root `pyproject.toml` declares the project as `superdex-dev` version 1.0.0 with the classifier `Private :: Do Not Upload` and a comment stating that it resolves through local paths, so a published copy would be a shell. The root file is a development workspace, not the distribution you install. The published packages are the per-module wheels.

## Where SuperDex is the wrong tool

The most obvious limitation is timing. SuperDex Teleop, the VR teleoperation module, is not in this release. The README says initial components for Unreal Engine 5 based virtual teleoperation arrive in Q4 2026, and that the gallery videos were recorded with it. So the demonstrations on the repository page were produced with software you cannot install yet. If your research plan depends on collecting human demonstrations through a headset, this release does not cover it.

SuperDex Lab is the second caveat, and it comes from the project rather than from me. An early preview that the README says will receive substantial improvements is not an API to build a multi-month training pipeline against without pinning versions.

The third is platform depth. The stated requirements are Linux x86_64, Windows x86_64 and macOS ARM, but the detailed instructions in the README are Linux-shaped: the X11 and OpenGL 4.1 prerequisites, the `apt` and `dnf` package lists, the Clang installation walkthrough. The README does not document a Windows or macOS equivalent for the GUI runtime dependencies. A macOS ARM user can plausibly install the Python wheels; whether Studio launches is not something the README addresses.

Finally, if your manipulation problem is not contact-rich, the contact-first design buys you nothing. A pick-and-place benchmark in free space gains no accuracy from a solver tuned for tactile sensing, and you inherit a smaller ecosystem than you would get elsewhere.

## SuperDex against MuJoCo and Isaac Lab

The honest comparison is with MuJoCo and Isaac Lab, and the difference is where each puts its effort.

MuJoCo is a general contact simulator with a mature, widely reused model format and a large body of published work. Its contact model is well understood and its ecosystem is enormous. SuperDex's claim is narrower and deeper: a physics engine purpose-built for tactile manipulation, where stable contact and accurate sensing are the design target rather than a configuration option. Whether that produces better grasps on a sponge is an empirical question the README does not answer with numbers, and the gallery videos are demonstrations, not benchmarks.

Isaac Lab takes the opposite architectural bet. It is built on GPU-parallel simulation for throughput, which is the right shape when you want millions of environment steps and can tolerate contact approximations. SuperDex Lab's stated abstraction is the Markov decision process and dynamics-constrained optimization, with MPC and system identification named alongside RL. That is a different centre of gravity: fewer environments, more emphasis on the dynamics being right.

The practical split: choose MuJoCo if you need a model format everyone else already uses, Isaac Lab if you need raw sample throughput, SuperDex if contact fidelity on soft or threaded objects is the thing your results hinge on and you are willing to be early.

## Licence, maintenance and the cost of staying current

SuperDex is Apache-2.0, stated both in the repository metadata and in the `pyproject.toml` licence field, with the standard Apache header reproduced at the top of that file. That is a permissive licence with an explicit patent grant, which is usually the frictionless option for both academic and commercial work. It is not legal advice, and if you are shipping a product you should read the `LICENSE` file and the `NOTICE` handling yourself rather than taking my summary.

The maintenance picture is straightforward. The repository is not archived, and the last push was on 2026-09-16. The most recent release is v1.0.0, tagged on 2026-08-24. So this is a project with recent activity and a versioned release line, not an abandoned research dump.

Upgrade cost is where you should budget attention. The Python bindings use the stable `abi3` ABI from Python 3.12 onward, which means one wheel works across 3.12 and later rather than one wheel per minor version. That reduces rebuild pain. The counterweight is the `stable` branch convention: the README says it always matches the latest published release, so pinning to a tag rather than tracking that branch is the safer habit for reproducible experiments. Between v1.0.0 and the current `main`, the repository carries a `CHANGELOG.md` at its root, though the README does not describe what changed in it.

## Conclusion

Adopt SuperDex if your work is contact-rich manipulation and you want the physics engine, the asset authoring tool and the RL harness from one vendor, on Linux with Clang 17 or newer. Do not adopt it if you need the VR teleoperation path today, if you depend on SuperDex Lab being stable, or if you build on Windows or macOS without a way to test the GUI path. Verify three things first: that `uv pip install superdex` resolves for your interpreter (CPython 3.12 or newer), that your graphics stack exposes OpenGL 4.1 for Studio, and that the `stable` branch actually matches the v1.0.0 tag rather than whatever landed on `main` since 2026-08-24.

## FAQ

### What is Project SuperDex used for?

It is a simulation platform for dexterous manipulation research, combining a contact-first physics engine, a robotics SDK, a desktop asset authoring GUI and a Gymnasium-style reinforcement learning interface. The README describes it as a unified platform for dexterous manipulation research.

### How do I install SuperDex?

The README's quickest path is to clone the `stable` branch, run `uv venv`, then `uv pip install superdex`. Linux GUI components additionally need an X11 display, OpenGL 4.1 and a list of runtime libraries installed via apt or dnf.

### Which operating systems and Python versions does SuperDex support?

The stated requirements are Linux x86_64, Windows x86_64 and macOS ARM, with standard GIL-enabled CPython 3.12 or newer. Native binding wheels use the stable abi3 ABI from Python 3.12 onward.

### Is SuperDex Teleop available in this release?

No. The README says initial components for Unreal Engine 5 based virtual teleoperation will be available in Q4 2026, and that the gallery videos were recorded with SuperDex Teleop.

### How do I run SuperDex examples in double precision?

Set the environment variable SUPERDEX_PRECISION=double before running; otherwise single precision is used. The README notes this alongside the Python example commands.

## Sources

- [facebookresearch/project_superdex on GitHub](https://github.com/facebookresearch/project_superdex)
- [License: Apache-2.0](https://github.com/facebookresearch/project_superdex/blob/main/LICENSE)
- [Project website](https://projectsuperdex.com)
- [README](https://github.com/facebookresearch/project_superdex/blob/main/README.md)
- [Releases](https://github.com/facebookresearch/project_superdex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/facebookresearch-project-superdex