Full OpenGL Depth with Partial Color Recording
I am making a program that displays the terrain in two separate passes, with a depth clearing in between (there is no way to change this requirement). In the first pass, I render the skybox and terrain very far away using deep testing. I clear the depth buffer bit to 1.0. Then I do all my close terrain with depth tests. Therefore, the code looks something like this:
// My State
glEnable(GL_BLEND);
glBlendFunc(GL_ONE, GL_ZERO);
glEnable(GL_DEPTH_TEST);
glDepthMask(GL_TRUE);
glDepthFunc(GL_LESS);
glClearColor(0, 0, 0, 0);
glClearDepth(1.0);
// Pass 1
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
DrawSkybox();
DrawFarTerrain();
// Pass 2
glClear(GL_DEPTH_BUFFER_BIT);
DrawNearTerrain(); // IMPORTANT: All done in one draw command
The following images show the color values and depth (white = 1.0) at the end of each pass:
Pass 1
Pass 2
As you can see, inside this single draw command for the second pass, the pixel values are written to the depth buffer, but the color buffer is only partially written. The white area is causing some weird problems.
According to GDebugger, this was my state at the time of this draw command:
- GL_BLEND: TRUE
- GL_BLEND_EQUATION_ALPHA: GL_FUNC_ADD
- GL_BLEND_EQUATION: GL_FUNC_ADD
- GL_BLEND_EQUATION_RGB: GL_FUNC_ADD
- GL_BLEND_DST: 0
- GL_BLEND_DST_ALPHA: 0
- GL_BLEND_DST_RGB: 0
- GL_BLEND_SRC: 1
- GL_BLEND_SRC_ALPHA: 1
- GL_BLEND_SRC_RGB: 1
- GL_DEPTH_FUNC: GL_LESS
- GL_DEPTH_TEST: TRUE
- GL_STENCIL_FUNC: GL_ALWAYS
- GL_STENCIL_TEST: FALSE
- GL_BLEND_COLOR: {0, 0, 0, 0}
Can anyone tell me what's going on? I feel like the GPU is drowning me out.
EDIT:
- I currently have one live GL context.
- My card is an Intel HD 4000 with the latest drivers running on an Intel i7 with 8GB of RAM.
- The MY FBO color attachment is internally GL_RGBA16F, and the depth nest is GL_DEPTH_COMPONENT32F.
- Stencil testing is never used.
source to share
Well, I spoke to someone who ran into such an error and I resolved the issue in the process.
It turns out that everything in the white part at the end of the first pass is not white, but NaN in fact. GDEBugger displays values as (255, 255, 255, 255) as it shouldn't support displaying any other texture formats. He simply says: "NaN, you must understand white: P".
Okay, why NaN matters if we're doing pixel swaps - glBlendFunc (GL_ONE, GL_ZERO). This is because operations on NaN still cause NaN to go all the way down the pipeline. GL execution still does "Result = SourceFactor * Source + DestFactor * Dest" - no optimization is performed.
In regards to the fix ... it turns out that doing "outFragColor = clamp (outFragColor, vec4 (0.0), vec4 (3000000000000.0))" in the fragment step (outFragColor is the pixel return value) will not result in NaN, although outFragColor contains NaN. Hover over your mouse.
source to share