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 
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.
[/quote]
I completally agree.
Will.
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.
Cheers,
Will.
I think it’s the simplest to request a new project at java.net and then we’ll all simply have to give our +1. I believe we’re enough for that, so it should go fast.
pureode, … bluesky had also the idea to call it JDE for JavaDynamicsEngine.
I actually like very much JDE, because it’s so close to ODE. From that name typos, we could also call it JODE (Java Open Dynamics Engine), like jogl.
Arne
I got my webspace allocated at last. Here is what BOUML draws when it reverse engineers the ODE source:-
I have to say my favourite name so far is JDE.
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.
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.
Just a thought, worth exactly $0.02 
like I said…wait 3 - 4 months.
DP
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.
Arne
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!!
here here.
Will.
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?
I think with your ODE and C/C++ knowledge you are very suitable. Thank you
Will.
As for other name ideas: ODE4J ?
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 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?
ODE4J doesn’t give me the impression of a pure ODE impl, more I get the impression it is a binding like Ogre4j.
Is 1.5 even standard on the Mac yet? http://192.18.37.44/forums/index.php?topic=10648.15;topicseen
I believe there was some codeweaver tool that could transform Generics into 1.4 bytecode, so this could be an option I guess.
I agree there’s no need for prefixes on the class names in java.
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).
Will.
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?
Yeah, I think we should keep to floats.
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 relavant
Porting 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
[/quote]
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:-
collision_quadtreespace.cpp:324: dArray<dxGeom*> DirtyList;
collision_trimesh.cpp:308: /* dxTriMesh::ClearTCCache uses dArray's setSize(0) to clear the caches -
collision_trimesh_internal.h:94: dArray<SphereTC> SphereTCCache;
collision_trimesh_internal.h:100: dArray<BoxTC> BoxTCCache;
collision_trimesh_internal.h:106: dArray<CCylinderTC> CCylinderTCCache;
lcp.cpp:381: dArray<int> C,N; // index sets
testing.h:37: dArray<dMatInfo*> mat;
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.
[/quote]
Bah!
[quote]JOODE
[/quote]
I like that one. Perhaps pronounced judy? Java Object Orientated Dynamics Engine
+1 for JOODE
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.
If generics is really so rarely used, we really could stick to 1.4.
Arne
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.
OK great! Yeah I will submit a project form now.