[ODE] Breakable Joints

[Roel van Dijk]

It's nice to see that there is some interest in my contribution :-)
I do get some requests from time to time to update the breakable joints to 
work with another solver. But I kinda stopped supporting it because it's so 
much work to update it everytime a small thing changes in ODE.

David Walters wrote:
> I guess what I'm saying is that I'm not so sure it's a good idea to
> add this breakable feature for the reasons I've given. If the work
> that it is doing is somehow better than using dJointGetFeedback then
> maybe I'd have a case - but for now I think it's not necessary to
> bloat up the code just for the sake of possible "helpfulness".

What the contribution does is not much better (faster) then dJointGetFeedback. 
It is pure convenience. Therefore I agree that it is better to keep the 
breakable joints outside of ODE's core. It is fairly easy to have exactly the 
same functionality with a few utility functions that only use ODE functions 
from the public API.

The only performance gain to be had from having the breakable joints inside 
the solver is that you have to loop over the joints just once. Using 
functions outside of the solver would mean you have to loop over the joints 
twice. One time to compute the contraint force inside the solver and one time 
to check if the force on a joint exceeds a set limit.

Megan Fox wrote:
> Conditions that ODE brings about internally are very, very hard to
> react to in external code.
>
> In this case, for instance, a car never just has its wheel "fall off."
>  The axel snaps (KAPAW!), the car should clang down on that side and
> skid around in a circle throwing off sparks, the guy riding the car
> should freak the heck out, etc.

In order to address that problem I added a callback function. So the effects 
you described can be implemented. The downside is that callback functions are 
ugly. Side effects in general are ugly of course, but callbacks are just a 
bit more ugly :-)


So, an overview of the pross and cons.

PROS:
- Very small performance gain
- Convenient (if breaking is the only functionality you want)

CONS:
- You need extra code in every solver
- Extremely small performance loss if you don't use breakable joints
- 1 extra pointer in every joint struct
- Can only handle 4 breaking conditions (body 1, 2 force and or torque)
- No elegant way to inform the user when a joint breaks