Hi guys, I was wondering if all java gaming libraries could join forces and create a common Math library for vectors/matrices/transformations/etc stuff.
All implementations (phys2d, jbox2d, slick2d, libgdx, lwjgl-utils, etc) seems to be very similar and to have similar stuff. If all of them work together, we could have a common and better math library.
Vecmath seems interesting to be modified for the greater good but only jbullet is using it, also I dunno about its license.
What do you think?
Vecmath API (there is BSD or so licensed reimplementation btw) is closest to best candidate for two reasons: it is somewhat official (but quite weak to be honest) and technically probably the best you can achieve in Java. And we’ve tried, me and other devs to come with a better API.
I don’t think such unification will happen as everyone has their opinions and it’s easier and more coherent to port everything including vector/matrix/etc. routines in ported libraries.
However, in an unlikely event if there would be some evolved vecmath API (basically just added stuff to vecmath api and in unofficial package) and have support in other java gamedev libraries, I would most likely adapt JBullet to it.
When I worked on jsnakes, I used jbullet for the physics and I remember using vecmath and it has a lot of useful methods in the API but also IMO has a lot of not related stuff in some of its classes. Btw, I found an updated copy of vecmath on github, dunno if the github project’s author is related to the original code.
I am agree that the unification could never happen, but we have to try. Maybe we could start by defining only an API, not an implementation, so we could at least use the same methods: distance() or dst(), length and lengthSquared or len() and len2(), etc. Then ppl could implement them using the implementation they want (fast, ultra fast, using native code, etc).
The biggest thing that the vecmath libraries are missing (unless its been added recently) is that there is no support for read-only or immutable types. It is really useful to be able to return a vector that won’t change on you without needing to make a defensive copy.
Same approach libgdx and slick2d uses I believe (dunno about jbox2d Vec2 or Vector2f from LWJGL-util). One thing to notice is they have a tmp() and cpy() methods to return a temporary or new vector (respectively) with the values of the current vector. Maybe that could be an addition to vecmath (or other library).
All these libraries use this approach for a performance reason by avoiding making billions of new instances and killing the GC (which sucks on the Android platform for example). I like the approach but I also like easy to use APIs.
I took a look at openmali, seems like vecmath plus a looooooooooooot of stuff (even collision stuff) (I also took a look at commons-math from apache and I have the same opinion). I believe the smaller the common math library is, greater chances of ppl using it. However, I also believe that multiple common math library modules could be made.
You can see my conclusion from 2008 regarding openmali and generally about vecmath libraries in Java.
Unless you can come with something new, this was already resolved. The only thing that could be improved is to make more projects using Sun’s Vecmath. However in some projects this is no issue, eg. in JMonkeyEngine you work with JME vecmath and jbullet or other physics engines are behind abstraction so the conversion is done in JME itself.