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  
opengl view question  Leroy  3  3,920 
Jul 23, 2007 11:08 PM Last Post: AnotherJake 

2d opengl lighting question  Leroy  9  8,175 
Jul 21, 2007 11:41 PM Last Post: OneSadCookie 

gluUnproject implementation  TomorrowPlusX  3  11,594 
Sep 19, 2006 08:27 AM Last Post: TomorrowPlusX 

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

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