Do you think there are any ways to improve the current Ode Objects? Thenew high level Odejava objects are a very good step in the rightdirection however there are still some issues that I feel are holdingthem back. The issue I have is that when you create say a Joint object,the object is added to the Space automatically. I understand this isdue to the C roots of ODE but I feel it would be nice to have an evenmore Object Oriented approach.

The Xith3D model has several advantages, not the least being readabilityand also that you can add a BranchGroup to one scene - then say tenminutes later it can be added again to another scene (assuming it wasremoved from the first one). With OdeJava one would have to call theconstructor of all those methods again. Like with BranchGroups, OdejavaGeom's would have to be acyclic.

Having Odejava and Xith3D share the same model would also helpreadability immensely.

I believe this change is more of a design decision than a large codingeffort. As far as I can tell, it wouldn't be hard to refactor thecurrent objects.

* Geom.java would need a new abstract method "addToSpace(Space space)"

* GeomBox.java for example would need this change:

Local variables: float sizeX, float sizeY, and float sizeZ in theconstructor would need to be instance variables

* GeomBox.java would need to implement the addToSpace method and have itcontain the Ode.dCreateBox ODE constructor.

So the main changes will be a new method in the Geom's so they can beadded to a Space, and storing the initialisation data in the geom.

Doesn't Space already have a method addGeom(Geom)? The constructor of the geoms could be changed to not call this method automatically. (I currently don't have the time to look at this in detail, so sorry if I am off the beam.) And yes, I agree with your thoughts.

Ode.dCreateBox is the line which is adding the box to ODE. Also - all of those variables are actually temp variables, so currently this operation can only be performed in the constructor (yes it's a trivial change I know).

Perhaps one way of doing it is to add an abstract method to "Geom" which is like "addToSpace(Space space)";

Essentially what I am saying is that it would be nice for these objects to have a use after construction. Currently that's all they are good for. It'd be nice to be able to add them to spaces, remove them from spaces, change their size etc... We can also code in Serialization as a nice by-product of this.

Xith3D/Java3D serve as a good model for this IMHO. A physics engine is quite similar to a 3d scenegraph in many ways just with the results being mathematical not visual. In fact due to the fact both have similar results (some kind of virutual world) but different ways of getting thereAPI's, it makes it harder to think it out.

Higher Level (HL) API is simple as the underlying ODE does not require for the HL API to be complex. So putting this API in shape should not be a big task. Current HL API was 'designed' and implemented in a weekend or so, actually it was more of getting Odejava 0.2 released than properly designing API and thus postponing release again with weeks..

Currently all Geoms that are created are implicitly added to Odejava.getCurrentSpace(). So if you want to add Geoms into different spaces then you have to change your 'current space' by calling Odejava.setCurrentSpace() each time you're hopping to another space. This is of course completely wrong design. Note that Odejava class has also currentJointGrouop and currentWorld, these are quite analoguous to currentSpace.

At least Geom.java and Body.java should be changed.

One option is to add Space into Geom's constructor (this affects all non abstract Geom classes, like GeomBox, aswell).

Another option would be when Geoms are created, add them always to non-existent space (zero). Then create addToSpace method and use this to set Geom into a space that developer wishes. I think this is good solution, and is exactly what Will suggested.

Same thing should be done for currentJointGroup. Initially they go to zero ("non-existent limbo"), and developer needs explicitly to call myJoint.addToJointGroup(myJointGroup)

* GeomBox.java would need to implement the addToSpace method and have itcontain the Ode.dCreateBox ODE constructor.

I'd like to implement mySpace.addGeom(myGeom) instead of myGeom.addToSpace(mySpace). I assume this is what you meant.

Quote

* GeomBox.java for example would need this change:

Local variables: float sizeX, float sizeY, and float sizeZ in theconstructor would need to be instance variables

Yes, this might be good also. There's other classes also where data would be nice to be accessed through instance variables.

Instance variables are nice but they might have some issues as ODE gives the final word what is their value. Also they are redundant, but on the other hand save us from JNI calls. The main issue I could think of is that if something (lower level API calls, ODE itself) changes these variables then Java instance variables are out of synch. Hence the simplistic "non-java style" implementation of float[] GeomBox.getLengths() that returns x,y,z lengths in a single call. Perhaps adding more conviniency methods would do the trick, like getLengthX() etc?Other option is to trust that ODE does not change these values without Odejava's knowledge, this is the case with GeomBox classes x,y,z sizes.

Summarum:

Initially all created Geoms or Joints are in limbo, they do not affect simulation in any way.

Definitally A is better, I agree - but you could always have both (myJointGroup could simply call myJoing.addToJointGroup(this)).

Quote

One option is to add Space into Geom's constructor (this affects all non abstract Geom classes, like GeomBox, aswell).

Another option would be when Geoms are created, add them always to non-existent space (zero). Then create addToSpace method and use this to set Geom into a space that developer wishes. I think this is good solution, and is exactly what Will suggested.

I don't like the first option. The second option is ideal, apart from anything else it will make Odejava code much more readable.

Regarding the instance variables - what I would like to see is definitally the Ode objects being "useful" after creation be it though instance variables or JNI calls, callbacks. A few more methods like "mySpace.remove(Geom)" and ones like that would be nice too.

Just to make sure I am on the right track - if I want to use this nothing space - I just use this as my spaceId:

1

newSWIGTYPE_p_dSpaceID(0, true);

yes?

Will.

Yes, you could use also Ode.getPARENTSPACEID_ZERO() method, it has the same effect. Actually better name for this method should be simply: Ode.getSPACEID_ZERO(), just like the other get*ID_ZERO() methods.

Yes, you could use also Ode.getPARENTSPACEID_ZERO() method, it has the same effect. Actually better name for this method should be simply: Ode.getSPACEID_ZERO(), just like the other get*ID_ZERO() methods.

Ok, I'll use that. Infact I had just created a SPACEID_ZERO static object as part of the Space class - maybe I'll still keep it just for conveniance (but have it call getSPACEID_ZERO() instead).

The conversion is progressing - I would have finished it yesterday had I not fallen asleep :-/

I've been playing around trying to get the optimal mix of readability vs. succinctness (with emphesis on the former) into the high level objects. I have drawn upon Swing, AWT and Xith3D/Java3D as references.

Basically I am elimitation anything that's not explicit. In other words - Odejava.getCurrentX() and removing Space from Body (infact there is a todo in the source to do just that). The main problem with these static calls is that unless you have the source in front of you, you think "how does it know which space to add my body too?". Removing everything todo with Space from the Body class is also a good think I think - the programmer then must do this explicitly.

I think that totally getting rid of Odejava.getCurrentX() methods is wise - the programmer is free to code their own equivilent (taking all of 3 seconds).

Will, just go for it.

Explicit process (even if longer) is definately better than wrapping up things implicitly under some class. The old implementation was done in a flash, it's bad just as you and source comments stated ("these should be removed").

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org