I've read lots of documentation regarding gluUnproject(). I've got a perspective projection with the following call to gluUnProject().



and when I use values of 0.0 and 1.0 for the 3rd parameter, I get world coordinates that lie on the near and far plane. I then tried values between 0.0 and 1.0, and got values world values that lied between worldZ (near) and worldz (far). So far so good.

Because I could get no information on how gluUnProject() handles pixelDepth < 0.0 and pixelDepth > 0.0, I went ahead and tried some of these values. I was expecting garbage or undefined values, but instead I got values that fell into the range of [0.0, 1.0].

Was this just lucky happenstance or do values (>1.0 or <0.0) have some esoteric uses?

The input to gluUnProject is a depth buffer value. As you've found, 0.0 is near, 1.0 is far, values outside that range are meaningless, and it's potentially useful (though slow!) to glReadPixels() a single depth value to pass in.

The usual way to use gluUnProject is to call it twice, once with 0.0; once with 1.0. That gives you back the endpoints of a line segment in your world space, which you can analytically intersect with your geometry to determine what was clicked.

Does your comment:

Quote:and it's potentially useful (though slow!) to glReadPixels() a single depth value to pass in.

refer to:

glReadPixels(winX, winY, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &windowZ);

If so, why is this potentially slow. Aren't we just asking the Depth Buffer to return a value of one if its elements?

It's not really the amount that you are sending, it's the fact that you have to synchronize the cpu and gpu (a pretty big stall) in order to transfer.