A couple questions about allowedCcdPenetration.
What is the intent of allowedCcdPenetration? Is it designed to improve gjk stability, or perhaps to allow the user to ignore grazing contacts? Or am I on the wrong track here?
Also, what is the expected effect? I previously thought it was something like a backwards collision margin -- continuous sweeps would not detect hits unless body0 and body1 penetrate more than allowedCcdPenetration. However, in this situation:
- allowedCcdPenetration is the default (0.04)
- body0 and body1 are slightly penetrating (say 0.03)
- body0 performs a short (0.03) convex sweep test into body1
I expect to receive a hit at the point where body0 penetrates 0.04 units into body1; or, perhaps an hit at t=0. Instead, it seems as if all sweeps of length < 0.04 return with no result. Specifically, the check in btContinuousConvexCollision::calcTimeOfImpact examines projected velocity instead of max penetration, which seems incorrect if there is pre-existing penetration. Is this the expected/desired behavior, or a bug?
The concrete case I'm looking at is a character proxy, which can walk substantially into collision when moving slowly.
(edit: added a bit of clarification)
allowedCcdPenetration questions
-
- Posts: 1
- Joined: Thu May 20, 2010 4:34 pm
Re: allowedCcdPenetration questions
I'm having exactly the same problem. There is a test at the end of btContinuousConvexCollision::calcTimeOfImpact():
In the case of shapecasts, result.m_allowedPenetration is initialized from btDispatcherInfo::m_allowedCcdPenetration, which defaults to 0.04. Unless I'm sorely mistaken, this means that the shapecasts used in btKinematicCharacterController::stepForwardAndStrafe() will always fail given a sufficiently slow speed of movement, or a sufficiently high framerate.
I'd like to reiterate paul.dubois' question: what is the expected behaviour? Also, what is the effect of tweaking btDispatcherInfo::m_allowedCcdPenetration?
Thanks in advance,
- Steve
Edit: In case this clarification helps, here's the relevant part of the commit log from the introduction of btDispatcherInfo::m_allowedCcdPenetration (revision 1193):
erwin.coumans 08/07/2008 8:08:49 PM
+ improved KinematicCharacterController
+ improved btSubsimplexConvexCast, btContinuousConvexCollision and btGjkConvexCast to support configuration that start in touching/penetration, required for 'sliding'.
Edit 2: Ah, I see this issue has already been been reported: http://code.google.com/p/bullet/issues/detail?id=347
Almost a year old now...
Code: Select all
if ((projectedLinearVelocity+ maxAngularProjectedVelocity)<=result.m_allowedPenetration)
{
return false;
}
I'd like to reiterate paul.dubois' question: what is the expected behaviour? Also, what is the effect of tweaking btDispatcherInfo::m_allowedCcdPenetration?
Thanks in advance,
- Steve
Edit: In case this clarification helps, here's the relevant part of the commit log from the introduction of btDispatcherInfo::m_allowedCcdPenetration (revision 1193):
erwin.coumans 08/07/2008 8:08:49 PM
+ improved KinematicCharacterController
+ improved btSubsimplexConvexCast, btContinuousConvexCollision and btGjkConvexCast to support configuration that start in touching/penetration, required for 'sliding'.
Edit 2: Ah, I see this issue has already been been reported: http://code.google.com/p/bullet/issues/detail?id=347
Almost a year old now...
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: allowedCcdPenetration questions
This is the correct interpretation. I just fixed a bug, latest svn trunk should work now:continuous sweeps would not detect hits unless body0 and body1 penetrate more than allowedCcdPenetration
http://code.google.com/p/bullet/source/detail?r=2362
Sorry for the long delay in handling that issue,
Thanks,
Erwin