Quote:Is gluLookAt(...) from glut, an example of an affine transformation that
combines translation and rotations ?

Yes, it is :)

'Look-at' functions, in general, do the following:

1. Build a rigid-body (i.e. rotation and translation only) transform given a position, a target position, and an up vector for reference.

2. Invert the transform.

The transform is inverted so that it can be used as a view/camera transform. A 'look-at' transform without the inversion is essentially an 'aim-at' transform, which can be used (for example) for billboard effects.

Vector math does not allow to multiply 2 matrices where the number of columns in the left matrix is different from the number of rows in the right matrix. So you cannot packetize an arbitrary (here 4) amount of vectors to build a matrix for a specific matrix product.

Instead, you would multiply each point vector by the transformation matrix, so that you get the same amount of (transformed) vertices at the end. E.g.
pi' = M * pi where i = 1,...,4
Here M (i.e. the matrix on th left) has 2 columns, so the points pi (the matrix on the right) needs to have 2 rows. Because the pi has only 2 values, it is therefore a matrix with 2 rows and 1 column. Hence it is named a "column vector".

You can also try the other way around:
qi' = qi * M where i = 1,...,4
Here M (i.e. the matrix on the right) has 2 rows, so qi needs to have 2 columns by 1 row. Hence it is named a "row vector".

This distinction is important due to matrix multiplication isn't commutative. The conversion between the 2 kinds is named "transposition" (a mirroring about the left-top to bottom-right diagonal). To be precise, the M's in the both formulas above are also not the same, because the one M must be the transpose of the other M.

EDIT: Forgotten to say:
The matrix product goes as follows: The value of the resulting matrix at column j and row k is the sum of all particular products of the values of the k-th row of the left argument matrix by the j-th column of the right argument matrix.
/EDIT

Now, using row vectors as an example, the products are
p1' = p1 * M = ( k * 0 + 0 * 1, 0 * 0 + 1 * 1 ) = ( 0, 1 )
p2' = p2 * M = ( k * 1 + 0 * 1, 0 * 1 + 1 * 1 ) = ( k, 1 )
p3' = p2 * M = ( k * 1 + 0 * 0, 0 * 1 + 1 * 0 ) = ( k, 0 ) // the OP has a faulty point here
p4' = p2 * M = ( k * 0 + 0 * 0, 0 * 0 + 1 * 0 ) = ( 0, 0 )
so you can see a scaling in the horizontal direction.

[Edited by - haegarr on February 14, 2010 2:09:04 AM]

Quote:Then the new set of points is calculated by the following multiplication, right?

tl *= M;
tr *= M;
br *= M;
bl *= M;

where are represent t* and b* as a column vector, and M as a 2x2 matrix?

It depends on how the *= operator is implemented. Typically, v *= M would be equivalent to v = v * M, meaning that the vectors would be row vectors rather than column vectors.

Quote:Original post by Concentrate
Oh. I see thank you. BTW, how would I appropriately define the coordinates
of the rectangle? Would it be a good idea to define it as a matrices like
R =
[x y]
[x y+1]
[x+1 y+1]
[x+1 y]

and then pass it onto a function called Matrix scaleHoritontal(const Matrix& m);
where it does the necessary transformation. I'm just trying to visualize how
one would implement one of these transformation, static methods, an Algorith
class, or what ?

I'm not sure what the advantage of storing the coordinates in a matrix would be. Typically, you would just store the vertices in a container of some sort, and apply the transform matrix to each in turn (as described in haegarr's post).

Note that a quad doesn't necessarily require special handling. A triangle has three vertices; a quad has four; an n-sided polygon might have more than four. Each of these shapes (and many others) can be represented in exactly the same way: as a collection of vertices and (optionally) connectivity information (e.g. indices).

There are occasions where it may be advantageous to use a custom data structure for a particular type of shape, but in general you should think of geometric transformations as operating on a sequence of vertices, without regard for what shape they happen to represent. In other words, the function that applies the transform doesn't care (and doesn't even need to know) that the vertices it's working with represent a quad.