Simbody: A C++ Multibody Dynamics Library for Skeletons, Robots and Machines

Who Simbody Is For, and the Problem It Actually Solves

Writing a rigid-body simulator from scratch means implementing joint parameterizations, constraint Jacobians, integrators with error control, and contact models before you can simulate anything interesting. Simbody exists so that you do not have to. It is a C++ API for articulated mechanisms: sets of rigid bodies connected by joints, pushed by forces, and restricted by constraints. The README names the intended domains directly: biomechanical structures such as human and animal skeletons, mechanical systems like robots, vehicles and machines.

The audience is therefore not end users. It is developers building domain-specific applications on top of a dynamics core. The README states that Simbody "provides a C++ API that is used to build domain-specific applications; it is not a standalone application itself." The evidence is in the ecosystem it names: OpenSim for biomechanists, Gazebo for roboticists, and MacroMoleculeBuilder for biomolecular research. If your product is a simulation tool, Simbody is a candidate for the layer underneath it. If your product is a simulation, you are looking at the wrong kind of dependency.

Generalized Coordinates and O(n) Dynamics: The Core Mechanism

The design decision that shapes everything else is the coordinate system. Simbody models motion in generalized, also called internal, coordinates, and the README describes this as a multibody dynamics library for motion in "generalized/internal coordinates in O(n) time," noting that this is sometimes called a Featherstone-style physics engine. The linked theory manual is where the derivations live; the README only states the property.

The practical consequence is that the number of degrees of freedom scales with the number of bodies rather than with the number of pairwise contacts, which is what makes long kinematic chains such as a skeleton tractable. The architecture visible in the repository follows the same split: SimTKcommon, SimTKmath and Simbody are separate top-level directories, so the numerical and common layers are not entangled with the multibody layer. A program assembles subsystems. The README's example creates a MultibodySystem, attaches a SimbodyMatterSubsystem and a GeneralForceSubsystem, adds Force::Gravity, then builds MobilizedBody::Pin joints between them. Forces, constraints and bodies are all registered against the same system object, and the state is realized from topology before integration begins.

That is a fairly conventional subsystem composition pattern, and the interesting part is not the pattern but what it buys: the system can be realized in stages, so topology-level work is separated from state-level work. The cost is that you must understand the realize phases to use the API efficiently. The README does not explain them; it points to the User Guide.

Installing Simbody and Running the Double Pendulum

The README lists eight installation routes across Windows, macOS, Linux and FreeBSD, and it also suggests checking Repology to see whether your Linux distribution packages Simbody. Two of the routes are one-liners. On Ubuntu or Debian the README documents installing pre-built binaries with apt-get, and on macOS it documents an automated build and install through Homebrew. The exact package names are not reproduced in the portion of the README available here, so check the repository's Installing section rather than guessing a package name.

The Conda route is documented for Windows, macOS and Linux, and vcpkg is documented as a separate option. If you prefer to build from source, the dependencies section gives the floors: CMake 3.21 or later, gcc 4.9.0 or later, Clang 3.4 or later, or Apple Clang (Xcode) 8 or later, plus LAPACK 3.6.0 or later and BLAS. Visual Studio 2015, 2017 or 2019 are the supported Windows compilers, and on Windows the README says all needed library dependencies, including linear algebra and visualization, ship with the installation.

Once the library is available, the smallest real program is the double pendulum from the README. It defines the system, two pin-jointed bodies, a visualizer and a RungeKuttaMersonIntegrator, then steps to 20 seconds.

#include "Simbody.h"
using namespace SimTK;
int main() {
    MultibodySystem system;
    SimbodyMatterSubsystem matter(system);
    GeneralForceSubsystem forces(system);
    Force::Gravity gravity(forces, matter, -YAxis, 9.8);
    Body::Rigid bodyInfo(MassProperties(1.0, Vec3(0), UnitInertia(1)));
    MobilizedBody::Pin pendulum1(matter.Ground(), Transform(Vec3(0)),
            bodyInfo, Transform(Vec3(0, 1, 0)));
    MobilizedBody::Pin pendulum2(pendulum1, Transform(Vec3(0)),
            bodyInfo, Transform(Vec3(0, 1, 0)));
}

What you should see when this runs is a window showing two linked spheres swinging under gravity, because the README's version adds a DecorativeSphere of radius 0.1 to each body and registers a Visualizer::Reporter at a 0.01 second interval. The README also sets the second pendulum's initial rate to 5.0 and integrates with RungeKuttaMersonIntegrator. If the window never appears, the likely cause is the optional visualization dependency: the README lists FreeGLUT plus Xi and Xmu as optional, so a build without them still simulates but cannot draw.

To wire Simbody into your own project rather than the examples tree, the README points at cmake/SampleCMakeLists.txt as the starting point.

Where Simbody Is the Wrong Tool

The README is explicit that Simbody is not a standalone application, and that single sentence rules it out for a large class of users. There is no scene file format, no editor, and no scripting console described in the README. If you want to open a program, drag bodies around and press play, Simbody gives you none of that; the Visualizer is a debugging and presentation aid attached to a running C++ program, not a front end.

The build surface is the second constraint. LAPACK 3.6.0 or later and BLAS are required dependencies, not optional ones. On a platform where those are awkward to provide, or where you cannot add a native compiled dependency at all, Simbody does not fit. The compiler floors are also real: gcc 4.9.0 or later, Clang 3.4 or later, Apple Clang 8 or later, and Visual Studio 2015, 2017 or 2019 on Windows. A project pinned to an older toolchain cannot build it without an upgrade.

Release cadence is the third thing to weigh, and it cuts both ways. Simbody-3.8 was released on 2025-05-17, but the previous release, Simbody-3.7, was on 2019-12-08. That is a gap of more than five years between feature releases. The repository is not archived and the last push was on 2026-09-22, so work continues, but anyone planning to depend on a steady stream of new releases should read the CHANGELOG.md and the commit history rather than assume a schedule. A library whose API is stable for years is fine for a product; it is less fine if you are waiting on a specific feature.

Simbody Against a Game-Oriented Physics Engine

The obvious comparison is with a general-purpose physics engine of the kind used in games and light robotics simulation. The difference is the coordinate representation. A typical game engine represents every rigid body with an unconstrained six-degree-of-freedom pose and then solves contacts and joint constraints as impulses or iterative constraint projections. That approach is tolerant of interpenetration, restarting and large numbers of simultaneous contacts, and it is tuned for visual plausibility at interactive rates.

Simbody instead works in generalized coordinates, with the README describing O(n) dynamics in that formulation. Joints are not penalty constraints between free bodies; they are the coordinates themselves. This is the formulation that makes inverse dynamics, prescribed motion, and constraint forces meaningful quantities you can read back, which is why the README can list forward, inverse and mixed dynamics as features alongside gradient descent, interior point and global (CMA) optimizers. A game engine rarely exposes any of that, because its job is to produce a frame, not a torque.

The trade-off runs the other way too. Generalized coordinates make closed kinematic loops and intermittent contact harder to express than an impulse solver does, and Simbody's answer to that is a set of dedicated tools rather than a default: the examples directory contains ExampleClosedTopologyMechanism, ExampleContactPlayground, ExampleCustomConstraint and ExampleAssemblerPlayground. If your problem is thousands of colliding debris pieces, the impulse-based engine is the better fit. If your problem is a knee joint under load, Simbody's formulation is the one that produces the numbers you want.

Maintenance, Releases and the Apache-2.0 Licence

The repository is not archived, and the last push was on 2026-09-22. Two continuous integration badges sit at the top of the README, one for GitHub Actions and one for Appveyor, with a Codecov badge alongside them, so there is automated build and coverage machinery in place. The CI workflow file lives under .github/, and CMakePresets.json at the top level suggests preset-based builds are maintained.

Upgrade cost is dominated by the C++ ABI and by your dependency graph. Simbody is a compiled native library, so an upgrade means rebuilding your application and every other native library that links against it in the same process. The README's dependency floors are the other upgrade lever: if a future release raises the CMake or compiler minimum, you inherit that work. The CHANGELOG.md is the file to read before moving between versions, and the release notes for Simbody-3.8 are the record of what changed most recently.

On licensing, Simbody is Apache-2.0, and the licence text is at LICENSE.txt. Apache-2.0 is a permissive licence that includes an express patent grant, which matters for a library that may end up inside a commercial robotics or medical product. This is not legal advice; the terms that apply to your distribution are in LICENSE.txt, and the question of whether your product triggers the notice and attribution requirements is one for your own counsel.

Editorial conclusion

Adopt Simbody if you are writing a C++ program that needs accurate articulated-body dynamics with constraints, contact and error-controlled integration, and you accept that you must build the surrounding application yourself. Do not adopt it if you want a ready-made simulator with a scene editor, a scripting console or a Python-first API; the README presents a C++ API, and the repository's examples are C++ files. Before committing, verify that your toolchain meets the stated floors (CMake 3.21 or later, gcc 4.9.0 or later, Clang 3.4 or later, Apple Clang 8 or later), that LAPACK 3.6.0 or later and BLAS are available on your platform, and that your licence review is comfortable with Apache-2.0. Then build the double pendulum from the README and confirm the Visualizer window appears, because that single run exercises the library, the linear algebra stack and the optional OpenGL path at once.

Frequently asked questions

Official sources

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