It seems like no matter what I work on in Blackspace, I can never quite step away from having fun with rigid body physics. Some might have already gathered from Jerry’s dev blog post (looking at the top-left window icons) that we are using XNA and various other frameworks at our disposal. I plan to get to that all in time, but the most important one of them all - not because of the API code size but because of how it will integrate into the core gameplay experience - is our physics system. So I figured it’d be good to briefly touch on how we’ve integrated BEPU into our framework, and before I do that, I want to point out that BEPU is simply great in just about every way. The demos are to the point and the forums are very active and helpful thanks to “Norbo” who answers just about any question posted on there.
Here’s a “stress test” shot of boxes scattered about on the planet using BEPU:
When we were working on prototype tech, right off the bat, we pretty much knew we wanted to use a 6-sided-normalized-cube mesh that would be utilized as a height map for physical interaction with a planet-like surface, . I’ve already seen a handful of other projects utilizing a similar scheme, though in most cases, they usually talk about rendering a planet surface, rather than the physical interaction aspect.
The idea is fairly simple. For each vertex on the cube’s faces, you normalize the vertex position using the distance from the origin of the planet, which creates a spherical mesh. While there are some caveats like mesh density and potential seams that would have to be treated with care, hardly any of the cons out weigh the pros. All of the benefits are all in line with most flat terrain technology utilized in big open world games. That said, almost none of the physics engines that I personally know support what we now refer to as “Cube-Terrains” (or spherical height maps). So in BEPU (and previously in JigLibX before we moved to BEPU), we added cube-terrains as a new primitive type.
In the case of terrain-like collision detection, BEPU calculates a set of potential triangle hits from the terrain and in a later call will go on to calculate the contact positions and normals. While the speed of a cube terrain lookup helps in retrieving the potential collisions, the good part about this is that the rest of the processing for collisions happens similar to how another polygon-soup mesh object would work. So we do not have to re-implement cube-terrain to sphere, box, cylinder, capsule etc. collision methods. It all gets filtered though the same pre-existing BEPU functionality. Unfortunately with JigLibX, this process is a bit more manual for the programmer.
BEPU already has demos showcasing rigid body dynamics on planet-like spheres with point gravity (instead of directional gravity in most games), so I won’t go into the details there. The results are pretty much as expected. I did have to come up with a hybrid gravity fall-off as the realistic gravitational calculations are either too “floaty” or “strong” depending on the distance from the origin, and such drastic fluctuations make the gameplay extremely tough to tune.
What you’re seeing in the screen shots above as the gray wireframe boxes are physics “islands” and one can simply think of them as a way to do physical interaction pruning and this is how BEPU handles complex cases of stacking, be it horizontally or vertically.
That’s it for now.
-Volga
