Re: [Plib-devel] Ancient history....depth buffer queries

[Scott M. <mcm...@ca...>]

Steve Baker wrote:
> 
> Scott McMillan wrote:
> 
> > The OpenGL 1.1 manual says to use glGetFloatv for this enum...
> 
> No - it doesn't.  The OpenGL 1.1 'Blue Book' says:
> 
>   "Type conversion is performed if params has a different type
>    than the state variable value being requested."

Actually I meant to say "the 1.1 Red book implies...."

 
> However, it notes that:
> 
>   "If glGetIntegerv is called...most floating-point values are
>    rounded to the nearest integer value."
> 
> *most*?!?  Well, it goes on to explain that colours and normals
> are exceptions.
> 
> However, a bit later on:
> 
>   "GL_DEPTH_RANGE  params returns two values: the near and far mapping
>    limits for the depth buffer.  Integer values, if requested, are
>    linearly mapped from the internal floating-point representations
>    such that 1.0 returns the most positive representable integer
>    value and -1.0 returns the most negative representable integer
>    value.  The initial vlaue is (0,1)."
> 
> ...so, glGetFloatv should return (0,1) and glGetIntegerv should
> return (0,2147483647)

If I only had a blue book.....However on the 02 I don't get what
you state above.  I get something slightly different:

   (0,2147482496)  - not MAX_INT

> > The way I did get this to work is to sample the depth buffer as
> > GL_FLOAT (instead of int) and use the results of
> >
> >    glGetFloatv(GL_DEPTH_RANGE, z_vals);
> 
> ...but you need to multiply the results by MAX_INT before you plug them
> into my equation.

Actually no...after some brief units cancellation analysis, I think I
should do everything with floats as reported from GL_DEPTH_RANGE and
glReadPixels and get what appears to be a proper range value (within
the accuracy of the depth buffer, of course).  No multiplication by
MAX_INT is necessary.  Here is my code:

        GLfloat depthRange[2];
        glGetFloatv(GL_DEPTH_RANGE, depthRange);

        GLfloat *depthData = (GLfloat *) malloc(sizeX*sizeY*sizeof(GLfloat));
        glReadBuffer(GL_BACK);
        glReadPixels(0, 0, sizeX, sizeY,
                     GL_DEPTH_COMPONENT, GL_FLOAT, depthData);

        for (a given index into the depthData array)
        {
                float dz = depthRange[1] - depthRange[0];
                float dp = farClip - nearClip;

                float range =
                    -((farClip*nearClip*dz)/dp)/
                    (depthData[index] - ((farClip + nearClip)*dz)/(2.0*dp) -
                     (depthRange[1] + depthRange[0])/2.0);
        }

If I am misunderstanding your last statement please clarify with
some math.

> > I still need to do timing to see if sampling the depth buffer as
> > GL_FLOATs incurs an extreme penalty (not sure I have much choice
> > though as I need not only a cross platform solution but a cross
> > OpenGL driver solution).
> 
> Well, reading back the Z buffer is always expensive - it's just
> a matter of degree!

When they want a depth buffer image, you don't have too many
choices.  I was wondering if there was an extra penatly incurred
by reading floats instead of ints.  I am not really sure where
to go to read up on technical aspects of the depth buffer and
read backs.

scott

P.S. should we take this discussion off-line...it is straying a
bit from PLIB development?

-- 
Scott McMillan                        mailto:mcm...@ca...
Cambridge Research Associates         http://www.cambridge.com
1430 Spring Hill Road, Ste. 200       Voice: (703) 790-0505 x7235
McLean, VA 22102                      Fax:   (703) 790-0370