[ODE] Breakable Joints
Roel van Dijk
roelvandijk at home.nl
Thu Aug 31 11:09:43 MST 2006
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.
- Very small performance gain
- Convenient (if breaking is the only functionality you want)
- 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
More information about the ODE