request for list of known setLocalScaling() bugs

[cgripeos]

Hi Erwin,

I'm using Bullet 2.78 on Win32.

Perhaps this has already been answered, but I was curious if there was a known list of scaling issues and "gotchas" with Bullet that somebody can point me to.

The reason I ask is because I've been noticing a few issues with scaling while using Bullet and doing searches in the forum brings up a lot of posts. Some posts mention that certain shapes, like cylinder and sphere, do not support non-uniform scaling.

Here's what I'm noticing with my stuff...

1) create a btCollisionShape of either box, sphere, convex hull or triangle mesh shape.
2) create a btCompondShape and make the first collision shape the child.
3) create a rigidbody and give it the compound shape.

when I setLocalShape() of the compound shape, the shape gets scaled bigger than what my value is (viewed via btIDebugDraw)

when I setLocalShape() of the child shape, the scale is fine

Also, when scaling the compound shape, collision against the rigid body will sometimes not work at all. The AABB looks fine (even though the shape is scaled wrong).


Thank you in advance for any help,
cg

[cgripeos]

A side thought about btCompoundShape::setLocalScaling()

I noticed that when setLocalScaling() the btCompoundShape, the scale gets applied to all its children.

In a game we might need to do a lot of instancing of RigidBodies, where every instance of a Rigidbody's shape can have its own scale.

As mentioned above, my RigidBody has a btCompoundShape as its child shape. When I want to scale a RigidBody, I just scale its btCompoundShape.

I'd like to not have to duplicate the child shapes of that btCompoundShape and instead create them just once and share them with all instances of the RigidBody.

This could lead to really good memory savings. If we could just store the scale in the btCompundShape, instead of applying it to the child shapes, we can then share the children.

As is right now, I can only share vertex data of child btTriangleShapes or btConvexPointCloudShape shape instead of the entire shape. Other shapes like spheres, boxes, capsules, etc. can't be shared at all when scale is used (unless there is a better way to do this).

thanks again for you time,
cg

[dphil]

I also had a problem with compound shapes not scaling the child shapes properly. I had to make the following change to the setLocalScaling function in btCompoundShape:

Original (from the latest bullet source code):

Code: Select all

void btCompoundShape::setLocalScaling(const btVector3& scaling)
{

	for(int i = 0; i < m_children.size(); i++)
	{
		btTransform childTrans = getChildTransform(i);
		btVector3 childScale = m_children[i].m_childShape->getLocalScaling();
//		childScale = childScale * (childTrans.getBasis() * scaling);
		childScale = childScale * scaling / m_localScaling;
		m_children[i].m_childShape->setLocalScaling(childScale);
		childTrans.setOrigin((childTrans.getOrigin())*scaling);
		updateChildTransform(i, childTrans,false);
	}
	
	m_localScaling = scaling;
	recalculateLocalAabb();

}

Modified for better scaling behaviour:

Code: Select all

void btCompoundShape::setLocalScaling(const btVector3& scaling)
{
    for(int i = 0; i < getNumChildShapes(); i++)
	{
		btTransform childTrans = getChildTransform(i);
		btVector3 childScale = getChildShape(i)->getLocalScaling();
		childScale = childScale * scaling / m_localScaling;
		getChildShape(i)->setLocalScaling(childScale);
		childTrans.setOrigin(childTrans.getOrigin() * scaling / m_localScaling);  // note the difference here
		updateChildTransform(i, childTrans,false);
	}
	
	m_localScaling = scaling;
	recalculateLocalAabb();

}

In addition, I found that scaling gImpactMeshShapes more than once resulted in incorrect scaling. I think it had something to do with a call to updateBounds() which messes something up for future scalings. So right now in my project, if I ever call setLocalScaling more than once on a gImpactMeshShape, I delete the shape and create a fresh one with the right scale I want.

[cgripeos]

That fixed my problem! Thanks! It looks like Bullet needs a good unit test/demo for testing scaling issues.

Thanks for the help dphil.

cg