Finding where translate takes me

[racura]

Hey, first post
    
I am currently trying to find the X, Y and Z coordinates after translating and rotating.  Is there any code that would output it as such?  I need it so that another method can take in as

public void translateSourcePos    (FloatBuffer matrix)

or

public void setSourcePos    (float x, float y, float z)

Second method would be better as I can then get ride of the first   

[Kai]

You can build up a basic translation matrix as well as a rotation matrix and multiply them (in the order that is appropriate for you). After that, you have a transformation matrix that, when being multiplied with a vector v (source position) gives you a vector v' with the new vector (e.g. destination position).

[firemanphil]

If you have only translated and rotated your coordinates then you can just transform your vertex using the modelview matrix like this:

public Vector4f findTransformedPoint(Vector4f point){
		Vector4f translatedPoint = new Vector4f();
		Matrix4f matrix = new Matrix4f ();
        FloatBuffer params = FloatBuffer.allocate (16);
        GL11.glGetFloat (GL11.GL_MODELVIEW_MATRIX, params );
        matrix.load (params);
        Matrix4f.transform(matrix, point,translatedPoint);
		return translatedPoint;
		
	}

This gives you the transformed point (I think!).

[Kai]

If you have only translated and rotated your coordinates then you can just transform your vertex using the modelview matrix like this:

This indeed would work for any transformations (translation, rotation, scale), since the modelview as well as the projection matrix are just matrices which incoming vertices will be multiplied with. So it's just a basic vector/matrix multiplication. But I would suggest using a linear algebra library that does not run in the OpenGL driver, like "vecmath", because matrix manipulations through the driver are awfully slow compared to a direct invocation of a java method.
Also doing it the way using the modelview matrix requires you to save and restore the matrix with push/pop commands that also come with an unnecessary performance overhead.

[firemanphil]

But I would suggest using a linear algebra library that does not run in the OpenGL driver, like "vecmath", because matrix manipulations through the driver are awfully slow compared to a direct invocation of a java method.

Do you know why this is? I would have thought the driver would be good at matrix manipulations seeing as it does so many of them!

Also doing it the way using the modelview matrix requires you to save and restore the matrix with push/pop commands that also come with an unnecessary performance overhead.

I don't understand why this is necessary. I am reading the current state of the matrix so there shouldn't be a need for push/pop. I assumed the performance dip would be due to the glGetFloat method.

[Kai]

Do you know why this is? I would have thought the driver would be good at matrix manipulations seeing as it does so many of them!

The biggest one is the overhead of JNI to translate java method calls to native ones and any argument validations that occur in the LWJGL classes.
The driver is not that fast at matrix manipulation; the GPU is. But the glTranslate, etc. methods do not make it that far!

I don't understand why this is necessary. I am reading the current state of the matrix so there shouldn't be a need for push/pop. I assumed the performance dip would be due to the glGetFloat method.

Yes, but you might find the need to build the matrix yourself with the convenient glTranslate, glRotate, etc. methods on the OpenGL matrix stack and afterwards get the resulting matrix with glGetFloat just to transform some vertices with that matrix. Then, in order to prevent any pre-existing matrix setting to be destroyed, you would push/pop.
The overhead of the OpenGL commands involved in that would be way higher than doing the matrix manipulations within the Java linear algebra classes.
In fact when you have some Physics and other stuff that heavily relies on math involved in your program, you would have to have some sort of math library for that, too, and then it is cumbersome to keep those two parallel worlds "OpenGL matrix stack" and your own math objects in synch.
I believe this might be the reason why the Khronos group decided to mark the matrix stack and any glTranslate, glRotate, etc. operations as deprecated in the OpenGL 3.0.

[firemanphil]

Thanks for the reply, very informative.