Does anyone know the way a typical (uncompressed) depth buffer stores data?
Is it a floating point number?
Does it store distance or inverse distance?
Is the near clip plane the lowest value, and the far clip plane the largest?
What happens when the clip planes are changed while rendering one scene to the depth buffer? Does this screw things up?
Thanks for any info
Krylloan
To the first questions, I don’t know the answer. To the last :
>What happens when the clip planes are changed while rendering one scene to the depth buffer? Does this screw things up?<
Nothing, and this is a very useful technique for rendering wide scenes having both very near and very far objects. I believe that most games do it.
Hope this helps
Morglum
[This message has been edited by Morglum (edited 03-24-2002).]
For the first questions, the answer might be that it depends of the hardware you use. However, that should be transparent to you.
Morglum
[This message has been edited by Morglum (edited 03-24-2002).]
For the first question, as Morglum says, it depends on the hardware. Since you don’t have direct access to the depth buffer, there is no reason why you should know it.
Originally posted by Morglum:
[b]
>What happens when the clip planes are changed while rendering one scene to the depth buffer? Does this screw things up?<
Nothing, and this is a very useful technique for rendering wide scenes having both very near and very far objects. I believe that most games do it.
[/b]
Is this true? If the near and far clip planes are moved, then aren’t the Z values computed differently and couldn’t far objects be drawn on top of near objects?
It could see it working if you draw groups back to front and clear the Z-buffer in between each group.
[This message has been edited by Jambolo (edited 03-24-2002).]
Originally posted by Bob:
For the first question, as Morglum says, it depends on the hardware. Since you don’t have direct access to the depth buffer, there is no reason why you should know it.
I can think of one reason: when you want to read the depth buffer, its better to know the format. I myself dont know what’s typically used. I’m guessing its not in float. Sometimes it is 16 bit, sometimes 24, and rarely 32 bit.
Example:
For the color buffer, if your screen is in 32 bits, then reading with GL_RGBA8 and GL_UNSIGNED_BYTE (GL_BYTE) will be fastest.
V-man
Jambolo, not if you draw things in the proper order. Split the depth range into segments and draw the segments from farthest to nearest, clearing the depth buffer for each segment.
[This message has been edited by DFrey (edited 03-24-2002).]
Yes, that’s what I was thinking of.