Deferred rendering skybox troubles

Hi all,

as the subject states I have problems with my deferred renderer and skyboxes. The problem is that my geometry bleeds into the areas where the skybox is drawn.

For debugging purposes I replaced the depth renderbuffer in my FBO with a depth texture to look at the contents.

As you can see the ‘bleeding’ takes also place in the depth buffer. And I have no idea why.

The steps I perform are the following:

Init (once):
-setup FBO (same size as system framebuffer)

Each frame:
-setup camera
-depthfunc = GL_LESS
-bind system framebuffer
-clear (color and depth)
-depth only pass (no color writing)
-bind FBO
-clear (color and depth)
-depth only pass (no color writing)
-depthfunc = GL_EQUAL
-geometry pass (MRT(3); one 16FP texture each for position, normal and color)
-bind system framebuffer
-enable additive blending
-lighting pass (here: one directional light -> fullscreen quad without depth writing and depth test)
-enable depth test
-depthfunc = GL_LESS

I have absolutely no idea what is happening here and would be very thankful for any pointers that help me debug the problem.
Source code can be provided as needed.

Im not 100% sure what youre doing the depthbuffer shouldnt change with a skybox as u dont write depths with it ie glDepthMask(false);

but try something like

draw skybox

also looking at the depthbuffer the sky values should all be the same i.e. there should be no curves in the top left/right corners

This I tried before posting here. Doesn’t change anything. I assume it is because of the ‘corrupt’ depth buffer.

Yes, I know. This is why I am looking for help. The curves are what I called ‘geometry bleeding’. They belong to a scaled version of the cylinder that you see in the picture above. Rotating the view also changes this curves. But I have no idea why the cylinder shows up in the sky.

In that case it seems as if the skybox is not the issue at all, its a red herring,
but as you say youre redrawing the cylinder (in a different position/scale)

  • the best bet is to step through with a debugger + see where this could be happening
  • another possiblity is youre blending a fbo/texture which has the cylinder in it over the framebuffer
  • also related to this you could try out gldebugger/glintercept + get it to save the current texture/FBO states and see if theres something strange there

This is correct. The problem is with the fragments that are not touched in the geometry pass.

No. Perhaps I did not make myself clear. I do only draw the cylinder once (well actually three times (2 depth passes and 1 geometry pass)), but a scaled version shows up as artefacts. I replaced the cylinder with a cube and get this depth texture:

As I am on Linux gDebugger seems to be my only option. I hope that I can still download a demo version. I will report back after trying it.

I could not get gDebugger to give me information about my textures/fbo so I output the GBuffer myself and these are the results (looks like there is something fishy going on):



Final rendering:

So it looks like I have two corrupted buffers, some geometry in the depth buffer that does not belong there and just don’t know why. At least there are no OpenGL errors.

are all your buffers/textures the same size?

to me it looks like youre not clearing the buffers fully correctly.
perhaps u have set glScissor(…) to the wrong size or have glDepthMask( ) == false

if u look at the top depthbuffer image u see that its the same cube but scaled ~2x (u can see the blocky pixels) are you sure youre drawing it with a 1:1 mapping from FBO/texture -> screen

actually something to try is to just have an empty scene + then capture the position,normal etc textures, they should all display a uniform color.
once thats working add the skybox + then try again.

Color and depth are ok. Color shows an all black texture and depth an all white one (verified with GIMP that it really is only a single color).
Position and normal are corrupted. So my question is how to clear the fbo textures correctly?
glClear allows me to clear the depth and color but what about the other two?

it seems here you want to clear all 3 or 4 buffers (1depth + 3 color)
so when u do
-bind FBO
-clear (color and depth)

do u have something like?
glDrawBuffers(3, buffers);
glClear( … );

Yes I have. But since I cleared before my depth pass my engine issued a glDrawBuffers(GL_BACK) right before clearing. And clearing later did not help, because I disabled color writing and did not reenable it before the glClear command.
Unfortunately this does not solve my problem with the artefacts. They are a little bit different now but still there. I will investigate further and report back.

I had a similar problem. I would get junk data when i would use an fbo that was at a lower resolution than my other fbos. The reason for this i believe is because your mipmaps need to be regenerated whenever you bind a texture, you’re getting junk data because the mipmaps are empty and it’s displaying whatever data that used to be in that memory location( like a previous fbo). Try making a call to glGenerateMipmapEXT(GL_TEXTURE_2D); after you bind each one of the affected textures, this should create the necessary data for your textures. This worked for me. hope that helps, this drove me nuts for a few days.