updateSingleAabb seems to not work for resting objects

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Have a block just standing around.
2. Resize it so that it no longer touches the ground
3. Call updateSingleAabb() and activate()

What is the expected output? What do you see instead?
I'd expect the block to then fall down because it is no longer touching the 
ground. Instead it justs floats in the air, as if it was still it's old size. 
It will fall down as soon as you make it move.

What version of the product are you using? On what operating system?
Bullet 2.79, Windows 7 64 bit (bullet compiled as 32 bit though) in Visual 
Studio 2010

Please provide any additional information below.
I've attached a modified version of the basic demo that comes with bullet that 
shows the problem.
Replace the BasicDemo.h and BasicDemo.cpp from bullet 2.79 with the provided 
versions.
The demo consists of a block standing in a field that I will resize after the 
demo has run for five seconds. The block will refuse to fall down by itself. It 
will fall down though if you throw cubes at it. (right click)
The relevant code is in lines 50 to 62 in the provided BasicDemo.cpp

Original issue reported on code.google.com by malteska...@gmail.com on 17 Oct 2011 at 6:56

Attachments:

• brokenUpdateSingleAabb.zip

[GoogleCodeExporter]

If you change the collision shape or scale, you need to manually remove the 
cached contact points. 

The easiest way is to first remove the object from the world, change the 
collision shape, and re-insert the object in the world.

There is also another API to manually clear the contacts for specific objects, 
but the CPU cost is not much different from the remove/insert method.

Original comment by erwin.coumans on 18 Oct 2011 at 3:34

[GoogleCodeExporter]

Isn't removing/adding a bit slow? Especially if I have several objects in the 
game that I rescale each frame? It looks like the complexity for that could be 
O(n*m) with n being the total number of objects and m being the objects that I 
remove/add.
(oh by the way a tiny optimization for that: consider doing the linear search 
in remove rigid body starting at the end. I would think it more likely that an 
object that is to be removed has just been added. I'm thinking of all the many 
games that spawn enemies and then when you kill them they have to be removed 
again)

Also the reason why I thought that updateSingleAabb should work here was this 
forum post:
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=3262
In there you say that updateSingleAabb is specifically for this. Shouldn't that 
function also do the removing of the cached contact points?

Original comment by malteska...@gmail.com on 18 Oct 2011 at 5:07

[GoogleCodeExporter]

>>Shouldn't that function also do the removing of the cached contact points?

Unfortunately it doesn't. Either you remove/change/re-insert or remove the 
contact points in another way.

Removal/re-insertion into the array of objects is not the main performance 
bottleneck. Updating the broadphase data structures and allocation of other 
structures (contact caches/manifolds etc) is. If you are using a 
btDbvtBroadphase it should be O(log(n)).

world->getBroadphase()->getOverlappingPairCache()->cleanProxyFromPairs(object->g
etBroadphaseHandle(),world->getDispatcher());

Original comment by erwin.coumans on 18 Oct 2011 at 8:16

[GoogleCodeExporter]

Alright, works for me.
In that case I would think that it would be convenient to provide a function 
that calls updateSingleAabb and then calls that line. Otherwise other people 
would run into the same problem and be confused. And neither the remove/add 
approach, nor this one is documented anywhere as far as I can tell.
Providing a function that is called updateForNewSize(btRigidBody &) or 
something would make it clear for people that they have to call that function 
when scaling an object that has already been added to the world.

But anyways: My problem is solved, so I guess you can close this ticket if you 
want.

Original comment by malteska...@gmail.com on 18 Oct 2011 at 11:39

[GoogleCodeExporter]

Right, it should be documented.

Thanks for the feedback!

Original comment by erwin.coumans on 20 Oct 2011 at 5:51

[GoogleCodeExporter]

See https://github.com/bulletphysics/bullet3/issues/134

Original comment by erwin.coumans on 30 Mar 2014 at 7:40

• Changed state: Moved