I'm glad you brought this up! I've been re-writing my math library and am working on the same thing.

The first thing to realize (and you may already know this), is that for most transformation matrices a general inverse is not required. If your transformation is composed of a rotation matrix R and a translation matrix T, then (using row vectors) the combined transformation is R*T, and the inverse is T-1*R-1. Fortunately, you can invert a translation matrix simply by negating the translation components, and you can invert a rotation matrix by transposing it. So no costly general inversions are required.

If you already knew all that, sorry. As for general inversions, I'm also looking for an optimal approach. The method I've seen used most often for small (<=4x4) matrices is the adjoint method. This can be optimized by factoring out the common subdeterminants, but still requires a fair amount of work.

However, I've been looking at some professional source code that uses another method. From what I've seen so far, the matrix is decomposed into a block representation. For example, a 3x3 matrix is decomposed into an upper-left 2x2 matrix, a 2x1 column vector, a 1x2 row vector, and a scalar in the lower right. The inverse is then found through operations on these blocks. The savings over the adjoint method appear to incease with the matrix dimension; for 4x4 and higher it appears to be significantly more efficient.

Now, I have no math training and am in the process of teaching myself linear algebra at the moment. So this may be some totally standard technique, and I just don't know what it's called. So I'll take this opportunity to ask the math-knowledgeable: what technique is this? I'd like to research it, but I'm not sure what to google for...

Anyway, I know that didn't answer your question. But maybe it will get the discussion started.

A method for determining the inverse of a matrix is to use Gauss-Jordan elimination. For small matrices, you can use Cramer's rule.

Quote:Original post by MDI
Can I ask why in books translation matrices are 4x4 whilst we've been taught the same thing in lectures using 3x3 matrices? What's the [seemingly] redundant extra entries for?

perspective projection and translation.

most rasterizing software works with so called homogenized coordinates: 4d coordinates which usually all lie in one fixed hyperplane in the fourth dimension.

sounds quite complex, but all it means is carrying perspective and translation information along in the matrix. the perspective information is, indeed, usually redundant. however, apis like opengl and such always work with 4x4 for generality. for your own software renderer i wouldnt bother with them, and just do the only perspective transform you probably need, your camera transform, the inituative way.