Very slow cleanup.

[MaxDZ8]

Hello again.
I'm still moving my first steps in integrating and using Bullet. As the demos are mainly functional, I wanted to understand how much can I stress Bullet so I've wrote a program to generate some test collision geometry according to the pattern I need. I am testing about 12x the amount of complexity I plan to use. I'm talking about 4904 static objects. For the time being, I'm running debug mode.

Problem is cleanup takes a lot of time, in the order of 20 minutes using btDbvtBroadphase. I haven't tried SAP as it is my understanding it is even slower at insertion/removal and anyway, the benefit does not look very good to me. I've found out that btHashedOverlappingPairCache::m_overlappingPairArray counts 11,875,865 elements so no wonder this takes a while.

Perhaps I should just ditch debug? I need debug for the time being. How can I help the library in performing faster cleanups? Is this expected?

Suggestions are welcome.

[Erwin Coumans]

If there are 11,875,865 overlapping pairs with just 4k objects there must be a problem in the world setup.

Are all object at the same place and overlapping?

[MaxDZ8]

I had produced a debug output yesterday morning and there was no overlapping. Most of the objects are tightly packed, with some merging already going on.

Since then, I've added another geometry generation routine which does not quite look ok to me. My plan was to investigate it in more detail today and tomorrow. This routine runs for perhaps the 5% of the time so I hoped it would not be a problem, but perhaps it is.

Nonetheless, knowing this could be a problem is important to me, thank you. I will look into it and report as soon as I know more.

[MaxDZ8]

Ok, here's what happened. The debug output was just wrong. As soon as I loaded in bullet (I modified basicDemo to load a serialized file), everything was messed up big way. I started to search for errors between the component working on the debug visualization and the bullet volume generation.

It turns out that in a branch (the one running about 90% of the cases) I forgot to set btTransform's rotational component, which clearly wreaked havoc. Sorry for the inconvenience.

[majestik666]

We do have the same kind of issues with very slow reset/cleanup.

I can think of a big sim (~300,000 objects i believe) and it is taking a few minutes
to actually reset the simulation.

I did quite a lot of profiling to see where the time was gone and it's actually the
removeRigidBody that is taking 90% of the reset time.

Is there any tree operations happening when removing a rigid body (am using dbvt broadphase) ?
I'm wondering if it'd be possible to do something like :
- disableTreeUpdate();
- remove rigidbodies
- updateTree();
- enableTreeUpdate();

Francois

[MaxDZ8]

Have you checked the number of overlapping pairs? For almost 1000 times the amount of objects I had, I think that's fairly fast!

[Vince]

Hi,

I am facing the same issue, would it be possible to have a removeAllObjects ?

Deleteing objects one at a time is very slow especially when we need to reset an entire simulation and we dont want to update the broadphase collision detection.
Did someone have been able to implement such functions without creating memory leaks ?

Thanks

[Vince]

Hi,

I have found a quick and dirty solution for a temporary fix in my app. Before calling deleteRBFromWorld(rb), the broadphase handle of the rbs are set to null (rb->setBroadphaseHandle(0)).

The cleanup is much faster and the rigid bodies and broadphase structure are deleted. unfortunately, it generates some memory leaks (about 1M for 10.000 objects).

Did someone found a much nicer way to speed up the cleanup ?
Thanks