Transform3D#set( Quat4f, Vector3f, float ): signature correct?

Hi all!

Shouldn’t it be Transform3D#set( Quat4f, Point3f, float ) ??

The second parameter describes a point in space and not a direction (like a normal or so).

Opinions??

  • J

Are you asking about changing the API?

At first I’m asking whether it is correct. If it is not, I’d ask for a change of API.
Clarification is also important for the design of my ingame API, maybe my thinking is wrong.

My point, when you e.g. transform a Vector3f by a Matrix4f, the translational part is not applied. This is useful when the Vector3f e.g. describes a normal. This is bc. a Vector3f describes just a direction and not a point in space.

Applying the Matrix4f to a Point3f, translation is applied.

So:

Vector3f == direction
Point3f == location in space

IMHO Transform3D#set( Quat4f, Vector3f, float ) needs a position in space as second argument, so it should be a Point3f.

Well, it could just be a Touple then. But I think they use Vector b/c of the functions that Vector provides over Point

But it’s about the meaning!?

It isn’t a vector! It’s a point?

Tuple3f would be completely wrong, bc. it has no meaning.

a Vector (speaking in mathmatical terms) is technically not a point; but that depends on the notation you use. Generally speaking you assume the parent vector is (0,0) which would indicate that this currect vector is an absolute translation. However, if the parent Transform3D is not (0,0) then the Vector does not describe a point, but describes a method to get to that point.

Hence using a Vector3d/3f would be the correct method signiture and not Point IMO.

DP

Hm, I see … although I cannot follow that (0,0) argument, for a Transform3D always describes a position relative to the parent. So it always counts from (0,0) of its reference frame.
Virtially, a ‘true’ (0,0) never exists.

Taking it another way: in my API I need to place a (game)object. I wonder wether it has to be Movable#set( Vector3f,Quat4f) or Movable#set(Point3f, Quat4f) ? IMHO the same should hold for Transform3D.

There is a very real and distinct mathmatical difference between a directional vector and a positional vector.

Lets put it in example terms:

(1, 1) -> (7, 9)

That means: move from (0,0) by (1,1), then move by (7, 9) ending up in (8,10). Now the (1,1) does describe a Point since the parent of (1,1) is (0,0), but the (7,9) describes a directional move from (1,1) hence the (7,9) is not a point, but a directional vector.

The Transform3D#set(…); cannot be a Point since a Transform3D can have parent transforms which would clash with the idea of a Point, but the idea of a mutable vector that can be both a positional vector and a directional vector works, hence Vectors is an elegant solution to the problem.

Since I am familiar with your gameobject API, I would go for Movable#set(Point3f, Quat4f). This is because the Movable object has no inherit transformation stacks and thus, only requires the final result of the transformation which is a Point, not a Vector. In essence, your Movable object requires a “world view” and not a “local view”. Hope that makes sense, if not, ask away and i’ll try to explain myself more.

As a side note, I think the whole idea of having Point, Vector and Tuple in a math API is stupid since conversion from one form to another is necessary for performance. In your example a Movable could describe the Transform of a leaf node which is the result of the accumulation of all the transforms into 1 Point, but you can’t cast a Vector to a Point since Point doesn’t inherit from Vector. Simple documentation could be written on each method to specify what that method takes, whether it was a directional vector would suffice. Hence why im very reluctant to move to vecmath for VE.

DP

I don’t think its stupid. E.g. does Matrix4f uses different code when transforming a Vector3f and a Point3f of course. This alone is enough reasoning behind it. For a vector, only the rotational part is applied (e.g. for normals) while the full matrix is applied to a point that describes a position in space (resp. position in a reference frame).

Without that distinction, you’d have to care yourself and be very clear about what you have. As you said, there are differences, mathematically speaking.

Simple documentation can suffice in those cases or just a name hint e.g. Matrix4f#rotateVector(…) or Matrix4f#rotatePoint(…). The only caveat of using Point and Vector IMHO is that in the end result after all of this, you would need to change from a Vector to a Point, in which case maybe a simple cast will do, but with vecmath, you would need to instantiate a new object or keep one in a pool.

Looking at it from a CPU based skeletal animation framework, thats alot of vectors your going to be transforming and alot of new objects creating (hopefully java 7 with on stack allocation will help there, but we’ll have to wait and see).

DP

But transforming a vector (e.g. a normal) gives a vector again, transforming a point gives a point. It just has to be kept consistent, which also is the original cause for this question.