The Physics Engine Landscape

Before any of the math, it helps to see the whole board. This series is about how physics engines work on the inside, so this first piece maps the engines people actually use, and pins down two things: the skeleton they all share, and the small number of choices that make them different.

Everything here is cited. Wherever I make a claim about an engine, there is a link to that engine's own documentation or the original paper, collected under Sources. I got a few of these wrong from memory the first time; the corrected versions are called out in A few claims, corrected.

What every engine does

Strip away the branding and every rigid-body engine runs the same loop each step:

1. Collision detection. Find which bodies are touching, and where.
2. Constraint solve. Compute the forces or impulses that stop interpenetration and honor joints and friction.
3. Integration. Advance positions and velocities forward in time.

The differences live almost entirely in how steps 2 and 3 are posed. The rest of this series walks that loop from the bottom up. The table below is the "you are here."

The map

Two foundations sit underneath several of these rows. Featherstone's articulated-body algorithm is the O(n) forward-dynamics method that makes minimal coordinates practical, and XPBD is the compliant, step-independent form of position-based dynamics. Both get their own chapters later.

Two axes that explain the differences

Read across the table and the divergence collapses onto two axes.

Theoretical axis: how contact is modeled

• Hard complementarity (LCP). Non-penetration and friction as a linear complementarity problem. Bullet's iterative velocity solver lives here.
• Convex relaxation. Reformulate contact as a convex optimization, trading a little physical exactness for smoothness and reliable convergence. MuJoCo drops the LCP complementarity constraint outright, and Drake's SAP solver eliminates the constraints analytically into an unconstrained convex problem.
• Positional (XPBD). Skip forces entirely: project positions to satisfy compliant constraints, stable regardless of stiffness or step size.

Technical axis: coordinates, parallelism, differentiability

• Coordinates. Minimal / generalized (MuJoCo, Drake, RaiSim) versus maximal per-body (PhysX, Bullet) with reduced-coordinate articulations bolted on. This is exactly the maximal-vs-minimal choice Part 1 builds an interactive around.
• Parallelism. Single-scene CPU (Drake, RaiSim, PyBullet) versus massively batched GPU/TPU (MJX, Isaac Gym/Lab, Brax, Warp).
• Differentiability. Whether you can get gradients through a whole step (Brax, Warp, Drake's AutoDiff), the subject of Part 9.

Your three starting topics are not a random walk across this table. Maximal vs minimal coordinates sits on the technical axis; the cone-based contact optimization sits on the theoretical axis; XPBD is the third branch of that same theoretical axis. They are one traversal of these two axes, which is why the curriculum is ordered the way it is.

Concretely, a minimal-coordinate engine spends its life assembling and solving

$$M(q)\,\ddot q + C(q, \dot q)\,\dot q + g(q) = \tau + J_c^{\top} \lambda,$$

where the mass matrix $M(q)$ and the bias term $C(q,\dot q)\dot q$ come from the left side (Part 2 derives them), and the contact forces $\lambda$ are exactly what a constraint solver on the theoretical axis produces (Parts 5 to 7).

A few claims, corrected

Building this table caught a few things that "everyone knows" but the primary sources do not actually say:

• PhysX is not an "LCP" engine, at least not in its own words. The docs describe an iterative (P/T)GS solver with rigid non-penetration and an optional compliant model, and call friction "Coulomb patch friction." They do not use "LCP" or "pyramidal cone," so I do not either.
• TGS is PhysX's recommended solver, not yet its SDK default. The docs say it "will become the default soon" while PGS stays available. Isaac configs often select TGS downstream.
• Genesis is not fully differentiable today. It is designed to be, but currently only the MPM and Tool solvers expose gradients; the rigid solver does not yet.
• Newton's MuJoCo backend is "MuJoCo Warp" (the informal "MJWarp" is not the project name), announced at GTC on March 18, 2025 by NVIDIA, Google DeepMind, and Disney Research.

Sources

Every link below was fetched and checked against the specific claim it backs.

• MuJoCo. Overview: "combination of simulation in generalized coordinates with optimization-based contact dynamics." Computation: drops the LCP complementarity constraint (convex), cone "elliptic or pyramidal," Newton/CG/PGS solvers, RNE and CRB. MJX: JAX reimplementation for GPU/TPU "big batches." Functions: mjd_transitionFD finite-difference derivatives.
• PhysX / Isaac. Articulations: reduced coordinates, references Featherstone's Rigid Body Dynamics Algorithms. Rigid Body Dynamics: PGS and TGS solvers, compliant model since 5.1, Coulomb patch friction. Isaac Gym paper: physics and training on GPU, "2-3 orders of magnitude" speedup. Isaac Lab: unified robot-learning framework.
• Drake. MultibodyPlant: state is generalized positions and velocities. Hydroelastic contact: pressure-field contact surface. v1.5.0 notes: the SAP (Semi-Analytic Primal) contact solver. Castro et al., 2022: the unconstrained convex contact formulation behind SAP. AutoDiff: automatic differentiation scalar.
• Bullet / PyBullet. Quickstart Guide: Featherstone btMultiBody and a maximal-coordinate option; robotics, games, ML. Sequential impulse solver: "SIMD implementation of the Projected Gauss Seidel (iterative LCP) method." GPU discussion: PyBullet's OpenCL backend is not enabled. Tiny Differentiable Simulator: the separate autodiff project.
• Brax. Repository: "fast and fully differentiable physics engine," generalized / positional (PBD) / spring / MJX backends, JAX and massively parallel. Paper: differentiable, accelerator-scale rigid-body simulation for RL.
• NVIDIA Warp. Repository: GPU-accelerated, JIT-compiled kernels, differentiable. XPBD integrator and Featherstone (CRBA) integrator: reduced vs maximal coordinates. Differentiable simulation blog: forward and backward kernels.
• Newton. Announcement: built on Warp, MuJoCo Warp backend, NVIDIA + Google DeepMind + Disney, March 18, 2025. Repository: GPU-accelerated, MuJoCo Warp as primary backend.
• RaiSim. Articulated systems: generalized coordinates. Contact: per-contact bisection solver, friction-cone projection. Hwangbo et al., 2018: the bisection method, single-core CPU timing, legged robots.
• Genesis. RigidJoint: generalized coordinates. Rigid collision resolution: MuJoCo-style quadratic penalty, CG and Newton. Docs index: fastest engine ("10-80x"), differentiable only for MPM and Tool solvers so far.
• Foundations. Featherstone ABA: Carpentier and Mansard, 2018 (O(n) ABA, spatial notation) and Featherstone's publications (Rigid Body Dynamics Algorithms, 2008). XPBD: Macklin, Muller, Chentanez, 2016.

Next in Part 1: rotations and SO(3), then the maximal-vs-minimal coordinate choice with a four-bar linkage you can drag.