JOODE tests conversion to current Xith3D

[Marvin Fröhlich]

hi

I wanted to start converting the JOODE test cases to the current Xith3D. But there's a problem. You know, we're using an alternative (GC-cheap) vecmath implemention. And it provides a few additional functionalities, that we make use of in Xith3D. Our vecmath implementation (which is now part of the openmali) and sun's one cannot not exist in the classpath at the same time.

So it would be really cool, if we could remove sun's vecmath from the JOODE project and use openmali instead.

Marvin

[Amos Wenger]

(Note : I need JOODE to be to the latest Xith3D so that I can implement and improve the XPAL (Xith3D Physics Abstraction Layer) to work tightly with JOODE).

[t_larkworthy]

Yeah I don't see any problam with that.
Biggeruniverse .. your messing around with vecmath, do you think you can swap the main trunk with openmali's implementation?

Tom

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

May I take this as granted, now?

Marvin

[biggeruniverse]

Sure, but there are some MathUtils methods giving me trouble, plus I still don't see the point of the RealPointer class. Those are the only reason the vecmath patch is not complete.

After that, I assume it's easy to switch to openmali.

[Marvin Fröhlich]

Sure, but there are some MathUtils methods giving me trouble, plus I still don't see the point of the RealPointer class. Those are the only reason the vecmath patch is not complete.

After that, I assume it's easy to switch to openmali.

Cool. Please let me know, when you're ready for openmali.

Marvin

[t_larkworthy]

Can I confirm that using open mail does not mean we have to change any import statements or anything. It is just a matter of swapping the vecmath.jar yeah? Would everything need to be recompiled against the openmali jar? I would require the user could choose which to use. I really don't want to be committed to Xith3D as the renderer. Also I would much rather be able to distribute the binaries as dependant on the vecmath jar as they are easy to get hold of.

I still don't see the point of the RealPointer class.

Ah yes, the sacred RealPointer class. That is simply supposed to be an object orientated version of how a pointer acts like in C source code. It was used to help porting. You could literally replace all C code like Real * a = {1,2,3}; a++. It's half between a reference and an array. In the ODE source its used as both sometimes so it was a real headache porting some of the code until the RealPointer class. There is actually no point in having it in JOODE now, it was just to help porting. In the c code Vector3 and Matrix4 etc. were all in a sense subclasses of Real pointers (becuase they were all just arrays of floats) .
Everywhere where their is a JOODE RealPointer should eventually at least get replaced by a Vector3 or another subclass of it. The only part I would be worried about is the LCP implementations, as they used array indexing to jump about Vectors. In ODE it was possible to create a massive array and move the pointer address about (the index in the RealPouinter class), which meant the pointer looked up different Vector3 (or matrices or whatever).

Tom

[Marvin Fröhlich]

Can I confirm that using open mail does not mean we have to change any import statements or anything. It is just a matter of swapping the vecmath.jar yeah? Would everything need to be recompiled against the openmali jar? I would require the user could choose which to use. I really don't want to be committed to Xith3D as the renderer. Also I would much rather be able to distribute the binaries as dependant on the vecmath jar as they are easy to get hold of.

OpenMaLi's API is fully compatible to vecmath's one, all the same packages, all the same classes. So if you're using vecmath, you will always be able to use openmali by a simple switch of the jar in the cp (and vice versa). Nothing should be needed to be recompiled, even though I have never tested something like that. If you don't make use of openmali's extras in JOODE, nothing could keep you from switching to another rendering engine, that maybe doesn't want openmali.

Marvin

[t_larkworthy]

OK thats great. I am gonna test that.

Tom

[t_larkworthy]

Where do I actually download openMali?

Games published by our own members! Check 'em out!

[Amos Wenger]

Where do I actually download openMali?

Official website : https://openmali.dev.java.net/

We use a release in Xith3D : http://xith3d.svn.sourceforge.net/viewvc/xith3d/trunk/third-party/math/
(Seek openmali.jar)

If you have any problems, let us know (Marvin and/or me)

[Amos Wenger]

So, I can't see anything in the main branch.. what is the progress with the OpenMali switch ? As I said, I'm waiting on that to continue to work on XPAL.

[biggeruniverse]

look under branches/ , instead of trunk.

[Amos Wenger]

look under branches/ , instead of trunk.

okay, but didn't you say you were going to merge with the main branch ?

[Marvin Fröhlich]

okay, but didn't you say you were going to merge with the main branch ?

the "main branch" is the "trunk", isn't it?

Marvin

[Amos Wenger]

the "main branch" is the "trunk", isn't it?

Yeah, that's what I mean.

[Amos Wenger]

*bump*

any plans to merge the "openmali-powered" branch and the trunk ?

[t_larkworthy]

Can we not merge it yet. I want to see what Art says.

Would a switch mean that JOODE cannot be used with Java3D?

[Marvin Fröhlich]

Can we not merge it yet. I want to see what Art says.

Would a switch mean that JOODE cannot be used with Java3D?

No. As long as you don't use openmali's extras, the API is fully compatible in both directions. So all you need to do to ensure compatiblity to Java3D is to switch to Sun's vecmath from time to time and see, if everything compiles (and change if needed) and switch back.

Marvin

[Amos Wenger]

So, any objections that I merge the two branches ?

[t_larkworthy]

no I think its ok.

[Amos Wenger]

no I think its ok.

ok