Perspective Projection

[Benjamin100]

For some odd reason my perspective projection matrix is not working.
I created it as an array, with the second to last element being -1/2.
I applied it in the vertex shader, which compiles without error,
but nothing shows on the screen.

One thing that isn't clear in what I've read is whether the vector automatically divides by w when given the final position, or whether that must be written into the vertex shader. I assumed I had to do it myself, so I did.

[short]

1. go here:
http://cpp.sh/

2. reduce your code to as small as possible:
post a link to that here, we'll be able to help easier.

[Benjamin100]

Ugg. I had left this program for a week and came back to it again, only to realize I wasn't testing to see if the perspective uniform was working. I put in an error message and it came up.
That makes sense, as nothing would show no matter how I used it. Once I figure out what is missing I will see if it works.

EDIT: Nevermind. That was because I had taken out the perspective so that I could test other transforms.
That wasn't the problem. I'm going to play around with this a bit more before I'll even know what code I think is causing the problems.

[Benjamin100]

Should I have not tried making my own projection matrix? Should I have just used the GL math functions? I'm beginning to think that would be wiser.

[dandymcgee]

Should I have not tried making my own projection matrix? Should I have just used the GL math functions? I'm beginning to think that would be wiser.

While deriving the projection matrix mathematically is somewhat difficult, defining your own projection matrix isn't all that hard. The full derivation can be found here: http://www.songho.ca/opengl/gl_projectionmatrix.html

The simplified result (where projection center = screen center, almost always the case in games) is this:

Let r = screenWidth / 2.0f
Let t = screenHeight / 2.0f
Let f = far plane (Z)
Let n = near plane (Z)

Projection matrix can be calculated as follows (ignore the top part, just pay attention to the matrix):


In case link dies:

Code: Select all

[n/r,   0,            0,                   0]
[  0, n/t,            0,                   0]
[  0,   0, -(f+n)/(f-n), -2.0f * f * n/(f-n)]
[  0,   0,           -1,                   0]

But yes, it's a lot easier to use a decent math library. GLM http://glm.g-truc.net/0.9.4/index.html can do this for you via one of following methods:

glm::perspectiveFov http://glm.g-truc.net/0.9.4/api/a00151. ... e5406517d7
glm::perspective http://glm.g-truc.net/0.9.4/api/a00151. ... 5daf22560f
glm::frustum http://glm.g-truc.net/0.9.4/api/a00151. ... ba99131299

Look at their parameters to determine which one is the best for your situation.
All of these methods return a matrix4 which you can then pass to your vertex shader via uniform.

One thing that isn't clear in what I've read is whether the vector automatically divides by w when given the final position, or whether that must be written into the vertex shader. I assumed I had to do it myself, so I did.

Positional vector w should always be 1. Directional vector w should always be 0. If you set it to anything other than 1, your projection matrix is likely not going to work as expected.

[Falco Girgis]

Should I have not tried making my own projection matrix? Should I have just used the GL math functions? I'm beginning to think that would be wiser.

No, you definitely should be doing your own, as I think the built-in OpenGL ones are being obsoleted.

There really isn't enough information here to help you. We need to see your actual matrix and your shader. As Dan said, the w is required for perspective division, so if that's zero, you're going to have a big problem (unless you're doing an orthographic projection, in which case it doesn't matter). You may also be getting the matrix right, but you've chosen something incorrectly as your near and far planes resulting in your submitted vertices not even mapping into the view frustum...

[dandymcgee]

I also just realized I accidentally posted the orthographic matrix on my first post. I didn't realize that page was showing both. It has been edited to properly reflect a perspective projection matrix.

It's also worth noting that, depending on how you're storing it in memory, you may need to transpose this matrix when you send it to the shader via uniform. In addition, the order in which you multiply your transformation matrices with each other is significant, because matrix multiplication is not commutative.

[Falco Girgis]

It's also worth noting that, depending on how you're storing it in memory, you may need to transpose this matrix when you send it to the shader via uniform. In addition, the order in which you multiply your transformation matrices with each other is significant, because matrix multiplication is not commutative.

Yeah, very good points I forgot to mention... Shit's column-major in GL.

[Benjamin100]

Thanks Dan, the matrix you showed helped.

I just had a really simple matrix set up with the final "-1".

I'd seen the other matrix before in my book, but I assumed it wasn't necessary. I'm not sure why. It seemed like all I was really doing was dividing by the z, so I should only need to change that second to last number to achieve the general effect. I wasn't thinking about the view area at all.

[Benjamin100]

It's also worth noting that, depending on how you're storing it in memory, you may need to transpose this matrix when you send it to the shader via uniform.

Why would I need to change it?
Does GLM not use the same standard for matrices?

[dandymcgee]

It's also worth noting that, depending on how you're storing it in memory, you may need to transpose this matrix when you send it to the shader via uniform.

Why would I need to change it?
Does GLM not use the same standard for matrices?

There's some discussion here about the common confusion: http://stackoverflow.com/questions/1771 ... lumn-major

Basically, depending on what order you (or your library) load your matrices into RAM (matrices are stored as 16 contiguous values), you may have to multiply them in a different order to get the expected result. If your transformations are completely fucked up and you can't figure out why, try multiplying them in reverse order and see if it fixes it. The glUniform functions take a parameter (GLEnum transpose: GL_TRUE or GL_FALSE) which tells OpenGL to automatically transpose the matrix when it loads it into VRAM for use by your shaders. Just be mindful that order matters when working with matrices.

[K-Bal]

If your transformations are completely fucked up and you can't figure out why, try multiplying them in reverse order and see if it fixes it.

I have to do this EVERYTIME I'm setting up some matrices because my brain is just not able to visualize all this shit at once.

[Benjamin100]

Well now I'm completely confused. Been trying to make it work, but ever since I changed one number around it has been acting odd.
If I decide it does need to be in a different order, should I also transpose with the uniform function?

[K-Bal]

Well now I'm completely confused. Been trying to make it work, but ever since I changed one number around it has been acting odd.
If I decide it does need to be in a different order, should I also transpose with the uniform function?

The matrix that stands closest to your input vertex in the multiplication will be applied first. Therefore, your model-view matrix should be the inner and the perspective matrix the outer one:

Code: Select all

v_transformed = P * MV * v

P  = Perspective matrix
MV = Model-view matrix
v  = Input vertex

Stick with this order and transpose your matrices if necessarry.

Edit: You will very probably either transpose both or neither matrices at the same time.

[dandymcgee]

If your transformations are completely fucked up and you can't figure out why, try multiplying them in reverse order and see if it fixes it.

I have to do this EVERYTIME I'm setting up some matrices because my brain is just not able to visualize all this shit at once.

Yeah.. and then you start doing camera transformations where everything is reversed yet again. Takes some patience and careful thought to make sure everything is working the way it's supposed to. :P