Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'd like to use either Bullet or ODE on low powered devices (mobile and consoles), but the frame rates are below the acceptable 25-30fps for simulations.

I've found that one articulated body by itself is enough to degrade the performance of either engine.

Are there optimizations or tricks I can use to get around these problems?

share|improve this question
An articulated body is not light on a physics engine as many shapes will be close to eachother and need to be tested for penetration (assuming they are jointed close together). What amount of shapes, what kind of shapes and what kind of contraints are involved? –  Kaj Aug 19 '10 at 7:34
I'm using exactly 1 vehicle and a few boxes on a flat terrain. 2 vehicles was too much. With ODE, I think the vehicle is especially the problem since it is using 4 hinge joints. –  zmdat Aug 19 '10 at 12:28
Are you using btRaycastVehicle? I see you said the terrain is flat, but what kind of physics primitive is it? just a plane? –  Chris Howe Aug 19 '10 at 13:27
Currently using Bullet's raycast vehicle and a plane for the terrain. ODE provides no raycast vehicle out of the box so I may go with Bullet simply for the speed advantage. –  zmdat Aug 19 '10 at 18:26
It's really hard to know what your performance-issues are without providing some sort of performance-trace. What's hogging your cycles, what is your integration time etc. It could be something as simple as your data being unordered all over the memory which causes unneccessary l2-cache misses. Please provide some sort of profiling so that we can investigate the issue further. –  Simon Aug 22 '10 at 12:08
show 1 more comment

3 Answers

I've used Bullet on a fairly low-powered console with a scene containing a couple of dozen boxes. Maybe the issue is with your scene setup? What collision shapes are you using? Try to use simple collision shapes such as boxes and cylinders, rather than convex hulls.

Take a look in btScalar.h and make sure you are using any platform-specific math routines you have access to. Make sure you aren't using double-precision. Does your platform have hardware FP support?

I have never used it, but Bullet contains some profiling functionality. It may help to determine exactly where in Bullet you are spending the most time.

share|improve this answer
It looks like I will have to learn ARM VFP and NEON assembly to improve that area in Bullet. –  zmdat Aug 19 '10 at 12:37
@mdat: take a look at code.google.com/p/vfpmathlibrary and surrounding code.google.com/p/oolongengine for inspiration =) –  leander Aug 22 '10 at 15:11
add comment

If your target devices don't have hardware floating point support (many don't), you should look into converting the engine to fixed-point math. I'm not sure of whether this is just a matter of changing a define or potentially a whole rewrite though :-(.

At any rate, http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/IntroductionToFixedPointMath is a great resource for learning how fixed-point works.

share|improve this answer
add comment

In bullet you can skip the broadphase. It is a pre-phase supposed to find and collect potentially colliding objects, an optimization for bigger scenes, but since your scene is simple, you know your colliding objects anyway. ODE has something similar IIRC.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.