johan helsing.studio

In a sudden and ambitious outburst of not-invented-here syndrome combined with hype-train, I decided there weren't enough physics engines out there and it would be a good idea to write one myself using all the latest buzzwords. In this tutorial series, I'll explain step-by-step how to build an extended position-based dynamics (XPBD) rigid-body physics engine using entity component system (ECS) architecture in rust.

I've always wanted to make games were fluids, soft-bodies and rigid-bodies interact and are a significant gameplay element. However, I've always found existing game physics engines to fall a bit short, especially with respect to soft-bodies and fluids. Most physics engines focus almost exclusively on rigidbodies, and if they have soft-bodies, cloth and fluid integrations, it seems mostly an afterthought. On the other hand, most fluid simulations are usually contained to a fixed volume, run on the GPU and are hard to interact with.

This month, however, I saw some really inspiring videos on two-minute papers, specifically the XPBD method, and I decided to write my own physics engine using this approach.

In this tutorial series, I'll explain step-by-step how I built bevy_xpbd, a 2D physics plugin for the Bevy game engine.

XPBD at a glance

XPBD stands for Extended Position-based dynamics. It's a variant of position-based dynamics (PBD) developed by Matthias Müller and Miles Macklin. It's an approach to simulating physics that has several advantages compared to most existing game physics engines like box2d.

The most relevant paper I found on XPBD is this one. It's a bit academic and might be hard to follow without reading some of the references, so a better intro to the subject might be Matthias' 15 minute video tutorial, where he explains some of the concepts. It's a great video, and pretty easy to follow.

I don't intend to do a full write-up on the comparison of XPBD vs. force-based and impulse-based dynamics, but grossly over-simplified, here are the reasons to prefer XPBD

1. It's stabler (meaning it's harder to make simulations that where things oscillate out of control and/or fly out into infinity.)
2. It's simpler to implement
3. It's simpler to understand how constraints work
4. It's really easy to get strong fluid/soft-body/cloth/solid coupling
5. It's easy to parallelize and fits well with the ECS paradigm.

If all this sounds complicated, don't worry! I'll go through it in detail in the following parts.

Physics engine - Part 1: Ball collisions

In this part, we'll set up a crate for our physics engine, implement the core simulation loop and get some balls to collide.

Physics engine - Part 2: Static boxes

In this part, we'll add support for static colliders, including boxes.

Physics engine - Part 3: Stacking and substepping

In this part, we'll continue implementing the XPBD algorithm. We'll start by looking at stacking, a common challenge in physics engines, and solve it by adding substepping.

Physics engine - Part 4: Dynamic boxes

In this part, we'll continue we're we left off in part 2, and add dynamic boxes.

Physics engine - Part 5: Spinning and body builders

In this part, we'll add rotation to our dynamic and static rigid bodies + a short bonus section on body-builders.

Physics engine - Part 6: Debugging, pausing, saving

In this part, we'll add an inspector to our examples, and see how we can easily step through problematic cases one frame at a time.

Physics engine - Part 7: Friction

Friction

There is still one glaring problem with our simulation: It’s still all very slick. Boxes just skid off the floor. We’re lacking friction.