Trying to locate performance sink

[Dragonlord]

Went up to 2.64 ( one day later you send out 2.65, well, should not change the problem ) trying to fix a performance problem but it's still there. I'm not sure what causes it since profiling shows that the time eater is an internal call in the library. I tried using the bullet profiling class but to no avail ( chances are I don't get how your profiler works ). Most probably something wrong on my end but I'm a bit stuck on where to start looking.

There's a scene with a couple of terrains and objects all using btBvhTriangleMeshShape as their shape. All terrains have the CF_KINEMATIC_OBJECT flag ( since giving them CF_STATIC_OBJECT as it should be causes asserts all the time ). All other objects are mostly CF_KINEMATIC_OBJECT and a few dynamic. Therefore the collision world consists of mainly static ( kinematic flag ) triangle meshes and a few dynamic ones.

For narrowing down the problem I've set everything to static ( kinematic due to asserts ). btDynamicsWorld::stepSimulation( 0.01, 1 ) eats for this simple configuration with nothing moving ( all disabled! ) and less than 200 triangle meshes incredible 17ms time. This would be not much of a problem if this would be many objects moving but this is a setup with everything disabled and nothing moves.

What's going on? Bullet allergic against objects with kinematic flags? Did a new triangle class emerge that I didn't notice ( btw, documentation is hell out of date... grep-ing through .h files is not so fun )? Or is there simply no way to get past this high idle time waste?

I would like to get some headsup on this problem before I start messing around replacing internal classes with modified ones. No sense trying to optimize something if it can't be optimized ( although in this particular case it would surprise me ).

EDIT: Forgot to add something. All static ( kinematic due to asserts ) terrains and objects are triangle meshes but all dynamic objects are boxes.

[Erwin Coumans]

Went up to 2.64 ( one day later you send out 2.65, well, should not change the problem ) trying to fix a performance problem but it's still there. I'm not sure what causes it since profiling shows that the time eater is an internal call in the library. I tried using the bullet profiling class but to no avail ( chances are I don't get how your profiler works ). Most probably something wrong on my end but I'm a bit stuck on where to start looking.
[/quote]
Can you upgrade to Bullet 2.65? It has a better profiler, please search for 'm_profileIterator' in Bullet/Demos/OpenGL/DemoApplication.cpp

There's a scene with a couple of terrains and objects all using btBvhTriangleMeshShape as their shape. All terrains have the CF_KINEMATIC_OBJECT flag ( since giving them CF_STATIC_OBJECT as it should be causes asserts all the time ).

What is the assert exactly? It sounds like the collision flags are not setup properly. Is there any console output?

Erwin

[Dragonlord]

The terrain is a triangle mesh that can be located anywhere in the scene. Hence while creating the rigid body I have to position the triangle mesh. Doing so though with CF_STATIC_OBJECT causes an assert but works with CF_KINEMATIC_OBJECT. This situation happens in the world editor where the user is allowed to move static geometry around while designing the world. As soon as the position is changed an assertion happens.

EDIT: I tested again with the new build. Looks like the assertion in the position change has been taken out. It doesn't assert anymore moving a CF_STATIC_OBJECT around. The slowdown persists though. Therefore it's not a problem with static/kinematic.



EDIT:
Tried 2.65 as suggested by Erwin. The time consumption of the simulation stepper call goes down from 17ms to 4.5ms . Therefore an update to the new version is a good way to tackle this.