glm::perspective fovy question


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?

This is the gluPerspective equivalent:

ymax = tanf(fovyInDegrees * 2.0 * M_PI / 360.0) * znear;

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.

Or am I completely nuts?

Please enlighten me :slight_smile: Thanks!

I must say, I don’t know.

Have a look here, there is some details about the implementation og gluPerspective:…Perspective.htm

I just follow, how it was done in GLU for GLM implementation.

Guess what! I tracked down the reasons:

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 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! :slight_smile: So the guy who edited the wiki page
inserted a bug :wink:

I created an account there and reverted their changes to
the original source code. Now it should be correct again.

To make it short it was a bug on this wiki page that
lead to this confusion about fovy. Sorry!


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:

Sorry for the harsh tone, but something like this is beyond me.


Great digging Schnulla!

OMG what the hell are you talking about?
Of course PI stands for 180°.
And of course we know that we need half the fovy.

And guess what this is exactly what we do by multiplying
fovyDegrees with (PI / 360.0f). We convert to radians
AND divide by two.

(fovyDegrees / 2) * PI / 180.0 <=> fovyDegrees * PI / 360.0

So my correction on the wiki page was correct.
Now go back into your cage.

i think an apology is in order here.

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.


Oh well, fair enough Chris!
I believe that ‘overreaction’ is what passionate people do. :wink:

I agree, that was fair!