Constraint range

[Moose]

Hello,

I am in the final stages of a bullet based project about integrating bullet into a large commercial visualizations system. It has been challenging, interesting and also a lot of fun to see things moving in a natural like fashion.

Much like the ConstraintDemo we are using 6dof generic constraints to give the user sort of a picking cursor to be able to move dynamic objects about. This looks and works nicely. However, consider this classic example. You have a ball laying in front of a brick wall. You create a constraint on the ball and move the constraint towards the wall and finally past it. The ball will first collide and stick to the wall as I expect but when I move the constraint further and further past the wall, all of a sudden the ball will snap right through the wall and arrive at the constraint pivot again like pulled by a rubber band.

Now I have a number of questions about this:

1) Is this what people mean by the constraint "breaking"?

2) Is this caused by a property of the object (wall or ball) or it's material or is the reason in the constraint?

3) Is there a physical / mathematical reason for that? As in: Is this on purpose or a mathematical accident.

4) How can I prevent this? In my use case I can tolerate the ball going through the wall but not that early. Right now it happens when the constraint reaches about 5 times the size of the ball past the wall. I need at least 20 times. Is there a way to do that?

Cheers,

Moose

[Moose]

Right,

I couldn't find an answer to all the questions by myself but in case anyone is interested I have a few things.
There seems to be no generic way to solve this. By taking the ConstraintDemo examples and applying that to my own use case I found a way to at least make the constraint "weaker" so it doesn't pull the object through the wall too easily:

generic_constraint->setParam(BT_CONSTRAINT_STOP_CFM, 0.8, 0); // default 0.0f
generic_constraint->setParam(BT_CONSTRAINT_STOP_CFM, 0.8, 1);
generic_constraint->setParam(BT_CONSTRAINT_STOP_CFM, 0.8, 2);
generic_constraint->setParam(BT_CONSTRAINT_STOP_CFM, 0.8, 3);
generic_constraint->setParam(BT_CONSTRAINT_STOP_CFM, 0.8, 4);
generic_constraint->setParam(BT_CONSTRAINT_STOP_CFM, 0.8, 5);

generic_constraint->setParam(BT_CONSTRAINT_STOP_ERP, 0.1, 0); // default 0.2f
generic_constraint->setParam(BT_CONSTRAINT_STOP_ERP, 0.1, 1);
generic_constraint->setParam(BT_CONSTRAINT_STOP_ERP, 0.1, 2);
generic_constraint->setParam(BT_CONSTRAINT_STOP_ERP, 0.1, 3);
generic_constraint->setParam(BT_CONSTRAINT_STOP_ERP, 0.1, 4);
generic_constraint->setParam(BT_CONSTRAINT_STOP_ERP, 0.1, 5);

Doing that, I have to move the constraint about 5 times further behind the wall before the ball snaps through. Which is tolerable here.
I also found out that CFM stands for "constraint force mixing" in case anyone doesn't know that either. I don't know the use though. "ERP" apparently stands for "error tolerance factor" but I'm not sure about this.

By searching the web I also found people talking about this phenomenon and suggesting to use "continuous collision detection". I have activated this and extensively tweaked all parameters that seemed connected with it. There was however no visible effect whatsoever.

Hope this helps anyone with the same problem,

Moose

[Basroil]

1) Is this what people mean by the constraint "breaking"?

Not sure that constraint really broke, it seems to have worked the entire way through. Did it have uncorrectable error for a while? Yes.

2) Is this caused by a property of the object (wall or ball) or it's material or is the reason in the constraint?

My guess would be that the ball was given enough velocity at the end of one step to overcome the collision prevention and correction. You can check the ball velocity when it breaks through, if the velocity times your solving rate is higher than the distance the error correction can fix in that frame, it could happen. Assuming the only external force in the direction of tunneling was the constraint, it probably was the constraint in conjunction with the ball size, wall thickness, world step size, solver type, etc.

3) Is there a physical / mathematical reason for that? As in: Is this on purpose or a mathematical accident.

Pretty sure it's a programming necessity, but you will have to wait for Erwin Coumans.

4) How can I prevent this? In my use case I can tolerate the ball going through the wall but not that early. Right now it happens when the constraint reaches about 5 times the size of the ball past the wall. I need at least 20 times. Is there a way to do that?

Well, you can always try using a 6dofspring joint instead of the standard one and start decreasing spring strength if the constraint is limited (isLimited). Using that method you might even be able to keep spring strength in some directions while lowering it in the limited direction. There's a ton of ways around it depending on what you can and can't do though.

[Moose]

Thanks for the clarification.
I understand this is all stuff that is supposed to be handled in the simulation substep handler. So far I only extract collision information in there. Looks like there's way more to be done. I'll look into it. BTW, maybe someone can point me to a good starting point? Like a demo or example that shows what else can be done in such a handler?

Cheers,
Moose