[ODE] Breakable Joints

[David Walters]

> Thanks for the contrib.

Hi, sorry I think I've given the wrong impression here, all I've done
is merged the "BreakableJoints" contrib by Roel van Dijk from the
contrib folder into ODE.

I'll try to answer questions on it though... and why I think it should
be added to ODE.


> I have some remarks:
>
> - It is very difficult to oversee the impact of your patch.
>   the patch file is very large: 22K lines.

Yeah, most of the bulk of the patch file is the removal of the contrib
files - I didn't realise that this would take up so much space - it
doesn't make it very readable on its own, sorry.
I'd suggest taking a copy of your local SVN copy and applying the
patch to it (I created it with Tortoise SVN) for readability.


> - As I understand, you have added some flags to the joint, and
>   a new callback for when it breaks?

Okay, permit me to copy from the original readme, that should make
things clear about the functionality:

======================================================

Functions:


dJointSetBreakable (dJointID joint, int b)
	If b is 1 the joint is made breakable. If b is 0 the joint is made
	unbreakable.

void dJointSetBreakCallback (dJointID joint, dJointBreakCallback *callbackFunc)
	Sets the callback function for this joint. If a funtion is set it will be
	called if the joint is broken but before it is actually detached or deleted.

void dJointSetBreakMode (dJointID joint, int mode)
	Use this functions to set some flags. These flags can be ORed ( | )
	together; ie.

    dJointSetBreakMode (someJoint,

dJOINT_BREAK_AT_B1_FORCE|dJOINT_DELETE_ON_BREAK)
	dJOINT_DELETE_ON_BREAK    - If the joint breaks it wil be deleted.
	dJOINT_BREAK_AT_B1_FORCE  - If the force on body 1 is to high the joint will
								break
	dJOINT_BREAK_AT_B1_TORQUE - If the torque on body 1 is to high the joint will
								break
	dJOINT_BREAK_AT_B2_FORCE  - If the force on body 2 is to high the joint will
								break
	dJOINT_BREAK_AT_B2_TORQUE - If the torque on body 2 is to high the joint will
								break

void dJointSetBreakForce (dJointID joint, int body, dReal x, dReal y, dReal z)
	With this function you can set the maximum force for a body connected to this
	joint. A value of 0 for body means body 1, 1 means body 2. The force is
	relative to the	bodies rotation.

void dJointSetBreakTorque (dJointID joint, int body, dReal x, dReal y, dReal z)
	With this function you can set the maximum torque for a body connected to this
	joint. A value of 0 for body means body 1, 1 means body 2. The torque is
	relative to the	bodies rotation.

int dJointIsBreakable (dJointID joint)
	Returns 1 if this joint is breakable, 0 otherwise.
	
int dJointGetBreakMode (dJointID joint)
	Returns the breakmode flag.

void dJointGetBreakForce (dJointID joint, int body, dReal *force)
	Returns the force at what this joint will break. A value of 0 for body means
	body 1, 1 means body 2. force must have enough space for 3 dReal values.

void dJointGetBreakTorque (dJointID joint, int body, dReal *torque)
	Returns the torque at what this joint will break. A value of 0 for body
	means body 1, 1 means body 2. force must have enough space for 3 dReal
	values.

================================================================================


>
> - Can you explain the advantage over your code over the existing
>   approach?

I think the key advantages are clarity and ease of use - to a new
user, it's very clear how to achieve the desired effect of a joint
breaking when a given force or torque exceeds a limit. Setup for this
condition is easy to setup and can be left for to ODE manage.


>   With ODE you can already add a feedback to a joint, and with this
>   feedback you can trivially test for exceeding a limit, and have
>   the joint break.

>From your point of view, I guess this patch does become redundent
given the existing joint feedback functionality.

I'd argue though that developing ODE with just a bare bones feature
set isn't very helpful for new users, I think the addition of some
more specific functionality like this would give it a friendlier image
and if new features are added sensibly, with the option to build upon
more atomic low-level features instead, I think you get a win-win
situation for everyone.


>   Why do the break-test in ODE itself, instead of the user app?

To make the feature automatic for the user, which seems to be much
more helpful than just providing functionality for you to read joint
forces.



>   The current mechanism is seems more generic:
>   You can do other stuff when limits are exceeded, other than breaking.
>   Or you can have more complex break conditions.
>
> - I'm not yet conviced that joint-breaking should be ode-space instead
>   of user-space.

I somewhat agree with what you've written here - I personally wasn't
really aware of this joint feedback system, that is partly down to the
fact that I personally never went looking for something like it
(rather than bad documentation or anything else negative about what's
there already).

You're right that it's more generic and that's probably better from a
flexibility point of view - but I think there's a need for explicit
specialisations of certain features since it makes everyones life
easier - and that's got to be beneficial to the project.


I'd like to see ODE used by more people, and I think the only way to
do that is for it to be very quick to get results with. I have
collegues who are using it for commercial applications and for them
it's a case of picking a physics engine "off the shelf" and using the
one that will get results in the time allowed.

At some level there should be some learning for a package, but I look
at Havok and that has optional sub-components written for you to do
vehicles and rag-dolls and I think that if those sorts of features
were provided with ODE it would raise its reputation.


I seem to have written a massive e-mail here, I hope I've not rambled
on too much!

Regards,
Dave