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:-

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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.

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.

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).

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.

This is good

Quote

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.

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.

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.

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

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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.

Fair points however I would prefer to see an exact ode related reason to abandon 1.4 being that JOGL, LWJGL, Odejava and Xith3D are still all 1.4 compatable. Ultimately it's up to the primary coder I guess, that is just my opinion

Quote

Quote

IMHO I think the best attempt is to develop a pure Java physics engine from the ground up

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.

One can create the project in java.net, but then the JGO board has to approve it. Perhaps we can petition for a speedy approval given we are not just a bunch of unknowns.

We need to decide on the name and who the owners are.

My votes are for "pureode" for the former and the main developers (defined as those who are committed to working several hours a week on the project) for the latter. What do you think?

How related will this project be to Odejava? Ultimatlly most people will be wanting an O-O layer anyway so I am guessing it will be quite related. Perhaps we should make it a sub-project of Odejava (which basically just affects the navigation from the java.net directory and nothing else I think).

t_larkworthy, you are sounding very enthusiastic - are you prepared to take the role of team leader? I am certainly prepared to commit a substantial effort to the project but I don't feel that I am the most qualified to lead it.

As for project leader, yes I would be prepared to take that role if everyone is ok with that. I shall list a few things that I think make me suitable for the role for anyone who needs convincing.I have played around with the code of ODE.I have made a pretty comprehensive robot simulator based around javaode, I was thinking of open sourcing that but I would rather get the underlying technology more stable (which is what this should achieve).My math is fairly strong. (Java like most people here is 2nd nature and not really worth mentioning)I have been a designer for two fairly substantial (albeit J2EE) commercial software projects.c and c++ is good, though not up to my Java

My drawbacks are:I have just started a MSc in Neuroscience after completing an MEng in Software Engineering. As all you techies will realise its pretty difficult learning lots of biology from nothing. The overall plan is to do a PhD in neuroinformatics after that. Anyway the workload is pretty punishing, so although most weeks I would like to put in more than 5 hours, some weeks I will have to be strict about how many hours I do. I imagine I will do most work on this project on Sundays.

I have never been a team leader before.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

I have just started a MSc in Neuroscience after completing an MEng in Software Engineering. As all you techies will realise its pretty difficult learning lots of biology from nothing. The overall plan is to do a PhD in neuroinformatics after that.

Very interesting research ... I had done some graduate research in ALife which I think is partially related. Just wasn't as serious as you. Good luck with your research!

When reading all these plans for a physics-engine, I can't help but mention that PPU (Physics Processing Unit) that is about to be released on the market. Hardware acceleration will completely blow away any code that runs on the CPU/GPU doing the physics. So what's the point of truely reinventing the wheel, when such a superb piece of hardware is about to shift our way of thinking abuot physics? Bindings to that engine will also support systems without a PPU because it can also run on the CPU.

PPU accelerated - good and fine, but how do you want to get it to Java? Wait until ODE manages the acess or write a on the PPU's physics-API dependent Java-Interface? Especially the Java-Interface for the PPU is not an option, because who says, that that PhysX API will get the standard? And another Point: It looks, as if it only works for Windows, so we could through Java's platform independency into the garbage bin!!

Ok back to topic...I think it is a very good idea, that t_larkworthy becomes the project leader.

PPU accelerated - good and fine, but how do you want to get it to Java? Wait until ODE manages the acess or write a on the PPU's physics-API dependent Java-Interface? Especially the Java-Interface for the PPU is not an option, because who says, that that PhysX API will get the standard? And another Point: It looks, as if it only works for Windows, so we could through Java's platform independency into the garbage bin!!

I agree. In IT it is always wise to keep abrest of new developments but rarely wise to put on hold current work waiting for them. Wait till it is standardised and supported, then we can worry about it. Who knows what areas will be optimised anyway, CPU intensive operations might be easilly passed off to the PPU when the appropriate bindings exist. Furthermore who is actually going to have a PPU? Until they build them onto the GPU almost nobody and even then it will take years to become mainstream. My game is designed to run on a GeForce MX 400!!

Quote

Ok back to topic...I think it is a very good idea, that t_larkworthy becomes the project leader.

I don't really mind, but when I hear JDE I think "Java Development Environment" i.e. a variation of IDE. Google seems to agree

JODE was my first choice as a name for Odejava but there is another project with that name already.

Any other ideas?

Quote

As for project leader, yes I would be prepared to take that role if everyone is ok with that. I shall list a few things that I think make me suitable for the role for anyone who needs convincing.I have played around with the code of ODE.I have made a pretty comprehensive robot simulator based around javaode, I was thinking of open sourcing that but I would rather get the underlying technology more stable (which is what this should achieve).My math is fairly strong. (Java like most people here is 2nd nature and not really worth mentioning)I have been a designer for two fairly substantial (albeit J2EE) commercial software projects.c and c++ is good, though not up to my Java

My drawbacks are:I have just started a MSc in Neuroscience after completing an MEng in Software Engineering. As all you techies will realise its pretty difficult learning lots of biology from nothing. The overall plan is to do a PhD in neuroinformatics after that. Anyway the workload is pretty punishing, so although most weeks I would like to put in more than 5 hours, some weeks I will have to be strict about how many hours I do. I imagine I will do most work on this project on Sundays.

I have never been a team leader before.

I think with your ODE and C/C++ knowledge you are very suitable. Thank you

I suggested Generics because I see that the structure of the objects indicates things like arrays of Joints and such. If they are to use the resizeable ArrayList class then I think the benefits of the added type safety would be significant.. I.e. for much of the same reasons that "dReal *" sucks in C/C++, ArrayList<Object> is undesireable in Java. It's just an idea. It's up to you guys to decide.

I also would vote to drop the "dx" prefix on the class names when porting to Java. It just isn't the Java way to have such a prefix. I'm not sure if writing a new Matrix clas and delegating to Matrix3f/4f is the way to go, or if Matrix3f/4f should be used directly along side a helper class with static methods much like Math. Or maybe Matrix3f/3d would be the base class of an ODE Matrix class? Without the operator overloading the code referencing such classes will look significantly different from the C++ code anyway.

That brings another question: Would you use Matrix3f or Matrix3d, ODE appears to have a compile-time switch to choose single or double precision. How much will this matter? Will using doubles make it any more stable? Will it affect the speed significantly?

Regarding floats vs doubles, I'd suggest floats for now since it is faster (and that's what Odejava used). There's nothing to stop us in the future overloading the methods with support for doubles though (in much the same way as Java3D did it).

A spectator's small comment:JDE sounds too similar to JRE, JDK, IDE, and so on.JODE I'd like best. Will says it's already in use.JODEL is too close to JODE I guess (but sounds funny in case you know what Jodeln ist)JOODE to emphasize the OO aspect? Again to close to JODE I guess.JODOE (short for John Doe? :-)<no further ideas>

I personally thought that we should keep the Java class names exactly the same as the ODE ones. I know thats gonna totally break with java convention but I think it has several advantegous:ODE documentation will be more relavantPorting code by copy and paste will be easier as class names will not have to be adjusted.

Another thing that is against Java convention that I think would be a good idea is to port structs as classes with lots of public attributes. That will mean java code will be able to access data just like it does in the C++ code.

Both these things will make is much easier to compare the C++ code and Java code for initial coding and maintanence. I think it will have productivity benifits.

PPU discussions are important as a 'political' context to this project but I do not think that the technology should really intefere with our decision making process. There are far too many unknowns with the technology. Untill there are 3 different manufacturers and 50% of games PCs contain one and all the best games all use them I don't think we java people should be pining after the technology.

Quote

Matrix3f/4f should be used directly along side a helper class with static methods much like Math

Yeah I think your right actually. I ahve been thinking about this. My initial view was that a custom wrapper would allow us to put in all the extra multiplication functions used to optimize ODE. However there is nothing more annoying than using a API that does not use standard classes, especially as our project will probably have a dependancy on the standard library anyway. I thought that the vecmath API made lots of classes final but it doesn't so subclassing is an option, however I do not like that idea becuase developers will still need a translation step somewhere to get their own constructed matricies into the system (unless we code a mechanism for them, which is more work for us ).So yeah, static helper methods I think is the way to go using the standard vecmath classes.

As for generics. Although I really really like java 1.5, the features should only be used if the existing ODE design which we are copying uses them. There exists two places where tempaltes are used. The first is the dArray class, the 2nd is an obscure part of the trimesh code. If the dArray use of generics was wide spread then I would maybe say that we need to use them, but the dArray class is actually used very little:-

The QuadTree space and the trimesh stuff are both areas I did not want to port. The only real place is the LCP solver, and there is is used to store a list of integers ... big deal. (Damn! we *need* autoboxing )

So yeah. I think generics are not needed. Thus we might as well stick to 1.4.

Some of you might be wondering how ODE does store lists of things. Bodies and things are joined up in a link list fasion. Its a bit urgh for us Java people seeing the body code containing the implementation used to store it as a list, but I believe we should still replicate this.

Quote

I don't really mind, but when I hear JDE I think "Java Development Environment" i.e. a variation of IDE. Google seems to agree

JODE was my first choice as a name for Odejava but there is another project with that name already.

Bah!

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

I think we should use javax.vecmath, becuase then we're reducing the amount of errors - we would probably get errors even by simply porting the ode math stuff. We'll probably also work with vecmath on the outside (because OdeJava does), so it would only increase the overhead if we add another layer.

Well some of the matrix functions need to be ported. There are lots of optimizations like: if you know the 3rd column and 4th row are all zero ....Its all very specialized in the LCP. But yeah. We can add peripheral methods to a static class and just use the standard matrix classes as they are.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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