OpenMali initiative - Trying a bit of tidying about maths libs

[eMKa]

“Hey the unification guy still isn’t bored to post rubbish useless threads :o :o”

OK just kidding ;D

This is not a project proposal as my project has been approved, here it is : OpenMali (https://openmali.dev.java.net)

There is really little content in the CVS.

The thing that pushed me to create this project is the following facts :

• Not everyone is a Math guru. And finding Math libraries that does “just the job you want” is sometimes useful
• Sometimes you find code that do “nearly what you want”, in which case you can just copy/paste and modify it to fit your need. Anyway, you’re glad you didn’t have to do the initial implementation
• Even if you have interest for Maths, some algorithms/technics/formulaes are just HARD to find. Spending 3 hours on Google may be a pleasure for some guys but not for me. If it’s clearly documented in my favorite lib, then it’s just easier
• Even if you find a paper on the algorithm you want, that does not mean you’re able to implement it… and yet you may be a fine AI/gfx programmer, but you just need some physics/to know how to detect objects in a cone/anything else

This is the FIRST GOAL of this library : Provide a set of reliable, clear, and documented open-source algorithms. The license should be compatible with commercial projects, and should permit modification of the code, too. (LGPL or BSD may be fine, or maybe both).

Now for the second goal here’s :

• The widespread vecmath.jar from sun has been reported to create much, much garbage and to slow down things that could be implemented in a better performance-wise way.
• Dave Lloyd once reported on his blog (talking about Fuze3D progress) that there was a bug in Quaternions that prevented his Cal3D port to work. He just did a workaround but if vecmath.jar was maintained that would have many headaches avoided for others programmers
• JOODE had problems and a discussion about how to support both jME and Xith3D cause they use different vector math library… And interfaces or factory solutions just can’t fit the job : too slow
• theKman and me have the same problem with Cal3Dj : he does jME support and I ported the whole to Xith3D and most of the work was renaming com.jme packages to javax.vecmath ones… And if he updates his code I’ll be obliged to work from diffs… not cool

So the SECOND GOAL would be, IF AND ONLY IF there is interest for that in the jME, JOODE and Xith3D communities, to “provide an open vector/matrix math library which is fast, generates as little garbage as possible, and which contains enough functionalities for the three libs I talked about”.

[eMKa]

So for the first goal I expect much people to request Developer access in order to upload their algorithms then clean&javadoc them, so we have a pretty good basis.

In the CVS there is a few examples of classes, like the Distance class or the Angle class.

For the second goal, if developers of the three proposed project would post here that’d be ideal, if not I’ll contact them by mail.

I think starting on something like that would be good : http://www.objectclub.jp/download/vecmath_e

[sunsett]

Does
https://vecmath.dev.java.net/
have any explicit dependencies to Java3D?

[eMKa]

@sunsett

Does
https://vecmath.dev.java.net/
have any explicit dependencies to Java3D?

No

[sunsett]

Then why not contribute to that instead of creating yet another math library? I thought the issue was less that everyone was that there isn’t an abstract math library, rather the opposite, that there are too many? How is this not just adding yet one more to the problem?

-Matt Hicks

[eMKa]

@sunsett

Then why not contribute to that instead of creating yet another math library? I thought the issue was less that everyone was that there isn’t an abstract math library, rather the opposite, that there are too many? How is this not just adding yet one more to the problem?

-Matt Hicks

That’s a good point and I thought about it. So the SECOND goal of OpenMali would be handled by a resurrected javax.vecmath ? Cause actually if not everyone use it it’s maybe it’s not fast enough or lack some functionalities.

How hard would it be to port jME to javax.vecmath ?

Anyway, the FIRST goal remain.

[sunsett]

why don’t you just abstract out the vecmath features from jME and THEN you’d have something we can all get behind.

If I recall there were some specific reasons jME decided to not go with the vecmath features there, but I don’t recall exactly what they were, I agreed at the time though so I’m sure they were good.

-Matt Hicks

[eMKa]

@sunsett

why don’t you just abstract out the vecmath features from jME and THEN you’d have something we can all get behind.

explain further… do you mean I should contribute to vecmath the missing features that are in jME ?

@sunsett

If I recall there were some specific reasons jME decided to not go with the vecmath features there, but I don’t recall exactly what they were, I agreed at the time though so I’m sure they were good.

I’d be pleased to know which were these… apart from an unexplainable desire to rewrite the whole world, as it seems to me jME always did.

Note to prevent flames : I didn’t wanted to re-implement anything from scratch for the SECOND goal of OpenMali, just to fork to have a true open-source project.

[irrisor]

I think javax.vecmath was not used because

1. of it’s license
2. the tedious process to contribute
3. it was lacking some garbage-less functions (would have to inverstigate which these are)

Regarding porting from/to vecmath to/from jME: it’s quite laborious as the methods have different signatures and sometimes even require flipping parameter and called object. (e.g. it’s not possible to do a simple regexp replace).

And with adding another math package I have the same concerns like sunsett. I think it would be better to work on unifying several projects under a common existing math package that could be improved… creating a de-facto-standard is the only thing that could work…

[eMKa]

@irrisor

I think javax.vecmath was not used because

1. of it’s license
2. the tedious process to contribute
3. it was lacking some garbage-less functions (would have to inverstigate which these are)

Regarding porting from/to vecmath to/from jME: it’s quite laborious as the methods have different signatures and sometimes even require flipping parameter and called object. (e.g. it’s not possible to do a simple regexp replace).

And with adding another math package I have the same concerns like sunsett. I think it would be better to work on unifying several projects under a common existing math package that could be improved… creating a de-facto-standard is the only thing that could work…

OK you’re right.
Now for issue #1 : there’s an open source implementation of the javax.vecmath API
Issue #2 : indeed because it’s part of the JCP process… but if we add sources from the open vecmath implementation into openmali it would be really easy to me to grant sufficient permissions for everyone serious that want to use&contribute to it. I don’t really want to create another vecmath library, just make the open version contributable (maybe I have to ask permission or opinion to the author).
Issue #3 : if the open implementation is contributable as a java.net-project then they could be added (code borrowed from jME math library).

So ?

I’d be happy to contribute porting jME to vecmath if it’s approved.

[zero]

I have a self-developed math library, which I plan to open source (see here). I don’t know if it meets your requirements, but please tell me if you are interessted in joining forces. I could create a svn account, if you like…

[irrisor]

[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:27575"]
I’d be happy to contribute porting jME to vecmath if it’s approved.
[/quote]
I think I have to lower your enthusiams a bit here :-:I don’t think that this could really happen in near future. And that’s because it would not just be porting jME itself but all applications programmed with jME! This would mean the same for other projects which makes the plan to have a unified math library a really tough undertaking…

Probably it is possible to have library that allows adopting the library interface instead of porting to it . . . but that’s only a very vague idea . . .

[eMKa]

@irrisor

[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:27575"]
I’d be happy to contribute porting jME to vecmath if it’s approved.

I think I have to lower your enthusiams a bit here :-:I don’t think that this could really happen in near future. And that’s because it would not just be porting jME itself but all applications programmed with jME! This would mean the same for other projects which makes the plan to have a unified math library a really tough undertaking…

Probably it is possible to have library that allows adopting the library interface instead of porting to it . . . but that’s only a very vague idea . . .
[/quote]
So what ? I just begin to come a bit angry about that >:( >:( People just feel comfortable with their messy stuff and don’t want to spend 1 week to refactor their code with a new math lib so they save months of pain for people trying to make their library Xith & jME-compatible… Grr so what will we just have separate versions of everything ? Will cal3dj be forked and have separate progress for Xith and jME ? And twice as many bugs as if there was a single version… Just can’t believe it’s gonna happening. So when a Gamasutra writer said games were developed really really bad with ugly ugly code and no re-use at all how right was he.
As I said I’m ready to dedicate time to do a port of jME to vecmath BUT if all the guys who use it aren’t willing to take this effort then right just fine.

@zero

I have a self-developed math library, which I plan to open source (see here). I don’t know if it meets your requirements, but please tell me if you are interessted in joining forces. I could create a svn account, if you like…

Please give me the URL of the existing website/SVN repo. I’m willing to take a look at it. I’ve always been for joining forces, whatever people said.

[sunsett]

You see, the reason you get angry is because you see this as “messy code” and “lacking features”, but from where we stand we’ve got all the features already. You are making the presupposition that multiple projects makes sense. In the jME world we don’t need Xith, we don’t need Java3D, and we don’t need an open-source math library. You see an advantage to joining forces (and rightly so), but from our perspective we gain nothing except for headache in the conversion.

Further, you say “spend 1 week refactor their code”. That’s all well and good in premise, but in reality jME actually has commercial game development companies using it and that has to be taken into consideration. We have more than just the small side-project games being developed with jME and it’s a LOT more than a 1 week project to refactor the math library.

The more I think about the idea of collaboration the more I understand why jME isn’t collaborating with the community now, it just doesn’t make sense. Sure there is a lot of duplicated functionality, but at the same time there are benefits to seeing multiple perspectives on accomplishing tasks and being able to learn from each other. If we collaborate on everything that is often lost.

I’m not trying to beat you down here, but what Irrisor said is very accurate. If you really want good support, come to jME…we’ve got great collaboration inside our own community, but unfortunately it’s not really likely to occur with all the other projects.

-Matt Hicks

[eMKa]

@sunsett

You see, the reason you get angry is because you see this as “messy code” and “lacking features”, but from where we stand we’ve got all the features already. You are making the presupposition that multiple projects makes sense. In the jME world we don’t need Xith, we don’t need Java3D, and we don’t need an open-source math library. You see an advantage to joining forces (and rightly so), but from our perspective we gain nothing except for headache in the conversion.

Further, you say “spend 1 week refactor their code”. That’s all well and good in premise, but in reality jME actually has commercial game development companies using it and that has to be taken into consideration. We have more than just the small side-project games being developed with jME and it’s a LOT more than a 1 week project to refactor the math library.

The more I think about the idea of collaboration the more I understand why jME isn’t collaborating with the community now, it just doesn’t make sense. Sure there is a lot of duplicated functionality, but at the same time there are benefits to seeing multiple perspectives on accomplishing tasks and being able to learn from each other. If we collaborate on everything that is often lost.

I’m not trying to beat you down here, but what Irrisor said is very accurate. If you really want good support, come to jME…we’ve got great collaboration inside our own community, but unfortunately it’s not really likely to occur with all the other projects.

-Matt Hicks

Hehe. Individualist one. “Oh as long as my thing is working then let’s not mind about the other ones…”… And I’m just amazed at how do you explain collaboration is just useless.
And that :

If you really want good support, come to jME…we’ve got great collaboration inside our own community, but unfortunately it’s not really likely to occur with all the other projects.

Is just pure advertising. What do you think we do in the Xith3D team ? D’you think everyone works in its own little place ?

[eMKa]

So there’s really no way I should worry about jME compatibility when doing anything… Because you have already everything then probably you don’t need any of what I do or others (e.g. Xith folks) do.

[sunsett]

Individualism would be me writing my own engine. I’m happy with the engine I use and try my best to contribute to it. Collaboration is great in the jME community. All I’m saying is that it isn’t really feasable to expect collaboration between the different engines as they are very different and as you’ve seen there are just too many issues trying to reconcile them. You accuse me of advertising, yet you and your hideously huge logos for Xith and the other thing? You also try to play the part of the “man-in-the-middle” that wants to get everyone working together, but you’re so extremely biased towards Xith you’ll never get anywhere without it.

Honestly, I don’t see the benefit of this debate, I was trying to explain to you the reasons why another math package is actually adding to the problem instead of solving one, but you seem to care less about having an open mind and more about pushing your opinion of “collaboration everything” when it doesn’t really make sense.

I’m not going to stand in the way though if you really want to add yet another math API…doesn’t hurt me any, so here my
+1

:-p

[irrisor]

just to note it again: any 3d game engine would have severe problems with replacing their math library - you can ask around on the xith forums if they would be up to switching to another math library… I think they won’t like that thought either…

I would really like to have a common math library for e.g. JOODE and jME but I simply don’t see how that could be done without using jMEs maths stuff in JOODE (as JOODE is a young project).

Until someone has a really clever idea how to do it, this discussion does not lead anywhere, I fear.

[eMKa]

@sunsett

Individualism would be me writing my own engine.

Wasn’t it what was made with jME ?

@sunsett

I’m happy with the engine I use and try my best to contribute to it. Collaboration is great in the jME community.

Great…

@sunsett

All I’m saying is that it isn’t really feasable to expect collaboration between the different engines as they are very different and as you’ve seen there are just too many issues trying to reconcile them.

I don’t understand all these people who say that Xith3D and jME are very different. Could you please explain that.

@sunsett

You accuse me of advertising, yet you and your hideously huge logos for Xith and the other thing?

You’re right… I’ll try to reduce their size.

@sunsett

You also try to play the part of the “man-in-the-middle” that wants to get everyone working together, but you’re so extremely biased towards Xith you’ll never get anywhere without it.

Please explain more. Apart from my hideously huge logos then I even did a thread on this forum to do comparison between jME and Xith3D and I finally found Xith3D more at my convenience.

@sunsett

Honestly, I don’t see the benefit of this debate, I was trying to explain to you the reasons why another math package is actually adding to the problem instead of solving one,

Indeed and you seems to still haven’t understand what I wanted to do with open vecmath for the second goal of OpenMali : I wanted to provide it a VCS repository so it can be actually used and contributed.

@sunsett

but you seem to care less about having an open mind and more about pushing your opinion of “collaboration everything” when it doesn’t really make sense.

Absolutely not for this discussion, you see I arrived to the conclusion it wasn’t worth doing anything in the sense of jME if you’re not using it (just what you said).

@sunsett

I’m not going to stand in the way though if you really want to add yet another math API…doesn’t hurt me any, so here my
+1

As I mentioned the project is already approved and our discussion has been successful cause I decided to give up the SECOND goal of OpenMali

@irrisor

just to note it again: any 3d game engine would have severe problems with replacing their math library - you can ask around on the xith forums if they would be up to switching to another math library… I think they won’t like that thought either…

Yeah sure but that’s a price to pay.

@sunsett

I would really like to have a common math library for e.g. JOODE and jME but I simply don’t see how that could be done without using jMEs maths stuff in JOODE (as JOODE is a young project).

Undoable. Maintaining two versions of a library with two different math libs is overwork…

@sunsett

Until someone has a really clever idea how to do it, this discussion does not lead anywhere, I fear.

It leads to the conclusion it’s not worth trying to have a bit of compatibility. And unless as you say a clever idea save you I don’t see how JOODE will support jME. All abstract thingies have been considered and proven to be far too slow.

[sunsett]

Okay, I’m done with this conversation apart from one response I feel it necessary to make:

[quote]Apart from my hideously huge logos then I even did a thread on this forum to do comparison between jME and Xith3D and I finally found Xith3D more at my convenience.
[/quote]
Yes, this is what I find so laughable. In spite of responses that show that jME is superior to Xith in every way you “found Xith3D more at my convenience”. Well, good luck with that. :

-Matt Hicks