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".

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?

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.

I think javax.vecmath was not used because1. of it's license2. the tedious process to contribute3. 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....

I think javax.vecmath was not used because1. of it's license2. the tedious process to contribute3. 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 APIIssue #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).

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..

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 . . .

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 . . .

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.

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.

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.

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 :

Quote

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 ?

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

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.

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.

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.

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....

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.

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.

I sent you a pm, please let me know when you had time to take a look at it

If you'd take a look at the current state of the community(s), regarding current code, current usage of that code, licensing, etc. if you want jME to switch to your unified math library, the only solution would be to take jME's math code and work from there. That, if you did look into all these things.. would be the only reasonble thing you can expect from us, as any reasonable person would conclude.

Maybe something like that is true for Xith too, I dunno, I'm no Xith expert.. I know enough from using it briefly there's too much I don't like about it, but -and please pay attention to this- I'm only saying this to illustrate that this absolutly does not change one damned bit, since I'm not a Xith developer or even user, and thus it's none of my buisness.

If Xith doesn't feel like switching either, for whatever reason, you have a problem. That doesn't mean you can't make your grand unified math library.. as long as you believe you have the skill, dedication and tact to make one so good we'd be stupid not to use it. You just can't reasonably expect that we believe that. Not even after Integer.MAX_VALUE forum posts on the subject. Good code however, can be very convincing..

If you'd take a look at the current state of the community(s), regarding current code, current usage of that code, licensing, etc. if you want jME to switch to your unified math library, the only solution would be to take jME's math code and work from there. That, if you did look into all these things.. would be the only reasonble thing you can expect from us, as any reasonable person would conclude.

Maybe something like that is true for Xith too, I dunno, I'm no Xith expert.. I know enough from using it briefly there's too much I don't like about it, but -and please pay attention to this- I'm only saying this to illustrate that this absolutly does not change one damned bit, since I'm not a Xith developer or even user, and thus it's none of my buisness.

If Xith doesn't feel like switching either, for whatever reason, you have a problem. That doesn't mean you can't make your grand unified math library.. as long as you believe you have the skill, dedication and tact to make one so good we'd be stupid not to use it. You just can't reasonably expect that we believe that. Not even after Integer.MAX_VALUE forum posts on the subject. Good code however, can be very convincing..

I think the last part of your post is really ironical but I don't understand what you mean by the Integer.MAX_VALUE forum posts ?? And no I don't believe that I have the skill nor tact nor knowledge to make one so good [...] if that was the case I wouldn't need java.net

I think the fact I am/was a "very biased Xith3D developer" was due to the fact I spent quite some time for Xith3D and so I feel engaged in it so I have some difficulty to accept some APIs may be better suited. But now I see clearly APIs are evoluting and sometimes die to be replaced by better alternatives.. And it's risky to bet on a single API.

Took me a while before I decided to do this post.

jME seems nice after all, and as my FPS seems pretty low in my Xith game, and Xith3D -> jME transition (+learning) seems to take not much time I decided to port my game to jME to see the difference.

However I'm willing to continue to support both libs.. Oh and BTW I changed the logos they're 40-pixels wide instead of 50 and I put one about jME so users can try by themselves (Does Java3D have a logo ? )

If Xith doesn't feel like switching either, for whatever reason, you have a problem. That doesn't mean you can't make your grand unified math library.. as long as you believe you have the skill, dedication and tact to make one so good we'd be stupid not to use it. You just can't reasonably expect that we believe that. Not even after Integer.MAX_VALUE forum posts on the subject. Good code however, can be very convincing..

I think the last part of your post is really ironical but I don't understand what you mean by the Integer.MAX_VALUE forum posts ?? And no I don't believe that I have the skill nor tact nor knowledge to make one so good [...] if that was the case I wouldn't need java.net

Quote

It's not ironic. It's the truth.. I'm trying to explain to you that making forum posts about how library X and library Y should be unified won't make that happen. Not even if you repeat it many times.

It's a noble endavour, and I can see the benefits of a good unified math library.. but until you make one that takes reality into account -that there's at least one (again, can't speak for Xith) well established engine out there that already has a good math library- you can't expect people to adopt your ideas, or expect them not to be skeptical.

In practise, I think it's not easy to write a good maths library (read: one better than what we have now) because you want to unify other programs. I'd have higher hopes for someone who has a big passion for maths and wants to make a very functional and fast math library. If you think you're that last person (or both, I guess) I wouldn't want to discourage you.. a good library can hold it's own, regardess of wether jME or Xith wants to adopt it. But if you plan to just put together some existing functions and break the syntax in the process, I don't think it'll gain a lot of traction.

Yup a good math library needs to have quality. Even if it isn't as fast as other libraries fine-tuned to a certain engine it must at least provide other benefits that a math library specific to a certain engine doesn't have. It certainly helps discussing the differences and the benefits each math library offers since it's rare for engine developers to document this important info anywhere.

Another subject that would be interesting to discuss for unification would be content loaders for 3d scenes. Each engine usualy has half a douzen of specific content loaders which do exactly the some thing when parsing content. Wouldn't it be easier if we worked together to create a unified library for content loaders? At least the content parsing part would be the same for every engine and the model used to represent the parsed content in memory could be a sort of "dom" model. Leaving only the code to translate from the "dom" representation of the content to each specific engine.

There is a lot more things that can be unified for the benefit of all.

If Xith doesn't feel like switching either, for whatever reason, you have a problem. That doesn't mean you can't make your grand unified math library.. as long as you believe you have the skill, dedication and tact to make one so good we'd be stupid not to use it. You just can't reasonably expect that we believe that. Not even after Integer.MAX_VALUE forum posts on the subject. Good code however, can be very convincing..

I think the last part of your post is really ironical but I don't understand what you mean by the Integer.MAX_VALUE forum posts ?? And no I don't believe that I have the skill nor tact nor knowledge to make one so good [...] if that was the case I wouldn't need java.net

Quote

It's not ironic. It's the truth.. I'm trying to explain to you that making forum posts about how library X and library Y should be unified won't make that happen. Not even if you repeat it many times.

It's a noble endavour, and I can see the benefits of a good unified math library.. but until you make one that takes reality into account -that there's at least one (again, can't speak for Xith) well established engine out there that already has a good math library- you can't expect people to adopt your ideas, or expect them not to be skeptical.

In practise, I think it's not easy to write a good maths library (read: one better than what we have now) because you want to unify other programs. I'd have higher hopes for someone who has a big passion for maths and wants to make a very functional and fast math library. If you think you're that last person (or both, I guess) I wouldn't want to discourage you.. a good library can hold it's own, regardess of wether jME or Xith wants to adopt it. But if you plan to just put together some existing functions and break the syntax in the process, I don't think it'll gain a lot of traction.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org