Erin Catto of Kintsugiyama, veteran video game developer who worked on the Tomb Raider series at Crystal Dynamics and later contributed to Diablo III, Overwatch, and other franchises at Blizzard, discusses video game physics engines with host Jason Davey. Erin created the popular open-source Box2D library used in titles including Angry Birds and Noita, and he released Box3D in 2026, bringing the much-loved physics engine to the third dimension. Underpinning everything from platformers and racing games to industrial robotics simulations, modern physics engines present a host of interesting engineering challenges, including the need to balance accuracy, stability, determinism, and performance. Catto describes the core concepts, the various trade-offs and factors that influence the design of these systems, and how they fit into the broader software architecture of a video game.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
- SE Radio 536: Ryan Magee on Software Engineering in Physics Research
- SE Radio 175: Game Development with Andrew Brownsword
- SE Radio 92: Introduction to Game Development with Oliver Jucknath
Other References
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Jason Davey 00:00:18 Welcome to Software Engineering Radio. I’m your host, Jason Davey, and our guest today is Erin Catto, who will be chatting with us about video game physics engines. Erin is a video game developer who started in the industry at Crystal Dynamics working on the Tomb Raider series and later went on to contribute to the physics engine powering Diablo III, Overwatch, World of Warcraft and more at Blizzard. Today he is at indie studio Kintsugiyama, developing a new title, the Legend of California. But Erin is perhaps best known as the developer of Box2D, an open-source physics engine used in titles including Angry Birds, Niota, Crayon Physics and more. In 2026, he released Box3D, which brings this much-loved physics engine to the third dimension. Welcome, Erin. Before we move on, is there anything you’d like to add to your bio?
Erin Catto 00:01:01 Oh, that all sounds good. Yeah.
Jason Davey 00:01:04 Awesome. I’m excited to get into the topic with you. If listeners would like some additional context, we have a couple of shows in our archive on related topics including Episode 175 on Game Development with Andrew Brownsword and Episode 536 with Ryan Magee on Software Engineering in Physics Research. So Erin, let’s start by defining some key terms. When people hear physics engines, what exactly are we talking about? What responsibilities broadly does a physics engine have in a video game?
Erin Catto 00:01:30 Right, so a physics engine is responsible for a lot of things. The primary thing that you’ll find in games is that it is used for collision. So, if you think about old games like Pacman or Pong, those needed to have collisions so that objects wouldn’t go through walls or whatever, but it was very simple fixed function things. With modern games, you have more complex environments, especially when you go into three dimensions. You need some way of shooting a ray through the world and finding out what does that ray hit. That’s the most bread-and-butter thing you’ll find in a physics engine is just that collision detection. But physics engines these days also bring other things to the table, such as rigid body simulation. So, you may want to have a box that tumbles across the ground realistically to create that sense of immersion into a 3D world. And so, we need to simulate the physics of that. So that involves the collision detection, involves solving differential equations, solving constraints, friction, contact, lots of things go into that. And then furthermore, physics engines are very important for performance. They’re kind of a key aspect of the game loop that you’ll find in a game. So, it needs to have very good performance.
Jason Davey 00:02:54 Awesome. Let’s dig into a few times you mentioned there, so you alluded to the fact that all the games used fixed function physics. What does that mean exactly?
Erin Catto 00:03:03 So if you take a game like Pong for example, there’s a ball that’s moving up and down and you have a paddle, you would just have some simple logic in your game that will check, did the ball reach the paddle? Is it between the left and right side of the paddle? If so, okay, change the velocity of that ball to go the opposite way.
Jason Davey 00:03:24 Okay. And newer games are generally based on a rigid body system. I think listeners might intuitively have a sense of what a rigid body is, but can you make that a little bit more concrete?
Erin Catto 00:03:33 Right, so rigid bodies aim to simulate Newton’s laws of motion fundamentally, and it does that for objects that are of fixed shape. So, the shape cannot deform. So, if you have a box, it’s always a box and you can’t squash it or stretch it. So given those limitations, we can do fairly efficient simulation of how that box may translate, how it may rotate, and how it would move through the world and collide with the world.
Jason Davey 00:04:04 Okay, so that makes sense. Box2D, as I understand it is a rigid body physics engine, but are other forms of physics, I guess soft body or deformable objects used in games? Where do those have their place?
Erin Catto 00:04:15 Soft bodies are a little bit more niche. I think what you’ll find in a lot of 3D games you may not notice though, is there is a lot of cloth simulation because if you see a triple A game, you see lots of interesting characters wearing interesting clothing and you want those characters to move through the world and seem natural in their inertia, their secondary motion of their items of clothing. So, you would want a claw simulation there, and that’s typically considered soft body collision or soft body simulation. Other kinds of soft body simulation you may find are things like water simulation or maybe something more deformable. Those exist, but they’re more niche in games these days.
Jason Davey 00:05:04 Okay, that makes sense. So, you mentioned secondary motion. I think that’s also a principle that animators may be aware of. I think it’s the idea that if you stop moving then your clothes continue, they have some momentum, they continue to swing, your hair moves with you, and you don’t seem like a stiff artificial object.
Erin Catto 00:05:21 Correct. So, if you imagine that an animator would have to animate every piece of clothing to represent that little bit of inertia, that little bit of responsiveness to movement, that would be fairly intractable, it would be a huge amount of data, a huge amount of labor. So, we fall back to simulation to cover the gaps there in that presentation.
Jason Davey 00:05:43 Okay. I think we’ll touch later more on how physics integrates with other systems, but it sounds like often animators will hand animate something and physics simulation is actually applied on top to create this secondary motion. Is that fair to say?
Erin Catto 00:05:56 That’s correct. So in your game engine, you would have an animation system, it would take all the animation data, it would blend it together, produce the final pose, and then after that runs then you would kick off to the cloth simulation where it takes that change in pose and then applies that to some cloth simulation that then tries to respond to that movement.
Jason Davey 00:06:19 Okay. Awesome. So, getting back to some of the fundamentals, people from high school may remember terms like a force, an impulse, a talk. Can you explain and give us a quick recap of what those are?
Erin Catto 00:06:31 Right. So these terms are related to Newton’s laws of motion. So, a force is something when you apply it to an object, it causes that object to accelerate and there’s a proportionality there. And that proportionality is expressed through the mass of the object. So, the greater the mass of something, the lower the acceleration will be when you apply the same force. So, force is just something external coming in and pushing. It could be like a jet engine, it could be an explosion, it could be a muscle, things like that. These can all apply forces and then torque is the angular counterpart of that. So a great example of torque is when you’re on a seesaw, you may have played on a seesaw as a kid and you may have noticed that if you sit at the end of the seesaw you will have more leverage on the person on the other side, but if you scooted in towards the pivot point, you would have a lower leverage on the person on the other side, and that’s a consequence of the torque being a force at a distance.
Jason Davey 00:07:43 Awesome, thanks. That makes sense. And maybe continuing with a seesaw example, it leads to another question which is that seesaw is presumably attached or anchored in the middle. Can you talk about what a constraint or a joint is in a physics engine and maybe relate it to that example or any others that help to illustrate that?
Erin Catto 00:08:01 Yes. So rigid bodies on their own are interesting. They can move and tumble through the world, but they also become interesting in other ways when you can constrain them, limit their motion in some ways along certain degrees of freedom. So, if you look at a seesaw, it has a pivot in the middle, and if you think about how can that seesaw move at that point, it really can only rotate. It can’t translate, and there’s some axes where it cannot rotate about, so it can’t like spin along the long axis. It only can spin around that middle axis there. So that is one example of a constraint. There’s many other examples of constraints you’ll find in physics engines such as slider constraints, distance constraints, and the most fundamental that you’ll find is the contact constraint.
Jason Davey 00:08:52 That leads us on, I suppose, to what is the contact constraint?
Erin Catto 00:08:56 So a contact constraint is used to keep a rigid body from basically falling through the floor. So, when a box falls on the floor in a physics engine, what happens is there will be a collision detection system there that detects that the box is now touching the floor, and then it will use some sort of algorithm to compute contact points. For example, you can think of a box we might determine at the four corners where the box is touching the floor, we would create contact points there, and then we would hand those contact points off to the rest of the physics engine, which then tries to constrain that movement. So, you would first, at each corner of the box, you would want to prevent that corner from going deeper into the ground. So that’s a normal constraint, that’s one aspect of contact. And then you may also want to apply some friction in that ground plane to slow down the movement of that corner of the box.
Jason Davey 00:09:57 And when you say normal constraint, you don’t mean normal in terms of regular, you mean normal in terms of something acting at rectangles or pushing away from the surface?
Erin Catto 00:10:06 Correct. So that refers to the normal vector of the surface, which is basically up, so it’s the opposite of tangent.
Jason Davey 00:10:16 Okay. Something else you mentioned in passing was the idea of casting array into the world. Can you talk about these kinds of query operations and how those fit into a physics engine?
Erin Catto 00:10:26 Right. So, there are two fundamental operations you’ll do for collision. One is the Raycast. So, you can think of a Raycast as I am looking into the world through my radical. If you imagine like a first person game, you might have a radical, which is maybe a UI element in the middle of your screen, and then as you hover over things in the world, it may indicate that, oh, you’re pointing at this treasure chest, and then that treasure chest might highlight or get some glow effect on it, and you need a Raycast to go through the world, examine what’s in the world and then see what is the first thing that is hit. So, it is basically a line that starts at an origin point, say at your eye and then goes straight out along some path through the world, and then the Raycast query on the world will tell you this is the point you hit, this is the object you hit, and all sorts of data that you can collect from that.
Jason Davey 00:11:28 I suppose it may not be immediately obvious that this is really a physics operation. It’s something within the realms of the physics engine to resolve that because that’s the part of the system that understands the physicality of space and the objects in the world?
Erin Catto 00:11:41 Right. So these things tend to all come together in the physics engine because first of all, if you’re going to have rigid body simulation, you need all those shapes to be there already to provide those contact constraints. For example, you’re going to need that floor there so that the box doesn’t fall through the floor. If there’s a treasure chest there, you probably also want the box to bounce off that treasure chest, so it becomes much more convenient just to put all that into one simulation.
Jason Davey 00:12:08 Awesome, thank you. I think that covers the basics for us.
Jason Davey 00:12:35 Let’s move on to a little more of the nitty gritty of how this works. As I understand it, physics engines have something you might call a simulation step or a time step. Can you walk us through each frame of the game or each time the physics engine updates, what are the stages that happen and what are the responsibilities of each stage?
Erin Catto 00:12:53 Yeah, so physics engines have fairly well-defined stages that you’ll find in just about any physics engine, and so there’s some common terminology that you’ll hear when we talk about the physics engine update. The first stage is typically called the broad phase. And the broad phase its responsibility is to find all the rigid bodies that are potentially touching each other. So, this is a very course level of collision detection and the way we achieve that course level of collision detection is by having a bounding box for every collision shape that would be moving. And typically, this is an access aligned bounding box, and then what we do is we put all those access aligned bounding boxes into a data structure that sorts them spatially, and then from that we can then quickly determine that for example, this crate that’s flying through the world, it is hitting the treasure box.
Erin Catto 00:13:56 Okay, potentially it may not actually hit it, but it’s potentially. So that is sort of a pass. It gets rid of a lot of potential collision pairs, and so that’s an optimization. And then we go to the narrow phase where we take those potentially climate pairs and actually compute those contact points that we mentioned before. So, the narrow phase is a very computational geometry heavy area of the physics engine, which deals with things like you may have heard of the separating access test or GJK, which is a distance test. And then we bring those algorithms together to find out the details of those collision interactions and then ultimately to compute those contact points. Now that we have those contact points from the narrow phase, we then pass those off to the solver phase. The solver phase is responsible for actually computing a Newtonís equations of motion and then applying the constraints. And then finally we wrap up at the end of the physics step by doing a transform update or a position and rotation update on every object that has moved.
Jason Davey 00:15:14 So when we talk about resolving these contact points, naively we might assume that if an object is going to collide with another object, like a box is going to start penetrating into the ground, we can just move it back a little bit until it’s not touching anymore. Why is that not sufficient for a true physics engine?
Erin Catto 00:15:32 Yeah, so you could just simply translate objects back and that is a very viable strategy for a simulation where you don’t really care about rotation. As soon as you want objects to rotate in a realistic way, you really need to start applying forces to objects at the contact points or at constraints so that they are actually obeying Newton’s laws emotions more precisely and that will then engage with the rotation of that object and cause that box or that seesaw to rotate in a realistic manner.
Jason Davey 00:16:15 I see. So, if we imagine a box falling towards the floor, if it’s falling perfectly straight, then maybe it’s okay just to move it up so it’s not inside the floor, but if one corner of the box is kind of leading, then when it impacts the floor, it’s going to impart some kind of rotation or it’s going to spin off in some direction or something like that?
Erin Catto 00:16:32 Correct. So, it’s important to understand that rigid bodies have a mass which is masses like weight, but it disassociate from the actual gravity that’s present. So, weight is more dependent on gravity. So, weight is different on say the moon versus the earth, but the mass is basically the number of atoms and the kind of atoms that make up that object and that’s immutable whether you’re on earth or on the moon. Aside from the mass though, there’s another aspect of rigid bodies that’s very important when we think about rotation, and that’s this concept of the moment of inertia or the inertia tensor, and that is a quantity like mass, but it also accounts for the geometry, the size of the object, the shape of the object, and that is something that has to be computed and because it’s a rigid body that geometry is fixed, so we know what that moment of inertia is, and that moment of inertia really determines how an object will react when it is given an impulse or force that’s off from center and how it would rotate. So, objects that have high leverage because you’re hitting from a point that’s very far from the center may rotate differently than a point that’s more aligned with the center.
Jason Davey 00:18:02 I see. It sounds like this is quite a deep rabbit hole, so I’m curious to what extent game physics engines are quote unquote real physics or how they would differ from something you’d see in a scientific physics simulation.
Erin Catto 00:18:15 Right, so that’s a very good question, and this question is very interesting because a lot of the times we really want to simulate Newton’s laws motion as accurately as possible in a physics engine because that will give the most realistic result. There are real-time constraints though, so we must make some trade-offs here and there. My point of view is that we should make as few trade-offs as possible when it comes to actually meeting Newton’s laws in motion. So that’s, for example, that force equals mass times acceleration. That is usually almost always obeyed in a physics engine. Then there is every action that has an equal and opposite reaction. That one is not always obeyed in a physics engine, but usually you should try to obey that law, otherwise you will introduce some very unintuitive movement. And so, we want to satisfy those equations in motion, but there have to be trade-offs. There are differential equations that we’re solving in the process of simulating Newtonís laws and we’re solving those approximately. We can’t solve those exactly. I think that’s the main tradeoff that you’ll find in a physics engine that is different for games versus something that’s an engineering focus.
Jason Davey 00:19:37 I see. So, along the line of those trade-offs, what properties are physics engines really trying to achieve things like accuracy, stability, performance, maybe determinism? How do these things play together?
Erin Catto 00:19:50 Yeah, so for a game we cannot predict ahead of time everything that’s going to happen. So, there can be scenarios that we never predicted or tested. So, the physics engine needs to be very robust against those unknown scenarios. So that makes a real-time physics engine very challenging because it has to not only be very fast, it has to also be very robust. Now there is an aspect that comes into game development which can assist this though because we can control the content to some degree. We can control the size of the crates that are in the world, the number objects that we allow in the world and so on. So, we can have some influence on that. You also mentioned determinism. Determinism is another aspect of physics simulation that is largely optional. It’s not required to have determinism in a game. However, there are some benefits to having determinism. Determinism is very valuable when it comes to reproducing and debugging bugs. If you can reproduce the same simulation over and over, then you can debug that thing very well, effectively. It’s a very important aspect for multithreading development in general is if you have a deterministic system, it becomes much easier to debug.
Jason Davey 00:21:21 I imagine it could also be important for multiplayer games potentially where several players are simulating the same objects on opposite sides of the planet, and in some cases it’s important that these things stay in sync and in some it may not be. Could you maybe give some examples of cases where you care about determinism in cases where you don’t from that aspect?
Erin Catto 00:21:40 Yes. This largely depends on your network model. So, a lot of games you’ll find such as first-person shooters, arena shooters, these tend to have a client server architecture where the simulation is happening on the server and then the client is just receiving all the state of things that matter from the server and just moving things around in the world according to what happened on the server. So, you don’t actually need any simulation on the client for this. You just simply broadcast basically like you’re streaming a Netflix show. The client has no ability to affect the outcome. On the other hand, there’s games like real-time strategy games which are historically peer to peer, and the idea there is to minimize the overhead of the server. So, let’s get the simulation off the server and leave that simulation up to the clients to do. This is important in real-time strategy games historically, because real-time strategy games, there may be hundreds of different units that need to be simulated, and if you have to simulate all these characters on the server, that could be a heavy cost.
Erin Catto 00:23:04 So the idea with these peer-to-peer games is that every player has a chance to apply some input. That input goes to the server and then it is rebroadcast to all the players. Now that all the players have the input of every other player, they can then simulate their game world. That simulation across all the players has to be given in an identical answer. So, if a unit or a character for player one moved 10 meters to the right, it shouldn’t also move 10 meters to the right for all other players, and that has to be deterministic.
Jason Davey 00:23:43 I see. And I imagine there are maybe things which are purely cosmetic, some leaves fluttering around or moats of dust and things like that where this is not an issue and maybe you don’t have to be quite so rigorous about how those are synchronized between players?
Erin Catto 00:23:56 Yeah, that’s a very interesting topic. So, I worked on Overwatch and Overwatch, when a character dies, they go into a physics simulation called a ragdoll where limbs of the character are represented as rigid bodies. Typically, they’ll have a capsule shape and then there’s constraints between the limbs to prevent the limbs from coming apart. This is very important and so you would have hinges on the elbows pretty much exactly like you would have on a seesaw. Anyhow, these Ragdolls and Overwatch are purely a client effect. They’re not simulated on the server, and they actually do not need to be simulated on the server because you have no way of really interacting with them in any way as a player that would affect the gameplay. A consequence of that is if you have two friends sitting side by side playing Overwatch on different computers, they may see the ragdolls head off in different directions, and for that game, that is fine.
Erin Catto 00:25:05 For the current game I’m working on, if a character dies and goes ragdoll, you as a player, you need to be able to go up to that character and interact with it, collect its food or collect its money or things like that. So, for that to be possible, the server needs to know about that ragdoll, and it needs to simulate that ragdoll. So, for some games you can do client only on some physics effects. For other games it has to be on the server, or it has to be replicated and it has to be part of the shared experience in some way.
Jason Davey 00:25:38 I see. So, it sounds like technological improvements open up the door for these things to be included in the design of a game that maybe wouldn’t have been feasible before. On that topic, can you maybe walk us through some of the milestones as you see it in the history of physics in games, maybe some key games that introduced things that have changed the landscape because they simply weren’t possible or had never been done before?
Erin Catto 00:26:00 For me, the game that changed everything for game physics was Half-Life 2. This was a game first person game that had what I call physics puzzles. So, you would have seesaws that you needed to interact with in order to advance further in the level or other destructible objects that maybe were blocking your path and you needed some way to destroy them. So that game introduced a lot of concepts in game physics. So that was in the 3D space. In the 2D space, the first thing that I saw that really changed things was the Crayon Physics game, and that was a game where you could draw shapes in the world and they would interact with each other, move as rigid bodies, and you would use those to solve puzzles. That may not be the most popular 2D game that had physics. Those of course Angry Birds really brought game physics into the spotlight as a mass market thing, so that was also very notable.
Jason Davey 00:27:10 Yeah, I distinctly remember both Half-Life 2 and Crayon Physics. Crayon Physics, you had a kind of canvas and a challenge to get one object from A to B through whatever means necessary, and you could draw objects with a crayon and spawn them into the world and create seesaws and ramps and slingshots and all of these interesting things. In Half-Life 2 I remember stacking boxes to get over an obstacle, which is something you didn’t often see before because for whatever reason stacking boxes seems to be something really hard to support in a physics engine. Can you elaborate on that problem?
Erin Catto 00:27:46 Yes. So, stacking boxes are kind of the bread butter of a physics engine. Physics engine programmers often look at this problem quite a bit, so it can be challenging to simulate boxes stacking because first of all, we have the real-time constraint. So, this becomes a problem with a stack of boxes because there are a lot of forces involved and all of these forces become interdependent. So, if I have a stack of 10 boxes, all these boxes are touching each other and the forces between the top two boxes has an influence on the forces on boxes lower in the stack. And to resolve that interdependency requires solving a large system of equations, and if we want to do that in real-time, we need to take shortcuts. It wasn’t widely known for quite a while how to make the right trade-offs there, what the right shortcuts were to compute those forces. So that is actually part of the art of game physics is finding out what are the right shortcuts that you can take to take something that’s an offline simulation to an online simulation, yet try to retain as many of the qualities of that offline simulation as possible.
Jason Davey 00:29:09 When you say offline simulation, you mean something that you would run as a batch job and stick on a supercomputer to churn away at as opposed to online being something you can run at 60 frames a second inside a game?
Erin Catto 00:29:21 Correct. So, there’s a principle for game physics, which is very important for performance is we are presented with systems that we have to simulate that if we were to write down all the equations for what we’re solving, it actually becomes a big matrix equation. So just filling out the matrix is an N2 operation and then solving that matrix would be an N3 operation. For games, we can only accept linear scaling, we cannot have quadratic scaling, let alone cubic scaling because as soon as you get into that space, then your performance becomes entirely unpredictable. It is non-intuitive to understand that, okay, I just doubled the number of boxes and now my performance has gone down by a factor of four or a factor of eight. It’s not sustainable. So, we have to figure out what are the right tradeoffs to take that large system equations and solve them approximately in the near time.
Jason Davey 00:30:29 I see. So, you mentioned the algorithmic complexity, linear time, N2, N3. What is a typical value of N in a modern game physics engine? How many objects might be alive and moving around the world?
Erin Catto 00:30:42 Easily in modern games you can have thousands of moving objects, and you may have tens or hundreds of thousands of non-moving objects.
Jason Davey 00:30:53 And I imagine separating those out so you’re not doing unnecessary work for objects that aren’t moving is a key optimization.
Erin Catto 00:31:00 Yes. One of the big complexities of a physics engine these days is managing that separation. So, first of all, we want to separate the truly static objects from the objects that are able to move. That’s one aspect. And then another aspect is for the moving objects, they may come to rest if a moving an object that could potentially move, like some crate just flew across the room, but now it’s settled in the corner while it’s sitting in the corner. I don’t want to have to pay for simulating that crate. It should be okay, it’s not moving, it’s come to rest. I want to put that to sleep and remove that from the active simulation. That process of sleep allows us to have very large worlds with thousands of objects, but we’re only simulating a small fraction of the awake moving objects, and that creates a lot of bookkeeping, a lot of data management in the physics engine. That creates a lot of complexity in that process of transitioning things between being awake and being asleep.
Jason Davey 00:32:12 Yeah, that makes sense. I imagine also you might have some objects on one side of the games world which are interacting with each other and another set of objectís way on the other side of the map, which are kind of in their own cluster. Is that something that also factors in here?
Erin Catto 00:32:27 Yeah, so that concept is referred to as islands. So, you can imagine these scenarios where yes, you have objects that are interacting in one space of the world and objects that are interacting another space in the world, but those two piles or groups are not interacting with each other. They may actually be touching the same floor, the same static object, but that interaction doesn’t travel through that static floor. So, these groups are established based on the moving objects and how they’re interacting with each other, and we can make many optimizations around that. Some physics engines will simulate those independently, and you could imagine I’m going to simulate these independently on different threads on the CPU on different cores, so now I’m able to parallelize that work.
Jason Davey 00:33:21 Absolutely. I feel like as soon as you mentioned multi-threading, we’re naturally moving onto the subject of how game engines are really architected. So, they don’t exist in isolation. How do they typically integrate into the game? What’s the division, for example, between the graphical representation of the games world and the physical representation?
Erin Catto 00:33:39 Right, so there is a division of labor for sure in a game engine between the physics simulation and then the rendering process. And there is nothing to say that the visual representation of the world has to align with the physics representation of the world. For example, you could have a wall in a game that happens to be a facade, and you could walk through that wall. Normally that’s not the case. Normally you would want those representations to align. So, the way that we get that alignment is through the authoring process of the content creator. They will create some visual representation and then alongside that, they will create a physical representation. Now if you’re just authoring a crate, you may have a very detailed crate with ridges and different features and textures on that crate. But then when you pass that to the physics simulation, it is just a box. So, there is an abstraction there between what is visual and what is rendered.
Jason Davey 00:34:47 I see. So typically, physical representation may be a simplification. One term you used earlier, which I didn’t pick up on was a capsule. Can you explain what a capsule is? It’s one of these; I think archetypal simplified physical representations. What is a capsule and why is it a useful primitive?
Erin Catto 00:35:03 Yes, a capsule is a very fundamental shape in most physicsí engines, and you can think of it as the shape of a pill. A pill which is a cylinder, but with the ends are rounded like spheres. And so, a capsule is just that. It is a cylinder with rounded ends, and that ends up being a very useful shape. It is, as I mentioned, it’s used for ragdolls, but it can be used for other things. It’s also used often for the character representation that we put in the world for something called a character mover or character controller. You can imagine your character is encased in a large capsule, so it is like a cylinder that’s vertical and it’s rounded on the bottom and rounded on the top. And then as you move through the world and maybe slide along walls, it is that representation that is sliding along the wall.
Erin Catto 00:36:06 And the capsule shape is very slippery. You could say it’s curved in all ways, but it’s not a sphere. It’s a little bit more human shaped than a sphere. So that’s why it has become so ubiquitous in game physics is because it provides that smooth surface, yet it has a little bit more detail to it than a sphere. And it’s very efficient to simulate because when we get down to the computational geometry part of it, it is just a line segment with a radius around it. So, there’s a radius around the central part, which is the cylinder portion, and then when we get to the end points, there’s a radius around it, which is the hemisphere part of it.
Jason Davey 00:36:52 I see. I suppose one thing that may not be intuitive to some people is that we maybe think of a sphere as a complex shape because it’s got an infinite number of sides or facets to it. But actually mathematically, in some sense it may be the simplest shape.
Erin Catto 00:37:06 That’s correct. When you collide two spheres in a physics engine and 3D, you just need to compute the distance between the two center points and then discount the radiuses of the two spheres, and then that gives you the distance between those spheres. So, it is very simple to do those calculations. It’s probably one of the simplest collision algorithms you can have in a physics engine.
Jason Davey 00:37:32 Whereas doing the same for a triangle or a box or a cube, even though we think of those as perhaps more primitive shapes computationally, it gets quite hairy quite quickly?
Erin Catto 00:37:41 Yes, you can actually think of it in terms of what is the number of points that I need to describe this shape. So, a sphere needs one point and a radius, a capsule needs two points and a radius, a box needs eight points. The radius is zero; a triangle has three points. The complexity you will see there ends up being quadratic in the number of points involved.
Jason Davey 00:38:09 I see. So, if an object in the games world can be assembled from primitive shapes like circles and capsules as opposed to being what we might picture as a polygonal model, it tends to be simpler or easier on the physics engine?
Erin Catto 00:38:22 Yes, absolutely. And this gets back to what I was talking about earlier where when we’re developing a game, we get to determine the content, we get to determine the abstractions that we’re going to make in the physical representation of the world. So when I’m making a crate, I would just make it as a box rather than giving it a detailed mesh with thousands of triangles because that is just going to have much better performance characteristics.
Jason Davey 00:38:51 I see. And again, on the subject of performance these days, developers are increasingly looking to shift work from the CPU to the GPU. Is that also true of physics engines in games?
Erin Catto 00:39:03 That is often something that is very interesting to look at, and there are lots of people that look at the end of the day though, often what happens is we want our physics objects that we have in our games to be interactive. We want the player to interact with them, we want to apply force to them, we want to know where they are in the world so that we could perhaps break them or play sounds for them or play visual effects on them. And this becomes very challenging if they exist on the GPU. So typically, rigid body physics is always done on the CPU. The good news is there are still many optimizations and CPUs are very powerful. So, we can do a lot on the CPU these days. Further, the realities of game development, especially at the high-end 3D level, is that the GPU is already very busy and often the CPU is not busy. So that creates a space for physics engines to come in and add some value to the game without creating a load on existing systems.
Jason Davey 00:40:17 I see. That makes sense. In terms of CPU side optimizations, then, you alluded before to multithreading, I imagine SIMD kind of techniques also apply. Can you talk about those a little bit?
Erin Catto 00:40:28 Yeah. So multithreading is very important for a physics engine. Ideally, we want to scale linearly with the number of cores. Generally, that’s not completely feasible in a physics engine because there are always going to be some serial aspects. The challenge is to reduce those serial aspects as much as possible. So, a lot of effort in the multithreading design for physics engines is about reducing those serial sync points. When it comes to SIMD, then it becomes important to look at the performance of things that are already being done in parallel and make those even faster. So, if I have, let’s say I’m colliding with two boxes together in the narrow phase and I want to compute the contact points. As I mentioned, the collision between shapes is quadratic in the number of points. So, what we can do with SIMD is we can take some of that work and have that work be done in groups of four.
Erin Catto 00:41:38 So for example, when I’m colliding two boxes together, I need to check every edge pair between those two boxes to see if they’re colliding or not. So, if you think about that, every edge pair is quadratic. So, what you can do is you can group up four edge pairs and then use SIMD instructions on the processor to solve for those edge pairs simultaneously. So, this is making use of instruction sets that have long existed on CPUs such as SSE2, AVX, or Neon. And these instructions are called SIMD because it’s a Single Instruction that takes Multiple Data, so that is SIMD.
Jason Davey 00:42:25 So by single instruction, multiple data, an example might be typically we think of A CPU being able to add two numbers together. SIMD allows you to pack four numbers from one set together and pack another four numbers and then add them all at the same time and read out the four results, which is why you talk about solving multiple things together in lockstep in groups of four.
Erin Catto 00:42:47 Exactly. So, it could be with SSE2 or Neon, maybe doing groups of four. There’s AVX-2, which lets you do groups of eight, and then there’s even AVX-512 that lets you do 16 at a time. And so that becomes very appealing that if I can organize my work, I will get this big boost to the computational processing.
Jason Davey 00:43:12 Yeah, all of this sounds very complicated and it raises the question in my mind of how do you test a physics engine?
Erin Catto 00:43:18 Yes. So, testing a physics engine is very challenging. However, we have some advantages. First of all, I mentioned earlier that we can do offline computations and that they should compare them to online real-time computations. So, we could take an algorithm that we’ve optimized and then compare that result with a brute force approach. So that’s one thing that we can do, and we can do that as unit test. That’s fairly straightforward to set up. Another thing that we have to our advantage is physics simulation is very visual. So, I always create some sort of visual representation of the simulation so that I can study it and make sure it looks right. I will add all sorts of features to that debug rendering, drawing the contact points, drawing the forces, drawing the mass, all sorts of details you can add there to track down problems. I’d say those are the main two tools that we have working for us.
Jason Davey 00:44:22 I suppose manual testing is still something that’s quite prevalent and still necessary in video games. Is that fair to say?
Erin Catto 00:44:28 Yes. So, the nice thing about a physics engine as an abstraction is if you can develop that as an independent library that’s independent of a game or independent of a game engine, then you can create an iterative environment where you can test very rapidly changing algorithms, changing approximations, changing your data format, optimizing things, and you can do that in a very focused way with a separate physics engine.
Jason Davey 00:45:03 I see. So, speaking of physics engines as separate libraries from games, let’s talk a bit about Box3D. So, you’ve recently released this engine. There’s a really great introduction video you have on YouTube, which we’ll include in the show notes where you demonstrate a lot of the key features. So, listeners can check that out. And I’d like to dig into your thinking a little bit behind some of the design decisions. Can you talk briefly about where Box3D and before that Box2D came from and some of the lessons in software design or architecture you’re bringing into the new version, the 3D version of this library?
Erin Catto 00:45:36 Yes. So, Box2D started out as a tutorial for a conference. My goal was to create a minimal set of code that shows how to stack boxes that hard problem that we talked about, which computationally is usually done in order and cubic time, which is not feasible. So, Box2D started out as about 200 lines of code that showed here’s how you can stack some boxes in linear time and it’s stable. And then I didn’t expect it, but that code was picked up and people started making games with it. And so, then I realized there was actually a thirst for this technology to be shared, and so I decided to make that an open-source project.
Jason Davey 00:46:20 So this is the era where Crayon Physics, for example, came about. Is that one of those early games which used your library?
Erin Catto 00:46:26 Correct. And this was around 2006, 2007 that Box2D came out. And that was also the time when the iPhone came out, and then people were able to easily download games to their phone and people found that they could write games using physics to create a lot of engagement on that platform. So, this really was kind of a golden area of 2D game physics. That project evolved over time, and I used it as a vehicle for testing out new physics algorithms, new techniques that I then used in my 3D work at my regular job. But on the side, I was developing this 2D technology. And so that evolved over the years. It had starts and stops on and off. Around 2022, I decided I wanted to really see how far I could push Box2D in terms of performance. Up to that point, it had been more, in my opinion, pedagogical, it was a learning platform for myself just to try new solver techniques, new algorithms.
Erin Catto 00:47:43 It transitioned from being a C++ library to being a C library. It had multithreading, it had SIMD, the solver changed just about every aspect of the library changed, so this was a bit disruptive. So, it was a major version change. And nevertheless, it’s been fairly well received. People are very happy with the performance. And then I took that technology into 3D as part of my work with Kintsugiyama into the engine Box3D, and that’s been evolving for the past few years. And that was just recently released as Box3D, and that really is the sibling project of Box2D. The goal there is to keep them very similar. So, if you’re going from 2D to 3D, it’s very similar experience.
Jason Davey 00:48:35 Awesome. So, some of your demos with the Box3D show very large scenes with large numbers of dynamic objects. Can you talk about some of the techniques you use to achieve that? I think some of them may have mentioned already in terms of islands and sleeping objects and things like that.
Erin Catto 00:48:50 Yeah, so first of all, there’s heavy use of multithreading, the broad phase that I mentioned earlier, finding all the pairs of objects that might be touching, that’s done in parallel, the narrow phase, finding all the contact points between the objects that’s done in parallel. And then the big challenge for multithreading for game physics is the solver. We talked about islands as being one potential way of multithreading the solver aspect that can start to fall apart though when you have very large islands. So, I decided to take a different direction than using islands for the solver aspect, what I do there is graph coloring, graph coloring of the connections between the shapes. So, the contacts, the contact points, those get colored according to what bodies they’re interacting with. And with this graph coloring technique you can find, so say color one is red and then color two is green, and color three is blue.
Erin Catto 00:49:58 So now you’ve bucketed all these constraints into red, green, and blue. I know because of the graph coloring that all the contacts that have red, none of those are touching the same two bodies. So, you can think of those as micro islands. So, all of those contacts that are color red, they are not touching the same bodies. So, what you can do is you can say, well, okay, I have a thousand contacts that are color red. I can solve those in parallel. So, I have a thousand contacts that are red, and I will split those up and maybe solve those in chunks of maybe 10 contacts at a time on the various cores. And it’s just like a parallel four basically when it comes to multithreading that and then you go to the next color and then do a parallel four on that, and then the next color until you’re at the end of the color range.
Jason Davey 00:50:55 I see. That makes sense. Box3D also includes quite comprehensive features for recording and playback of physics. Can you briefly explain how that works and maybe give an example of where it’s helped you on your current game project?
Erin Catto 00:51:07 Yes. So, this recording and replay feature has been very beneficial. The way it works is it has to first create a snapshot of the entire simulation of the world. This is needed because game physics engines do a lot of caching. They use a lot of temporal effects to keep track of things frame over frame. And so, they have a lot of internal states. So, the first job of that system is to create a clone of the world as a single blob of data essentially. That is easier than I expected in Box2D and Box3D because it’s a very array heavy engine. Things are just stored in arrays of data. And so, when it comes to that serialization process, I am just basically doing mem copies of big arrays. So, its plain old data, so that makes it fairly straightforward. And then how it proceeds is I have that initial snapshot of the world, then I record all the inputs to the world. So, if you applied a force to a body or you change the friction value of some material or you added or removed the body, all those events get recorded into the stream. And then when you go to replay what it will do, it will create a new physics world, load that snapshot into it, and then as you’re viewing that replay, it will replay those events that were recorded and it will actually do a live simulation there. To make that work, it relies on the entire process being deterministic.
Jason Davey 00:52:54 I see. And can you give an example of a specific gameplay or physics bug that helped you to debug?
Erin Catto 00:52:59 Yes. So, in our game, the Legend of California, we have mining and we’ve been working on improving the features of that system and making it feel more visceral, more physical. So, we have mining with voxels, but they’re not Minecraft style mining. It’s more these voxels are curved and we build meshes around them. So, when you’re mining, you will have a pickaxe, and you hit the wall with the pickaxe and then chunks will break off. So, we started making those chunks have a higher fidelity of shape that represent the pieces that are removed. However, we were not quite happy with how the pieces moved when they became physical, when they became rigid bodies. And it was hard to see in the game exactly why that was. There’s a lot of high movement speed. It’s hard to visualize all the collision that’s there. You’re in a mine, it’s dark, the lighting’s not maybe ideal.
Erin Catto 00:54:07 So I made a recording of that and then I was that digging process in the mine. I brought that into my replay viewer, and then I was able to scrub time forward exactly to the point where those chunks of material were spawned. And then I could observe what did they looked like, what’s their physical representation look like? Are they capsules? Are they convex holes? And when they spawn into the world, are they overlapped with the wall or are they in free space and what is causing them to move the way that they’re moving? And so, with the system, I was able to do this task in just a couple hours, which if I was trying to do this within the game engine, it would’ve been much more difficult.
Jason Davey 00:54:56 Yeah, that sounds super powerful and I know that the game development community is very excited about Box3D and who knows, maybe it will promote a generation of physics-based games in the same way that Box2D did. Erin, it’s been really great discussing video game physics with you. Are there any major areas we didn’t cover, which you’d like to mention briefly before we wrap up?
Erin Catto 00:55:14 I think that’s it. I’m very happy with the reception for Box3D, and yes, part of my goal is to inspire people to make games with fun physics aspects.
Jason Davey 00:55:26 Amazing. So lastly, if people want to follow you or they’re interested in tinkering with Box2D or Box3D in their own projects, where can they find out more?
Erin Catto 00:55:34 I recommend first head to Box2D.org. That also covers Box3D. And then I also have a YouTube channel that you can find using my name very easily. And I like to post fun physics videos there.
Jason Davey 00:55:49 Awesome. Thanks again, Erin, for the discussion. We’ll be sure to include those links and other useful resources in the show notes [email protected]. Thank you all for listening. This is Jason Davey for Software Engineering Radio signing off.
[End of Audio]
