The Wonderful World of Physics Simulators and How to Choose One

There's a lot of simulators out there, and with each simulator trying to sell itself for being the best of its kind, deciding which simulator to use is a whole task of its own.

The target audience for this post is people who, like me, are interested in using physics-based simulators for their research or fun projects, but unfamiliar with how the underlying physics engine actually works. Please note that the focus of this post is on rigid-body and optionally soft physics simulation, not, per say, for modeling biological systems or interacting in text-based environments. After reading this post, you should be able to make a principled decision on which simulator to use, beyond "this seems to be what everyone else in my field uses" and hopefully away from "all my options suck so I'm building my own hahha" and encourage you to make the right tradeoffs for your simulating needs.

Table of Contents

• The Physics Engine: A 3-Layer Cake

  • Layer 1: Collision-Free Dynamics
  • Layer 2: Collision Detection
  • Layer 3: Constraint Solver
  • Engine Features
• Simulator Features: Frosting on the Cake
• And Now, Some Cakes

The Physics Engine: A 3-Layer Cake

Typically your usage of a simulator is something like this:

scene = my_physics_engine.Scene(...)

...  # scene setup

for i in range(N):

	scene.step(...)  # "do physics"

	...  # get scene info / apply controls / etc.

What's going on in a physics step though? Given the current state of the scene q_t (this could be your robot joints, object positions, etc.), the velocities qd_t, and optionally some control input or external action, we compute the next state of q_t+1 and qd_t+1. This is generally done in 3 stages: collision-free dynamics, collision detection, then constraint resolution.

def step(q, qd, action):

    # 1. Collision-Free Dynamics: apply equations of motion
    q_bar, qd_bar = collision_free_dynamics(q, qd, action)

    # 2. Collision Detection: get contact points, where the interesting stuff is happening
    collision_data = collision_detection(q_bar, qd_bar)

    # 3. Constraint Solver: resolve the collisions and get realistic outputs
    q, qd = solver(q_bar, qd_bar, collision_data)

Layer 1: Collision-Free Dynamics

In the first step, the engine uses basic Newtonian equations of motion to update all the positions and velocities. However, when the world is discretized like it is in a computer, the numerical stability of the integration method can affect the simulation's stability and accuracy. The simplest way to do this is to compute q += qd * dt, which is the Euler method. There are some variations on this that try to be more stable, at the cost of doing slightly more computation.

Timestep

The most basic way to trade off speed and accuracy is to adjust the simulation timestep dt or the number of substeps per frame. Smaller dt or more substeps means more accurate and stable simulation, but at a higher computational cost. However, beware: some solvers (especially explicit ones) can actually become less accurate or even unstable if dt is too small, due to floating-point errors or solver limitations.

Articulation

For articulated rigid bodies like robots, the engine also needs to account for joint constraints and kinematics. Robotics-focused engines usually do this calculation in such a way that it is invertible so that you can do motion planning, while many game-focused engines typically use a quicker algorithm that only yields the forward dynamics, which is all you need for your silly ragdoll physics.

Layer 2: Collision Detection

Next, the engine needs to find where all the action is happening: the collisions. Since simulations are discretized in time, after updating the positions of all the objects we will often end up with some intersecting each other. Before we resolve these physical implausabilities, we have to detect which objects are intersecting and by how much. The detection is usually split into two phases: broad phase where we quickly rule out pairs that are definitely not colliding, and narrow phase for precisely checking the remaining pairs. Wikipedia has a good overview of this.

Collision Geometry

As a user, it is very important that you consider the mesh or collision geometry that you are using as the input to the physics engine. Collision detection on simple convex meshes will always be fast and more stable than on non-convex meshes. Many engines recommend to apply convex decomposition on your mesh to get the best performance. Some simulation platforms may even do this automatically for you. It is sometimes the case that problems such as slippage are caused by poorly configured geometry, and not necessarily an issue with the engine physics.

Layer 3: Constraint Solver

Once collisions are detected, the engine needs to resolve them, e.g. preventing objects from interpenetrating, enforcing joint limits, and simulating friction. Mathematically, for rigid bodies, this means solving the Linear Complementarity Problem (LCP). To solve this exactly is NP-hard, so most engines relax the conditions and/or use approximate solvers for this, with varying levels of accuracy and speed.

Engine Features

So every physics engine is essentially a packaged assortment of these 3 steps. Usually, you have the option to mix and match different algorithms for each part as well. On top of that, every algorithm has its own parameters to tune, so be mindful that you will get varying levels of speed and accuracy from one simulation platform based on how well you set up your environment as a user.

Aside these core components, there are some additional aspects that are usually baked into the engine. These features tend to be design choices that are closely tied to the core components, so it will be more difficult to simply extend an existing engine to support them. Often, you will find engines dedicated to supporting these features specifically.

Differentiability

A differentiable physics engine outputs smooth gradients with respect to its inputs by backpropagating through dynamics, collisions, and constraint solving. Of course, this will require at least 2x additional computation to compute the backprop, but it is usually worth it when you're doing machine learning or optimization because it allows for much faster training.

Parallelization

Physics engines can be parallelized at different levels. For game-focused engines where fast real-time simulation of single, complex environments is a priority, you may have per-object parallelization. On the other hand, for robot learning scenarios, multi-scene parallelization will probably dominate your training time cost much more than any optimization of a single scene. Additionally, parallelization may be handled on CPU or GPU. To support GPU, the physics engine might use lower level frameworks like Taichi or Warp to abstract kernel code (native GPU code can be painful to write).

Multiphysics

Beyond rigid bodies, you may be interested in simulating soft deformable objects and fluids, or even temperature, electromagnetics, etc. Also, you may want your rigid objects to be able to interact with your soft objects and vice versa. There are several different ways to represent and simulate soft objects, but generally anything soft will be much, much slower than rigid body simulation. Remember, supporting soft objects means implementing the dynamics, collision, and constraint solving steps specific to the soft body representation/algorithm.

Note: Beware of Benchmarks

A performance/speed number means nothing without the full context. Is it on a single scene or multiple scenes? How many entities? How many contacts? With how much physical precision? Just as every engine is an opinion piece which makes trade-offs for the aspects that it cares most about, every benchmark or comparison paper will only cover a subset of use cases. Ideally, the person running benchmark should fully understand the design choices and tunable parameters for each simulator, otherwise the results may be misleading as it will not be reflective of the actual performance. Especially with increasing amounts of money on the line in robotics research and industry, the position/background of the authors should be carefully considered. You may find that the author of a benchmark is a developer of their own simulator, in which the developer optimized for the aspects that they care most about, and will know how to tune the parameters of their own simulator to get the best performance, but only use defaults for other simulators.

As a simulation user, you should consider the required levels of accuracy vs stability vs consistency for your use case. When looking at simulators, also consider the intentions of the engine developers. Depending on the main use case, "speed" and performance will be optimized along different axes. Maybe one day we can convince aallll of the simulation developers to get in a room and battle it out on a buuunch of different scenarios... but realistically, that probably won't happen anytime soon. As a general rule of thumb:

• For video games: It's probably fast for single scenes and has stable, although not accurate physics.
• For robotics design: It'll be slow but have accurate physics and probably have good support for things like kinematics out of the box.
• For robot learning: It's going to be massively parallelized across scenes but not nearly as good at single complex scenes.

The Simulator: The Cake with Frosting

What I'm going to call a simulator is the platform/infrastructure built on top of the physics engine, kind of like all the frosting and toppings on a cake.

• Graphics: Raycasters vs rasterizers, textures and materials, lighting, shaders, and so on...
• Robotics Kit: Support for kinematics, dynamics, path planning, sensors, actuators, reinforcement learning environments, etc.
• User Interface: A nice API and/or GUI to interact with the simulator.

If there's a feature you're looking for, there's definitely a simulator out there that prides itself on it! However, it's going to be hard to find a simulator that has all the things, and there are the practical aspects to consider as well.

• Compatibility: Erm, does it run on your machine?
• Community Support: Is there a community you can ask questions or is it dead and you're on your own for this?
• Ease of Use: Are you happy working with this simulator or do you want to rip your hair out already?
• Extendability: If you have a weird use case, is it possible to easily modify or extend the code?

Unfortunately, there's a lot of for-research codebases that are no longer maintained. As a general rule of thumb, I would generally avoid codebases whose README is a paper abstract or hasn't had commits in the last year or so.

And Now, Some Cakes

As an informed user, you're ready to shop for your simulator! Here's a table of some physics engines (core physics providers) and simulation platforms (contains additional features/ecosystem on top of a physics engine).

This is by no means an exhaustive list, and may contain some errors. Please let me know if you find any missing or incorrect information.

By the way, the tables are horizontally scrollable (shift + scroll wheel if you're on desktop + mouse).

Glossary

Or um, Ingredient List if we're still going with the cake analogy.

Physics Engines

Cake Recipes.

Simulation Platforms

Decorated Cakes.

Last updated: September 2025. I will try to connect these tables to a GitHub repo later.

Further Reading

If you want to learn more about the math behind the physics, this online textbook is a great resource. Also, PhysX and MuJoCo provide a nice detailed breakdown of their choice of algorithms. This contact models comparison paper (Le Ledic et al. 2024) and differentiable physics simulators review (Newbury et al. 2024) provide more in-depth analyses across simulators for their respective topics. Finally, if you are looking for more specific simulators, here is a larger, better-maintained list of simulators.

This post may contain errors. Feedback and corrections are much appreciated.

Thanks Yiling for the simulation workshop I based this on and for the helpful feedback!

Cover image credit: Placid Plastic Duck Simulator