[Odejava] JavaCollision shenanigans

[William Denniss]

I am very close now to removing all of the code in Odejava.java relating to the static storage of the current World/Space and JointGroup objects.

Here's the bind:

If you compile the current CVS, you will get 5 warnings, relating to the use of setCurrentWorld.

Since both setCurrentWorld and getCurrentWorld are marked as deprecated and the internal objects are private, you may ask as I did: "if nobody is using the getCurrentWorld(), why is setCurrentWorld() being used?".

This is a very good question.  One I am hoping Jani may be able to help me with.  The problem is that if you don't call setCurrentWorld - the shit hits the fan nativly in the JavaCollision class.  This is despite the fact that it never calls getCurrentWorld (from within Java code).

Here's the dump:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16

Unexpected Signal : 11 occurred at PC=0x4DCF3F36 Function=(null)+0x4DCF3F36 Library=/usr/java/j2sdk1.4.2_03/jre/lib/i386/libodejava.so   NOTE: We are unable to locate the function name symbol for the error       just occurred. Please refer to release documentation for possible       reason and solutions.     Current Java thread:         at org.odejava.collision.JavaCollision.createContactJoints(Native Method)         at org.odejava.collision.JavaCollision.applyContacts(JavaCollision.java:153)         at org.odejava.test.car.Car.step(Car.java:473)         at org.odejava.xith3d.test.CarExample.render(CarExample.java:237)         at org.odejava.xith3d.test.CarExample.main(CarExample.java:108)

Everyone's favourite SIGSEGV ;-)

Can you please look into this code Jani?

Once this is cleared up then those static methods will be gone forever from Odejava.

Cheers,

Will.

[Jani Laakso]

I am very close now to removing all of the code in Odejava.java relating to the static storage of the current World/Space and JointGroup objects.

Excellent! I'll check this today or tomorrow latest.

This is a very good question.  One I am hoping Jani may be able to help me with.  The problem is that if you don't call setCurrentWorld - the shit hits the fan nativly in the JavaCollision class.  This is despite the fact that it never calls getCurrentWorld (from within Java code).

The answer is found from odejava.cpp. I'll check this issue later but for now you must set the world (once) before stepping simulation ahead.

Here's a fix:

public void stepFast() {
 Ode.setWorldID(worldId);
 Ode.dWorldStepFast1(worldId, stepSize, stepInteractions);
}

public void step() {
 Ode.setWorldID(worldId);
 Ode.dWorldStep(worldId, stepSize);
}

So add Ode.setWorldID(worldId); line to both methods, this will remove the crash you got.

[William Denniss]

I tried that temporary fix but still had the same problem but I didn't look to deeply into it.  There's no hurry.

Another question I have is regarding Geom which is attached to the zero space - it is perfectly ok to call any of the methods on it is it, even before it's added to a Space?

Currently there is a check to prevent this but I am thinking that some of these can be safely removed.  However I will leave an assertion in the addToSpace method to ensure that a Geom can't be added to a Space if it's already in one (the correct procedure is of course to remove it first) and I'll probably make this method final as well.

Cheers,

Will.

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

[Jani Laakso]

I tried that temporary fix but still had the same problem but I didn't look to deeply into it.  There's no hurry.

Sorry, I gave wrong instructions, I should have checked this from the source code and not rely on my memory alone.

Currently Odejava supports only single World. Odejava.cpp needs to be converted from static into instantiable class, after this is done the setCurrentWorld method can be removed and then Odejava supports multiple Worlds.

Let's keep setCurrentWorld method for now, I also removed deprecated status from setCurrentWorld as it is required for now.  I'll add multiple world support for Odejava later after some more important things are done.

Another question I have is regarding Geom which is attached to the zero space - it is perfectly ok to call any of the methods on it is it, even before it's added to a Space?

ODE's own documentation can help out here. Although it is  somewhat sparse on some areas. If the documentation won't tell this, then you need to ask it from q12.org or try i out yourself.

Currently there is a check to prevent this but I am thinking that some of these can be safely removed.  However I will leave an assertion in the addToSpace method to ensure that a Geom can't be added to a Space if it's already in one (the correct procedure is of course to remove it first) and I'll probably make this method final as well.

There's some things that user can do in "wrong order" and on some cases ODE won't even complain anything but can ignore some setting that was done too early. This is just a hunch that I have based on my ODE experience.

Optimally Higher Level API should make all kinds of checks and make sure processes are executed in right order. This requires some testing if you wish to find most problematic cases out.

At this point I wouldn't worry if HL API does not contain all the asserts that it should have. Just make sure the demos work so Odejava newbies see how things should be done.

[Jani Laakso]

I removed all deprecated World.setCurrentWorld calls from the demos. They are no longer required.

Deprecated status is back online with setCurrentWorld

Current world is now set when creating a World. There's an assert on the class to make sure that World is created only once for now. This will be removed when multiple world support works properly on Odejava. It's not a big task but requires me to convert Odejava.cpp into object oriented class.

[William Denniss]

Great

The demos worked calling the methods on the Zero Space so I will assume it is no problem.  Hence I removed these redundant asserts (but still leaving some which do matter).

Will.