Camera Frustum calculation


In the AbstractCamera::setFrustumPerspective() method, the frustum top and bottom are computed using the following code:

float h = FastMath.tan( fovY * FastMath.DEG_TO_RAD ) * near * .5f;
frustumBottom = -h;
frustumTop = h;

I don't understand this line: if fovY is the entire angle, I think the line should be float h = FastMath.tan(fovY * 0.5 * FastMath.DEG_TO_RAD) * near;
Could someone explains me why it's done like that? Or is it an error?


It's not the half of the angle but the half of the height, which is needed. So the formula is correct (and your's is not, btw - it makes a difference).

Thanks for your answer Irrisor,

I understand that we need the half of the height, but if fovY is the entire angle, I think that tan(fovY) * near doesn't compute the height:

Could you explain me a little more? Where is it the mistake in my scheme?  :?

Thanks :)

Actually, I think he's correct.  It has not come up before because the end result for the standard value (45degrees) ends up being pretty close.  Since our frustum calcs are based on the frustum* values, it did not hurt the bounding checks or anything either, so really how many people would be able to tell you that they were seeing 53 degrees instead of 45?

I want to confirm this bug. The *.5 should be inside tan(), not outside. Just set the fov to 120, and without this fix the view will become junk.

See these pages:

Not related to this but i cant figure out why if i use LWJGLCamera.lookAt and then get the view matrix back from OpenGL, i get different result than when i try to calculate the viewmatrix myself as described here:

Anyone got an idea on this?

Why isn't this bug fixed? I had issues with my implementation of shadow mapping because of the bug. See post

I can confirm it was fixed months ago and is in 2.0…  I don't have the old 1.0 code in front of me, so maybe it is not corrected there.

Ok, I haven't switched to 2.0 yet so that's the problem then. Sorry for that.

there is no point in switching yet, i'm sure it will be fixed in jme 1.0 too very soon (its still not)

I recall that I did not change it in jme 1.0 because it would change the behavior of everyone's projects that use 1.0 jME.  Yes, it is an error that makes the FOV incorrect, but perhaps people have coded to the results rather than the expected behavior?  Thoughts? Perhaps that is not a big deal.

This is possibly a good example of when using a versioning system could assist. The current 1.0 version could become 1.0Final and a new version started 1.01 with this change in.