Compound shape transforms break collisions

[sgraham]

mCompoundShape->addChildShape(scaledTransform, boxShape);

I am having some strange behavior with primitive collisions. I'm using Bullet 2.81 and I am relatively new to using Bullet directly in C++. I just started using the compound shape and I am finding that collisions only work when both of my boxes are set to Identity transforms. If I scale them in any one direction or all directions uniformally, the boxes no longer collide.

The debug drawing shows the correct (stretched) box that it should be colliding with, but they fall right through each other unless both are set to identity. Just curious if anyone else has experienced this, and whether or not transforming shapes is even the right way to do this, or should I be creating a new shape for every box I add to the compound? Right now I have one box shape, but input a different transform with each addChildShape command... I thought I saw somewhere that this was the most efficient thing to do. It is in fact how it is done in at least one of the demos, however that demo does not stretch the box shape.

Let me know if I need to paste more code, it's kind of a pain at the moment as I am trying to integrate bullet into my game engine. But if needed I can break it down.

To put what I'm trying to do simply. I would like the ability to have compound shapes which represent the collision geom for a given game asset. Ideally the fewer the shapes the better and the more primitive the better, but in that case stretching will be necessary to do some nice fitting. I saw some Blender examples do this which use Bullet under the hood, so I am pretty sure it is supported and also the whole point of compound shapes.

Thanks!

-Shaun

[sgraham]

Here's what my code is doing. Note that some of the variables here are declared elsewhere, but should be obvious what they are based on the name of the variable.

Code: Select all

// init the world
btDefaultCollisionConfiguration* mCollisionConfiguration = new btDefaultCollisionConfiguration;
btCollisionDispatcher* mDispatcher = new btCollisionDispatcher(mCollisionConfiguration);
btBroadphaseInterface* mOverlappingPairCache = new btDbvtBroadphase();
btSequentialImpulseConstraintSolver* mSolver = new btSequentialImpulseConstraintSolver();
btDiscreteDynamicsWorld* mDynamicWorld = new btDiscreteDynamicsWorld(mDispatcher, mOverlappingPairCache, mSolver, mCollisionConfiguration);
SetGravity(-10.0f);



// first rigid body = cube floating above ground located at position (0, 8, 0), scale = 1 unit
// set up rigid bodies with this code
btTransform bulletTransform;
bulletTransform.setFromOpenGLMatrix(inputOpenGLmatrix);

btCompoundShape* mCompoundShape = new btCompoundShape();
mCompoundShape->addChildShape(bulletTransform, box); // if bulletTransform is not identity on any of the rigid bodies created, collision fails, though debug drawing looks as expected

btTransform rbdInitialTransform;
rbdInitialTransform.setFromOpenGLMatrix(inputInitialTransformOpenGLmatrix);

btTransform rbdCenterOfMassOffsetTransform;
rbdCenterOfMassOffsetTransform.setIdentity();
rbdCenterOfMassOffsetTransform.setOrigin(mCenterOfMassOffset);

btDefaultMotionState* mMotionState = new btDefaultMotionState(rbdInitialTransform, rbdCenterOfMassOffsetTransform);

btVector3 inertia(0.0f, 0.0f, 0.0f);
if (mMass != 0.0f) {
    mCompoundShape->calculateLocalInertia(mMass, inertia);
}
    
btRigidBody::btRigidBodyConstructionInfo rbInfo(mMass, mMotionState, mCompoundShape, inertia);
rbInfo.m_friction = mFriction;
rbInfo.m_restitution = mRestitution;

btRigidBody* mRigidBody = new btRigidBody(rbInfo);

// add rigid body to the world
mDynamicWorld->addRigidBody(mRigidBody);

// duplicate above code for second rigid body
// second rigid body = stretched cube for ground plane located at position (0, 0, 0), scale = (20, 1, 20)
// NOTE: if I change this so scale = 1, falling cube then lands on this cube.

    
// step simulation
mDynamicWorld->stepSimulation(timeStep, maxSubsteps);

[sgraham]

After more rigorous testing, I have found that adding scale to the primitive does collide correctly with btBvhTriangleMeshShapes (and possibly others?). But always fails when colliding with another box primitive, regardless of which primitive is scaled, and regardless of the fact that the debug drawing looks correct. My conclusion is that translating and rotations work fine for box to box collisions, but scaling causes box to box collisions to fail, which is a bug in Bullet.

If you've had other results, please let me know. Can anyone confirm my results with their own test?

Thanks.

[sgraham]

Note that you can change the scaling on the btBoxShape when first created. The only catch there is that I was planning on having a single shape representing all box primitives and a transform to do any customizing of scale. Setting the scale when btBoxShape is first created works as expected. So you can do custom shapes that way, you just can't add scale to the transform when adding it to a btCompoundShape.

Though since btBoxShape is a primitive shape and doesn't have to store a bunch of vertex/tri data, perhaps this is not a big deal?