i posted this message in the beginners’ forum. halcyonblaze answered and he was helpful (thanx halcyon). i am just trying to get another answer, so i thought to post it in the advanced forum. if you think the question is trivial and should not be posted here, please don’t answer. on the other hand, if you want to help…
i have this problem:
after several pushes/pops/translates/rotates i get the modelview matrix using glGetFloatv() and store it in a 4x4 GLfloat matrix. how can i inverse this matrix? (i know opengl is not a math api, and i also know i can invert it using maths, ie gauss method. but is there any other way (faster), because i want this calculation to take place several times during a rendering cycle?).
to better understand the problem:
i need to transform the light using the inverse modelview matrix (that’s what the trouble is all about, the inversion). then i use glLoadIdentity() and after that i load the modelview matrix (not inverted) and draw an object. since i have several transform commands, i started working on a weird (and maybe stupid) solution: i kept track of the transform commands (for example, after a glPop i inserted a number in a matrix (i call it command matrix), after a glTranslate i insterted another number in the same matrix - in order to “describe” the transformations). then, when i wanted the inverse matrix, i executed the commands “described” in the commands’ matrix one by one (negated and in the revese order). but the problem was that i needed to draw many objects and somewhere i lost it with many pushes/pops.
so, i decided to abandon this solution and try to explicitly inverse the modelview matrix myself.
somewhere in the forum i read that if you discard the translations from the modelview matrix, you can easily invert it. i wonder how this can happen since after discarding the translations (keeping only the rotations) the matrix is still not easy to invert.
any help would be greatly appreciated.
thanx in advance for your time
[This message has been edited by kawasakis900 (edited 02-05-2003).]