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:
- use reprojected depth map from previous frame. (it one difference from “mountains example”)
- build depth mipmap. (as in “mountains example”)
- cull with “Transform Feedback” (as in “mountains example”)
- have profit
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 
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]