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
P2P constraints seem to tunnel through collision data
-
- Posts: 69
- Joined: Sat May 10, 2008 8:39 am
P2P constraints seem to tunnel through collision data
Last edited by mreuvers on Tue Jul 29, 2008 8:22 am, edited 1 time in total.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: P2P constraints seem to tunnel through collision data
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
Let's add this as a feature for Bullet 2.71.
Thanks for the feedback,
Erwin
-
- Posts: 69
- Joined: Sat May 10, 2008 8:39 am
Re: P2P constraints seem to tunnel through collision data
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.Erwin Coumans wrote:In this case the strength (maximum force/impulse applied) of the point to point constraint should be limited.
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
Last edited by mreuvers on Tue Jul 29, 2008 8:23 am, edited 1 time in total.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: P2P constraints seem to tunnel through collision data
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.I'm not entirely sure whether this solves the problem.
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
-
- Posts: 69
- Joined: Sat May 10, 2008 8:39 am
Re: P2P constraints seem to tunnel through collision data
Thanks for the prompt reply!
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'.
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
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.Erwin Coumans wrote: 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.
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'.
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.Erwin Coumans wrote: 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.
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
-
- Posts: 69
- Joined: Sat May 10, 2008 8:39 am
Re: P2P constraints seem to tunnel through collision data
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
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
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: P2P constraints seem to tunnel through collision data
Thanks a lot for the patch, it will be applied and included in Bullet 2.70.
Erwin
Erwin