Adding a auto constraint breaking feature enabled by boolean flag with break tolerance settings

[GoogleCodeExporter]

Erwin Coumans posted a great piece of work back in 2006 that in many 
physics engine is a standard. The post was here:

http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?
f=12&t=400&sid=be972d0cc0e7fe6ac3241e998b26d274

What I am proposing is adding a breakable flag and a btScalar 
breakThreshold flag to the typed constraints. This would be used during 
solving of collisions when forces are applied to constraints. If the force 
exceeds the threshold and the flag is enabled, then remove the constraint.

It is completely Erwin's work, but internalized.

Original issue reported on code.google.com by ronald.n...@gmail.com on 4 Nov 2009 at 2:42

[GoogleCodeExporter]

Such flag and threshold is a good idea. Constraints can be disabled this way.

>> I need to access the btDiscreteDynamicsWorld from btRigidBody
>>  to perform the removeConstraint function. 

Instead of calling 'removeConstraint' it is better to just leave it up to the 
user/developer to remove 'disabled' 
constraints.

Do you have a patch?

Original comment by erwin.coumans on 5 Nov 2009 at 4:59

[GoogleCodeExporter]

Well without a method such as was in that post, it is just a matter of storing 
a 
retrieving a couple of variables for use. But you are more than welcome to 
this. 
These are for 2.75.

Original comment by ronald.n...@gmail.com on 5 Nov 2009 at 7:25

Attachments:

• btTypedConstraint.h
• btTypedConstraint.cpp

[GoogleCodeExporter]

Not sure if this is of interest to you since it is totally based upon your 
code, but 
its how I ended up doing it at the user/developer level.

void PhysShapeBullet::checkToBreakConstraints()
{
    int count = m_body->getNumConstraintRefs();
    for (int i = 0; i < count; ++i)
    {
        btTypedConstraint* constraint = m_body->getConstraintRef(i)
        if(constraint->getBreakable())
        {
            btScalar imp1 = constraint->getAppliedImpulse();
            btScalar imp = imp1 * imp1;
            if(imp > constraint->getBreakThreshold())
                m_world->removeConstraint(constraint);
        }
    }
}

Original comment by ronald.n...@gmail.com on 5 Nov 2009 at 7:28

[GoogleCodeExporter]

I did find something wrong though. getAppliedImpulse returns 0.0 every time. I 
tested this by using a ragdoll that performed my function above and gave me a 
console display of the value of imp. I even modified my function to check if it 
was 
getting the value of breakThreshold and if the removeConstraint would work 
without 
the "if" statement. In both of those cases the data was accurate and the 
function 
performed perfectly. 

This can only mean that m_appliedImpulse is being set to 0.0f each time step 
after 
the calculations are completed which I would say defeats the purpose of the 
getAppliedImpulse function.

Original comment by ronald.n...@gmail.com on 6 Nov 2009 at 4:32

[GoogleCodeExporter]

Yeah, I posted about this problem in issue№300. Its happened due to solver 
computations(computed impulse doesn't applying to m_appliedImpulse).
You can now use getAppliedImpulse() with obsolete "*USE_OBSOLETE_SOLVER true" 
define.

Original comment by antonbar...@yahoo.com on 6 Nov 2009 at 4:29

[GoogleCodeExporter]

The getAppliedImpulse issue should be resolved in latest trunk, could you check 
that?

Original comment by erwin.coumans on 12 Feb 2010 at 11:35

[GoogleCodeExporter]

getAppliedImpulse is broken in version 2.76. The impulse is never zeroed out, 
meaning it keeps incrementing every frame until the object goes to sleep. 
Obviously not the desired behavior for breakable constraints. The applied 
impulse needs to be zeroed out every frame. but it should be done right before 
solving to keep the data useful. solveGroupCacheFriendlySetup seems like a good 
candidate.

the other bug is in how the applied impulse is computed in 
solveGroupCacheFriendlyFinish. The different constraint rows each sum up their 
signed contribution. This means that the orientation of the constraint in the 
world can change when it breaks.

For instance when testing it on an object with an off-centered COM with a 
slider constraint to the world, the break happens at a lower threshold if the 
object is turned 180 in the world because the rotation impulse gets either 
added or subtracted from the linear impulse. The (more) correct math for 
anisotropic breaking constraints should be to sum the square of the impulses 
and compare against a squared breaking threshold.

Original comment by bpatm...@gmail.com on 13 Sep 2010 at 9:46

[GoogleCodeExporter]

@bpatmail:

Could you check out version 2.77 or svn/trunk?

The constraint impulse should be zeroed out in line line 830 
currentConstraintRow[j].m_appliedPushImpulse = 0.f;
See also http://bit.ly/bcBZzj

Do you have a patch for your suggestion?

Original comment by erwin.coumans on 14 Sep 2010 at 11:29

[GoogleCodeExporter]

It looks like the impulse increments because of lines 1145-1148 from the above 
link:

btScalar sum = constr->internalGetAppliedImpulse();
sum += solverConstr.m_appliedImpulse;
constr->internalSetAppliedImpulse(sum);

What's the repercussion of not adding in internalGetAppliedImpulse() ?

Original comment by rodeo...@gmail.com on 1 Oct 2010 at 9:33

[GoogleCodeExporter]

Im using bullet 2.76. I added the following to lines 775-784. This seemed to 
have helped the problem, but am not sure of the repercussions: 

if (1)
{
   int j;
   for (j=0;j<numConstraints;j++)
   {
      btTypedConstraint* constraint = constraints[j];
      constraint->buildJacobian();

      constraint->internalSetAppliedImpulse(0.0f); // Added line
   }
}

Original comment by rogue.bi...@gmail.com on 24 Mar 2011 at 11:32

[GoogleCodeExporter]

Added the constraint breaking feature with an example in Demos/ConstraintDemo

http://code.google.com/p/bullet/source/detail?r=2369

Original comment by erwin.coumans on 2 Apr 2011 at 7:02

• Changed state: Fixed