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

[Steve B. <sjb...@ai...>]

Scott McMillan wrote:

> In answer to a previous question: This is an OpenGL question and
> not a Performer one.

OK - I gave the Performer answer because you mentioned that you'd
seen something of mine on the Performer mailing list...and also because
I can't think of any occasion where I've actually done this in raw
OpenGL.
 
> I have been having problems with the approach below on one piece
> (so far) of NT/PC hardware:
> 
>    the AccelGalaxy card and/or its OpenGL driver.
> 
> The culprit is the following piece of code that I am not sure is valid
> OpenGL code:
> 
>    glGetIntegerv( GL_DEPTH_RANGE, z_vals ) ;

Yes - I have to say that this *looks* like it should be glGetFloatv,

> 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."

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)

> ..., and
> AccelGalaxy drive truncates the floating point values to ints and
> reports 0 and 1 for near far (where as an SGI O2 would report 0 and
> something close to MAX_INT).

Exactly.  So the AccelGalaxy OpenGL is buggy - presumably because someone
didn't read the fine print about this peculiar exception to the glGetInteger
rules.

> 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.
 
> 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!

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)