[Odejava] setting the Body mass before adding geom

[William Denniss]

I just spent an hour hunting this particular bug and despite the fact I now know the cause - I still don't know why.

Basically - I was adjusting the mass before adding a geom.  The result was the the collisions wern't happening.When I changed the order around - it worked again.  Any idea why?

I've altered the Body method to warn against this:

1   2   3   4   5   6   7   8   9

public void adjustMass(float mass) {                     if (geoms.size() == 0) {                 System.out.println("Odejava - warn: geoms should be added before the mass is adjusted");           }                   Ode.dMassAdjust(massId, mass);         Ode.dBodySetMass(bodyId, massId);     }

but I'd like to know the reason behind it before I commit it in.

On a related note - we probably need a better Odejava logging setup so developers can log such warnings.

Will.

[William Denniss]

btw - if the problem lies with ODE then I shall raise it in the appropriate ODE forum - I just want a sanity check first

Is this "mass must be set after geoms are added" clause an Odejava or ODE limitation?

Will.

[Jani Laakso]

btw - if the problem lies with ODE then I shall raise it in the appropriate ODE forum - I just want a sanity check first

Is this "mass must be set after geoms are added" clause an Odejava or ODE limitation?

I'm quite sure that the cause is ODE itself. Roughly sayed, it's a typical C styled project that misses a lot of checks, no exceptions, anything goes styled programming is allowed. Even I have found various oddities from ODE, you just have to do things in certain order, best is to see example files and follow their style.

Games published by our own members! Check 'em out!

[William Denniss]

thanks.

I think this is another reason (together with doc compatability) that Odejava  should by design be built and advertised as purely an ODE OO/Java interface.  Trying to overcome such limitations like this will be a pain.  Most calls currently are fairly intuitive as to what the underlying method calls are, but perhaps we can make it a policy that all ODE calls are declared in the docs.

I'll look into adding log4j so we can setup warning levels - and add this warning to the logging (rather than System.out).

Will.

[matheng10]

Ok today I lost about three hours finding the same bug :-)

I wish i looked at the top of the console window ;-)

I also think I found the cause:

You cant' call adjustMass if you don't have a properly set-up dMass for your body. (if i understand it right adjustMass simply "scales" the current mass structure)
If you create a body without passing a geometry the dMass gets allocated but not properly initialized i solved the problem setting the default dMass for a Body to be a sphere with radius =1 in Body.java around line 140 i modified

       if (geom != null) {
           setGeom(geom);
       }

with

       if (geom != null) {
           setGeom(geom);
       }
       else
           Ode.dMassSetSphere(massId, DEFAULT_MASS_DENSITY, 1f);

Now back to the parser ;-)

[William Denniss]

tsk tsk, not reading the forums

You are jumping the gun a bit on Odejava XODE support - currently release 1.0r17 has a bug the ordering (as you found) of the elements needs to be changed.  To fix the bug - your xml is invalid according to 1.0r17.  1.0r18 will be released soon.

The Odejava XODE impl is the "reference" XODE implementation and currently the only - hence as I am coding it I am ironing out problems with the spec.  You really are brave to be using it in this early stage.

I did offer to put priority on the bits you needed when I continue coding this long weekend.

Please email me any code you create if you would like it included in the API.

drop me an email and I'll give you my ICQ number if you like.  If you are developing code of mine that is currently in pre-alpha mid-development stage I strongly urge you to have an open dialog with me (ICQ/Email/Forums whatever).  Too late now I guess...

Will.

[matheng10]

I sent my details to you so we can coordinate on the parser

About this bug:
Maybe the correct behaviour should be changing Odejava to refuse (exception? assert?) an adjustMass before a proper dMass is supplied (through setDefaultMass(Geom) setGeom (which calls setDefaultMass with the passed Geom) setBoxMass or setSphereMass)
or agree that Bodies start with a default mass some kind of geometry.

[William Denniss]

got ur ICQ#

I agree - probably an exception as it is an illegal state to be in.  Can you make a patch please?  Throwing IllegalOdejavaException is probably the best way I think.

Odejava should never though a native exception or do "strange" things like this - everytime I come across a method which if used in the wrong circumstances causes this I have been trying to document and warn against it.

Will.