Finding where translate takes me

Started by racura, May 19, 2009, 07:53:10

Previous topic - Next topic

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
Quotepublic void translateSourcePos    (FloatBuffer matrix)
or
Quotepublic 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

QuoteIf 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

QuoteBut 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!

QuoteAlso 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

QuoteDo 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!

QuoteI 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.