Center of mass shift and local inertia

[Verbo]

Hi,

I has been a while since I have implemented the center of mass shift in my integration of Bullet Physics in Virtools and it works fine. However, a question just came to my attention. When we use a compound shape to implement the center of mass shift, I can see that the local intertia that is calculated doesn`t seem to take the child shapes into account.

So, even if I might sound pretty dumb, my question is: should the center of mass position modify the local inertia? Because right now, even if I have an object with a shifted center of mass, the local inertia that is calculated from the compound shape doesn`t seem to change whatever I do, but the simulation itself, seems ok, hence my questioning...

Can somebody give me a hint about that?

Thanks

Verbo

[Erwin Coumans]

You need to use btCompoundShape::calculatePrincipalAxisTransform to calculate the inertia shift transform, and create a shifted compound shape.

See attached BasicDemo for some example how to use this (press 'f' to fracture the cube compound).

Hope this helps,
Erwin

[deepscratch]

the download is unavailable, for some reason........

[Erwin Coumans]

The forum has been migrated to a new server, because of server issues. Some files weren't copied into the right location.

Can you try it again?
Thanks,
Erwin

[deepscratch]

awesome, got it

[dphil]

I have briefly gone over the extended Convex Decomposition demo (posted here http://code.google.com/p/bullet/issues/detail?id=90) that includes breaking of objects. It seems like the part of the code that does the actual breaking is in the clientMoveAndDisplay() function:

Code: Select all

if (gCompoundBody && gSubShapeIndex>=0) {
		int index = gSubShapeIndex;
		gSubShapeIndex=-1;
		
		btCompoundShape* compound = (btCompoundShape*)gCompoundBody->getRootCollisionShape();
		btCollisionShape* childShape = compound->getChildShape(index);
		
		btTransform newBodyTransform = gCompoundBody->getWorldTransform() * compound->getChildTransform(index);
		compound->removeChildShapeByIndex(index);
		//compoundWrapper->removeChild(childShape);
		//compound->recalculateLocalAabb();	// maybe needed
		
		const btScalar mass=1.f;
		btRigidBody* body = localCreateRigidBody( mass, newBodyTransform,childShape);
		body->setUserPointer((void*) gUserPointerForDynamicBodiesThatDontBreakCompound);	// If commented out the whole compound gets broken with a single touch (a must see!)
		
		
		if (compound->getNumChildShapes()==0) {
			m_dynamicsWorld->removeRigidBody(gCompoundBody);
			gCompoundBody = NULL;
		}	
	}

So, basically, breaking simply involves grabbing one of the child shapes (in this demo determined beforehand based on a collision contact point) of a btCompoundShape, removing it from the compound, creating a new rigid body with that shape (with the appropriate world transform), and adding that new rigid body (the "broken-off" piece) to the collision world?

[Flix]

So, basically, breaking simply involves grabbing one of the child shapes (in this demo determined beforehand based on a collision contact point) of a btCompoundShape, removing it from the compound, creating a new rigid body with that shape (with the appropriate world transform), and adding that new rigid body (the "broken-off" piece) to the collision world?

Well, that's what I did...
Of course by doing it this way it's not a real breaking: bricks that are left alone after the removal of nearby bricks won't be removed from the compound and won't fall by themselves.

I remember I recalculated the local inertia of the compound shape (after the removal) too: this can be costly but made the simulation a bit more realistic and prevented possible crashes when using compound->removeChildShapeByIndex(index) (now the code is a bit old: I don't know if this problem still occurs or if there's a faster way to avoid crashes without recalculating the local inertia: this could be a very good improvement in case of static objects, for which I recalculated the local inertia just to avoid crashes).

Another easy improvement is to subtract the brick mass to the compound rigid body at each removal (I don't remember if I did it).

Hope it helps.

[Flix]

I remember I recalculated the local inertia of the compound shape (after the removal) too: this can be costly but made the simulation a bit more realistic and prevented possible crashes when using compound->removeChildShapeByIndex(index) (now the code is a bit old: I don't know if this problem still occurs or if there's a faster way to avoid crashes without recalculating the local inertia: this could be a very good improvement in case of static objects, for which I recalculated the local inertia just to avoid crashes).

I don't know if this will fix the problem and/or if this fix is already embedded in the recent releases of the Bullet library, but I've just discovered a post here: http://bulletphysics.org/Bullet/phpBB3/ ... e+compound in which

Index: src/BulletCollision/CollisionShapes/btCompoundShape.cpp
===================================================================
--- src/BulletCollision/CollisionShapes/btCompoundShape.cpp (revision 2052)
+++ src/BulletCollision/CollisionShapes/btCompoundShape.cpp (working copy)
@@ -110,6 +110,7 @@
m_dynamicAabbTree->remove(m_children[childShapeIndex].m_node);
}
m_children.swap(childShapeIndex,m_children.size()-1);
+ if (m_dynamicAabbTree) m_children[childShapeIndex].m_node->dataAsInt = childShapeIndex;
m_children.pop_back();

}

This is a patch for the Bullet source code.

I don't know if it works in my case.
It's probably equivalent to compound->recalculateLocalAabb(), although it's much faster, and I'm not sure this was enough to avoid crashes in my demo.