Point/Vector/Tuple/Coord3f mess

Engines, Libraries and Tools Xith3D Forums
#1

I have looked at the changes introduced with collision code and I think that xith3d is getting into very dangerous situations because of Point/Vector/Tuple/Coord3f.

In java3d, everything worked on Point3f and Vector3f, almost none of methods accepted Tuple3f. While this caused a lot of headache when you had to move data there and back just to match some method signature, at least it was very helpful (for me) math-wise - if you had ray method, you new what Point and Vector meant without looking at javadoc or parameter names. With pair of tuples, you need to be a lot more careful - and mistake will go unnoticed silently and can even work correctly in some cases !

Now I see that Coord3f extends Vector3f class was added to unify Point3f and Vector3f. Again, I understand the reason - Tuple3f has not exposed enough methods to be useful, so even in xith3d you had to sometimes copy data there and back or rewrite basic stuff like dot product yourself just to have it work on tuples you got from elsewhere (this would be not a problem if they would be Vectors as they should, but…). But then comes the transform and while Coord3f extends Vector3f, MatrixExt4f transforms it as a point… and this is a one step too far IMHO. Look at following examples

MatrixExt4f me;
Coord4f coord;

I can transform coord as point using
me.transform(coord);
but


Matrix4f matr = me;
matr.transform(coord);
versus
me.transform(coord);

I don’t know if it hits you as much as me, but if I see a code which just assigns a pointer to superclass and this changes a result of method call…

Same goes for


Vector3f vec = coord;
me.transform(vec);
versus
me.transform(coord);

In first case it is transformed as vector in second as point.

This is bound to be a cause of major and hard to detect errors in both core lib and user programs. Solutions ? I do not see ideal one, but here are some ideas:

Rename transform(Coord3f) method from MatrixExt4f to transformAsPoint(Coord3f) and add second one transformAsVector(Coord3f). Then make Coord3f to extend Tuple3f and copy vector methods there in addition to point ones - this way it will not get mistaken by accident. At the same time, transform methods as different enough to not be available with other meaning in plain Matrix4f.

In every method which has incoming Coor3f parameter, stress if it is looked at as point or vector if it makes a difference.

In some cases add explicit Point/Vector name to method, as you cannot rely on parameter signature matching to do a job, so you need to go EIFFEL route and encode everything in method name.

My personal choice would be to go back to java3d route and use Point3f/Vector3f in meaningful way, even if it costs developer a bit of extra work. But as it is one of design guidelines of xith3d to not have such distinction, at least let’s make it very hard to make mistakes.

#2

Yes it is dangerous, but perhaps necessary.

I would prefer the transformAsPoint or transformAsVector methods.

I personally prefer a unified solution. The collision code really brought it home as I was constantly switching back and forth from vectors to points, making extra copies for no good reason. Unfortunately all the methods in the Vecmath library are declared final, so we cannot alter the behavior whatsoever.

Basically is there some reason why we would not want to calculate the distance between two vector endpoints? Well Vector3f does not have this method. Is there any reason why we would apply a transform with a translation component to a vector and not have it apply the translation part? I think it is non-intiutive that transform of a vector will only effect rotation and scale, but ignores the translation.

I personally would prefer that Xith3d used a single unified Coord which did away with the distinction of point and vector except that would introduce too much incompatiibility with older code.

I will revert the Transform3D back to using the Matrix4f and will introduce the two transformAs methods. I do think having the Coord3f as a unified Tuple for use in subsystems like collision should be allowed.

#3

A related question: If you had the chance to do a vecmath library from scratch, would you make the distinction between vector and point or not?

I’m currently writing a program and it’s really frustrating to write vector math things. You always have to convert between vector and point (sometimes making unnecessary copies). On the other hand distincting between point and vector can increase readability. (Side note: In this case operator overloading would greatly enhance readability.)

#4

In my own vecmath lib, I have Vector and Point extend Tuple4f and I use homogeneous coordinates.

That way, when it makes sense to handle vectors and points the same way (eg. homogeneous transformation), I use them as tuple.

The main drawback is obviously the use of an additionnal float (w), even if the user doesn’t really need it.