The thin "btBoxShape" box cannot to be laid flat on the "btConvexHullShape" plane.

[Winson]

Hello everyone,
I have a strange problem: Why the thin "btBoxShapeBox" box cannot to be laid flat on the "btConvexHullShape" plane?

The "btConvexHullShape" plane:

Code: Select all

btConvexHullShape* hull = new btConvexHullShape();
const btVector3 v1 = btVector3(0, 0.1, -2);
hull->addPoint(v1);
const btVector3 v2 = btVector3(0, 0.2, -2);
hull->addPoint(v2);
const btVector3 v3 = btVector3(0, 0.1, 2);
hull->addPoint(v3);
const btVector3 v4 = btVector3(0, 0.2, 2);
hull->addPoint(v4);
const btVector3 v5 = btVector3(-5, 0.2, 0);
hull->addPoint(v5);
const btVector3 v6 = btVector3(-5, 0.1, 0);
hull->addPoint(v6);
hull->setMargin(0.02f);

The thin "btBoxShape" box:
(1) Case 1:

Code: Select all

btBoxShape* boxShape = createBoxShape(btVector3(0.125, 0.018, 0.125));
boxShape->setMargin(0.0);

(2) Case 2:

Code: Select all

btBoxShape* boxShape = createBoxShape(btVector3(0.125, 0.018, 0.125));
boxShape->setMargin(0.04);

This is contradictory! Physical engine suggests to use a positive margin (zero margin might introduce problems), but in this case, positive margin introduced problems.
In fact, I have to create BoxShape with positive margin, so I wonder how to solve this problem when using the positive margin to create BoxShape.

btBoxShape collides with btConvexHullShape calls btConvexConvexAlgorithm class to get the closest points between two convex shapes. I think btConvexConvexAlgorithm class is the cause of this issue.

Thanks!

[drleviathan]

Bullet will deactivate moving bodies when both velocities are below some thresholds for > 2 seconds. The default thresholds are hard coded magic numbers:

linearSleepingThreshold = 0.8 m/sec
angularSleepingThreshold = 1.0 rad/sec

With those defaults it is possible for slowly tumbling objects, or even ballistic objects in weak gravity, to be deactivated early, resulting in strange resting rotations or stopping in mid-air. Try setting lower thresholds and watching carefully how the thin boxes settle. Sometimes very small objects can rattle around for a long time before they are deactivated.

Code: Select all

void btRigidBody::setSleepingThresholds(btScalar linear, btScalar angular);

If the boxes rattle or roll too much then you could also try decreasing restitution (bounciness) of the boxes and/or their floor to help them settle faster.

As to the "zero margin might introduce problems" thing: Supposedly the GJK algorithm is really fast at finding the closest approach between two convex objects... when they don't actually overlap. When they do overlap (e.g. the origin is outside the Minkowski difference) then the algorithm tends to take longer to figure it out. Also, when they overlap the penetration resolution code must kick in, and while it is good at NOT pumping energy into the system it IS non-physical in nature. Finally, sometimes the penetration resolution code could decide to tunnel out the other side. So the benefits of larger margins are (I think): better performance and less penetration/tunneling.

If performance isn't a problem (e.g. you aren't simulating a huge number of collisions), and you aren't worried about tunneling (e.g. low speeds), and you don't mind other penetration resolution artifacts (which really are small, especially when you don't have deep piles) ... then go with small or zero margin.

Alternatively, if your only objects in the world are small boxes and thin convex hulls, then you could just put all the margin on the convex hulls and give the boxes zero margin. Because the BoxBox algorithm actually treats the boxes with sharp edges and what is a marginized convex hull if not a slightly smoother hull?