Box2D Forums

I'm adding more robust physics to my game engine. I already had two physics engines incorporated into my engine for evaluation, one of which is Chipmunk. There are a few advantages that Box2D has over Chipmunk that prompted me to also incorporate it into my engine to do a direct comparison against Chipmunk (Continuous Collision Detection, Sleep state for non-moving bodies, and from anecdotal sources, better performance). The problem is that Box2D is performing substantially worse than Chipmunk, both under Windows and iPhone, under the exact same testing conditions within the exact same framework (4 static rectangular shapes forming a box, which is filled with 50 dynamic bodies with circle shapes).

The reason I'm posting is to be certain that I'm not doing anything wrong that is negatively impacting Box2D performance. I'm hoping that those familiar with Box2D can peruse my source to see if anything looks out of place. I would really like to use Box2D because of the CCD and sleeping, but performance trumps all.

World creation:


Body creation. 50 bodies with circular shapes are created, 4 with rectangular shapes:


World update:


Each frame I update each object to retrieve its position and rotation for rendering with simple calls to GetPosition() and GetAngle().

At this time I'm not doing any collision events / processing whatsoever in my framework. What you see here is all that's going on.

Now one thing I do note is when the bodies finally all settle down and stop moving, FPS jumps way up, so obviously Box2D is able to sleep many of the bodies. I'll do a test with more complex shapes to see if Box2D improves in that area. However my engine will mainly be dealing with simplistic objects.

Considering Chipmunk is vaguely based on earlier version of Box2D, I would be surprised if the performance is significantly different. But you have to be careful to test the same thing on each.

The biggest structural change between the two is that Chipmunk uses a spatial hash for the broadphase. This is likely faster in general, but Erin opted against it as it requires more "tuning". Sweep-and-prune, the Box2D broadphase, will possibly outperform it if you have very different scales of bodies (though both perform badly), but not for the test you propose. The good news is, Box2D's broadphase is "pluggable", so should not be difficult to write a spatial hash broadphase.

Other than that, I think the most likely source of the discrepancy, is that Box2D has continuous collision detection, while I don't think Chipmunk does. This a powerful feature, but it could slow things down. Try SetContinuousPhysics(false). But as you have mainly nonbullet dynamic bodies, I'm not sure how much difference this will make.

Also, ensure that you are running under the same parameters. I see you've set iterations=1 for Box2D, which is unusual. Are you running Chipmunk at 1 iteration too?
It would probably be fairer to test both under a more reasonable value (like 10, the chipmunk default), but I doubt it will effect your results, unless you have a large pile of objects (in which case, the pile will probably collapse on itself).
You might even consider setting different iterations for both, but trying to equalize "physical stability", so you can truly see which would perform better for a given level of output.

Your other parameters are a bit out of whack too. 12.5 is a bit large on Box2Ds scale, but nothing to worry about. But you have set inertia to 1.0. For a circle it would usually be 0.5*M*R^2, or about 15000. Or am I missing a call to SetMassFromShapes later in your code?

Thanks for the reply. First, I read in the wiki that "performance" is affected by scale. I took that to mean performance as in behavior, not speed. However I went ahead and scaled everything down by 1/10, and performance did increase. At this point Box2D is running faster than Chipmunk, particularly after all objects have collided. That seems really strange to me. Is it reasonable that the size of shapes affects performance? I'd really like to get a handle on what is going on, so if that is not possible, then I'll dig deeper to see what is going on.

Yes, I did forget to copy / paste one line from my source. I call SetMassFromShapes() last after the body and shapes have been created for each object. I removed the code where the mass data was set explicitly, as it was being discarded by SetMassFromShapes().

I now have a different problem. My circles are overlapping quite a bit, some easily by 50%. Also the simulation is very bouncy. I can drop a large circle onto a pile of smaller circles, all shapes having 0 restitution, and the large circle will invade down into the stack and then be thrown back up into the air. I don't have this problem with Chipmunk - the objects simply feel more solid. Am I missing something else here?

Thanks again.

You want
Step(dt, 10);
not
Step(dt, 1);

Iterations doesn't mean looping steps internally, it is iterations of convergence for the solver. It needs to be at least 10 for physics to look remotely rigid. Chipmunk's default is 10, so you should compare them the same at that.

Regarding scale, have a look in b2Settings.h, which contains "tuning parameters" which are scale dependant. I think if you correctly change all those, Box2D will work at any scale, but it's better to not touch them. By default they are tuned to work best with objects between size 10 and 0.1.

Chipmunk also allows you to specify the iterations during the step, and I was also using 1. Using 10 does seem to help overlap, but not springiness. If I drop the big circle all the little ones seem to still compress a lot, and spring the big one back out in the air. The iterations also kills performance. From 60 to 30 on an iPod Touch 2G with all other settings the same.

The Box2D configuration you mention does make sense as far as the performance with larger objects.

Dan

You may have already done this, but it's worth double checking that you aren't using "Compile for Thumb" on the iPhone - this is a major performance killer for Box2d, since it cripples floating point speed. Further, try running in release mode instead of debug, and check that you've got -Os (Fastest, smallest) optimizations enabled (I've seen a bug with the iPhone compiler's -O3 optimizations that causes instability in Box2d, so avoid that one).

Re: springiness, if there's a huge mass discrepancy between the big object and the little ones, there's pretty much no way around that, it's a fundamental limitation of just about any physics engine (the "heavy on light" problem that we've discussed several times here).

As for the other performance issues, I'm not entirely sure what's going on, from what I've heard anecdotally Chipmunk and Box2d tend to have similar performance, but I don't know Chipmunk too well myself, so I'm not sure.

Can you profile things (Run->Start with Performance Tool->CPU sampler) under both and see where the bottlenecks are for identical situations? On the iPhone I've found that there are lots of non-obvious ways to bottleneck the thing, and half the time the problem isn't your code, it's something odd that's happening graphically or something like that.

Thanks for the excellent suggestions. I am working with the Release build, and had already checked the compiler optimizer setting, and it is set to -Os. However, Thumb was indeed checked, and after rebuilding everything I picked up at least 20% FPS. So many thanks for that one. Of course that improved both Chipmunk and Box2D. Right now Box2D is running around 25% faster than Chipmunk.

I will do some profiling soon, but I wanted to take care of the gross performance problems first, and so far two are eliminated (scale of objects and compiler for thumb).

Dan