Okay arne! 
That was kinda cute there, but my real question is the feasibility and would it be of any real value to do.
If we are going to implement the use of PPU, we would first have to clear out, how such a PPU works and then we would have to acess it some way (JNI 
).
we could simply write the code with that idea in mind, so we can change that later on, when somebody needs it. Another advantage of having it directly in Java.
So my conlusion: “Ignore” that first and implement it later on.
Is there a tool that generates an UML-diagram for the ODE source? Or has somebody created such a diagram? I think this would be a good idea for a starting point. I believe there’s loads of stuff, we don’t have to recode (e.g. Quat-multiplication), we could use javax.vecmath for that.
A UML diagram would be an excellent way to start. There are some UML tools that reverse engineer the code to a UML diagram. But I don’t know about C++. IMHO C++ is not really a true OOPL anyway. :o
Which tool did you use?
Damn you arne! I was just doing one before you posted that! Great stuff though, this needs to be analysed to see how it converts pointers and things.
What did you use? I was going for boUML. Can that model be transported into a JAVA freindly UML tool? Can you generate java stubs for that?
Can you supply a list of the C stubs it missed out (so we can create a static class with stubs)
Wow! BoUML is the new greatest open source UML tool on the market! It is very much like rational rose. Its a bit quirky still but it seems like its pretty powerful. I have a reversed engineered a very powerful c++ model. I think the class image is too big to fit on these forums. It is 360Kb.
The UML tool has used UML stereotypes to preserve the typedef struct and even template declarations. It has basically managed to preserve so much information its amazing. There are about 70 class like concepts it has managed to preserve after reverse engineering.
Your UML diagram seems to be corrupted.
I used umbrello to generate mine.
Yeah. Its coz the image is too big to upload into the forums. I have only just arrived at my new university. I do get webspace so I will use that once I work out the finer details of using it.
Won’t be till 2morrow though.
On another note, I don’t think we should worry about extra features such as PPU. If anything we should be discussing what features we do not need.
My list at the moment is:-
Trimeshes – they don’t work
FastStep – it is depricated
QuadTreeSpace – its a 2D datastructure, should be an OctTree if anything
Then I think we should talk about priorities.
The first thing to do is a skeleton implementation so we can actually run something.
Geometries: Sphere, then box and maybe nothing else
Space: SimpleSpace maybe HashSpace.
Joints: Slider, Hinge (becuase with those two you can more or less create any of the other types, one is for a linear degree of freedom and the other is rotational)
For the world the normal step should be implemented first. Quickstep can come later.
Obviously there are alot of gubbins that need to go under all that. When I look at the ODE code I see alot of things that have JAVA equivelents like the dStack, and dMatrix etc. I would suggest that we don’t do a straight forward port of their implementations, but do not try to substrituite either. We should go for the adapter pattern and recornstruct the equivelent methods that then delage to the JAVA version.
I really really like the BOUML tool. I think it will be able to provide a pretty comprehensive java skeleton to be filled in. UML lovers should check it out, I have used lots of open source UML tool like Argo now Poisiden, Eclipse etc and commercial ones like rational rose, Together. Never used Umbrella. Anyway this tool is really powerful despite being pretty new. Its a bit of a UI nightmare to control, but its more than made up for in power.
So these are my thoughts at the moment. They are just thoughts. Please feel free to criticize my ideas and put forward alternative ideas.
The key problem is all those “dReal *” fields. they point to matrices some times, vectors other times. arrays of vectors some times, arrays of matrices other times, etc. Some times perhaps they can be null?
It’s getting that high level understanding of exactly what they are that needs to be sorted out. I think that will take some time to dive into the depths of the C/C++ source to figure out what those pointers really mean.
Yeah. Those dReals are annoying. Most are fairly obvious what they should mean.
My webspace is not available yet so I cannot put up my UML diagram yet. However I have used BOUML to generate java. It has messed up a few attributes and missed a few things, but generally it is pretty good:-
struct dxBody : public dObject {
dxJointNode *firstjoint; // list of attached joints
int flags; // some dxBodyFlagXXX flags
dGeomID geom; // first collision geom associated with body
dMass mass; // mass parameters about POR
dMatrix3 invI; // inverse of mass.I
dReal invMass; // 1 / mass.mass
dVector3 pos; // position of POR (point of reference)
dQuaternion q; // orientation quaternion
dMatrix3 R; // rotation matrix, always corresponds to q
dVector3 lvel,avel; // linear and angular velocity of POR
dVector3 facc,tacc; // force and torque accumulators
dVector3 finite_rot_axis; // finite rotation axis, unit length or 0=none
// auto-disable information
dxAutoDisable adis; // auto-disable parameters
dReal adis_timeleft; // time left to be idle
int adis_stepsleft; // steps left to be idle
};
gets turned into
package JDE.generated;
class dxBody extends dObject {
// list of attached joints
public dxJointNode firstjoint;
// some dxBodyFlagXXX flags
public int flags;
// first collision geom associated with body
public dGeomID geom;
// mass parameters about POR
public dMass mass;
// inverse of mass.I
public dMatrix3 invI;
// 1 / mass.mass
public dReal invMass;
// position of POR (point of reference)
public dVector3 pos;
// orientation quaternion
public dQuaternion q;
// rotation matrix, always corresponds to q
public dMatrix3 R;
// finite rotation axis, unit length or 0=none
public dVector3 finite_rot_axis;
// auto-disable parameters
public dxAutoDisable adis;
// time left to be idle
public dReal adis_timeleft;
// steps left to be idle
public int adis_stepsleft;
}
This reverse engineering and generating system can only go so far though. Everything still needs to be checked by eye. It seems feilds generated like int x,y; seems to get missed, and it only really can reverse enginner the model. Porting the implementation is the real work and I don’t know of any tools to help with that.
There’s probably no way around of understanding how the ODE code works, without risking lots of errors and bugs.
I agree. IMHO I think the best attempt is to develop a pure Java physics engine from the ground up. There are plenty of game physics and generat physics book available.
When I looked at the code I found that some ODE classes would not need to be ported verbatim. For example dObject is not needed at all, I think. Nor, is the ODE array class. Java already has things to handle that. The array class of ODE seems to be either a direct Java array, or an ArrayList - depending on how it gets used… as in if it really needs to have a dynamic size.
Another question would be, should generics (and therfore a Java 5+ requirement) be used? I’m inclined to say yes, use generics. Around the time you are done, Java 6 will probably be released so you would still be supporting one major version back and you would get the advantages that Generics (and Enums, and for-each, etc…) will offer.
Nice idea in theory. For that we would need a dedicated team and a physics export.
To port ODE, we at least are starting with a mature physics engine and while Odejava still supports the native JNI ODE (which will be until this pure java port is ready) the quality of the port can easily be validated against ODE itself (using Odejava).
Will.
This is good
How would using generics help in this situation? I have not yet used them (still on 1.4.2 here) so I don’t know myself.
As for Enums, for-each, etc. Alone I don’t think they are compelling reasons to use 1.5 but I agree if we go 1.5 we may as well use them.
Will.
If you (or anyone else working on xith3d/odejava related projects) need webspace, send me an email, I have some space I can share (in the form http://users.xith.com/username).
Will.
I would go for generics and other features. I find they help in my productivity becuase intelligent editors like IntelliJ and Eclipse can auto generate more code when you use them. I think they can simplify code very well. I am not sure exactly where they could be used in the port becuase using them implies reorganizing the ODE design which is not what I think we should be doing.
[quote]When I looked at the code I found that some ODE classes would not need to be ported verbatim.
[/quote]
Yeah I am not sure about this. I think maybe that array class in ODe should probably go becuase it does not seem to be doing anything clever. Things like the dMatrix though I think should be included as a seperate class, whose implementation should delagate to the Matrix3f (or 4f or whatever) in Vecmath. I think its important though that we still make a wrapper that looks exactly like the ODE equivelant (actually that is impossible becuase in ODE they use operators on the class) .
[quote]IMHO I think the best attempt is to develop a pure Java physics engine from the ground up
[/quote]
No. I will not be part of such an effort becuase I do not think it would ever get finished. I am hioping that the ODE port might be a possible base for others to build from.
How do we go about getting the project allocated?