I would really like to learn OpenGL and put together a small program to play with GLSL, but somehow my attempt at Deferred Shading just fails. I have spend many evenings searching for the problem and testing and debugging, but I cannot find the error. I even asked for help on Stackoverflow, but the guys there are at a loss, too. So I want to ask here if anyone might be able to help me out? I will share any code you might need and I would welcome a little TeamViewer/Skype session if you want to play around in my environment.
As for my problem: I followed the “OpenGL 4 Shading Language Cookbook” by David Wolff (2nd edition) and put together a simple framework for me to play around. I set up two passes: The first renders the geometry (a cube) and the second one renders a quad to the screen (see chapter 5 for reference). When I try to render the cube to the screen, it works. When I try to render the quad to the screen, it works. When I try to use the passes, nothing renders (I see the clear color).
So just rendering the quad works, but not if you render something into the FBO first?
It sounds as if you’re setting some state for the first part then not setting all of it back for the second part.
I suggest commenting out the code which renders into the FBO until rendering the quad to the screen works. Then start re-enabling parts; if the quad disappears, you know what state you need to restore.
Other than that, there’s no point in posting that much code (or a link to it). It’s unlikely that anyone is going to take the time to read all of it, yet the “relevant” portions cannot be understood without first understanding the framework.
[QUOTE=GClements;1262750]So just rendering the quad works, but not if you render something into the FBO first?
[/QUOTE]
By now I can always see the quad, even when rendering stuff to the FBO first. When I render the colorTex, I only get the clear color, though. So I guess my matrices are messed up somewhere. Is there a simple tool or a preferred way to display the matrices in a nice way? Might this problem be related to something else?
[QUOTE=GClements;1262750]It sounds as if you’re setting some state for the first part then not setting all of it back for the second part.
[/QUOTE]
I spent the last days checking states. The FBO is always 1 for the first pass and 0 for the second. Since I use subroutines I do not have to switch the shader program. Since I set the model matrix on render and my framework updates all MVP uniforms because of that, the matrices are always set to the right values in the first pass. For the second pass I reset them all to 1.0 and lock the matrices so they cannot change (tested and works). Last but not least my VAOs are stored in the mesh objects’ variables. So when I render them they should also be always correct. Did I forget anything?
Realistically, it could be related to anything. As a general rule of thumb, changing any one parameter in any OpenGL function call is more likely than not to result in the output being complete garbage (e.g. a blank screen); you need to get almost every single one correct in order for the result to even resemble what it should.
Matrices can usually be inspected in a debugger. Bear in mind that OpenGL wants them in column-major order, whereas a 2D C array is in row-major order.
For deferred rendering, I’d try separating out the stages. Grab the data from the framebuffer attachments (using glGetTexImage or glReadPixels) and dump it as an image. Replace the textures from the first pass with known test textures and try to figure out what the second pass is doing with them.
OK, since I am still sitting at the same problem, let’s start over.
[QUOTE=GClements;1262818]Realistically, it could be related to anything. As a general rule of thumb, changing any one parameter in any OpenGL function call is more likely than not to result in the output being complete garbage (e.g. a blank screen); you need to get almost every single one correct in order for the result to even resemble what it should.
[/QUOTE]
yep, I got a first-hand experience of this rule while playing around with my initialization code. But then again, the critical code for this problem does not really work so I guess it could be a problem there?
Maybe I should give you an idea of the libs used: GLEW, GLFW, GLM, FreeImage, Assimp. Since I use GLM, the matrices should be the correct format.
It seems the framebuffer contains rubbish. The color part contains the glClear color (binding 2) and the normal part (binding 1) contains the texture I put into GL_TEXTURE1 in the first pass.
I think I am missing something very obvious. I have been playing around with this code for quite some time now, but I am unable to make the slightest progress. Any idea is welcome.
FWIW, the GLSL cookbook code linked earlier works fine (after correcting the #version in the shaders; the program specifically requests a 4.3 profile but the shaders use “#version 440”).
If you’re learning OpenGL you should probably be experimenting with something simpler than a deferred renderer.
The reason why is that deferred pulls together a lot of separate concepts, and while each is in theory quite simple, getting them all to work together does have an implied assumption that you already know what you’re doing.
As a general principle, the larger the project, the more complex the project, and the more dependencies the project has, the less likely people are to look at it.
If you can distil it down to a single source file using only OpenGL itself and common libraries (e.g. GLUT, GLFW, GLEW, GLM), then it’s more likely that someone will look at it.
