# Tiny Differentiable Simulator for C++ and CUDA

> Tiny Differentiable Simulator is a header-based C++ and CUDA rigid-body physics library for robotics and reinforcement learning. It supports templated differentiation, several contact formulations and fixed-point arithmetic, but adoption depends on C++17 compatibility and the limitations of rigid-body modeling.

**erwincoumans/tiny-differentiable-simulator** — Tiny Differentiable Simulator is a header-only C++ and CUDA physics library for reinforcement learning and robotics with zero dependencies.

- Repository: https://github.com/erwincoumans/tiny-differentiable-simulator
- Stars: 1,377 · Forks: 139
- Language: C++
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/erwincoumans-tiny-differentiable-simulator

## Tiny Differentiable Simulator for Rigid-Body Robotics Workloads

Tiny Differentiable Simulator, usually shortened to TDS, addresses a specific engineering problem: developers need a physics calculation that can participate in optimization or reinforcement learning without separating the simulator from an external numerical differentiation layer. The library implements rigid-body forward and inverse dynamics, so a robotics application can model articulated motion rather than treating physics as a fixed numeric function detached from parameter estimation. Its intended audience includes developers working on reinforcement learning environments, articulated robotics and simulation models whose parameters or controls need to be optimized.

The project also covers contacts through two distinct families. The README documents impulse-level LCP contact models and force-based nonlinear spring-damper contacts. That gives the library more than one contact formulation, but it does not mean that both formulations have identical behavior or numerical requirements. TDS additionally provides motor, servo and Series-Elastic Actuator models, making it relevant when actuator dynamics are part of the state or parameter search rather than decorative components added outside the simulation.

The core is header-based and advertised as having zero dependencies. The repository layout supports that description at the C++ library level, with source primarily organized under `src/` and templated implementation throughout the headers. Visual examples add separate concerns. MeshCat requires Python, `pip`, `meshcat` and `meshcat-server`, while the repository includes its MeshCat dependencies under `third_party/`. TDS is therefore a compact C++ physics layer, not a complete zero-setup visualization environment.

For CUDA workloads, the README states that TDS can run thousands of simulations in parallel on a single RTX 2080 at 50 frames per second. That is a project claim tied to a particular GPU and accompanying demonstration, not a portable performance guarantee. The useful capability is the design for parallel simulation, but an adopter still needs to account for model complexity, contact configuration, build configuration and GPU hardware.

## How Templated Scalars Change TDS Physics Evaluation

TDS separates the physics formulation from its scalar type through templates. The documentation says the same codebase can operate with forward-mode and reverse-mode automatic differentiation scalar types, including CppAD, Stan Math `fvar` and `ceres::Jet`. It can also use ordinary `float` or `double`. This is more consequential than a simple arithmetic wrapper. A forward-mode type carries derivative information through simulation operations, while a reverse-mode type can collect sensitivities for later evaluation. The choice changes compilation, memory behavior and the way an optimization library receives gradients, even though the rigid-body algorithms remain the same.

For applications that cannot tolerate floating-point variation, TDS also contains fixed-point integer math intended for cross-platform deterministic computation. Determinism here means using a fixed-point representation for repeatability. The README does not document the precision configuration, scaling rules, numerical range or performance cost of that mode, so those details need direct review before selecting it for a new model.

The simulation stack includes articulated rigid-body dynamics, inverse dynamics, actuator representations and contacts. TDS can therefore combine a model state, joint dynamics and environmental contact before a higher-level optimizer or controller examines the result. CUDA support extends the same simulation concept across many parallel instances. The README demonstrates parallel throughput, but it does not provide enough API detail here to claim a specific batching interface, memory layout or launch configuration.

This architecture is useful when the application wants gradients or many repeated simulations without replacing its physics engine with a separate autodiff graph. It also creates a trade-off. Header-based templated code can increase compile time and produce separate instantiations for different scalar types. The repository requires a C++17 compiler, and CUDA use adds a separate toolchain requirement that the README does not detail.

## CMake Build and a First Tiny Differentiable Simulator Example

The documented build path uses CMake and a compiler with C++17 support. Create the build directory, configure the project and compile in parallel. The README presents these as the open-source build commands:

```bash
mkdir build
cd build
cmake ..
make -j
```

These commands generate the CMake build tree and compile the targets configured by the repository. The README does not identify one universal first executable. Instead, it points developers toward examples such as `pendulum_example.cpp`, `laikago_eval.cpp`, `soft_contact_example.cpp`, `tiny_urdf_parser_example.cpp` and `tiny_urdf_parser_meshcat_example.cpp`. The first real choice is which model matches the application. A pendulum is a small repository-level starting point for inspecting a basic model, while the URDF examples demonstrate parser and visualization integration.

For MeshCat visualization, the documented setup is separate from the C++ build. Install the visualizer, start its server and open the generated browser page:

```bash
pip install meshcat
meshcat-server --open
```

The README states that this should open Chrome at `http://localhost:7000/static/`. It then says to compile and run `tiny_urdf_parser_meshcat_example` in an optimized or release build. No separate executable invocation is documented, and the README does not provide the exact CMake command or target-selection flag for this example. That omission prevents a complete copy-and-paste run sequence from being presented without guessing.

The repository also includes `tiny_opengl3_app` as a native OpenGL 3 visualizer under `src/visualizer/opengl`. Developers can avoid the Python and MeshCat setup when an OpenGL application is sufficient. This is a meaningful distinction: OpenGL is bundled with the library, while MeshCat introduces a separate Python-based process and browser workflow.

## Contact Models, Solver Scope and Numerical Limits

The clearest limitation is that TDS is specialized for rigid-body and contact simulation. It is not a general-purpose fluid, cloth or particle solver based on the documented feature set. A project whose essential behavior depends on deformable objects, fluid dynamics or another physics domain would need a different numerical core, even if it also requires automatic differentiation.

Its contact options represent different numerical approaches. The impulse-level LCP family is appropriate when contact resolution is formulated around impulses and constrained dynamics. The nonlinear spring-damper family instead represents contact through forces and is exposed to the parameter and stability behavior of that formulation. TDS contains both, so the selection can follow model needs, but migrating a design between them can alter state interpretation, parameter tuning and solver behavior. The README does not state that the two models are interchangeable.

Differentiation choice is another boundary. CppAD, Stan Math `fvar`, `ceres::Jet`, plain floating point and fixed-point integers compile through a templated interface, but they do not all serve the same workflow. Reverse-mode systems can suit optimization over many outputs, forward-mode systems can favor a different derivative representation, and plain floating point does not provide derivatives automatically. Fixed-point arithmetic changes both precision and numerical representation. TDS makes these options available, but it does not document memory cost, compile cost or a recommended scalar type by application.

For CUDA adoption, the RTX 2080 throughput statement cannot be transferred automatically to another GPU. It also does not identify whether the demonstration includes the same joint count, contact density or actuator models expected in production. The design supports parallel simulation, but workload-specific behavior remains unverified by the README.

## TDS Against a Separate Physics and Optimization Stack

A concrete alternative is to place rigid-body physics in a general optimization framework and propagate derivatives through its external `ceres::Jet` type. The repository itself contains `examples/ceres_estimation_real.cpp` and explicitly lists `ceres::Jet` among supported scalar types. This is the closest documented alternative in approach because it changes where differentiation belongs. TDS can compile its simulation functions with the external scalar type, while a conventional simulation may call a general optimizer through its own estimator interface.

The practical difference is integration depth. In the TDS route, the rigid-body algorithm remains in the templated simulator and can use contacts, actuators, forward dynamics and inverse dynamics behind the same scalar abstraction. In a more separated stack, the physics engine exposes forward evaluations and the optimizer wraps or differentiates them. TDS favors keeping physics and differentiation in one C++ codebase, but it also ties the project to the simulator's supported rigid-body and actuator formulations.

The choice is not automatically between zero dependencies and external autodiff infrastructure. The TDS README lists external scalar libraries as usable types, and the MeshCat path needs Python tooling. Header-based means no packaged runtime dependency for the core headers; it does not mean every supported scalar mode or visualization route has no external build considerations.

If a project needs deformable bodies or a mature external solver interface, the documented TDS feature set may not fit. If it needs gradients through articulated contacts and can compile against C++17, the same library can reduce the amount of adapter code between simulation and optimization. The deciding evidence should come from an example close to the intended joint, actuator and contact model.

## Maintenance, Licensing and Upgrade Surface

The repository is not archived, and its last push was on 2026-10-08. Those facts show recent repository activity, but they do not establish release cadence, API stability or the availability of maintainers for production support. The two listed releases, `cuda_laikago_codegen` and `cuda_laikago_codegen2`, are dated in December 2020 and are specifically named as CUDA Laikago code generation releases. The README does not present them as a general sequence of stable releases for every part of the library.

Upgrading therefore requires source-level review rather than assuming that release names describe all changes. C++ templates, contact APIs, CUDA paths and optional visualizers can affect compile compatibility. A consumer should check its own target list, compiler behavior and examples when changing revisions. The documentation does not provide a compatibility matrix, semantic-versioning policy or migration guide.

The project uses `Apache-2.0`, and the `LICENSE` file is present. Source headers also contain Apache License notices. That license permits broad use, modification and redistribution subject to its conditions, including preserving applicable notices and providing its license text when required. This is not legal advice. Organizations still need to review the actual `LICENSE` file and their distribution practices for notices, attribution and third-party components.

The bundled `third_party` content also deserves separate review. The README says all dependencies for MeshCat visualization are included there. That keeps the visualization layout self-contained in the repository, but consumers should identify the bundled components and versions before redistributing an application. The Apache-2.0 designation for the repository should not be treated as a blanket statement covering every possible dependency without checking.

## Conclusion

Adopt Tiny Differentiable Simulator when a robotics or reinforcement learning system needs a native C++ physics core with templated differentiation, especially when CUDA batching matters. Do not choose it for deformable bodies, fluids or other domains outside its documented rigid-body scope. First verify C++17 compatibility, contact and actuator semantics, the available build target, and whether floating-point or fixed-point scalars match the required numerical behavior.

## FAQ

### What is Tiny Differentiable Simulator used for?

TDS provides C++ and CUDA rigid-body dynamics for robotics and reinforcement learning. It supports forward and inverse dynamics, contact models, actuator models and templated automatic differentiation scalar types.

### How do I build Tiny Differentiable Simulator?

The README uses CMake and requires a compiler with C++17 support. It documents creating a `build` directory, running `cmake ..` and then compiling with `make -j`.

### Can Tiny Differentiable Simulator use automatic differentiation and fixed-point math?

Yes. The documentation lists forward-mode and reverse-mode scalar types such as CppAD, Stan Math `fvar` and `ceres::Jet`. It also supports regular `float`, `double` and included fixed-point integer math for cross-platform deterministic computation.

## Sources

- [erwincoumans/tiny-differentiable-simulator on GitHub](https://github.com/erwincoumans/tiny-differentiable-simulator)
- [Issues](https://github.com/erwincoumans/tiny-differentiable-simulator/issues)
- [License: Apache-2.0](https://github.com/erwincoumans/tiny-differentiable-simulator/blob/master/LICENSE)
- [README](https://github.com/erwincoumans/tiny-differentiable-simulator/blob/master/README.md)
- [Releases](https://github.com/erwincoumans/tiny-differentiable-simulator/releases)

---

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