Can't render depth cubemap OpenGL

Started by
8 comments, last by SleekoNiko 7 years, 1 month ago

I'm trying to render a shadow cubemap but I'm getting a black texture. I tried to look for an answer but most of the answers I found seem to be either including an unnecessary color attachment or the issue is with the projection of the shadow map. I got it to work for 2D images (dir + spot lights) but not point lights due to this issue.

Here is my Framebuffer generation code:


glGenFramebuffers(1, &fbo);
glBindFramebuffer(GL_FRAMEBUFFER, fbo);

glDrawBuffer(GL_NONE);
glReadBuffer(GL_NONE);

glGenTextures(1, &depthBuffer);
glBindTexture(GL_TEXTURE_CUBE_MAP, depthBuffer);
for (size_t i = 0; i < 6; i++) {
glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_X + (GLenum)i, 0, GL_DEPTH_COMPONENT32, width, height, 0, GL_DEPTH_COMPONENT, GL_FLOAT, NULL);
}

glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE);

glFramebufferTexture(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, depthBuffer, 0);

GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (status != GL_FRAMEBUFFER_COMPLETE) {
fprintf(stderr, "Framebuffer Error. Status 0x%x\n", status);
}

// Unbind
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);

Here is my shadow map rendering code run for each view. I don't use geometry shaders to automatically swap between the views because right now I'm trying to support everything starting 3.1 (I have a decent PC but my old laptop only supports that.) I may support both paths based on performance later:


glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
for (size_t j = 0; j < 6; j++) {
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_CUBE_MAP_POSITIVE_X + j, depthBuffer, 0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
geometryCache->Draw(proj, view[j]);
}
glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);

And finally, I render the deferred rendering sphere for the point light including this:


...
glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
glActiveTexture(GL_TEXTURE4);
glBindTexture(GL_TEXTURE_2D, depthBuffer);
glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
...

Does anyone have any ideas? Also, is it better to use gl_FragDepth to manually define the depth or to use a blank fragment shader for shadow maps (both spotlight and pointlight? Thanks in advance!

Advertisement

Not sure of the answer though have noticed your rendering 6 times, once for each face.

Check out https://learnopengl.com/#!Advanced-Lighting/Shadows/Point-Shadows as has code to do the rendering with 1 render as it uses a geometry shader, quicker.

Not too dificult to modify the tutorial for multiple lighting with a texture array.

Not sure of the answer though have noticed your rendering 6 times, once for each face.

Check out https://learnopengl.com/#!Advanced-Lighting/Shadows/Point-Shadows as has code to do the rendering with 1 render as it uses a geometry shader, quicker.

Not too dificult to modify the tutorial for multiple lighting with a texture array.

Hey, thanks Paul, but I already saw that link. I did say: "I don't use geometry shaders to automatically swap between the views because right now I'm trying to support everything starting 3.1 (I have a decent PC but my old laptop only supports that.)"

I don't see any mention of PCF, perhaps force a compare mode of none to fix the black texture issue.

glTexParameteri(GL_TEXTURE..., GL_TEXTURE_COMPARE_MODE, GL_NONE);

I don't see any mention of PCF, perhaps force a compare mode of none to fix the black texture issue.

glTexParameteri(GL_TEXTURE..., GL_TEXTURE_COMPARE_MODE, GL_NONE);

I'm not using PCF on point lights until I get it to work at all :P Also I tried COMPARE_MODE before I posted, it didn't work.

For my old shadows with debug depth texture displayed in corner, I had the same side effect which toggling the parameter (re-gen) would workaround. Though it wasn't the first or last time GL gave empty results of course!

For your second question I think there's nothing to lose by using an empty frag shader. Though I can't say the same for the alternative. I think the difference (if any) is readablity in your code. Best to test on various machines if you can, but I think optimizes like that are secondary and driver dependent.

For my old shadows with debug depth texture displayed in corner, I had the same side effect which toggling the parameter (re-gen) would workaround. Though it wasn't the first or last time GL gave empty results of course!

I'm sorry, toggling which parameter? Compare_mode?

For your second question I think there's nothing to lose by using an empty frag shader. Though I can't say the same for the alternative. I think the difference (if any) is readablity in your code. Best to test on various machines if you can, but I think optimizes like that are secondary and driver dependent.

Alright fair point, I'll keep that in mind. I just didn't want to do too many tests when the answers are probably already known.

For my old shadows with debug depth texture displayed in corner, I had the same side effect which toggling the parameter (re-gen) would workaround. Though it wasn't the first or last time GL gave empty results of course!

I'm sorry, toggling which parameter? Compare_mode?

...

Yes. GL_NONE would be set (when generating the

texture) for displaying the debug quad. Or enable a compare mode for normal shadow lookups to work. I noticed nobody else seemed to have the issue and later searched images for one which displayed a shadowed scene plus debug at the same time. Guess my method was old as the issue happened way back in 2008!

Also, not at work PC right now but I think you should set parameters before generating textures, possibly within the cube loop? I forget tbh.

Before this thread gets too old, plus if the OP is still around, and certainly for search results: I suspect the OP is using glBlitFrameBuffer from an FBO direct to the backbuffer, in which case the SRC/DST coords must be the same dimension. However, as stuff like shadow debug windows tend to be a fraction of the original size when viewed (as a 'postage stamp') then a 2nd FBO is required for the scaling to take place to. Then a 1:1 blit can be done from the 2nd FBO to the backbuffer with matching dimensions on SRC/DST.

I can't imagine why GL is like this, imo a bug :)

...indeed (read OP again).

Before this thread gets too old, plus if the OP is still around, and certainly for search results: I suspect the OP is using glBlitFrameBuffer from an FBO direct to the backbuffer, in which case the SRC/DST coords must be the same dimension. However, as stuff like shadow debug windows tend to be a fraction of the original size when viewed (as a 'postage stamp') then a 2nd FBO is required for the scaling to take place to. Then a 1:1 blit can be done from the 2nd FBO to the backbuffer with matching dimensions on SRC/DST.

I can't imagine why GL is like this, imo a bug :)

...indeed (read OP again).

Looking at the documentation for glBlitFramebuffer, it states that calling the function with different source and destination rectangle sizes will use interpolation (which must be either GL_NEAREST or GL_LINEAR). Did you call it with a valid filter?

There are some notable cases to handle which can be seen in the "Errors" section:

GL_INVALID_OPERATION is generated if mask contains any of the GL_DEPTH_BUFFER_BIT or GL_STENCIL_BUFFER_BIT and filter is not GL_NEAREST.

GL_INVALID_OPERATION is generated if filter is GL_LINEAR and the read buffer contains integer data.

GL_INVALID_OPERATION is generated if GL_SAMPLE_BUFFERS for the read buffer is greater than zero and the formats of draw and read buffers are not identical, or the source and destination rectangles are not defined with the same (X0, Y0) and (X1, Y1) bounds.

Edit:

Sorry, I forgot that we were talking about multisampled FBOs - it seems like there is some strange behavior with those indeed. :)

This topic is closed to new replies.

Advertisement