gluUnProject question

OpenGL OpenGL: Basic Coding
1

hi,

just a quick question on gluUnproject…

up until recently I thought that if i called something like


gluUnProject ((GLdouble) x, (GLdouble) y ,(GLdouble) 0, modelview, projection, viewport, &wx, &wy, &wz);

where the z-value equal to zero, this would correspond to the near-clip plane,

and if i called…


gluUnProject ((GLdouble) x, (GLdouble) y ,(GLdouble) 1, modelview, projection, viewport, &wx, &wy, &wz);

this would correspond to the far-clip plane,

i thought this the correct way until i ran into a problem using it,

if i use…


gluPerspective(45.0, aspect, 0.1, 200.0);

i run into problems setting z-value to 0 in gluUnProject for near clip plane, if i change it to 0.1 in gluUnProject call, however things work just fine,

this is the problem i had, if i translated my view, and this entailed a zoom factor, whenever i zoomed beyond the (0,0,0) mark or say beyond the z=0 mark, my results became erratic,sometimes totaly lost from the screen.

i am not quite sure what the problem was, but if anyone feels like indulging this, it would be appreciated.

2

sorry I dont understand fully but

the gluUnProject z value is the screen depth value
which goes from 0.0 -> 1.0
its not the value that u pass in the gluPerspective call
the faq or the ogl spec will shed light on what the equation thats applied to map the 0.1 -> 200.0 to 0.0 -> 1.0

3

yes that is exactly what i thought, and i guess it is correct, where 0.0 will be mapped to 0.1 which is near clip, and 1.0 will be mapped to 200.0 which is far plane, (or vice versa)…

anyway, my problem i am guessing is some kind of divide by zero, that is why setting it to 0.1 is fixing the problem, but i dont think it is a good idea to keep it like this, so i am going to go research some more and see if i can get to the bottom of it, i could post a sample from my code here to illustrate my problem, if anyone cares to help…

4

okay,

what i finally did to get gluUnproject to work in my code is to change from gluPerspective to glFrustum, and now gluUnproject is behaving, i have no clue why it was doing what it was,just really odd,

i have never used glFrustum and so i have read the man pages and tried to read up on other online docs, and then just experimenting with the settings,

perhaps somebody could give a tip as to how one would toggle the settings for glFrustum for a specific width/height ratio viewport to get a more or less good perspective,
from what i have tried to understand so far, for a given widthXheight resolution , you would need to set your left/right, top/bottom, so that the far plane is more or less the same dimension as widthXheight, is this correct?

i am goin to go experiment a bit more, but any advice appreciated.

5

gluPerspective(fovy, aspect, near, far);

should generate the exact same matrix as

glFrustum(-aspectneartan(M_PIfovy/360),aspectneartan(M_PIfovy/360),-neartan(M_PIfovy/360),neartan(M_PIfovy/360),near,far);

6

thanks for that, i actually also managed to find a simulated version of gluperspective that passes values into glfrustum,and that helped me understand it better

but thanks i am going to look at this as well, i really need to catch up on some of this math in any case, and just from the amount of reading i have done going over glFrustum, i think it is in my best interest to become a whole lot more comfortable with some of the math, …while using gluPerspective i just took a whole bunch of things for granted and when something went wrong, i didnt know where to start, but yeah, today has been a day of learning…

for interests sake


void gluPerspective(GLfloat fovy, GLfloat aspect, GLfloat zmin, GLfloat zmax)
{
 GLfloat xmin, xmax, ymin, ymax;
 ymax = zMin * tan(fovy * M_PI / 360.0);
 ymin = -ymax;
 xmin = ymin * aspect;
 xmax = ymax * aspect;
 glFrustum(xmin, xmax, ymin, ymax, zmin, zmax);
}

that helped me.

7

Maybe I’m wrong, but z value passed to gluUnProject is not relative to clip planes.
I’ve notice of this because in most of examples it’s obtained with glReadPixels, using a code like:

glReadPixels( x, viewport[3]-y, 1, 1,
GL_DEPTH_COMPONENT, GL_FLOAT, &z );

but note the function above return a value between 0 and 1, not related to clip planes, but to most far and the most near value in depth buffer (OpenGL 4 Reference Pages):

GL_DEPTH_COMPONENT
Depth values are read from the depth buffer. Each component is converted to floating point such hat the minimum depth value maps to 0 and the maximum value maps to 1. Each component is then multiplied by GL_DEPTH_SCALE, added to GL_DEPTH_BIAS, and finally clamped to the range [0,1].

So, if I’ve correctly understand, you can have, in example, a near-clip to 0, a far-clip to 200, a 3d plane polygon in 5 and a 3d plane polygon in 10: the depth buffer will be from 5 to 10, so these values will be mapped to 0->1, instead the clipping values.

Maybe???

8

So, if I’ve correctly understand, you can have, in example, a near-clip to 0, a far-clip to 200, a 3d plane polygon in 5 and a 3d plane polygon in 10: the depth buffer will be from 5 to 10, so these values will be mapped to 0->1, instead the clipping values.

Maybe???

Will you dig up every 4 month old unsolved thread?

To answer your suggestion that I am not sure to understand, depth values are always stored in the depth buffer in the [0 1] interval.
GL_DEPTH_SCALE and GL_DEPTH_BIAS are just scale and biais values that affect the read/write depth from/to framebuffer/texture operation.
For example, the when calling ReadPixels and reading depth values, these ones will be scaled, biaised and finally clamped to [0 1] before being written in the specified array.

The depth buffer does not adapt itself to the real depth range in the scene automatically. If you know that depth values are always between 5.0 and 10.0 then you can call glFrustum with this specific range.

9

It’s better don’t waste information. My question was in topic here, so why open a new thread?

To answer your suggestion that I am not sure to understand, depth values are always stored in the depth buffer in the [0 1] interval.
GL_DEPTH_SCALE and GL_DEPTH_BIAS are just scale and biais values that affect the read/write depth from/to framebuffer/texture operation.
For example, the when calling ReadPixels and reading depth values, these ones will be scaled, biaised and finally clamped to [0 1] before being written in the specified array.

The depth buffer does not adapt itself to the real depth range in the scene automatically. If you know that depth values are always between 5.0 and 10.0 then you can call glFrustum with this specific range.

To better explain my doubt, I’ve quickly done a sketch;

I know z buffer is always between 0 and 1, but reading the explanation here (that I’ve quoted in my previous post), it seem that glreadpixel normalize “z range 2” instead "z range 1.
I hope my question now is more clear (sorry for my bad english).
thx!

10

It’s better don’t waste information. My question was in topic here, so why open a new thread?

Your question is not totally related to the thread and not with its title. You are lucky that I re-read the thread from the beginning to understand what you are talking about. So you better create a new thread, there are many similar thread, so why use this one.

Anyway, glReadPixels does not normalizes depth range to the “z range 2” in your illustration. It just use the scale and biais you set in glPixelTransfer to transform retrieved values, nothing more. But if you want you can set the scale and biais values to fit your “z range 2”, you can do it, but I don’t see the usability, the best way is to directly set the right depth range in the glFrustum function and friends.

11

Thanks for reply.
And , next time, I’ll open a new thread :slight_smile: