Yeah. When we get java.net we should use those forums. The sourceforge pages are slow to load so it would annoy me using those forums.
OK. I have added the required libraries into the project, and the ode source we are working off, and a license (which is currently just a direct copy of ODE’s).
I spose it be nice to have a good ant script to run the thing…
Nice 
the test case also worked at my comp 
- the structure looks good, but could you post an uml diagram of what is already imlpemented? (I don’t have a good uml creater, that creates from java-files, there’s one in eclipse, but it made crap when I tried it and I don’t want it to delete all my code [that nearly happend, when I used it last time] )
About the forums: good, then we keep posting here for now.
Ok I’ve worked a bit on the code and added Boxes. It also works with one Box
Sphere-Box collisions are now possible.
Box-Box have still to be done. (So Only one Box allowed 
)
New functionalities for Vector3, Real and Matrix.
Matrix3 and Matrix4 extend now Matrix, that extends Real.
I’ve fleshed out the Mass class, so all of the ODE mass functions are now available. I even included two extras that aren’t part of the original spec.
I’ve also fleshed out Vector4 and Matrix3 a bit. Mostly convenience functions to make it easier to get and set them.
great stuff guys. I am having a look at OBBs at the moment. I dunno if I will be able to implement them. There are lots of bits missing that we need for to joode to work like determining the surface normal and depth etc. I might be able to work it out.
Hello guys. Can people stick to 1.4 syntax please, unless people want the debate opened again. In Box.java there was a strange @overide annotation which is 1.5 syntax, and in Mass there is an enum.
sorry for the @override eclipse does that automatically - I forgot to change the Compiler level to 1.4 - that’s now done.
Looks like the jar files currently in the repository are uploaded incorrectly. Tom, could you please replace the current jars in the repository with versions that aren’t uploaded as text files?
Here’s a link to a bug report regarding the bad jar downloads:
will the one, who has created that enum in net.java.dev.joode.body.Mass please change it back to 1.4 syntax, please? I haven’t used enums, so I don’t know what “special effects” you wanted to have with it. If it is only a way for error-messages, I’d suggest to throw an Exception - or if the error isn’t that serious to simply print to System.err
Yes. Jars should be binary. sorry, I was being sloppy when I first put everything in the repository. It should be ok now.
Regarding the error handling in Mass:
The way the original code is designed, it needs to check a post condition to ensure that the computed matrix is valid. Because this is a post condition rather than a more typical error, it makes sense to check it using an assert statement rather than throw an exception.
Enums are very similar to classes. When you write
enum MyEnum { FIRST, SECOND, THIRD}
You’re pretty much creating three classes called FIRST, SECOND and THIRD. You can then compare these against each other using the == and != operators, or even as arguments to a switch() statement. They’re actually pretty simple. You can read more about enums here:
http://java.sun.com/developer/technicalArticles/releases/j2se15langfeat/index.html
I was chatting with t_larkworthy over email last night, and I think both of us would really rather program in Java 5. Java 5 has lots of nice features (like generics and foreach loops) that make it easier and much more clear to code. The new additions to 1.5 aren’t that difficult to learn. If you read thorugh the page that I posted, that will give you a pretty good introduction to all the new features.
Also, does it makes sense to develop for 1.4? In a year’s time, Java 6 will be released, and 1.4 will be ancient history. I think it makes more sense to program to the current standard.
ok 1.5 then
OK if we are going 1.5 then a refactor is needed on the pointer types. I will do this at a later stage.
I am investigating arbitary trimesh collisions but it is not that simple. OBB papers I have read are fairly straight forward to implement but do not provide a measure of penitration or surface normal required for the collision system to work. Reading up on working that out is pretty heavy. Guass maps etc. all-in-all fairly horrific.
I am wondering if we can cheat and use the change in relative positions of the two colliding obects. That could then be used for an estimate for penetration depth and surface normal. The contact point also needs to be estimated … hmmmm. I cannot think of how to do that. Maybe I am too tired (1a.m.), I will go home and rest…
Isn’t it a simple matter of calculating the distance from the penetrated point to the point of colliision on the surface? I remeber implementing an engine a while ago, and solved it by doing something like this.
Also, how easy is it to simply copy the existing ODE code? Or is this something better rewritten?
The OBB tree calculations as they stand don’t tell you the penetration point. The existing ODE code doesn’t work (for arbitary trimeshes). I have realised this morning that last nights guestimate won’t work if more than one body is in contact at the same time (as is in the case when things are stacked on top of each other and under the force of gravity, a very common situation).
So an OBB tree will tell you very fast when there is a collision but does not tell you much about the nature of the collision. Minkowski sums can tell you the penetration depth and other info bu take something like O(n^6) to calculate (with a good implementation). For convex hullks you can calculate the minkowski sums in O(n^2) using clever guass map manipulations which are hard to understand. You can get better than that but with even more cryptic sums.
Couldn’t you keep 1.4 compatibility ?
At least on Mac OS, most users are still using this JRE, and as a pure java physics lib would be a great gift for applet development, tt’s too sad (and alienating) to force users into 1.5.
My 2c (If you go this way, I’ll try to backport it to 1.4).
Lilian
so what now? 1.5 or 1.4 ? I’ll start a poll and then we’ll see ( I hope you haven’t changed major parts to 1.5 yet)
About the trimesh business: we sure need TreeMeshes, but I think trimeshes can also very good be replaced by other things: e.g. Terrain, ConvexHulls or simply a triHull, where you specify where the inside and where the outside is. These will maybe also be very hard to implement, but they could run with faster speed. Normal trimeshes would then only have to be used in cases, where there is no replacement, making the problem not that urgent.
I would go with 1.5. You have to think about the target market for the API. I don’t think applets make a significant part of that market, and that is really only place where you would probably want to remain backward compatible.
Mac OS X has had Java 5 for download for some time now, and according to Apple engineers on their forums, Java 5 will become an automatic OS upgrade as part of the standard “Software Update” feature of the OS reasonably soon.
I suppose you could also have a build target in your ant script that uses retroweaver to make a 1.4 compatible version too.
Good God!!! That (http://retroweaver.sourceforge.net/) seems to be the perfect solution, not only for this project Thanks swpalmer! I didn’t know…