Just I thought I would give an update to my convex collision code. I have now finished writing code, but I have a massive backlog of debugging to do. The code does not work as yet, but its promising. At the moment my test convex cubes accelerate away from each other, as they are under the influence of a bogus constant collision. I am hoping it won’t take too much longer to get it working. Unfortunatly uni is sucking my time again, so it may tkae longer than it should do.
t_larkworthy i would not like to interupt your job with joode but i have some short questions, please answer them if you can:
-
When will some oficial joode release be available (in 2,3, 6 months time) ?
-
Will joode be made in one self package/jar, becouse in sourceforge cvs section there are many other libs that you are using probably for testing like vecmath and other, so i am asking will joode require external jars etc… or will be made in one jar?
-
What wiil be final size of joode implementation in jar that we will add to our apps (what final size could be in your opinion) ?
again than you t_larkworthy, arne and all other who makes grate job with that project
Quickly inexact answer :
It’ll be released when it’s ready ! As far as I know, there’s no release plan.
Dependances are : Vecmath, probably JAMA (=Matrix Math), maybe JUnit, but we could move test classes to other packages…
I have no idea… but it should be pretty small (compared to AGEIA, that is 175Mb big ! (with demos))
t_larkworthy : I want to participate more to JOODE, but I don’t really know which part is TODO actually… you seems to carry on well with your collision detection code…
Note : I have made a Java port of Chris Hecker 3D physic demo (http://www.d6.com/users/checker/dynamics.htm#samples) but I still have a big debug session to do. It needs Xith3D to work. If someone is interested, I’ll release it. (Maybe on Chris’s website)
For JOODE, I think we should separate the Collision Detection stuff from the CollisionResponse / Integration stuff. It makes more sense to me. We could just define two standards (using java interfaces) and provide a base implementation. If someone makes a better one, then users can flawlessly switch. Seems more modular.
[quote]1) When will some oficial joode release be available (in 2,3, 6 months time) ?
[/quote]
I am hoping within a month. That version will have unpowered, unlimited joints. And a convex polygon collision system.
[quote]2) Will joode be made in one self package/jar, becouse in sourceforge cvs section there are many other libs that you are using probably for testing like vecmath and other, so i am asking will joode require external jars etc… or will be made in one jar?
[/quote]
At the moment the only real dependancy that is used is the Vecmath package, and for testing the Xith package. I would like to clean the system so that the Xith bindings are seperatly packaged. There is a dependancy for JAMA matrix library, but that is only used when the sys is configured a certain way. You could easily not use the JAMA package without breaking the system. So the code we have written will be in one package and you will have to include external libs such as Vecmath to get it working. Hopefully the bindings will be in seperate packages so you will be able to only include what you need.
[quote]3) What wiil be final size of joode implementation in jar that we will add to our apps (what final size could be in your opinion) ?
[/quote]
At the moment the jar is 250kb, and I don’t expect it to grow much. If we did a bit of tidying it will probably get smaller.
[quote]For JOODE, I think we should separate the Collision Detection stuff from the CollisionResponse / Integration stuff. It makes more sense to me. We could just define two standards (using java interfaces) and provide a base implementation. If someone makes a better one, then users can flawlessly switch. Seems more modular.
[/quote]
Yeah in essence it is allready done like that. The collision system needs to be explicitly setup and connected the the rigid body system for collisions to work. So it is a fairly easy operation to create your own collision system and plug it in. I actually didn’t like the fact that users had to do this, so I have written a class called SimpleWorld that connects the collision system up for the user.
[quote]t_larkworthy : I want to participate more to JOODE, but I don’t really know which part is TODO actually… you seems to carry on well with your collision detection code…
Note : I have made a Java port of Chris Hecker 3D physic demo (http://www.d6.com/users/checker/dynamics.htm#samples) but I still have a big debug session to do. It needs Xith3D to work. If someone is interested, I’ll release it. (Maybe on Chris’s website)
[/quote]
Porting the different spaces is still open (HashSpace, QuadSpace). I think arne is trying to create his own OctTree implementation rather than port the existing codebase so there should be no overlap of effort.
Testing! Haha, boring but I have never tested whether a body can be removed from simulation, that will need to be tested before version 1, there is probably about a 50% chance it won’t work :-.
There will be a mass of refactoring work to be done, just renaming all the method names and suchlike becuase alot of them are ODE names (like dJointAttach). I think that should be the last thing to be done though before release.
Also kitfox wrote a great bit of code for reading a properties file for setting up the simulation environment, but that has not been leveraged yet. I would liike the properties file to be consulted (only once) for determining the options such as what physics intergration stratergy to be used (i.e. step_world_x1 or x2, Cholesky decomposition or LCP or JAMA etc.). Again I don’t think this should be worried about until last though.
So if you want a job I suggest porting HashSpace, then QuadSpace.
Maybe I should say about the long term l plan as I see it at the moment as well.
The next focus after release one will be
getting joints powered and limited.
Getting spaces other than SimpleSpace implemented (if they are not done in this release).
but the main focus will be architecture!
This will invlove:-
An interceptor pattern for basically everything. Similar to:- http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
So I would like to have a pre and post step world interceptor stack. An pre and post interceptor stack for body step events. Another set for body creation and deletion ( for global creation and deletion as well as stacks per individual body). I have decided the interceptor pattern acheives basically the same thing as an event model, only without the ambiguities of the delivery ordering (i.e. you explicity know what order everything happens).
This archetecture will be really cool for bolting in functionality to the system. If you want graphical bindings then implement them as a pair of interceptors that listen to bodies being created and destroyed. When a body is created the binding will get to look at it and create a graphical version, and when the body is detroyed the graphical version can be removed.
The collision system should also be abstracted out as an interceptor.
It will also be ideal for adding custom behaviours to subsets of bodies becuase the behaviours can be notified of the body being removed. Any kind of dependancies between objects will be able to be enforced with the pattern (just think of it as an event model).
I want a really good implementation of the interceptor pattern model. I am thinking that maybe we could use annotations to mark which methods will have interceptor stacks asociated.
Once that system is in place we can start doing the really cool stuff. like adding scripting language support.
Errr, no where near that big, infact, NxFoundation (math libs) is 72Kb, and the actua PhyXCore.dll is 1.23Mb. You have the multiplatform SDK and multiplatform demos there, and the models/textures probably take up alot…
As for Quadspace, i dont think thats a good solution to such a dynamic environment. IIRC, you had to constrain the boundries of the quadspace, so for pure dynamic environments, it isn’t a nice solution.
During my “metaball” phase of my programming life (yes! I go through phases ::)), i found this article that produces a dynamic tree of boxes that expand and relax according to where the metaballs are (meta balls are pure 3d volumetric rendering), it was pretty quick too, so that might be a good solution to the problem.
DP
[quote]As for Quadspace, i dont think thats a good solution to such a dynamic environment.
[/quote]
Its not my favourite either, which is why it should be the last of the spaces to be ported, but it does not take long to port code, and it has its uses (like real time stratergy maps). HashSpace is better. But even so the quad space is a tree space I think. It then shares similarities to OctTrees and they was good enough for unreal.
Anyway its all very well coming up with better ways of doing things, like the argument we had whether to port ODE or start from scratch, but if there is useful stuff you can port its way quicker and actually delivers results.
thomas, can I refactor all ODE methods ? Say, change dJointAttach to jointAttach, and so on. Or do it another way ?
Okay, refactoring done. Thanks Eclipse 
ARGH!!! These matrix mathmatics are driving me insane. I have the collision code working for the case when they are not rotated. But as soon as you rotate the things it all goes crazy. I have checked, double checked, trial and errored, triple checked and it all comes down to being impossible to visualise the calculations as they go along. I think I may need to develop a graphical debugging suite so I can draw the plane-vertex checks as they are performed and also visualise the gauss representations as they are checked. Its a massive pain though becuase the graphics engine is decoupled from the bit of code I am working on. I am running out of free time this week I can do it as well 
Grrrrrrrr. Its so close to working its infuriating…
Do you have these matrices orthonormalized? No gimbal locks? No round off errors?
Nah that shouldn’t be the problem. I dunno what is. Its just a stupid bug somewhere. I have put the wrong matrix in or something. Anyway I have added some graphic support for collision detections now, so you can see the normals as they appear. Hopefully I will be able to trace what is going on through them. Its a bit of a set back though. I really thought I was gonna get it all working soon. I am off for the weekend …
Hmm, AFAIK you guys doing a 1:1 port.
Maybe the easiest way to find the bug is to build the same test case with the original ODE C/C++ code. And then step with debugger thru the Java test case and at the same time thru the C/C++ test case (both line by line). So you see when the values in the java test case different from the orginal ODE.
But i’m not familier with your work (i’m just waiting till it’s done ;-)) - so maybe my suggested way is impossible.
Tropper
nah - it’s the convex-hull collision code, and ODE doesn’t have s.th. like that.
A 1:1 port would have been a bad idea, because ODE is written in C, thus not OO, but
JOODE = Java Object Oriented Dynamics Engine, so we really want to have it OO 
It’s nice that there are so many people interested in our work 
Arne
Bah humbug. Gimmie more time… There are flaws with the DEEP algorithm, but I am fixing them…
Quote from “Mickey’s Christmas Carol”, words of Uncle Scrooge.
You have as much time as you want. Well the DEEP algorithm hasn’t been tested ?
I’m waiting for this work to end, too, but I don’t want to put pressure, cause till it work I focus myself on improving Xith.
OctTreeSpace is implemented now.
I also fixed some bugs in SphereCollisionTest, it didn’t work anymore, because key gloabal variables were redefined and it used those instead of the ones defined in the super-classes.
I copied most of this test case and made a new one for testing the OctTreeSpace. (OctTreeSpaceTest).
I’ve also made a new package for it, so all Space-Testcases can go there. (net.java.dev.joode.test.space)
what next? - mmh maybe I’ll do some dokumenting on this stuff.
ohh and s.th. else: It printed loads of “null” messages to stderr. Both using SimpleSpace and my OctTreeSpace. Is this correct?
ok - that null thingi resolved (those were some old debug-statements of mine) It’ll not be there anymore, when I’m finished documenting and have commited the commented code.
Good job !
Have you made a bench ? Does it makes really a big performance optimization ?
nope haven’t made a benchmark yet, but it’s javadoc-ed now.
I also found two bugs when removing Geoms, the more serious one I was able to fix quickly, but I don’t know how to tackle the other one.
I’ll describe the problem:
I find the Geoms in my OctTree by their bounds. So, if I change the bounds, I won’t be able to find my Geom anymore. Luckily the bounds only get recomputed shortly before I test for collisions, so after removing the Geom. But if the bounds also get updated somewhere else, this bug would mean a memory leak (I would deposit references in my tree, without ever finding them to delete again)
Arne