Center of mass shift causes offset in collision detection?

[faichele]

Hello, again!

Sorry for the inconvenience; I discovered too late that I opened this topic in the wrong subforum, since this is not directly related to data import and export, but rather to the Bullet API itself. I didn't discover a way to move a topic to another forum with phpBB...

After digging through the Bullet sources, the COLLADA standard specification and the forums here, I finally succeded to create a simple Bullet scenario that achieves "credible" behaviour for some concave rigid bodies (see attached screenshot).
I used the approach mentioned in the threads at http://www.bulletphysics.com/Bullet/php ... f=9&t=2209 and http://www.bulletphysics.com/Bullet/php ... f=9&t=2828, specifying center of mass coordinates obtained from a CAD application in COLLADA, and adding the actual collision geometries to a btCompoundShape, using the center of mass transformation as child transform. The geometries I tried now behave one would expect from reality (for example, the screw correctly coming to rest lying sideways), but there's still one problem I can't figure out: Instead of resting at ground level, Bullet leaves the rigid bodies at rest with a z coordinate greater than 0!
I used the btIDebugDraw interface to implement a debug view (using Qt's GLWidget), and set it to draw the collision geometries and the AABB's of the btCompoundShape containers surrounding the original collision geometries, and it seems (at least to me) that Bullet lets the AABB's rest on ground level (see screenshots)...

I tried both a btBoxObject and a btStaticPlaneShape as collision geometries for the "ground" primitive; both lead to the same result, so I presume I placed the ground collision geometry at the correct z coordinate.

I don't know what I have still missed, I sincerely hop someone here can give me some additional input on this "phenomenon".

Thank you very much!

With best regards
Fabian Aichele

[faichele]

Hello!

This has been solved after some further experiments with the instantiation of the collision geometries and rigid body parameters; I had set the collision margin of the original geometry to 0 for testing, but not the collision margin of the btCompoundShape, which caused this offset.

One question then still remains: Where does the default value for the collision margin of a btCompoundShape come from then? Is it set up differently than for non-compound collision shapes?

Thank you anyways!

With best regards,
Fabian Aichele