Matrices - Performance Question

[H.Stony]

i have to recalculate the position of an object after transformation.

First Method:
pseudocode:

"Camera" transformations
push the matrix
object transformations
draw the object
pop the matrixto get the correct position of a transformed point i need to call "glLoadIdentity" so i have to take a second pass:

glPushMatrix();
glLoadIdentity();
Same transformations as above;
getTheMatrix();
glPopMatrix();Second Method:

"Camera" transformations
write the modelview in an array
push the matrix
load the identity
object transformations
get the modelview to recalculate a point
multiplicate the current matrix with the cameramodelview.
Load the new matrix
draw the object
pop the matrixBoth ways would work but which one is the faster one? is glMultMatrix slow?

hope you understand my problem. i hope someone has tested it or has experience with such performance questions.

thanks

[knackered]

Best not to use the gl matrix functions for this kind of thing - you should never use glgetfloatv as read backs are always a bad idea. Use your own matrix functions, and just call glLoadMatrix when you're about to draw an object with that transform.
If you insist on using the gl matrix manipulation functions in your application code then it doesn't matter which of your suggestions you use, the performance impact of the glgetfloatv will mask any variations in speed between the methods...

[H.Stony]

although i will use the gl matrix manipulation functions. my own functions were always extremly slow and a lot of work.

thanks

[Brolingstanz]

you should never use glgetfloatv as read backs are always a bad idea.why is this? what is the purpose of such functionality if it's always a bad idea to use it?

regards,
bonehead

[Brolingstanz]

my own functions were always extremly slow and a lot of work.look into sse/3dnow if supported on your target platform.

regards,
bonehead

[knackered]

why is this? what is the purpose of such functionality if it's always a bad idea to use it?The ability to read stuff back is for situations where you have no option (like reading back the framebuffer as part of some other more complex process), or you're an inexperienced developer without the ability to program simple linear algebra functions, or you're prototyping something, or you're profiling something.

Well perhaps it's not true that reading back a matrix is going to cause a pipeline flush, but it's as well to get into the habbit of not reading stuff back from your graphics API unless you have literally no other option, and even then try to maintain some asynchronousity.
It's a co-processor you see, getting its instructions from a FIFO, not your application thread. Reading back is obviously not the best thing to be doing.
Incidentally, if I saw a professional application using a graphics API to do its maths I'd be outraged...it just doesn't belong there, and makes portability an issue it needn't have been with a minimal effort.