I just took a look at the glm source for projection
(gluPerspective equivalent) and noticed that the
fovy is divided by two in the tan calculation:
valType range = tan(radians(fovy / valType(2))) * zNear;
I guess range should be the half_height of the near
clipping plane so first I thought it is ok to divide by 2.
But then I remembered that fovy is already the half of the
fov (e.g. we pass 45.0f to the function instead of 90.0f).
So maybe someone can explain this additional division
by two inside glm::perspective?
Here everything makes sense for me, we convert to radians
with (2*PI/360.0) but we don’t divide by 2 since
fovyInDegrees is already the half of our fov.
The input value fovy IS not the half vertical fov.
It is the full vertical fov.
It seems there is some confusion about that because in most
examples on the web and also in many commercial game titles
a very low value (<= 45°) is passed to the function.
But this is not because we have to pass the half fovy.
It is because 90° looks ugly (distortion). I found a
discussion about that here.
Now that we know that fovy has to be the full vertical fov
I checked the other source on OpenGL.org again where
it was not divided by 2. According to the wiki history
some guy edited the related line. So I checked the
original source code glhlib2.cpp.
And guess what the original source does exactly what the
glm library does! So the guy who edited the wiki page
inserted a bug
if you do not know your MATH do not change wiki pages!
how again do you translate an angle from degrees to radians? what angle does pi stand for?
i will tell you: pi stands for 180°! so you multiply degrees by pi/180°!
and now if you draw the frustum described by the gluPerspective call you see that you have to use half the fov_y to calculate the left and right parameters for the glFrustum call to generate a symmetric frustum.
please change the code back so people do not suffer your absolute ignorance!
and: instead of running and gunning the OpenGL wiki page, you could read up on radians on wikipedia:
i overreacted after looking at the change without checking what you actually changed. i thought you changed it from (fovy / 2.0) * pi / 180.0, of what i think is clearer what actually is happening (the compiler will optimize out the constant parts). your previous posts made the impression you did not know how to get to the symmetric frustum parameters to glFrustum from the fovy because of your (to me) confusing first post. i thought the math was clear (basic trigonometry) and did not understand your problem with the glm code (where radians(x) does nothing more than x * pi / 180.0).
so i stand corrected. again i am sorry for the overreaction.