My own physics or BEPU?

Norbo (the creator of the BEPU physics engine) dropped by the day before last to let me know that I should expect much higher performance than what I was seeing in my BEPU tests. He suggested that I should be seeing about 25ms per frame on the XBOX, to simulate 400 spheres colliding against a terrain. I thought it took more like 150ms.

This is Morbo, but that's who I think of whenever I see Norbo's name. Also I like pictures in my posts.


The following code creates 392 spheres. I replaced the code in the BEPU terrain demo that adds boxes to the terrain with this code, to do a quick benchmark of spheres on a terrain.

Random rand = new Random();

for (int i = 0; i < 7; i++)
    for (int j = 0; j < 7; j++)
        for (int k = 0; k < 8; k++)
            Vector3 position =
                new Vector3((float) rand.NextDouble()*10 + i*128,
                    400 + -j*2,
                    (float) rand.NextDouble()*10 + k*128);
            float radius = (float) rand.NextDouble() + 1;
            Space.Add(new Sphere(position,
                radius * radius * radius));

First, I want to point out that BEPU is an awesome project, and is generally very efficient from what I’ve been able to measure.

My physics simulation is much, much more limited in scope compare to BEPU. I don’t support any type of constraints, and I don’t have accurate restitution or friction.

In the BEPU terrain demo, on my E5300 2.6Ghz, overclocked to 3.0Ghz, on a single thread, the 392 previously mentioned spheres start the simulation updates off at about 1-2ms (when all spheres are in the air) until all of the spheres hit the terrain at which point the simulation takes 7-17ms per update, until all of the spheres reach a resting (inactive) state, where the simulation takes 2ms per update.

On the XBOX 360, this same simulation starts at 7ms per update, and then as soon as the spheres hit the terrain, the simulation jumps to 60ms per update, and steadily increases to well over 100ms per update over the course of the next 1-2 minutes, until it eventually starts to speed back up as spheres start to become inactive.

Edit: Testing with a much flatter terrain resulted in update times of around 30ms per frame with the default setup. Excellent! BEPU totally wins then.

Under similar conditions in my game (so the terrain is a different shape), my simulation takes 30ms per update on the XBOX 360, when all 400 spheres are in the air, falling at high speed under gravity. It starts slow compared to BEPU because I always sphere-cast spheres against the terrain no matter what, since they usually will intersect the terrain in the case of this game. The simulation then continues to about 35ms when the spheres hit the terrain, and updates continue to take about 30-35ms as the spheres eventually slow down.

Edit: some simple optimizations reduced this time to 21ms.

Of this 35 ms, the breakdown is:

  • The sweep and prune broadphase takes 3ms per update.
  • The sphere-terrain contact point detection/generation takes 7ms per update, and the sphere-sphere contact point generation takes 23ms per update.
  • The collision solver takes a total of about 3ms

Implementing a resting/inactive state would greatly reduce the 31ms of contact point generation after 30-60 seconds into the simulation, as most of the spheres would no longer need to generate a new contact points unless they started moving again. Implementing this optimization is not a priority right now, but I’m very curious to see what can be done with that.

In my simulation, 7 contact points (this is somewhat arbitrary) are generated for every sphere with the terrain no matter what position and velocity the sphere has. This is a place for some optimization if desired.

I generate a completely new set of contacts every single update. I think BEPU might persist contacts across multiple frames. I’m not sure if it’s practical for me to do this or not — I haven’t given it much thought yet. I’m also not sure how this affects BEPU performance.

A screenshot of the physics simulation running on the XBOX 360, while the white spheres are still rolling around on the terrain.

In the end, the difference between BEPU and my physics for this somewhat unscientific preliminary comparison seems to indicate that BEPU is about 3x slower for 400 active spheres colliding with a terrain at not very high speed. (In my simulation ~1m radius spheres travelled at speeds in the range of 1m/s – 20m/s).

Again, my simulation is limited in what it can simulate compared to BEPU, but it looks like in the special case of my game, where I want many spheres with only sphere-sphere and sphere-terrain contact, and I don’t care about accurate rotation and friction simulation, it looks like my physics simulator might make more sense.

I’m going to do some more tests, and get in touch with Norbo to see if there’s something I’m missing here, as I’d prefer to use the much more flexible BEPU if I can.

If I had to take sides right this moment though, then I’d say that it looks like I’m stuck with my own physics simulator.

Edit: BEPU may have won. I might be able to get a slight performance improvement over BEPU with a lot of effort, but BEPU’s performance is excellent under the new test conditions, and has way more functionality than I have implemented. The only remaining question mark is the large difference in speed between different test conditions in BEPU (placement of spheres and terrain shape), where in my simulation, things are pretty a constant 30ms per update (on XBOX) across the board for 400 spheres with the same tests used with BEPU.

This entry was posted in Coding, DBP2011, XNA. Bookmark the permalink.

One Response to My own physics or BEPU?

  1. Maggie says:

    Hola, Navegando en esta página tuve la fortuna
    de encontrar esta educativa información que compartes que hace
    referencia a esta dolencia de la que he estado estado buscando información, ya que en mi familia varios miembros la sufren.
    Muchas gracias por este gran aporte.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>