FBO, Depth texture and Frustum

[krazanmp]

Hi, I have a deferred rendering solution that uses an FBO RTT to render the scene data into.

One of the attached textures is the depth buffer, which SEEMED to work until I noticed that if I change the characteristics of the camera's frustum, the actual values of the depth texture don't change. I have verified this by moving the far clip plane, and reviewing the resulting depth texture. It doesn't change.

What is weird, that the far clip plane does clip the geometry that is being still rendered to the depth texture.

What am I missing?

[Dark Photon]

...if I change the characteristics of the camera's frustum, the actual values of the depth texture don't change. I have verified this by moving the far clip plane, and reviewing the resulting depth texture. It doesn't change....What am I missing?

Are you sure about that?

Assuming you have a std 32-bit depth+stencil buffer, try reading it back as:

    glReadPixels( 0, 0, xres, yres, GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8, buf );

and look at the actual fixed-point values ( pix >> 8).


Rendering a plane right in front of the near clip plane and look at its fixed-point depth value.

Then halve the distance to the near clip plane, render the plane at the same eye-space Z value as before, and then look at its fixed-point depth value.

If still problems, post some specific number (i.e. near/far values with the eye-space Z input values and the fixed-point Z readback values).

[krazanmp]

I am actually rendering the image overlaid on the rendered scene and animating the far component of the frustum using cos(accum) * 5000.0f + 5100.0f, which oscilates the far clip plane via a sin wave between 100.0 to 10100.0 units. This is visually verified by the obvious clipping of the rendered image. However as this is occurring, the rendered depth buffer doesn't change at all (unless I move the viewpoint).

I would expect that with such a dramatic change in the far clip distance that the rendered image would also have a dramatic change in appearance.

I will try reading the pixels back to the CPU first thing tomorrow morning.