   Matrices and OpenGL 3.x
  In OpenGL 3.1 it seems that the whole fixed function is removed.  So as I was computing the model, view, and projection separately anyways, I decided to use uniform variables to send these matrices to the shader, even though I am not using 3.1, just for fun.uniform modelMatrix, viewMatrix, projectionMatrix;This way, I could also compute things like inverseViewMatrix, and even do shadow mapping easier by supplying a lightViewMatrix rather than using a bunch of inverses to arrive at the model transformed point.But I have come into a problem where I need to compute gl_NormalMatrix by myself, which is the inverse transpose of modelMatrix*viewMatrix.  I do not have a general formula that takes the inverse of a matrix, and I think it can be optimized better if one doesn't use that. So what should be my course of action?  Should it be to get the rotate, transform, and scale transforms out of the matrix and then finding the individual inverse/transposes of these?  If so, how should I do this?   
  I think http://www.cvl.iis.u-tokyo.ac.jp/~miyazaki/tech/teche23.html can help.   ;  Double Post!   ;  Is this method fast enough?  I guess it would have to be.So I have to find the inverse transpose of the upper 3x3 portion AFTER I have multiplied model and view?  I guess I could pass the modelview at this point and not have to do that multiplication on the shader :).Thanks, I'll try this and see what happens tommorow.Wait, is this true:inverse(transpose(modelview)) == inverse(transpose(view)) * inverse(transpose(model))Because my view is generated via lookAt (which is orthogonal, so the inverse tranpose == the original matrix), and the inverseTranspose of the modelView matrix (which I have taken the view out of) is calculated by the drivers as gl_ModelViewMatrixInverseTranspose.edit: yep, that seems to work.[Edited by - solinent on May 26, 2009 10:00:23 PM];  I adopted an alternate approach that works great and is the most efficient in every ***normal*** situation, and you might want to consider it.  I'll give you the short description here, and if you want to pursue it, ask for more details and I'll supply them.  My approach avoids the need to compute or apply any inverse matrix.The most common transformations that cause problems are non-uniform scaling AND shear/skew transformations.  The problem is, if we transform vertex normal vectors with the conventional transformation matrix, it generates incorrect normal vectors (but correct position, tangent-vector and bitangent/binormal-vector).  After a careful analysis of how often various operations occur in real-world applications (games and realistic simulations), I decided to deal with this problem in an unconventional way that totally avoids inverse matrices).What I have my engine to is this.  Whenever a non-uniform scale or shear/skew operation occurs (rare during object creation, and ***extremely*** rare or never thereafter), the engine transforms the object coordinates of the object-vertices.  In other words, the engine ACTUALLY scales or shears the object, instead of perverting the object transformation matrix.  The engine then performs the appropriate special-purpose transformation of the object normals as appropriate to the operation (non-uniform scale or skew/shear).Thereafter, while the engine and application are running, the vertex positions and normals can BOTH be transformed by the same transformation matrix. In fact, when I wrote my SIMD/SSE2+ assembly language routines to transform vertex positions, normal-vectors, tangent-vectors and bitangent-vectors to world and/or camera (and/or projection) coordinates,  I found my code to multiply the position and vectors by the same transform matrix simultaneously was MUCH more efficient (faster) than all previous approaches.I believe this is a superior approach in practice.  It definitely works great, though you may find it makes some programmers uncomfortable - just because it is unconventional.   ;Quote:Original post by maxgpgpuI adopted an alternate approach that works great and is the most efficient in every ***normal*** situation, and you might want to consider it.  I'll give you the short description here, and if you want to pursue it, ask for more details and I'll supply them.  My approach avoids the need to compute or apply any inverse matrix.The most common transformations that cause problems are non-uniform scaling AND shear/skew transformations.  The problem is, if we transform vertex normal vectors with the conventional transformation matrix, it generates incorrect normal vectors (but correct position, tangent-vector and bitangent/binormal-vector).  After a careful analysis of how often various operations occur in real-world applications (games and realistic simulations), I decided to deal with this problem in an unconventional way that totally avoids inverse matrices).What I have my engine to is this.  Whenever a non-uniform scale or shear/skew operation occurs (rare during object creation, and ***extremely*** rare or never thereafter), the engine transforms the object coordinates of the object-vertices.  In other words, the engine ACTUALLY scales or shears the object, instead of perverting the object transformation matrix.  The engine then performs the appropriate special-purpose transformation of the object normals as appropriate to the operation (non-uniform scale or skew/shear).Thereafter, while the engine and application are running, the vertex positions and normals can BOTH be transformed by the same transformation matrix. In fact, when I wrote my SIMD/SSE2+ assembly language routines to transform vertex positions, normal-vectors, tangent-vectors and bitangent-vectors to world and/or camera (and/or projection) coordinates,  I found my code to multiply the position and vectors by the same transform matrix simultaneously was MUCH more efficient (faster) than all previous approaches.I believe this is a superior approach in practice.  It definitely works great, though you may find it makes some programmers uncomfortable - just because it is unconventional.Well, its less robust for sure, and involves more work :PI don't think I'll do it this way because the reason I was doing this in the first place was not because of non-uniform scales / shears in the loading format, but rather a single matrix that is not orthogonal (ie. a matrix where the inverse tranpose is not the same as the original).I have solved my problem for now by generating the inverse view matrix once, and then using the built-in gl_ModelViewMatrixInverseTranpose.  This way I don't have to actually switch right now, but in the future I think I'll calculate the inverse transpose before sending a full model.  This isn't that hard for a 3x3 matrix as described by Huntsman.   