P2P constraints seem to tunnel through collision data

[mreuvers]

Hi there,

We've been using the P2P constraints in one of our projects. We used the BasicDemo and made the following small changes:

- made sure we disable the AngularFactor (=0) of the rigid body that's been picked: we don't want any rotations
- set the cameradistance to 20
- made a btBoxShape for the groundplane. This way the small boxes are lying on a big box.

Now run the demo and pickup a small box. As soon as you drag this small box into any other collisionshape (other small boxes or the 'ground' box), the picked box simply tunnels through the collision. Apparently the constraint forces/pushes the picked box through the other collision shapes. IMO this should never happen at all, the smaller box should simply stay put and should not try to move through the other objects. If you enable the AngularFactor, the result is even worse: it tunnels through and in addition the picked box begins to shake like a hyperactive old man

We've also tried this in 2D with Box2D and the behavior in that demo application is exactly what we would like to see in Bullet as well: it stays put, without tunneling or weird shaky constraints

Is there any way to prevent this tunneling from happening?

Any help on this matter would be greatly appreciated!

Thanks,


Martijn

[Erwin Coumans]

In this case the strength (maximum force/impulse applied) of the point to point constraint should be limited. Currently, the btPoint2PointConstraint doesn't have limits, but those are easy to add.

Let's add this as a feature for Bullet 2.71.

Thanks for the feedback,
Erwin

[mreuvers]

In this case the strength (maximum force/impulse applied) of the point to point constraint should be limited.

I'm not entirely sure whether this solves the problem. We tried to lower the m_tau if there is a collision, but still it seems to tunnel through. I also tried to cap the max force applied, but that still doesn't get rid of the shaking/jittering.

I think the problem lies within the rigidbody itself, it should not try to tunnel through another rigid body at all. Even if it gets a force applied to it. If I keep walking into a wall, I can walk all I want but I'll never end up in the wall. (Unless a force is applied that would break the wall, but that's not the case here ).

In bullet however, if I constantly push the rigid body in the other rigidbody, it seems to tunnel through it, even if the impulse/force is not that high.

I will investigate a bit further though

[Erwin Coumans]

I'm not entirely sure whether this solves the problem.

Capping the applied impulse to a maximum should reduce the amount of penetration. Using a very small maximum impulse value should completely avoid the tunneling effect, but some jitter will still happen.

Box2D 2.x uses continuous collision detection to prevent (deep) penetration from happening. Bullet also includes continuous collision detection, but the current btDiscreteDynamicsWorld doesn't use this. Completion of the btContinuousDynamicsWorld is on the todo list. This will use continuous / predictive collision detection queries inside the simulation loop to avoid deep penetration, similar to Box2D 2.x.

Hope this clarifies things,
Erwin

[mreuvers]

Thanks for the prompt reply!

Capping the applied impulse to a maximum should reduce the amount of penetration. Using a very small maximum impulse value should completely avoid the tunneling effect, but some jitter will still happen.

But the problem then would be that the constraint doesn't do much anymore. If for instance I move the mouse below the background surface, the picked box should stay on the surface and if I then move the mouse from left to right, the picked box should still follow it.

If I lower the maximum impulse upon collision, like you suggest, the object will remain more or less inactive until I 'pull it out of its collision state'.

Box2D 2.x uses continuous collision detection to prevent (deep) penetration from happening. Bullet also includes continuous collision detection, but the current btDiscreteDynamicsWorld doesn't use this. Completion of the btContinuousDynamicsWorld is on the todo list. This will use continuous / predictive collision detection queries inside the simulation loop to avoid deep penetration, similar to Box2D 2.x.

Thanks for the heads up on that. Although I'm not entirely convinced that using discrete physics is the root cause of our problems. Or, that it will be fixed by using continuous physics.

Let me try to elaborate. To my understanding continuous collision is useful for objects that travel at high speeds. Using continuous physics you are able to detect a bullet that is traveling at high speed through a wall. In a discrete world it would probably have missed the wall and tunneled through it.

However in this constraint example, tunneling also occurs when you're dragging your object very slowly (1 pixel per second) into another object. Is using continuous collision detection the only way to properly fix this, or could there perhaps be some other evil force at work here ?

Cheers from the Netherlands,


Martijn

[mreuvers]

Hi there,

After experimenting a bit, I noticed that with a clamped impulse I can do pretty much what I want to do. Please find my patch (on the latest trunk) for p2p impulse clamping below. If you set a clampvalue > 0, the value will be clamped. If otherwise, it won't be clamped.

Erwin, thanks for the tips and enjoy the patch!

Cheers,


Martijn


**** PATCH ****
Index: src/BulletDynamics/ConstraintSolver/btPoint2PointConstraint.cpp
===================================================================
--- src/BulletDynamics/ConstraintSolver/btPoint2PointConstraint.cpp (revision 1213)
+++ src/BulletDynamics/ConstraintSolver/btPoint2PointConstraint.cpp (working copy)
@@ -100,6 +100,14 @@
btScalar depth = -(pivotAInW - pivotBInW).dot(normal); //this is the error projected on the normal

btScalar impulse = depth*m_setting.m_tau/timeStep * jacDiagABInv - m_setting.m_damping * rel_vel * jacDiagABInv;
+
+ btScalar impulseClamp = m_setting.m_impulseClamp;
+ if (impulseClamp > 0)
+ {
+ if (impulse < -impulseClamp) impulse = -impulseClamp;
+ if (impulse > impulseClamp) impulse = impulseClamp;
+ }
+
m_appliedImpulse+=impulse;
btVector3 impulse_vector = normal * impulse;
m_rbA.applyImpulse(impulse_vector, pivotAInW - m_rbA.getCenterOfMassPosition());
Index: src/BulletDynamics/ConstraintSolver/btPoint2PointConstraint.h
===================================================================
--- src/BulletDynamics/ConstraintSolver/btPoint2PointConstraint.h (revision 1213)
+++ src/BulletDynamics/ConstraintSolver/btPoint2PointConstraint.h (working copy)
@@ -25,12 +25,14 @@
struct btConstraintSetting
{
btConstraintSetting() :
- m_tau(btScalar(0.3)),
- m_damping(btScalar(1.))
+ m_tau(btScalar(0.3f)),
+ m_damping(btScalar(1.0f)),
+ m_impulseClamp(btScalar(0.0f))
{
}
btScalar m_tau;
btScalar m_damping;
+ btScalar m_impulseClamp;
};

/// point to point constraint between two rigidbodies each with a pivotpoint that descibes the 'ballsocket' location in local space

[Erwin Coumans]

Thanks a lot for the patch, it will be applied and included in Bullet 2.70.

Erwin