Sign in to follow this  

The edge of the screen isn't where it should be?

This topic is 4726 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

First, my question is how does the x value get devided by element[1, 1] of the projection matrix. If you can answer that please just write your response now. Otherwise, please read on to figure out what I mean. The projection matrix is set up with a call to gluPerspective(fovy, aspect, zNear, zFar) f = cotangent(fovy/2) f/aspect, 0, 0, 0 0, f, 0, 0 0, 0, (zFar+zNear)/(zNear-zFar), (2*zFar*zNear)/(zNear-zFar) 0, 0, -1, 0 Sorry if I can't write the matrix that clearly but I can't scan in a picture or anything to make it look better. When you multiply this by your coordinates [x, y, z, w] transposed, you get the fallowing: [x*f/aspect, y*f, z*(zFar+zNear)/(zNear-zFar) + w*(2zFar*zNear)/(zNear-zFar), -z] transposed. The z*(zFar+zNear)/(zNear-zFar) + w*(2zFar*zNear)/(zNear-zFar) is used for clipping out objects too far away. The projection matrix is multiplied with this orthagonal matrix: 1, 0, 0, 0 0, 1, 0, 0 0, 0, 0, 0 0, 0, 1, 0 The result looks like this [x*f/aspect, y*f, 0, -z]. Finally, perspective division yields what we're used to seeing [x/z*f/aspect, y/z*f, 0, 1]. Here's what is strange set f equal to cottan(45/2) and the aspect to .75. This means that f/aspect is approximatly .55228 which is what x is multiplied by. If x is equal to 1 and z is equal to -1, our rastorized x coordinate comes out to .55228. If the right side of the screen represents 1 and the left side -1 this puts us at about 3/4 of the way across the screen, but it doesn't. Instead, x = .55228 is the very edge of the screen when z = -1. This means that instead of being multiplied by .55228 it is being devided by it. The y coordinate has a simular thing happening. I cannot figure out why. Anyone know why?

Share this post


Link to post
Share on other sites
I think your projection matrix is incorrect, using the same variable names as the one you gave above i believe it should look like this (i am using the one below aswell)


f / aspect, 0, 0, 0
0, f, 0, 0
0, 0, -(zFar + zNear) / (zFar - zNear), -1
0, 0, -2 * zNear * zFar / (zFar - zNear), 0


EDIT: if you want to see how it is setup with gluPerspective you can download the Mesa 3d library source and have a look, i believe it'll be something like i posted above

HTH

Share this post


Link to post
Share on other sites
I got the projection matrix information off of a man page in a quick internet search. Here's the site www.hmug.org/man/3/gluPerspective.html. Of course, the page could always be wrong. There's an easy way to find out though. I'm gonna grab the matrix and print each value. Hehe.

Share this post


Link to post
Share on other sites
Your projection matrix is correct. nts's is just transposed (but if written like that as a C-style array it would be correct due to the memory layout used by OpenGL).

Enigma

Share this post


Link to post
Share on other sites
Quote:
Original post by binarybob0001
First, my question is how does the x value get devided by element[1, 1] of the projection matrix. If you can answer that please just write your response now. Otherwise, please read on to figure out what I mean.
The projection matrix is set up with a call to gluPerspective(fovy, aspect, zNear, zFar)
f = cotangent(fovy/2)
f/aspect, 0, 0, 0
0, f, 0, 0
0, 0, (zFar+zNear)/(zNear-zFar), (2*zFar*zNear)/(zNear-zFar)
0, 0, -1, 0
Sorry if I can't write the matrix that clearly but I can't scan in a picture or anything to make it look better.
When you multiply this by your coordinates [x, y, z, w] transposed, you get the fallowing: [x*f/aspect, y*f, z*(zFar+zNear)/(zNear-zFar) + w*(2zFar*zNear)/(zNear-zFar), -z] transposed. The z*(zFar+zNear)/(zNear-zFar) + w*(2zFar*zNear)/(zNear-zFar) is used for clipping out objects too far away. The projection matrix is multiplied with this orthagonal matrix:
1, 0, 0, 0
0, 1, 0, 0
0, 0, 0, 0
0, 0, 1, 0
The result looks like this [x*f/aspect, y*f, 0, -z]. Finally, perspective division yields what we're used to seeing [x/z*f/aspect, y/z*f, 0, 1].
Here's what is strange set f equal to cottan(45/2) and the aspect to .75. This means that f/aspect is approximatly .55228 which is what x is multiplied by. If x is equal to 1 and z is equal to -1, our rastorized x coordinate comes out to .55228. If the right side of the screen represents 1 and the left side -1 this puts us at about 3/4 of the way across the screen, but it doesn't. Instead, x = .55228 is the very edge of the screen when z = -1. This means that instead of being multiplied by .55228 it is being devided by it.
The y coordinate has a simular thing happening. I cannot figure out why. Anyone know why?


I do not know much about this stuff - but I do see a few math problems that might be messing you up.

: f = cotangent(fovy/2) ==> f = cotangent(fovy/2.0f)
: f/aspect, 0, 0, 0 ==? (float)f/(float)aspect, 0, 0, 0 // just in case!

I'd just make sure all the operations are using floats, just to be sure.

Share this post


Link to post
Share on other sites
Yes, when I'm programming I should indicate that I'm dealing with floats. I'm just trying to figure out exactly what happens mathematically, and in math we usually assume an infinite precision real or complex number system. My math is probably wrong, and I really, really want to know why. So if anyone has a book that explains everything or knows the name of a book then please post or cite it here. Thanks.

Share this post


Link to post
Share on other sites
I'm not sure if this answers your question, but the vector in eye coords (after the modelview transform) gets multiplied by the perspective matrix to give clip coords. This 4-element vector is then divided by its W value (the perspective divide) to get normalised device coords. See The red book, chapter 3.

You probably already know this, but remember that OpenGL matrices are column-major order, unlike most maths texts.

Share this post


Link to post
Share on other sites

This topic is 4726 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this