Jump to content
  • Advertisement
Sign in to follow this  
matthewwithanm

Projection Matrices help.

This topic is 4576 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm trying to project points from 3D space onto the screen using transformation matrices, as outlined in Wikipedia's 3D Projection article (http://en.wikipedia.org/wiki/3D_projection). Since the camera is stationary, and always at the same angle, the camera transform matrix simplifies to I, so I'm only concerned with the world transformation. My understanding is that the X, Y, and Z of the translation matrix are the coordinates of the point around which I am rotating. Only the Z coordinate seems to have no effect. For example, consider a point P = (0, 0, 100) with an x-rotation of a = PI / 2 radians and a translation matrix T = 1 0 0 0 0 1 0 0 0 0 1 100 0 0 0 1 Shouldn't the coordinate of the projection be (0, 0)? Instead, it's (0, 100) -- no matter what the Z value in my translation matrix. Am I misunderstanding the translation matrix? And if so, how do I define the center of rotation? What effect SHOULD the z value of the translation matrix have? Thank you so much for your help with this. It's greatly appreciated. matthew

Share this post


Link to post
Share on other sites
Advertisement
Thinking of the translation matrix as the point around which an object rotates isn't the best interpretation, because it's ambiguous. For instance, the Earth rotates around its own center axis, but it also rotates around the Sun. So which rotation would we be talking about? Mathematically, the difference is in the order of transformations. If you do TRv (T = translation, R = rotation, v = point), then you get the Earth rotating around its axis. If you do RTv, you get the Earth rotating around the Sun. And if R = I (no rotation), then it's even more unclear.

There could be a number of reasons why the projection isn't correct. Any one of the transformation matrices could be wrong, the order of transformations could be wrong, or the initial point v could be in the wrong initial frame. If you could show us what each of your transformation matrices are, and in what order you're applying them, that might shed some light on the situation.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zipster
Thinking of the translation matrix as the point around which an object rotates isn't the best interpretation, because it's ambiguous.


Sorry, I was just assuming the order that the Wikipedia article presents.

Quote:
If you could show us what each of your transformation matrices are, and in what order you're applying them, that might shed some light on the situation.


Thanks for the response. I'm using the matrices outlined in the Wikipedia article (http://en.wikipedia.org/wiki/3D_projection), though since my camera is stationary, the camera tranformation matrix simplifies to I.

The problem isn't in my matrices -- they've been checked and rechecked -- it's in, I believe, my interpretation of the process. I think you can probably clear it up for me in about five seconds, though. Consider a transformation TRv. Where T is of the form

1 0 0 x
0 1 0 y
0 0 0 z
0 0 0 1

What is (x,y,z)? If I'm correct in my thinking, it's the center of rotation of "earth." (Or is (-x, -y, -z) the center of "earth".)

Now consider the transformation TRv. Is (x,y,z) now the position of the sun?

Thanks for all the help.

Share this post


Link to post
Share on other sites
A rotation matrix always rotates around the "current origin" of the coordinates' system.
Suppose you've got a mesh whose vertices are expressed with respect to its own center and axes, the model space. (this is the case usually) If "v" is one of its vertices, then applying a rotation matrix, R*v, would result in the model being rotated around its own center. E.g., you could implement earth's rotation around its own axis this way.

The axis of the rotation is defined by the rotation matrix. So what happens if you want to rotate around the same axis but with a completely different point for pivot?
To implement such a rotation you must first translate the origin to the new pivot point, and then apply the rotation; This transformation would look like T-1*R*v, where T is the matrix

[ 1 0 0 Pivot.x ]
[ 0 1 0 Pivot.y ]
[ 0 0 1 Pivot.z ]
[ 0 0 0 1 ]

(Its inverse is the very same, with the Pivot negated)

The fact that matrix multiplication is not generally commutative, is very helpful in understanding how the transformation you want to achieve should look like, because matrices closer to the vector (e.g. in a product like in C*B*A*v) are applied prior to the others.
With this in mind, it is easy to see that if you want to translate an object in space and rotate it around one of its own axes, you have to rotate first and then translate, because the translation would change the pivot of the rotation.
Thus you should transform the object with the product T*R.
Using the product R*T would result in the object being rotated on an arc centered at the pivot point, which is a totally different effect.

Similarly, if you want to rotate a model (the earth) around its own axis and around the sun, you should use the product R2*T-1*R1, where R1 is the rotation around the earth's axis, T is the aforemenentioned translation matrix for Pivot=the sun's world coordinates, and R2 is the rotation matrix for the rotation of earth on its orbit.

Share this post


Link to post
Share on other sites
Quote:
Original post by matthewwithanm
The problem isn't in my matrices -- they've been checked and rechecked -- it's in, I believe, my interpretation of the process. I think you can probably clear it up for me in about five seconds, though.

I've adopted a simple interpretation that works for me when dealing with transformations. The first key isn't to look at the transformations from "left to right" or "right to left", because the order of transformations changes based on whether you're using row or column vectors. For instance, the TRv transformation with column vectors is the same as vRT with row vectors, so if you're reading the transformations in a certain direction your interpretation isn't consistent. You always want to read them either from "closest to farthest" or "farthest to closest", relative to the vector. So with TRv, R is the closest to v, and T is the farthest from v, and that doesn't change with vRT.

Your interpretation of the transformation then depends on how you read it. If you go with the "closest to farthest" method, then each transformation is separate and distinct, always relative to the world coordinate frame. In essence, you can think of the transformations as having no cumulative effect. For instance, when you do TRv, first you perform a rotation relative to the world frame. Then you perform a translation relative to the world frame. The world frame doesn't change, it stays fixed. So no matter how much rotation you did, you would always translate to the same spot. Using the solar system analogy, this would be the Earth spinning around its axis at some fixed location in space. Conversely, if you had the RTv transformation, the Earth would first be translated out into space. Then it would be rotated around the world frame. Thus the Earth rotates in an orbit. The reason this interpretation works the way it does is because transformations closest to v don't have to "go through" the other transformations first to get to v. So with TRv, R is right next to v and doesn't have to worry about T first. You could replace Rv with v', and the transformation becomes Tv'. To T, it's as though R never existed. Same with any arbitrary transformation ABCDEFGv. Gv becomes v', and ABCDEF are none the wiser. Replace Fv' with v", and ABCDE don't have a clue. Continue so on and so forth until you have Avn. This is why the transformations aren't cumulative in this interpretation.

Meanwhile, if you go with "farthest to closest", then the transformations are cumulative and always relative to the "updated" local frame. Expanding upon my previous explanation, this is because with ABCDEFGv, for A to get to v it has to go through BCDEFG first. So replace AB with A', to form A'CDEFGv. But now A' has to go through CDEFG to get to v. Thus the transformations accumulate. Given TRv, the first transformation is the translation, which translates the local frame out into space. The rotation is now relative to the updated local frame, but since it's now out into space somewhere, it just spins around itself. This also gives you the effect of the Earth rotating around its axis, even though the interpretation is completely different. Same with RTv. The local frame is first rotated. The translation is then relative to the local frame, which is "tilted", so you move along the tilted frame. This gives you the effect of the Earth rotating in an orbit.

The interpretations are interchangeable as you get the same end effect with either one (after all, the interpretation is just a way of thinking about things and has no affect on the final result), but sometimes one is easier to work with than the other. For instance, I find the the "closest to farthest" interpretation works best with the world-to-NDC transformation pipeline. You first want to perform the world transformation, so you have Wv. Then you want to perform the camera transformation, but it doesn't need to know anything about the world transformation, so you have CWv. Then you have the perspective transformation, which doesn't care about the world or camera transformations, giving you PCWv. So now you've built the transformation from this interpretation. How would you have done this if you interpreted the transformations as being cumulative? The first transformation then becomes the perspective transformation, and you somehow have to think of the other transformations as "building off each other" from then on. It just makes more sense to work the other way around. On the other hand, if you're working with skeletal animation hierarchies, it makes more sense to use the cumulative interpretation, because each level of transformations is affected by the transformations above it, so if you want to get the position of a character's hand it's easier to think of it as being cumulative from the position of the charater's pelvis, to his shoulder, to his elbow, to his wrist, to his hand.

This might take your brain a while to get used to, if you like how I see things. I know it took me a few months before I got everything straightened out [smile]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!