Collaboration proposal: SuperDex Physics as a physics backend for UniLab's RL framework

[TATP-233]

Hi SuperDex team,

I'm reaching out on behalf of UniLab (https://github.com/unilabsim/UniLab), an open-source, contract-driven reinforcement learning infrastructure for robotics. Having read the
Project SuperDex README, I believe there is a strong complementarity between our projects and would like to ask whether you'd be interested in exploring a collaboration: integrating
SuperDex Physics as a registered physics backend in the UniLab framework.

About UniLab

UniLab's design premise is "define the task once, use the solver and hardware that fit the job":

• A stable, backend-agnostic task layer — observations, actions, rewards, terminations, commands, events, and curricula are reusable task components that do not change when the physics engine changes.
• Physics engines are consumed through a SimBackend contract maintained in unisim-core (https://github.com/unilabsim/unisim). UniLab currently has adapters for MuJoCo (incl. MuJoCo Warp), Motrix, Newton, Genesis, Drake, IsaacGym, and IsaacSim.
• RL algorithms and the async runner (PPO/APPO/SAC/TD3 and replay-accelerated FastSAC/FlashSAC variants) live in unilab-rl (https://github.com/unilabsim/unilab_rl), decoupled from simulation.
• Support claims are evidence-based: every backend/task combination is tracked in a support matrix as registered → configured → tested → benchmarked, so no overclaiming.

Why SuperDex Physics interests us

SuperDex Physics is contact-first and purpose-built for tactile dexterous manipulation — exactly the regime where solver choice is driven by task fidelity rather than raw throughput. A UniLab adapter would let your physics engine be exercised against an existing portfolio of tasks, algorithms, and experiment tooling, and would give our users a first-class contact-rich manipulation backend. Conversely, we noticed SuperDex Lab is in early preview and planned for substantial improvements — if any of UniLab's task-layer, runner, or algorithm components are useful to you, we'd be glad to discuss that direction too.

What the integration could look like (proposal, open to your input)

1. PoC adapter: implement SuperDex Physics behind the SimBackend interface in unisim-core (parallel env stepping, deterministic reset, state I/O), starting with one representative
   dexterous manipulation task.
2. Validation & benchmarking: wire it into UniLab's registry, sim-to-sim contract checks, and support matrix; publish honest registered/tested/benchmarked status as evidence
   accumulates.
3. Governance: backend-specific logic stays in the backend adapter layer; both projects keep their own ownership boundaries. SuperDex Physics remains your engine — we integrate, not
   fork.

Questions for you

• Is there interest on your side in having SuperDex Physics exposed through external RL frameworks, or is SuperDex Lab intended to be the exclusive RL entry point?
• Does SuperDex Physics expose (or plan to expose) the primitives such an adapter needs: batched parallel simulation, deterministic reset/replay, and efficient observation/state extraction?
• Are there licensing, branding, or contribution-process constraints we should be aware of (Apache-2.0 first-party code looks compatible on our reading)?
• If you'd prefer a lighter first step, would a small joint proof-of-concept — e.g., one SuperDex task running under UniLab's training pipeline — be a reasonable starting point?

Happy to continue the discussion here. Thanks for open-sourcing SuperDex — the contact-first focus is a genuinely valuable addition to the ecosystem.

Best regards,
UniLab team

[TATP-233]

Following up with a concrete update: UniLab now supports SuperDex Physics end-to-end, and we have successfully trained a Go2 velocity-tracking policy with PPO entirely on SuperDex. Reproduction Guide. We also developed a native batch executor that we would be happy to contribute upstream.

The main results:

• Simulation throughput: The per-scene Python Scene.step path was our main bottleneck for RL workloads (~14.6k scene-steps/s at 128 scenes). Our C++ SceneBatchExecutor reaches ~160k scene-steps/s on a Ryzen 9 9950X3D with 16 workers—approximately 11× faster. In our trajectory comparisons, qpos/qvel matched the serial path exactly (max absolute error: 0.0).
• Full RL training: With 1,024 environments, Go2 PPO training completed 400 iterations (~9.8M environment steps) in 429–486 seconds across four reproduced runs, including policy inference and training.
• Policy evaluation: Under the same evaluation protocol, the SuperDex-trained policy achieved linear/angular velocity-tracking scores of 0.930/0.848, compared with 0.936/0.689 for our MuJoCo-backend reference, with zero falls over 128k control steps. Policy I/O compatibility was checked item-by-item through UniLab’s sim2sim contract.

The executor uses a persistent C++ worker pool, batched force/state I/O, selective readback, and control-step batching. PD/actuator forces are recomputed from the latest qpos/qvel at every physics substep.

The implementation is available on our fork, and published wheels are available through unisim-core[superdex] and unilab[superdex] 1.2.0 for reproduction.

Would you be open to a PR adding this executor? In particular, we would appreciate your guidance on whether selective readback (readback_mask) and control-step batching (step_control) fit the intended engine API, or whether you would prefer a different interface. We’re happy to adapt the implementation and include the benchmarks, ablations, and parity checks in the PR.

[ajithprabhakara]

Hi UniLab team, and thanks for the detailed write-up.

Short version: We welcome an integration, but we are not able to take on a joint engagement right now. Please reach out to us directly via projectsuperdex@meta.com going forward. Below are answers to your four questions.

1. Is SuperDex Lab the only RL entry point?

No. SuperDex Lab is our own Gymnasium-based harness, but it is not meant to be the only way in. SuperDex Physics has a public Python and C++ API, and you are welcome to build on it directly. We are happy to see SuperDex used in other frameworks, including UniLab.

2. Do the primitives you need exist?

Reset and replay: yes. SuperDex Physics has a state capture API today. Scene.capture_state() saves the dynamic state of a scene and returns a handle. You restore it with restore_state(handle, release_immediately=False) and free it with release_state(). There is also a byte version, capture_state_to_bytes() and restore_state_from_bytes(), which you own the memory for. You can restore those bytes into a different but compatible scene. That byte form is probably the one you want for a backend adapter.

Docs, with two runnable examples: https://projectsuperdex.com/physics/docs/concepts/state_capture/

Three limits to know before you design around it:

• A snapshot holds dynamic state only. That means transforms, poses, velocities, integration history, controller and constraint targets, external forces, and scene time. It does not rebuild scene topology, and it does not restore shapes, materials, or scene parameters.
• The bytes are an internal format and are tied to one build. Use them for short-lived transfer, not for long-term storage.
• A restore is not atomic. If it fails, the target scene can be left half-changed.

On determinism: Within one build, SuperDex Physics is designed to reproduce a run exactly, as long as the inputs, the solver and backend settings, the worker thread count, and the sequence of API calls all stay the same.

Batched parallel simulation: This works differently than you may expect. SuperDex does not advance N copies of a world in one call. Scene.step(dt) advances one scene. The solver parallelizes work inside that scene. Parallelism across environments is composed by the caller.

SuperDex Lab composes it in two tiers. An outer AsyncVectorEnv spreads work over N worker processes. Inside each worker, a SyncVectorEnv steps M environments one at a time. On top of that, environments in the same worker that use the same scene config share a single physics scene. Each one saves its own snapshot and restores it before its turn to step.

Full description: https://projectsuperdex.com/lab/docs/superdex_gym/batching/

Note: If you write your own vectorization, we recommend following SuperDex Lab’s pattern: run each scene single-threaded and use capture/restore state APIs to increase the batch size beyond the number of parallel workers. Three things are worth getting right. Each one fails quietly rather than raising an error:

• Step environments in a process one at a time, or set use_shared_scenes=False. Scene sharing is only safe with sequential stepping. If you step several environments at once in one process, their state restores interleave and the state gets corrupted. This option defaults to True.
• Pass one seed per environment, not a single number. A single seed gets expanded at both tiers. So W × K environments end up with only W + K − 1 distinct seeds. 1000 environments can end up with 132. Rollouts then correlate and nothing warns you.
• Choose the solver thread count on purpose. The physics context is global to a process and has one thread pool. sdp.initialize(num_worker_threads=-1) auto-detects every core, so N processes that each auto-detect will fight over the same cores. Lab sets this to 0 by default for that reason. Also note that reproducibility assumes a fixed thread count, so tuning threads for speed will change replay behavior.

State readout is done per actor, through calls like get_articulated_pose(), plus a query system you opt into per actor, for example register_query(QueryType.TOTAL_CONTACT_FORCE). There is no bulk buffer read and no direct tensor handoff, so budget for that in your observation path.

3. Licensing and contributions

Apache 2.0 on our first-party code is deliberate; we want people to use SuperDex without friction. Please review the full list of licenses associated with our project here: https://github.com/facebookresearch/project_superdex#license.

If you contribute code to Project SuperDex, we require you to sign Meta's Contributor License Agreement (CLA) as specified here: https://github.com/facebookresearch/project_superdex/blob/main/CONTRIBUTING.md.

Finally, please be advised that you are responsible for ensuring that your use of SuperDex is compatible with all applicable licenses.

4. On a joint proof of concept

We welcome your enthusiasm to work with us on a joint proof of concept; however, we are unable to take this on at this time since we are focused on the next set of releases for SuperDex.

That said, we would like to hear what you find. If you build an adapter, please tell us about the pain points, missing pieces, and any results. Bug reports and API friction are useful to us. Please file those through GitHub Issues on project_superdex.

If you already have work in progress and are experiencing specific issues, feel free to ask here and we will try to point you in the right direction.

Thanks again for the interest, and for the care in your write-up.