Could you add a frustrum definition method comparable to the gluPerspective function? It’s very handy to think of the frustrum in terms of FOV. I could call the GLU function directly, but my guess is that would break correct frustrum culling.
I was also going to request the possibility of defining an infinitely distant clipping plane, but I’m not sure. I’m implementing shadows as described in Practical and Robust Shadow Volumes. Their algorithm uses an infinite far clipping plane to ensure that the caps of the shadow volumes don’t get culled (which makes the technique unusable).
I think a simple solution for the meantime, is to put the onus on the programmer by requiring that he or she define a far plane that is guaranteed to be beyond the shadow volume caps - whose distance could be controlled by a parameter shadow generator.
I’m currently imagining a shadow bounding box. It would be the programmer’s responsibility to ensure that the far plane is always more distant than back of the shadow volume, regardless of the camera’s position. (On a Quake-like game, that would be easy, by specifying a far plane as large as the level.)
Could you add a frustrum definition method comparable to the gluPerspective function? It's very handy to think of the frustrum in terms of FOV. I could call the GLU function directly, but my guess is that would break correct frustrum culling.
I'll have to think about how to do it properly. The frustum of the camera, the same frustum for culling, etc, is defined by the left, right, bottom, top, near and far values. Using gluPerspective does not deliver those values very easily.
I think a simple solution for the meantime, is to put the onus on the programmer by requiring that he or she define a far plane that is guaranteed to be beyond the shadow volume caps - whose distance could be controlled by a parameter shadow generator.
Play around with it and see if you come up with a solution that would make sense to merge up into the base camera class. If it's simply a matter of insuring "far" is the size needed, then there's no change required.
laugh The irony is that it’s precisely the difficulty of the conversion that makes gluPerspective so useful! If I could get my head around what the frustrum parameters even meant I’d contribute something myself.
I have an idea about this, I’ll keep you posted.
Ok, that didn’t work out. I thought I could figure out the conversion based on the matrices created by the different functions based on the reference guide. No luck. For now, you’re going to have to use frustum, the redbook explains how to use it very well. I will keep my eye out on how to convert fovy, aspect, zNear and zFar into left, right, bottom, top, near and far. That’s all I was going to do inside the method. I’ve posted on the newsgroups, etc. We’ll see if I get anything.
Ok, I finally figured out how to do this properly. So now you can set the perspective of the camera using the jME equivalent to gluPerspective called setFrustumPerspective…
cam.setFrustumPerspective(45.0f,(float)display.getWidth()/(float)display.getHeight(), 1,1000);
Hey Mojo, your add of this to SimpleGame makes everything a bit stretched out in my game now… any ideas? I’m using simplegame for a few tech proofs.
fixed…
it had display.getWidth()/display.getHeight() instead of
(float)display.getWidth()/(float)display.getHeight(), so there was a round off error for the aspect ratio.
Awesome, thanks very much mojo!