ogl spec from 3.0 to the latest version mentions about api glCopyPixels’s type being GL_DEPTH_STENCIL
- Why is format STENCIL INDEX when DEPTH_BITS is no-zero?
- Why is format DEPTH COMPONENT when STENCIL_BITS is no-zero?
- Why does DEPTH_BITS and STENCIL_BITS both have zero and still need to do a copy operation?
The table is correct (if redundant.) See Issue 7 in EXT_depth_stencil.
Sorry, maybe I missed something.
“For example, if the framebuffer has non-zero DEPTH_BITS but zero STENCIL_BITS, then ReadPixels of DEPTH_COMPONENT is legal. But ReadPixels of DEPTH_STENCIL_EXT will generate INVALID_OPERATION.”
When DEPTH_BITS is non-zero, we should read pixels for
GL_DEPTH_COMPONENT . Isn’t it exactly opposite to what the table describes?
Hope to receive your answer.
glCopyPixels operation with a type of
GL_DEPTH_STENCIL generates a
GL_INVALID_OPERATION error unless both the source and destination framebuffers have both depth and stencil buffers. It doesn’t silently ignore missing buffers.
If either buffer is missing (zero bits), then a type of
GL_DEPTH_STENCIL acts as if you attempted to read the missing buffer (generating an error). It doesn’t act as if you’d attempted to read the buffer which actually exists (silently ignoring the missing buffer).
But what does this table mean? When STENSIL_BITS is zero,we should ReadPixels(STENCIL_INDEX)?Emmm,It looks like this.
That is correct. If you try to read DEPTH_STENCIL, without a stencil buffer, then it acts as if you called glReadPixels with STENCIL. Which throws INVALID_OPERATION.
Similarly with depth.
The only interesting part of the table is when both depth and stencil are missing, in which case if acts as if you called glReadPixels with DEPTH_STENCIL, which still throws INVALID_OPERATION. So, the entire table is redundant-- it could always act as if you call glReadPixels with DEPTH_STENCIL. It will always error, unless both depth and stencil buffers are non-zero.
The table is correct, but redundant.