odejava missing functionality

[frdfsnlght]

This post isn't meant to pressure Will and Jani, but meant as a place to document obvious missing functionality in the odejava binding. On a personal note, these items are holding me up, but hey, no pressure  

1) Multi-geom support within a body. Need the ability to add mulitple geometries to a body, each with their own translation/rotation relative to the body's reference point.

2) Ability to remove a Body from a World. There is, of course, a way to add a body, but no way to remove one.

3) Ability to remove a Geom from a Space. Like bodies in a world, I need to way to remove geometries from collision space.

4) DisplayTransformable.setTransform method should probably have an additional parameter: the OdeTransformable the DisplayTransformable is associated with in the DisplayBin. This would allow a single class implementing the DisplayTransformable interface to handle multiple objects. This isn't important for me now, but more a matter of Java form.

Those are the obvious ones for me.

On a related note, I'd be happy to contribute to the odejava project (instead of just whining). Should I get CVS write access or should I just post diffs to this forum?

-Tab

[William Denniss]

definitely submit issues with diffs though the collabnet page (don't use the forums).

1) is coming - in fact it's already here all that is needed is some helper methods I think

2) and 3) I could probably code in today

4) I disagree with this - OdeTransformable is an interface which means "you can get the transform from the ode object".  DisplayTransformable is an interface which means "you can set the transform to the display object".  BoundDisplayObject is what bindes these together - NOT DisplayTransformable (which is a single object).  Bascially it means you can associate *any* compatable ODE object (which there are currently 2) with any compatable display object (which can be anything really).  Does this explain your query?

Cheers,

Will.

[William Denniss]

issues 2) and 3) resolved.

Note that you can't remove a body from a world then add it to another like you can with Geom and Space.  Bodies can only be destroyed entirely as far as I know.

Will

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

[frdfsnlght]

Will,

I took a look at 2) and 3) myself and slapped some code into my copy of the source to get things working.

As I looked at the code, I also realized the problem with removing bodies from a world, but I decided for my purposes, I could just disable/enable the body, I think. As I understand it, a disabled body isn't "processed" by ODE, so it doesn't take up any CPU. As long as I also remove the associated geometry from the space, then ODE won't auto-enable the body during a collision, since there's no geometry to collide with. If my understanding of this is flawed, please correct me.

Related to 3): when I implemented my own version of the removeGeom method and tried to use it, I got an JNI exception at line 335 of Geom.java. I had to comment out the call to Ode.dSpaceAdd to get it to work:

1   2   3   4   5

public void removeFromSpace () {    Ode.dSpaceRemove(spaceId, geomId);    spaceId = Space.SPACEID_ZERO;    //Ode.dSpaceAdd(spaceId, geomId); }

Evidently, ODE doesn't understand a space with an ID of zero? If that fix is correct, please incorporate it.

I'd submit it as an issue, but I'm not sure how to. I think I need to be a member in the project in order to submit an issue (according to https://odejava.dev.java.net/servlets/ProjectIssues). Should I request membership?

-Tab

[William Denniss]

hi - did you look at the changes I made?  Hopefully they are similar to what you want.

Hopefully Jani will see this thread regarding the native exception - it shouldn't happen.  Although I remember seeing that before - I thought we had fixed that one.  What OS are you running?

regarding java.net - yeach request the "Observer" role and once granted you will be able to submit issues.

Cheers,

Will.

[frdfsnlght]

No, I haven't done a cvs update for a couple of days. I'll do that tonight if I get a chance, and incorporate your changes.

I'm using WinXP Pro.

I'll request Observer role. Thanks.

-Tab

[frdfsnlght]

Will,

I removed my changes from the code, did an update and compile, and there are no problems. In fact, my project compiled without changes, so I guess we think alike as far as method signatures.

Concerning 4) my only intent was to mirror the kind of interface used elsewhere in the Java API. For instance the TableCellRenderer interface specifies the JTable the renderer is being called for, allowing multiple tables to use the same renderer and the renderer having the ability to customize itself for the table. Perhaps your interface isn't quite the same thing, but I'd thought I'd mention it anyway. Like I said, I don't require the additional functionality.

-Tab

[frdfsnlght]

This has been brought up before, but I'd thought I'd add it to this post as well:

5) "getter" methods in Body (and possibly elsewhere) should accept vecmath objects as arguments and fill them in.

If I recall a previous post, the argument against this is that it violates the java conventions. On the other hand, it greatly reduces the number of transient objects (and related garbage collection).

I also believe it was proposed to use a different method name for the additional methods (e.g., fillVelocity(Vector3f v)). That's fine by me as long as the functionality is there and the extra objects are kept to a minimum (or never created at all).

-Tab

[William Denniss]

can you please show a specific example?

I have recently added several such methods to Body and Geom.

Will.

[William Denniss]

that discussion is here by the way: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=physics;action=display;num=1078922931

Will.

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

[frdfsnlght]

I see some of them now with the update I did earlier. But I don't see these (in Body.java):

1   2   3   4   5   6

public Vector3f getAngularVel(Vector3f result); public Vector3f getFiniteRotationAxis(Vector3f result); public Vector3f getForce(Vector3f result); public Vector3f getLinearVel(Vector3f result); public Matrix3f getRotation(Matrix3f result); public Vector3f getTorque(Vector3f result);

And in Geom.java:

1	public Matrix3f getRotation(Matrix3f result);

Sorry to be so anal; I was raised an engineer. Thanks for the work so far.

-Tab

[Jani Laakso]

This post isn't meant to pressure Will and Jani, but meant as a place to document obvious missing functionality in the odejava binding. On a personal note, these items are holding me up, but hey, no pressure  

Hey, ideas are always welcome!  

1) Multi-geom support within a body. Need the ability to add mulitple geometries to a body, each with their own translation/rotation relative to the body's reference point.

This should already work on Odejava, although only on Low Level, William is doing work with High Level API.

2) Ability to remove a Body from a World. There is, of course, a way to add a body, but no way to remove one.

This is because how ODE works, and may I say ODE's own API is pretty wierd from some places. There is no way to remove body from a world. Also when creating a body you have to add it into a world same time which later cannot be changed, in other worlds when you create an body on ODE, worldId is required parameter.

3) Ability to remove a Geom from a Space. Like bodies in a world, I need to way to remove geometries from collision space.

This already works, however I do not remember if it's added to Higher Level API? Now that I checked the source code I see that William has already added this method to Higher Level API also.

4) DisplayTransformable.setTransform method should probably have an additional parameter: the OdeTransformable the DisplayTransformable is associated with in the DisplayBin. This would allow a single class implementing the DisplayTransformable interface to handle multiple objects. This isn't important for me now, but more a matter of Java form.

I'll let William to handle this, perhaps now it's already fixed?

On a related note, I'd be happy to contribute to the odejava project (instead of just whining). Should I get CVS write access or should I just post diffs to this forum?

You can post patches here first, then ask for developer status if it seems that you really want to participate and do commits every now and then.

[Jani Laakso]

Will,
As I looked at the code, I also realized the problem with removing bodies from a world, but I decided for my purposes, I could just disable/enable the body, I think. As I understand it, a disabled body isn't "processed" by ODE, so it doesn't take up any CPU. As long as I also remove the associated geometry from the space, then ODE won't auto-enable the body during a collision, since there's no geometry to collide with. If my understanding of this is flawed, please correct me.

This is wrong, because ODE automatically enables any disabled body that comes in contact with another enabled body. Hope you got it?

Here's part of ODE's own documentation:
Enable and disable a body. Disabled bodies are effectively ``turned off'' and are not updated during a simulation step. However, if a disabled body is connected to an island containing one or more enabled bodies then it will be re-enabled at the next simulation step.

Remove it from space would do the trick you are looking for.

Related to 3): when I implemented my own version of the removeGeom method and tried to use it, I got an JNI exception at line 335 of Geom.java. I had to comment out the call to Ode.dSpaceAdd to get it to work:

I assume the HL API Geom.removeFromSpace now works?

[William Denniss]

an update:

#1 I'm having troubles with this one - even the low level API but that's another thread/issue

#2 Won't fix - use World.delete that's all there is

#3 Already possible

#4

I misunderstood this before, I think I understand you now.  However - I still don't really see the point.  If you can present a good use case I will consider it.  DisplayTransformable is really meant to represent a single object - not a collection.

The org.odejava.display package is very simple - I would think if you had a specific case like this you'd just implement your own way of keeping them in sync.  For me, I don't see the need

Will.