abstruse transformation Matrix question...

Member
Posts: 321
Joined: 2004.10
Post: #1
I've been reading ThemsAllTook excellent introduction to matrices at,

http://www.sacredsoftware.net/tutorials/...ices.xhtml

After reading the article, I understand which elements are filled out
for the various transformation matrices: translation, rotation, scaling, etc.

My question is what is the transformation matrix multiplied with?
Say I've got a cube currently drawn on my OpenGL screen. I want to
rotate it by some amount. I fill out the matrix's elements relevant to
rotation. I then take the matrix and then what? The article says:

"A transformation matrix is essentially a map from one coordinate system to another. By multiplying a vector or a set of vectors by a matrix, you apply the matrix's transformation to the vector"


Does this imply that my cube displayed on my OpenGL screen consists of a set of vectors? I was thinking that the cube was composed of a set of
vertices?

Here's something probably completely bogus. When the above statement
says, "A transformation matrix is essentially a map from one coordinate system to another" this isn't saying that each pixel coordinate on the screen is mapped
to a new pixel coordinate?

Maybe when all is said and done, I simply don't understand exactly what an openGL image consists of?
Quote this message in a reply
zKing
Unregistered
 
Post: #2
There probably are sites that can explain this WAY better than I can, but basically each vertex is treated as a vector. i.e. a vertex at position X, Y, Z can also be thought of as a vector: [ X, Y, Z ].

So when you transform an object like a cube, you take each vertex coordinate as a vector and multiply it by that tranformation matrix giving you its new position.

Does this make any sense?

It helps to do this by hand (or write some code that does it and step through a debugger) to really "see" it.
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #3
The great thing about OpenGL is that you can use it without actually knowing the math behind it, that way, when you do learn the math behind it, it becomes an even more powerful tool.

The questions you are asking are hard to answer specifically because of your mathematical background. Take a course on linear matrix algebra and a course on computer graphics, and you will begin to see how these things come into play. In the mean time, you don't truly need to understand how matrices work in order to do small things with OpenGL.

But to give you a few brief answers... your transformation matrix is going to be multiplied with your identity matrix. The identity matrix basically says, 0 is 0, 1 is 1, and so on. The transformation matrix remaps these things so that you get a 3D view, basically.

A vector is just a 1xN dimensional matrix. A position vector would contain 3 vertices. A cube would contain 8 sets of 3 vertex vectors.

Basically, these are things you learn over time and a lot of math classes that seem like they have no point until you actually have to use that math. Explaining it to you without the proper mathematical education would be pointless. Furthermore, you don't actually have to construct these matrices on your own, calls to glTranslate*, glRotate* and glScale* will do everything you need to do at this point in your programming career.

Anyone feel free to jump in and tell me I said something wrong at some point, as well.
Quote this message in a reply
Member
Posts: 321
Joined: 2004.10
Post: #4
Quote:basically each vertex is treated as a vector. i.e. a vertex at position X, Y, Z can also be thought of as a vector: [ X, Y, Z ].

Ok, that seems helpful, but... Doesn't a vector have a starting position xs, ys, zs
and a direction and magnitude specified by xd, yd, zd? In other words, an arrow
(i.e. line with direction) in 3D space.

Or is the starting point always assumed at the origin {0.0, 0.0, 0.0}? Or is
the vertex (vector) of magnitude and direction zero? Or is this nonsensical?

Or should I just wait and be reincarnated as Einstein Smile
Quote this message in a reply
zKing
Unregistered
 
Post: #5
WhatMeWorry Wrote:Ok, that seems helpful, but... Doesn't a vector have a starting position xs, ys, zs
and a direction and magnitude specified by xd, yd, zd? In other words, an arrow
(i.e. line with direction) in 3D space.

Or is the starting point always assumed at the origin {0.0, 0.0, 0.0}? Or is
the vertex (vector) of magnitude and direction zero? Or is this nonsensical?

For the math we do you can consider those vectors to have an origin of 0, 0, 0.

Well... its kinda complicated (that's a technical term only used those of us that were CS/Math double majors.)

You can think of the origin as the center of operations, for example if you create a rotation matrix it will always cause rotation around the origin.

Think of a model of the solor system... if the center of the sun is 0, 0, 0... say the Earth is somewhere like 1000, 1000, 50. If I take the earth's coordinates and multiply them by a "rotation" matix, it will move the earth around the sun (like the earth moving around the sun each year)...

But if I want to do the math of the earth rotating on its axis, what do I do?
I temporarily translate the earth's coordinates to 0, 0, 0, do my rotation (so it will rotate on its poles), and then translate it back to 1000, 1000, 50.

Ok, after rereading this I think it may be more confusing than helpful, but I'll post it anyway. Wink
Quote this message in a reply
Member
Posts: 321
Joined: 2004.10
Post: #6
Quote:But if I want to do the math of the earth rotating on its axis, what do I do?
I temporarily translate the earth's coordinates to 0, 0, 0, do my rotation (so it will rotate on its poles), and then translate it back to 1000, 1000, 50.

Not confusing at all! I'd study the Red Book's planet example
and never understood why the translations were there.

Let me see if I have this right: All transformation matrices ( translation, rotation, scaling, shearing, and perspective) can only be applied to vertices (vectors)
if they start at the origin. But by their very nature, all vertices start at
the origin; after all, vectors are always just x,y,z.

If a transformation (translation, rotation, scaling, shearing, and perspective) is desired on an object seperate from the origin, the object (ie all vertices) need
to be translated to the origin, the transformation of the object performed, and
the object translated back.

One thing bothers me about the second sentence though. I could see if
you want to rotate a sphere about it's x-axis, or a cube about it's y-axis.
Finding the value to translate the object to the origin and back again is
trivial. But say you had a pitcher object out in space and you wanted to
rotate it around it's z-axis. How would you know where the center of the
pitcher is so that it could be correctly translated? I assume there is something
stupid I've forgotten.

Thanks for all the help.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #7
Presumably, the data structure that stores your pitcher model would have all of its vertices expressed in relative coordinates to the point around which you would want to rotate it. Generally (for relatively simple cases), when you draw an object in a 3D scene, you would push the current modelview matrix, translate to the location where you want to position the object, multiply the modelview matrix by its orientation quaternion, submit the geometry to GL, and pop the modelview matrix so you can repeat the process for additional objects.

Oh, and I'm glad you're getting some use out of my tutorial. Grin
Quote this message in a reply
Member
Posts: 41
Joined: 2006.01
Post: #8
I have animated a globe, but never using a model that was defined using another app. The easiest way to do it (it's always a bit of trouble though) is to start with a regular solid that you can put your texture on, and sub-divide it's faces until it looks round enough. Sub-divide by taking midpoints on every edge to turn each triangle into 4. It's efficient to do this real-time, per frame, because taking a midpoint and setting it's magnitude is faster than a full transform, and won't cause a cache-miss because the data set is so small. (Reading from the simms costs at least 4 flops and can cost 10) Hidden surface removal can also be simplified for a sphere.

Let me know if you want more info or the inline transforms.
Quote this message in a reply
Post Reply