Collision margin in BoxShapes.

Post Reply
Paulo Pereira
Posts: 3
Joined: Tue Jun 11, 2019 5:04 am

Collision margin in BoxShapes.

Post by Paulo Pereira » Sun Jun 16, 2019 12:32 am

Hi,

I start working on a simulation with the bullet library to prevent and avoid collisions. I use bullet version 2.82.
I have some questions regarding collision margins.

In the manual, I found the following observation:
By default, this collision margin is set to 0.04, which is 4 centimeter if your units are in meters (recommended).
Which I suppose that refers to the margin defined in btCollisionMargin.h

Code: Select all

///The CONVEX_DISTANCE_MARGIN is a default collision margin for convex collision shapes derived from btConvexInternalShape.
#define CONVEX_DISTANCE_MARGIN btScalar(0.04).
The manual says that the btBoxShape subtracts the collision margin from the half extents. What does it mean? If a box has a size of 0.10m, the margin would be an inner box of size 0.09m that allows 1cm of penetration?

In the basic demo of the bulletExampleBrowser, we instantiate a bunch of box shapes with 20 centimeters.

Code: Select all

        btBoxShape* colShape = createBoxShape(btVector3(.1, .1, .1));
The boxes are colliding exactly on the surface(Without gap or penetration).
Why the boxes are not colliding with a small gap or penetrating of 4 cm?
I tried different margins with colShape.setMargin(x), and it doesn't change anything.

Thanks.

User avatar
drleviathan
Posts: 555
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Collision margin in BoxShapes.

Post by drleviathan » Sun Jun 16, 2019 5:21 am

The box-box algorithm does not add the margin. For more info watch this youtube video.

Paulo Pereira
Posts: 3
Joined: Tue Jun 11, 2019 5:04 am

Re: Collision margin in BoxShapes.

Post by Paulo Pereira » Sun Jun 16, 2019 5:22 pm

Thank you drleviathan,

I saw the video, and now I tried other shapes, and the margin got expanded. The bullet demos use the graphical representation of the extents+margin, so there is no visible gap.

Is the box-box the default algorithm used in the narrow phase when we only have box-box objects colliding? Are there other algorithms available?

Playing with the basicDemo, I detected when a box is rotating and translating it can penetrate the ground or other boxes. I have a screenshot of this behavior. There is a way to avoid penetration?
Attachments
BoxPenetration.png
BoxPenetration.png (399.55 KiB) Viewed 861 times

User avatar
drleviathan
Posts: 555
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Collision margin in BoxShapes.

Post by drleviathan » Sun Jun 16, 2019 8:56 pm

The shapeA-shapeB narrowphase collision algorithms are registered into a indexed array and called for the right parings. Box-box gets its own specific entry. Other pairings may fallback to more general purpose convexShape-convexShape algorithms, dunno for sure. I've chanced upon the relevant code during my explorations but I didn't examine it carefully enough to be an expert.

When you say the box can "penetrate" other objects... this happens while the box is active and moving or it is visible when the box has come to rest and has been deactivated? I ask because the default speed thresholds at which dynamic RigidBodies are deactivated are rather high (linear = 0.8m/sec, angular = 1.0 radian/sec) and my first hypothesis would be that slowly rotating boxes might get deactivated too early such that they appear to be slightly penetrating because their angular velocity wasn't truly zero at that moment. If this were the case then reducing the angular sleeping threshold might prevent this from happening.

Code: Select all

body->setSleepingThresholds(linearSpeed, angularSpeed);
An active RigidBody will be deactivated when its linear an angular speeds are both lower than the sleeping thresholds for more than 2 seconds.

If that were the problem and if you were to reduce the sleeping thresholds then objects would tend to take a little longer to deactivate but they would be more correctly oriented when they do.

Paulo Pereira
Posts: 3
Joined: Tue Jun 11, 2019 5:04 am

Re: Collision margin in BoxShapes.

Post by Paulo Pereira » Tue Jun 18, 2019 2:41 am

drleviathan wrote:
Sun Jun 16, 2019 8:56 pm
When you say the box can "penetrate" other objects... this happens while the box is active and moving or it is visible when the box has come to rest and has been deactivated?
It happens when the object is active and moving against the ground or other boxes. When the interaction with the object ends (Mouse click to apply angular and linear velocity), there is no penetration. I tried to change the thresholds, but it doesn't seem to reduce this behavior.

User avatar
drleviathan
Posts: 555
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Collision margin in BoxShapes.

Post by drleviathan » Tue Jun 18, 2019 4:21 pm

How do you extract the worldTransform of the RigidBody? Are you using something like DefaultMotionState::getWorldTransform()? If so then the following issue may apply:

Bullet's MotionState API will supply an extrapolated transform to the MotionState rather than the RigidBody's true transform at the end of the last substep. The reason for this is avoid aliasing issues when the simulation doesn't step at the same rate as the render rate.

Suppose you've configured Bullet to use substep = 1/60 sec with a maximum of 4 substeps per step and your game loop is running at about 30 Hz. But there is drift and load: sometimes your game loop rate slows down to only 28Hz. When this happens the timeStep passed to the stepSimulation() call will be 1/28. Bullet will only bite off substep sized chunks (usually two per step) and will accumulate the remainder. When the accumulated time is larger than a whole substep then Bullet will take three substeps and save the remainder.

The worldTransform supplied to the MotionState includes extrapolation for the remainder time. If it did not do this then you can get visual glitches (aliasing) in an object's otherwise smooth motion across the screen. However the extrapolated transform can cause rapidly tumbling GameObjects to appear to rotate too far into others when the corresponding RigidBody has not.

If this is your problem then the following measures may help:

(1) reduce the substep duration: smaller remainders --> less extrapolation

(2) reduce the restitution of RigidBodies: this will tend to slow down tumbling angular velocities which makes for less offset between real and extrapolated orientations

(3) Implement a CustomMotionState which ignores the worldTransform passed by the Bullet API and instead uses body->getWorldTransform()

Post Reply