Problem with glReadPixels using FBO

See MountainsDemo::renderScene() in mountains.cpp.

In particular, note that the FBO that’s bound at the top of this function has by default slice 0 of this->depthTex set as the depth buffer (see glFramebufferTexture2D() calls in setupFramebuffer()). That base depth buffer is rendered under “// draw terrain”. Then below that, the hierarchical Z map is created in render passes under “// create Hi-Z map if necessary” by iteratively reading from level i-1 of this->depthTex and writing to level i, where i = 1…numLevels-1.

[QUOTE=Dark Photon;1290271]See MountainsDemo::renderScene() in mountains.cpp.

In particular, note that the FBO that’s bound at the top of this function has by default slice 0 of this->depthTex set as the depth buffer (see glFramebufferTexture2D() calls in setupFramebuffer()). That base depth buffer is rendered under “// draw terrain”. Then below that, the hierarchical Z map is created in render passes under “// create Hi-Z map if necessary” by iteratively reading from level i-1 of this->depthTex and writing to level i, where i = 1…numLevels-1.[/QUOTE]

Ok.

It looks as that implementation render to the depth texture only with the terrain.
Thus culling is processing only using terrain, am I right?

So If I have huge thick forest without mountains. I will have too expensive cost of depth map rendering. (It requires “occlusion culling” using the trees).

And I think I should:

  1. use reprojected depth map from previous frame. (it one difference from “mountains example”)
  2. build depth mipmap. (as in “mountains example”)
  3. cull with “Transform Feedback” (as in “mountains example”)
  4. have profit :slight_smile:

It seems, that is what you tried to explane me in https://www.opengl.org/discussion_boards/showthread.php/200335-Problem-with-glReadPixels-using-FBO?p=1290032&viewfull=1#post1290032

Thank you!

[QUOTE=nimelord;1290280]It looks as that implementation render to the depth texture only with the terrain.
Thus culling is processing only using terrain, am I right?[/quote]

In the quick look I did yesterday, that’s what it looked like to me.

I have result of reprojection:

[ATTACH=CONFIG]1696[/ATTACH]

Top view is an original depth map.
Bottom one is a reprojected map rotated around Y axis for 0.2 degrees (so small rotation).
The left front looks a little bit darker (closer).
But right front too much brighter (looks strange, I mean: behind skybox).

It is correct result for reprojection or I’m doing something wrong?

:doh:Of course it was implemented incorrectly.
This is correct variant, I hope :slight_smile:

reproject shader:


#version 330

in vec2 outTexCoord;
uniform sampler2DArray depthTexture;
uniform mat4 prevFrameInvertedProjViewMatrix;
uniform mat4 currFrameProjViewMatrix;

void main() {

  float depth = texture(depthTexture, vec3(outTexCoord, 0)).r;
  vec2 cspos = vec2(outTexCoord.x * 2 - 1, (1-outTexCoord.y) * 2 - 1);
  vec4 depthCoord = vec4(cspos, depth, 1.0);
  depthCoord = prevFrameInvertedProjViewMatrix * depthCoord;
  vec4 position = vec4(depthCoord.xyz / depthCoord.w, 1.0);
  vec4 projPosition = currFrameProjViewMatrix * position;
  gl_FragDepth = projPosition.z / projPosition.w;
}

It shows us the holes of the parts which didn’t be seen on previous frame.

result:
[ATTACH=CONFIG]1697[/ATTACH]