Particle optimizations

[devmelon]

Hello world.

I am looking forward to hear if there are any suggested ways to improve physics on a large set of particles? Currently I have used collision filters and masks to avoid as much collisions as possible. I am currently using btSphereShape because I think it is fast enough. Are there other ways I can still improve my particles? My only requirement is that they bounce off walls and such. Rotation and other features aren't neccessary. I cache rigid bodies in my system, so I don't have to re-create new shapes/bodies all the time. I only add bodies initially. At current state I am using ~150-300 particles with bad performance on a high end computer. It would be very nice if I was allowed to have more particles. Am I dreaming, is this even possible?

My world consists of several bodies to collide against, however most of the geometry are static btBoxShape. A few are dynamic btConvexHull.

I am not sure but it seems the program slow down when particles pool.

Thanks in advance

[rpita]

Hi!

I'm new to Bullet but maybe the following tips can help you.

- Do you have compiled your application in release configuration so far? It's a huge performance gain.
- Check your broadphase type and parameters. It's likely for particles, that they move very closely in a small space compared to the measurements of the world. For example that's the worst case for sweep and prune algorithms as far as I know.

[devmelon]

Do you have compiled your application in release configuration so far? It's a huge performance gain.

Yes, it is a release build with release libraries. Running debug ends up at around 1-2 fps. This is however due to very unoptimized shadows. Release builds yields better results but the problem was introducing each particle having a rigid body with a sphere shape.

Check your broadphase type and parameters. It's likely for particles, that they move very closely in a small space compared to the measurements of the world. For example that's the worst case for sweep and prune algorithms as far as I know.

I am not sure which broadphase type we are using at the moment but it haven't caused any problems so far. I will sure look into this matter, maybe we've been using wrong broadphase all the time? The particles move about the same speed as the rest of the game objects. However, there are far more particles than other game objects. This means that any resource hogging game objects are neglected because there ain't any big numbers of them in the map.

Thanks for your input. I will look into the broadphase.

Still, if anyone have suggestions as on how to optimize particles, please contribute with your input. Don't be shy

[Erwin Coumans]

At current state I am using ~150-300 particles with bad performance on a high end computer.

Something must be wrong. Normally you should be able to simulate at least 500 to 2000 rigid bodies in real-time on a decent computer, above 30FPS. We are now working on some demos using 20.000 rigid bodies (not particles) in real-time with Bullet, using CUDA.

Can you create some performance statistics of an optimized/release build using "CProfileManager::dumpAll()", right after the stepSimulation, and attach its zipped output?
Furthermore can you create a COLLADA snapshot and include that as well, so we can analyse the data.

Thanks,
Erwin

[devmelon]

Something must be wrong.

Well, that wouldn't be the first time that happens

Normally you should be able to simulate at least 500 to 2000 rigid bodies in real-time on a decent computer, above 30FPS.

Could it be because the particles all pool up in the same spatial locations? Remember, they don't self-collide, so a small portion of space could hold 100s of particles.

Perhaps we should revise our particle demands. I think it would be sufficient enough to kill the particles upon collision with any objects, reducing the need for rigid body physics.

Can you create some performance statistics of an optimized/release build using "CProfileManager::dumpAll()", right after the stepSimulation, and attach its zipped output?

I can do that in a while, but at the moment I have been given other pressing issues. I will try to get back here as soon as I can though. Deadline crunching is always fun, isn't it?

[rpita]

Could it be because the particles all pool up in the same spatial locations? Remember, they don't self-collide, so a small portion of space could hold 100s of particles.

That's what I addressed with my second assumption regarding the broadphase above. Try out the btDbvtBroadphase. That can improve the performance when using many moving objects in a small space. Did you already double-checked your collision mask of the particles for avoiding particle-particle collision?

[devmelon]

Could it be because the particles all pool up in the same spatial locations? Remember, they don't self-collide, so a small portion of space could hold 100s of particles.

That's what I addressed with my second assumption regarding the broadphase above. Try out the btDbvtBroadphase. That can improve the performance when using many moving objects in a small space.

We haven't had time to play around with the physics just yet. The particle system is put on hold until we get some more stressing features handled, but I will look into it asap.

Did you already double-checked your collision mask of the particles for avoiding particle-particle collision?

The collision filter group for the particles have a flag not used by any other object in the game, and only that one flag. The particles have a mask that allows for collision between static objects and certain game objects but not particles themselves. Also, looking at the simulation (both with debug lines and without), one can clearly see that the particles are not colliding with each other. They behave as if there was no other particles but themselves in the world.

I have scheduled to do a performance dump of the physics simulation to post here, and I've planned to investigate the whole broadphase thing. I hope to be able to do so this week. If not, then next.