VecMath (fast?) replacement

Shared Code
#1

Hi all,
I finally got to give some attention to our vec math classes again.
After some reexamination, we are going with a somewhat J3D vecmath compatible API. We used compatible class names for easier replacement into existing projects. It’s quite stripped down however. For example, there are no double formats or Color classes and no plans to make them. The source is bare (few comments) as well right now, but the Javadocs for J3D vecmath would explain the existing methods that match.

If any gets a chance let us know what you think. We are trying to get a feel for what people use the most of in the original APIs but no more than that :slight_smile:

Also, this release does NOT use our fast math classes yet (sin/cos etc). We are still mulling the best way to allow the user to “config” it’s usage in the vecmath classes.

It is being releases under the BSD license and here is some info from the pitiful release notes in this early version.

Lite VecMath
September 26, 2003
Release Notes:

-----------------------------
General design choices:

No equals/hashcode combo
Used clonable interface instead of explicitly overridding clone.
No clamping methods
Only support floating point versions, i.e no double, int or byte classes.
No double convience methods
No need for Tuple parent types since there would only be one child class for each type
All color types dropped/unimplemented.  However, the Color3f convience methods have been added to Vector3f
No epsilonEquals

Package name will change in future releases.

-----------------------------
javax.vecmath Classes partially supported:

Matrix3f
Matrix4f
.
.
No INVERT (priority 1)
---------
Quat4d
Quat4f

True quat interpolation (slerp) not implemented yet. (priority 1)

---------
Vector2f
Vector3f


General, toString output format is the same as original vecmath.

And finally the download link
http://www.imilabs.com/loader/loader/vecmathLite.jar
I went ahead and added the javadocs into the jar.

#2

Extra comment…
These classes do not have any methods for working with FloatBuffers as the LWJGL vector/matrix classes do, but we will add them.
They are not here now because we are still looking at a few options. For example, I am leaning towards a utils class to do it in because there are several way you might want to pass on to FloatBuffers, not just a per matrix copy. I want to be able to things like pass arrays for vectors and have the utils write it all to an array and then to the FloatBuffer in one move if that proves to be faster (or for what size will it?)

#3

i havn’t had the chance to look at it yet but are you keeping the javax.vecmath package name? Otherwise it is a bit of a pain to switch (especially in this case where one implementation of the vecmath package should be almost identical in behaviour to the next). Reason I ask is you say " Package name will change in future releases."

Will.

#4

The package name I used was vecmath.*
I just dropped the javax.
I thought that this would make for trouble so I kept it similiar, especially since the API is pratically the same.

Possible it could become net.vecmath at some point?

#5

my opinion is that what you have is an implementation of the “javax.vecmath” library and therefore it should be named as such - this makes testing so much easier as you just pull one .jar from your classpath and plonk one back in. IIRC the other free implementation followed this.

The same argument could be used for Xith3D itself, but that is less of an implementation of Java3D, and more an implemenation of a similar scenegraph. With vecmath, the classes, method names and functionailty is exactally the same (hopefully) as it was for the official javax.vecmath package.

Fair enough you have cut some of the fat from the offiical javax.vecmath but what you have left in is essentially the same stuff. This way you don’t have to change a whole pile of import statements everytime you switch vecmath implementations.

Cheers,

Will.

#6

Are you “allowed” to do that?
Do you have to make an “endorsed standard” ? I know the java.* packages are off-limits, but 3rd parties are allowed to make implementations of the javax.* I just wonder if they are allowed to not match the official spec of a javax API and still use that name?

#7

Ok my original-cross posting has cause this thread to run in http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1063928279
as well.
I will stop posting there and move all my discusssions to here.
My last reply was this:
No offense, but the package name can NOT be the same.
It’s not the same API, or code.
And it’s not “javax”, that is a “semi” official package division used on many Java APIs.

Anyone else have an view? I’ve never heard of releasing an API with the same package name as an existing one from another source…

#8

Using only floats is fine by me.

Some questions:

[]
When you say no Tuple parent classes do you mean you will not have a Tuple3f which is the parent class for vector3f and point3f? Xith3d tries to use tuple wherever possible because in most cases points and vectors are treated the same, whereas in the places where it matters (like transform) we use the proper types.
[]epsilon equals is important for splitting bsp trees and t-juncture resolutions.
[]Hashing and equals is important for many algorithms, like building a list of unique coordinates.
[]We use quats all over the place for animation especially.
[*]Just as a note we also use Vector2f quite a lot.

My recommendation would be to fully implement the entire package and do a parallel test to compare all functional outputs asa regression test. I know it is more work, but it would go a long way to getting it adopted. Alternatively you could just open source it and people will help fill in the blanks.

#9

IMHO it was a disastrous error deriving Vector and Point from Tuple. It’s just simply not how maths work.

It might be sensible to have only Tuple as an actual class, and then have two static classes, Vector and Point, which have static methods for manipulating Tuples as Vectors or Points - because as we all know in maths, things change their identity rather a lot.

Cas :slight_smile:

#10

Well I for one consider it really freaking annoying that I can’t find the distance between two vectors, I don’t care how mathematically wrong it is. A lot of the times you use vector operations and the end result is a 3d coordinate in space… why do I have to convert it to a Point to do some simple operation on it?

Exactly what are the Vecmath operations that would be considered undetermined unless applied specifically to a point versus a vector?

THis is all ready annoying, but it would be 10 teims worse if Point and Vector were not even related classwise.

#11

[quote]I
It might be sensible to have only Tuple as an actual class, and then have two static classes, Vector and Point, which have static methods for manipulating Tuples as Vectors or Points - because as we all know in maths, things change their identity rather a lot.
[/quote]
What with matrix transforms ? You need to differ between Vector (rotation/scale only) and Point transforms. Of course, it is possible to do it by two separate methods (transformPoint and transformVector), but if language supports method overloading, why not use it ?

IMHO, Tuple -> Point/Vector inheritance is quite reasonable - from both math and programming point of view.

#12

Ok I’ll try to address everything I missed so far.

  1. As far as the vecor/point/tuple issues:
    I made Vector have the Tuple methods, so it would still work as usual. I also added the addition/different methods of Point class to the Vector class so all are there. So yes you can get the distance between two vectors-computed as points.(my pet-peeve as well)
    I have no plans to make a Point class, although it’s not that bad, copy Vector cut out vector only methods, whamo Point classs. But there is still no parent “Tuple” to use for type passing. Not sure what to say about this. My team never liked it, and aren’t interested in Tuples. This may be the biggest conflict for some original vecmath users, such as Xith.

  2. Epsilon equals to me has always belonged a utils class call. Even the uses you site are typically offline uses, i.e. not in-game execution. To me that is most certainly a utils class that does not end up in the final dist of a game.

  3. Hashing and equals are intended to be overwritten, just didn’t in this first release.

  4. The Quat class was implemented, just not complete yet.

  5. Vector2f in there too. :slight_smile:

[quote]Alternatively you could just open source it and people will help fill in the blanks.
[/quote]
I released it under BSD as per your request. I understood that to be open…?

On a different note, I just finished the fastSin\Cos intergration into vecMath. So rotX() and similiar are ~5-10 times faster depending on the VM with user-definable error (the user can set the table size). I will release this this week, and any new additions that come from this forum.
By intergrated I mean ADDed new methods. The original methods use the standard Math.sin() stuff.

#13

adressing the question are you “allowed” to call it javax.vecmath - there’s no law against it is there?

My impression of the library was more that it “was the official javax.vecmath API but with less classes” hence if it looks like the official one, works like the official one, why not call it the same package name so that people can just use them interchangably.

This is what the people of the “official” unofficial vecmath implementation (http://objectclub.esm.co.jp/vecmath/?) have done:

Tuple2f.java:


/*
   Copyright (C) 1997,1998,1999
   Kenji Hiranabe, Eiwa System Management, Inc.

   This program is free software.
   Implemented by Kenji Hiranabe(hiranabe@esm.co.jp),
   conforming to the Java(TM) 3D API specification by Sun Microsystems.

   Permission to use, copy, modify, distribute and sell this software
   and its documentation for any purpose is hereby granted without fee,
   provided that the above copyright notice appear in all copies and
   that both that copyright notice and this permission notice appear
   in supporting documentation. Kenji Hiranabe and Eiwa System Management,Inc.
   makes no representations about the suitability of this software for any
   purpose.  It is provided "AS IS" with NO WARRANTY.
*/
package javax.vecmath;

But, it seems like you are using your poetic license with the API which is a good idea as you and some of the the previous posters have thought of some ways to expand and enhance the API.

please excuse my misunderstanding, carry on your good work :slight_smile:

Cheers,

Will.

#14

I have a question for David and the rest of the Xith team. (suppose it should go in the Xith fourms then, but this thread is all over the place :-/ )
Are you using Kenji Hiranabe’s vecmath implementations, and if not why?
It’s totally complete, compliant, and the license seems opens source “enough”.

#15

… Strange but I completely missed this thread…

[quote]Are you using Kenji Hiranabe’s vecmath implementations, and if not why?
[/quote]
I tested Kenji’s vecmath with Xith3D and it works just fine [with minor modifications, such as serialization, etc.].

I see no reason why not to use Kenji Hiranabe’s vecmath implementation with Xith3D. But I still interested in performance comparison of different vecmath classes.

Yuri

#16

A random suggestion: how about getting it hosted as a middleware/library project on java.net? It could be a start towards more universal set of libraries (such as model loaders) which need some sort of shared core to avoid rewriting a bumpy wheel each time…

#17

+1 for Orangy Tang suggestion.

Yuri

#18

+1

#19

You know you’ve got my support on that!

+1

#20

+1 - agree also that loaders should get the same treatment