CPU usage grows linearly with number of static bodies

[pico]

Hi,

we currently have some problems in our game due to the way bullet handles bodies.

Each simulation step bullet goes through ALL bodies and does some testing on them. Things like isStatic, saveKinematic, applyGravity etc.
Those tests are very quick. Anyway, the cpu usage for those tests of course grows linearly with each body tested.

In our current (Wii) game, when using only static meshes, the Bullet CPU usage is like this:

256 Static Bodies=1.71% CPU (average) 2.45% CPU (peak)
1024 Static Bodies=9.01% CPU (average) 10.16% CPU (peak)

Those 10% really hurt, especially as nothing is going on.
Those bodies are all btBvhTriangleMeshShape. Due to various reasons they cant be grouped into an array.

What about having Bullet using two arrays? One for dynamic/active bodies and one for static/inactive. This should speed up thing for all games using a large number of non grouped meshes or large numbers of moving bodies that are mostly inactive.

[Erwin Coumans]

Can you provide more detailed break-down of this 10%?
We could make improvements, but we need to know more in details where exactly the cycles are spend. It shouldn't apply gravity for those static objects.
Could it be in btCollisionWorld::rayTest or btCollisionWorld::performDiscreteCollisionDetection?

What kind of operations/queries do you perform for those static btBvhTriangleMeshShape objects?
Thanks,
Erwin

[Erwin Coumans]

By the way, this upcoming improvement might help you:

http://code.google.com/p/bullet/issues/detail?id=128

[pico]

Can you provide more detailed break-down of this 10%?
We could make improvements, but we need to know more in details where exactly the cycles are spend. It shouldn't apply gravity for those static objects.
Could it be in btCollisionWorld::rayTest or btCollisionWorld::performDiscreteCollisionDetection?

What kind of operations/queries do you perform for those static btBvhTriangleMeshShape objects?
Thanks,
Erwin

Hi Erwin,

the cycles are not spend in actually doing something, they are spend in the test functions for each body before doing something.
There are no raycasts or other functions called. Just 1024 meshes added. Of course the problem is also related to the substeps. In my case i have 4 substeps. Many function tests get again called for each substep.

Here are some of the functions that go through all bodies and do tiny tests.

Those are called for all bodies:
saveKinematicState()
applyGravity()
clearForces()
synchronizeMotionStates()

Those are called for all bodies multiplied by substeps:
predictUnconstraintMotion
performDiscreteCollisionDetection();
integrateTransforms()
calculateSimulationIslands()
updateActivationState()

With 1024 objects and 4 substeps Bullet this sums up to 24576 test cases. When i take this number and divide it by the CPU cycles spend then we have 44 cycles for each test. With each test i mean each iteration in the above functions. 44 cycles sounds a bit much for that operation but for risc cpu quite possible.