OpenGL gluUnProject() pixelDepth question
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?
Code:
result = gluUnProject( windowX, // window coordinates (Input values)
windowY,
pixelDepth, // 1.0 = far clipping plane, 0.0 = near clipping plane
modelView,
projection,
viewPort,
&worldX, // world coordinates (output values)
&worldY,
&worldZ ); // Red Book p. 152
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.
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:
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?
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.
Possibly Related Threads...
Thread:  Author  Replies:  Views:  Last Post  
gluUnproject implementation  TomorrowPlusX  3  10,835 
Sep 19, 2006 08:27 AM Last Post: TomorrowPlusX 

gluProject <> gluUnproject help please  szgezu  9  7,758 
Feb 26, 2006 11:50 AM Last Post: szgezu 

Help with mouse click position to OGL coords using gluUnproject  hyn  14  14,881 
Aug 6, 2004 07:57 AM Last Post: GioFX 

An OpenGL Question  Justin Brimm  1  2,525 
Dec 13, 2002 03:38 AM Last Post: OneSadCookie 