Hello Guest

RGBA16F FBO Is Ending Up As All 0s?

  • 4 Replies
RGBA16F FBO Is Ending Up As All 0s?
« on: September 01, 2017, 16:52:44 »
So I've spent almost 4 days on this. Problem is I don't know what I need to know to know what to look for... o.0

I have a frambuffer which uses an HDR texture attachment created as follows:
Code: [Select]

The issue is that after the second rendering pass (rendering this color attachment texture to a "screen quad") results in a completely black screen.

After days the list of potential solutions I've tried is very long so I'll trim it down to the most relevant:
  • checking framebuffer status returns framebuffer_complete
  • rendering a single pass (no hdrFBO) results in the scene rendering successfully
  • spamming glCheckError() after [virtually] every gl call result in only GL_NO_ERROR
  • in the fragment shader for the second pass doing FragColor = vec4(1.0, 0.0, 0.0, 1.0) results in a red screen as expected (the shader is working and second pass is happening)
  • changing between RGBA16F & RGB16F has no effect (as well as their 24/32F compliments)
  • I have read (comments of this tutorial: https://learnopengl.com/#!Advanced-Lighting/HDR) that Nvidia cards may experience black screen issues and tried the solution provided, still results in a black screen
  • I have tested this on my NVIDIA GeForce GTX 750 Ti, another computer here which has an Intel GPU, and employed my brother's assistance to test on an AMD GPU, all 3 of which resulted in a black screen
  • updated my drivers

So at this point I've come to the conclusion that something must be wrong with my HDR FBO specifically the FLOAT flavored color attachment. It seems to simply not render into it? Is this possible/common?
I normally am an advocate for solving one's own problems, however, in this specific case I am quite literally at my wit's end.

Here is how I'm creating the HDR FBO (full source code is attached):
Code: [Select]
int hdrFBO = GL30.glGenFramebuffers();
int colorBuffer = GL11.glGenTextures();
GL11.glBindTexture(GL11.GL_TEXTURE_2D, colorBuffer);
int rboDepth = GL30.glGenRenderbuffers();
GL30.glBindRenderbuffer(GL30.GL_RENDERBUFFER, rboDepth);
GL30.glBindFramebuffer(GL30.GL_FRAMEBUFFER, hdrFBO);
GL30.glFramebufferTexture2D(GL30.GL_FRAMEBUFFER, GL30.GL_COLOR_ATTACHMENT0, GL11.GL_TEXTURE_2D, colorBuffer, 0);
GL30.glFramebufferRenderbuffer(GL30.GL_FRAMEBUFFER, GL30.GL_DEPTH_ATTACHMENT, GL30.GL_RENDERBUFFER, rboDepth);
if(GL30.glCheckFramebufferStatus(GL30.GL_FRAMEBUFFER) != GL30.GL_FRAMEBUFFER_COMPLETE)
System.err.println("Framebuffer check was not GL_FRAMEBUFFER_COMPLETE");
GL30.glBindFramebuffer(GL30.GL_FRAMEBUFFER, 0);

Attached you'll find the full self contained source. I apologize for some of the bad practice going on here as I threw this together from my engine-esk source (not reusing some instances and the like were a byproduct of this conversion).

Long story short I'm not even 100% sure what I need to ask. All I know is that it appears that in hdr.frag the sampler2D hdrBuffer is filled with 0s and thus results in a black screen. I'm just trying to understand why and how to fix it. If anyone has any helpful hints or outright knows why this isn't working I would greatly appreciate it and humbly accept any feedback!

Thanks in advance!  :-[

  • To see the example working with only a single render pass comment out exactly these lines: 193, 213-222
  • lines 113-115 are where the resources' string paths are
  • Any png should work, as long as it is named wood.png and relative path is appeased (and I'm not sure I can post the one I'm using), the one i'm using is from the tutorial I linked above.
  • the self contained example uses the jars from the attached screenshot called "required_jars_on_buildpath.png" and uses only java, joml, or lwjgl+included_libs.
  • If I find a solution before I get a response I promise to come back and share it here in the hopes of saving someone else from graying hairs :D
  • The shaders have been converted into a single file and will need broken up to run properly. Each one has a leading comment (before version declaration) which denotes intended file name
« Last Edit: September 01, 2017, 19:47:35 by MrNoperson »


Offline spasi

  • *****
  • 2054
    • WebHotelier
Re: RGBA16F FBO Is Ending Up As All 0s?
« Reply #1 on: September 01, 2017, 19:21:22 »
Hey MrNoperson,

The fix is simple, change the location of uvCoord in hdr.vert from 2 to 1.

Re: RGBA16F FBO Is Ending Up As All 0s?
« Reply #2 on: September 01, 2017, 19:46:02 »
Thank you for catching that!

Unfortunately, and embarrassingly enough, that was another byproduct of my conversion to the self contained test.

In my engine there is "Quad" class which has the attributes: position(0), normal(1), texCoords(2), tangent(3), bitangent(4). I forgot to change it back after trying to use that class instead of the quad in the source I have attached.  :-[

I have fixed it and will re-upload my shaders.txt as I am still getting a black screen.

Addendum: I have retested all changes since the aforementioned error was introduced to no avail.
« Last Edit: September 01, 2017, 20:24:21 by MrNoperson »


Offline spasi

  • *****
  • 2054
    • WebHotelier
Re: RGBA16F FBO Is Ending Up As All 0s?
« Reply #3 on: September 02, 2017, 07:16:57 »
You're right, I'd done another fix while debugging this that I forgot. You must move the first glClear after glBindFramebuffer(GL_FRAMEBUFFER, hdrFBO).

Re: RGBA16F FBO Is Ending Up As All 0s?
« Reply #4 on: September 02, 2017, 17:57:03 »
Works like a charm! Can't believe I overlooked that! I'm just glad that it wasn't an issue with how floating point fbo textures work!

A million, sincere, thanks spasi!  :)