Odejava with custom collision detection

[Mithrandir]

I'm trying to work out how to integrate a custom collision detection routine into the Java bindings to ODE. In the C-world, I would just make sure I have the right callback defined for my body geometry (dGeomMoved()).

In the low-level bindings, the code is back to front. It's making a JNI call to a method of the same name, rather than the other way around of having the native code make a callback to the Java code. ie

1   2   3

public static void dGeomMoved(SWIGTYPE_p_dGeomID arg0) {     OdeJNI.dGeomMoved(SWIGTYPE_p_dGeomID.getCPtr(arg0));   }

So, has anyone else managed to work around this issue and integrate custom collision detection with the basic physics engine? If so, how did you do it?

[William Denniss]

Jani knows more about the C side of Odejava, I have emailed him pointing to this question.  I'm sure there is a way to do it.

Will.

[Catharsis]

So, has anyone else managed to work around this issue and integrate custom collision detection with the basic physics engine? If so, how did you do it?

I am interested in this as well for integration with Auriga3D. I however, will not be looking at this possibility until January most likely.  Basically I want to use the BSP collision mechanism in Auriga3D, but ODE for dynamics.

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

[Mithrandir]

Thanks. From my other experience with ODE, and looking at a lot of example code using it, those callback functions are fairly critical to making it all work.

Found some more missing API calls too, but I'll start a bugzill entry about those.

[Jani Laakso]

I'm trying to work out how to integrate a custom collision detection routine into the Java bindings to ODE. In the C-world, I would just make sure I have the right callback defined for my body geometry (dGeomMoved()).

Do you actually mean that you do not wan't to use ODE's internal collision detection and use e.g. Java side collision detection library (this means that you must know ODE very well)? ODE's own collision library is quite good and it works nicely with ODE itself so I suggest you use it.

Or do you mean that you would like to handle ODE's callbacks (e.g. nearCallback) on the Java side? Easiest way currently is that you do your callback routine on the C side, they are simple routines in any case. I might add support for Java side callbacks later but I dont know when.

I'd really wan't to clean up Odejava's C side and better up the API for Java side. Also I got nice optimizations (JNI directbuffers) still pending (didn't commit them half a year ago). Have to wait and see if I get spare time any time soon now.

Jani.

[Mithrandir]

Do you actually mean that you do not wan't to use ODE's internal collision detection and use e.g. Java side collision detection library (this means that you must know ODE very well)? ODE's own collision library is quite good and it works nicely with ODE itself so I suggest you use it.

That is correct. I've used ODE on a couple of other private projects as C code. OPCODE is quite poor when dealing with large numbers of collidable objects - particularly when I need to know exact collision points on complex geometry. I have some other pure-java libraries that I've already written that I want to take advantage of.

In addition, I'd like to also be able to integrate it with simpler collision detection from non-physical objects. Think about simple ray-casting style picking to perform the collision detection. In particular this is used for some underwater vehicle modelling that we have to do for a project here. Without getting into the details, we're doing sonar modelling that will generate our "collisions" that will then be fed back into the physics model used to model the vehicle. A similar application could be used to drive a land-based automous robot, for example (not that this is what we're currently doing, but probably more familiar to most people here as an agent). You want the object to obey the basic laws of physics about turning/toppling/grip etc, but they don't want to do something at the point they've already collided with another object, but some time beforehand.