Given how widespread the usage of Box2D has been over the last decade+, I truly hope the creator has seen some form of financial benefit from it. His work is awesome and has benefitted the gamedev community immensely.
He mentions Jolt physics in this blog. That’s another example of “holy shit look at what one person can do”. I’ve found myself wishing I had Unity source so I could performantly inject that engine instead of being stuck with PhysX.
Jolt physics is an amazing piece of work way above my level of understanding, but as someone who loves physics in video games I always enjoy learning a bit about how it all works:
My understanding is that they process batches of edges at a time. If they "conflict" (meaning they want to do different things to the data structure) then they're processed in serial, otherwise all edges in the batch are handled sequentially. They provide a bound on how often edges should conflict, and use that to show the complexity.
I'm the last one to shill specific styles or languages, but:
class b2Island
{
b2Body** bodies;
b2Contact** contacts;
b2Joint** joints;
int bodyCount;
int contactCount;
int jointCount;
};
I understand that this is a physics engine and performance is paramount.
There is absolutely no real reason to use raw double pointers here, in my opinion there is likely a zero Overhead datastructure one could come up with to do exaftly the same thing, but unit-testable.
Further, why `int`? This isn't java, and this will cause any size comparisons to become unsigned-vs-signed comparisons, which likely will also be of different sizes. I'm saying those could and should be size_t, unless I'm missing something(?). Why would a count be negative? Why only allow a count up to int max, whatever that is on a given platform?
It just baffels me that people write serious business code in this style, still.
Edit: If the pointers are non-owning, there are references for that... Not that they're safer, but at least more idiomatic
Sometimes it's just wrong parameters (e.g. too low density, too low gravity, ...), but the 'jelly-like' behaviour may also help to keep the simulation stable (sometimes in games you can see the physics simulation explode, e.g. stuff being catapulted with near-infinite speed into space, putting some dampening into the simulation and allowing some 'slack' for resolving object intersections can help to avoid that, but also makes everything feel more jelly-like).
It's due to using a Gauss–Seidel solver which iteratively solves each constraint rather than a global solver that solves all the constraints at once. The reason to use the iterative approach is that global solvers can end up with unbounded runtime or without a solution in some cases. The downside is that some constraints are left unsatisfied after you've run through your fixed set of iterations so it takes time to converge. With big stacks you have a lot of constraints and it can take even more time to converge as errors propagate energy through the stack. You can solve this as a sub-problem by itself and maybe the 'large islands' work will tackle that.
TLDR; with iterative methods stiffness of things depends on the physics timestep size and number of iterations of constraint solving.
:) This was the same conclusion I came to when I first started researching this in video game design. No idea if there's actual merit to it, but the parallels are uncanny to be sure.
He mentions Jolt physics in this blog. That’s another example of “holy shit look at what one person can do”. I’ve found myself wishing I had Unity source so I could performantly inject that engine instead of being stuck with PhysX.