Hi All,
First off - I feel Odejava is coming along very nicely - especially with
Jani’s new collision objects.
I have been doing some more Xith3D <–> Ode work recently and would like
to suggest a slight improvement on the way the integration between those
API’s is organised based on my observations.
I found the OdejavaToXith3D class quite confusing. It does two tasks -
one is that it creates Xith3D representations of Ode objects, and the
second is that it updates the Xith3D objects with the correct new
coordinates of their bound bodies.
What I find confusing is that there are several linked lists and the
userData method of TransformGroup is used.
I think that the updating probably should be kept separate of the object
generation code and also it would be nice to decouple some of the
binding code from Xith3D and make it an abstract library which would
enhance readability and make it easier to support other display
libraries such as jMe.
So here goes:
There is a new package:
org.odejava.display.*
Basically it has an object named "DisplayBin" which stores all "Bound"
display objects (for example a Xith3D TG bound to an Ode Body). Calling
updateAll will update the display objects transform based on the Ode
one.
These bound objects are in a class named "BoundDisplayObjects" which
simply stores the DisplayObject and OdeTransformable (ie. body or geom).
DisplayObject is an interface which Xith3D and any other display API can
implement to use with Ode.
This package has some abstract classes and interfaces. Here are their
stubs and partial implementations.
/**
* Container of BoundDisplayObjectS
*/
public class DisplayBin {
protected List displayObjects = new ArrayList();
// some List methods such as add, remove, iterator ...
/**
* Calls update on all contained BoundDisplayObjectS
*/
public void updateAll();
}
/**
* Represents an abstract Display Object that is bound to
* an Ode Body or Geom (the OdeTransformable).
*/
public class BoundDisplayObject {
protected DisplayObject displayObject;
protected OdeTransformable odeObject;
public BoundDisplayObject (DisplayObject displayObject,
OdeTransformable odeObject) {
...
}
public void update () {
displayObject.setPosition(odeObject.getPosition());
displayObject.setQuaternion(odeObject.getQuaternion());
}
}
/**
* Interface for the DisplayObject
*/
public interface DisplayObject {
setPosition(Vector3f);
setQuaternion(Quat4f);
}
As you can see - to add support for a new graphical library all that is
needed is to create an object which implements DisplayObject - in the
case of Xith3D this is obviously TransformGroup.
I believe OdejavaToXith3D could be retrofitted to support this
abstraction so the API doesn’t break this time. Most of OdejavaToXith3D
wouldn’t be touched - only methods which do what this package would do
(i.e. the ones using these variables).
// Result lists, updated by createTransformGroups() method
LinkedList geomTransformGroup;
LinkedList bodyTransformGroup;
Ultimately I’d like to see those methods totaly removed - but they could
be deprecated for now.
So then there is a mere two classes any graphics library must implement
- the DisplayObject interface (which is dead simple) and some way to
generate it’s objects from the Ode ones.
If the response to this proposal is positive, I will do the modification
within 24 hours and have it in CVS. As I said - the API won’t break
(just some deprecation) so don’t worry about your code breaking.
I await your comments.
Regards,
Will.
Don’t know if there exists any patterns for this kind of problem, I’ve never needed to concern too much about object creation problems before, even on large projects.