Hi
I’ve added most recent Xith3D libs, migrated all test cases to the current Xith3D API and created a JOODETestLauncher to launch JOODE tests with only one starter conf.
Enjoy 
Marvin
Oh, btw. The JOODETestLauncher could display a nice logo in the south-west. So if you have a matching logo, please tell me.
Marvin
There is that armadillo in the res directory. Cheers (+qudus see my email on the dev list)
I was never successful so far when I tried to send a mail to the mailing list. So I will answer here.
As I wrote in the commit log, I added the most recent Xith3D libs. This meant to add all the platform specific natives. That’s the biggest amount of changed/added files
And I migrated all teh test cases to use the current Xith3D API and made them use the resolution (etc.) settings passed from the launcher. So I had to slighly change all the test cases. Of course the TestingWorld is changed much more.
I hope, this explains it.
Marvin
The mailing list does not work!!! Grrrrr, damn.
OK great, just it looked all funny in the diff, but I have updated to the new stuff without hitch so I am happy.
is there any reason, why there’s a vecmath branch in the joode svn, while the current joode version is still using javax.vecmath instead of org.openmali.vecmath? I believe the latest Xith3D uses openmali.
cheers
Arne
EDIT: Sorry I’ve now seen, that such a change should not be needed has read the thread, where you discussed the change - hmm - so it should be compatible as it is now - mmh - so why do I get those compiler errors saying, that Vector3f does not extend Tuple3f ???
but the vecmath package in openmali is called org.openmali.vecmath, not java.vecmath
I’m not getting something here… ???
Don’t know. I built the vecmath.jar from OpenMali source when it was javax.vecmath. However since I did that qudus and biggerworld have been upgrading the vecmath support and XithTest cases, so I am not 100% sure of the state of affairs. I beleive the vecmath.jar in the lib dir is infact a opnmali built one (but not sure).
I would not want to use open mali vecmath if it involves changing JOODE source, because then it would exclude or bloat Java3D users. JOODE code hardly uses any features of Vecmath anyways. I think the vecmath dependancy should be removed one day.
We have changed openmali to use org.openmali.vecmath package prefixes to get rid of some problems. But for projects like JOODE we still have our javax.vecmath package, which is now 100% sun-implementation-API-compatible. We have packaged it into a jar called vecmath-kh.jar. This jar should be used by JOODE. I would want to do this now, but after an SVN update JOODE is incompilable. I get the following problems:
- The Body.odeView field does not exist.
- The class net.java.dev.joode.joint.JointPenulty does not exist.
Any ideas?
Marvin
OK, I just found your note about this in the mailing list, tom. So I will wait until you fix it. Hey, a good tip: Install Linux instead of Vista ;).
Marvin
hmm Tom has fixed that problem Body.odeView and JointPenalty, but the incompatibility to the xith svn version still exists.
Actually it would have baffled me, if it would have been working then 
For example in net.java.dev.joode.test.xith.XithConverter
there are many lines saying something like
TransformGroup tc1 = new TransformGroup();
tc1.getTransform().setTranslation(new Vector3f(0, 0, -cylinder.getLength() / 2));
but net.java.dev.joode.test.xith.XithConverter is using javax.vecmath, while Xith expects org.openmali.vecmath.
I don’t understand how including/excluding jars can fix that. From my (until now) java understanding this is simply impossible…
And it isn’t, what I wanted to say. I will include the vecmath-kh.jar and the new openmali.jar AND fix the xith tests to use the correct vecmath implementation.
Marvin
ok - good I thought the world is now going totally crazy g
it actually won’t break any Java3D dependence (right Tom?) - as I can see the src dir (not the testcases and other xith-stuff) don’t seem to use any vecmath stuff at all, so it should only mean a change of the testcases and of the xith binding classes.
Ok - I think I could do the changes now, too. But I’m feeling as if I’ve caught a nasty cold, so I’ll be better off to bed now.
Arne
mmh - I’ll have to correct myself - the src/java directory uses javax.vecmath indeed (there were only no compiler errors, when trying to make it work together with the latest xith3d - that’s why for my wrong assumption).
So what now?
This incompetability is very unsatisfying 
Those incompatabilities I think are just caused by some convenience methods that allow bodies position etc. to be manipulated with vecmath storage classes. Biggeruniverse put them in, but perhaps they should go? We have our own storage classes, and if we did use an external one I am probably inclinded to go for something like MTJ (http://rs.cipr.uib.no/mtj/). ??
MTJ looks interesting - especially because it supports additional speed up with native BLAS.
I’ve looked at those Benchmarks from the MTJ guys and I don’t understand their statistic. With megaflops, they’re talking about millions of matrix-multiplication per second, right? But, why are all those algorithms so dammned slow for little testcases?
Otherwise, if they mean the number of calculations needed to perform one multiplication… - no - that won’t go - that wouldn’t fit either…
so - should I try to replace existing vecmath dependencies in src/java by the old Vector classes (Vector3) and so on?
or do we want to switch to such a matrix-package rightaway?
ok I just took the initiative and removed all javax.vecmath dependencies in the src/java folder. Ok - almost all - I didn’t know how to invert the momentOfInertia matrix withou javax.vecmath. But Mass is the only class having such a dependency.
I also changed the Xith-binding classes to fit the newest version of Xith. I haven’t updated the included builds of xith and the xith-tk yet, so there are currently new incompabilities.
I hope the newest builds of xith are already using org.openmali, so I don’t have to build the jars myself.
I’ve fixed the OpenMaLi related errors in the JOODE SVN trunk. The examples now work again.
About this matrix lib: How about GC-friendliness? Maybe this lib could fully replace the need for Sun’s crappy vecmath lib or our improved vecmath implementation and could be something the one and only math lib used by all engines… who knows. Would be nice at least.
Marvin
nice
I don’t know who useful this is, because those matrix-libs seem to be optimised for large matrices, but xith and so only need small (3x3, 4x4) matrices.
It is garbagless, but on closer inspection it is all implemented in doubles …
hmm, what a pitty! Then it is useless for us :(.
Marvin