PDA

View Full Version : glBlitFrameBuffer renders empty when using vec3 as output for fragment



SasMaster
07-02-2012, 12:15 PM
Hi all. Strange problem I am experiencing. I am rendering color data from frag shader to fbo texture attachment. If the fragment out is of type vec3 the glBlitFrameBuffer shows nothing. But if I set it to vec4 out then it shows all right. For the color attachment of the fbo I am using GL_RGB32F. Can it be the problem. Also I work with OpenGL 4.0

aqnuep
07-02-2012, 01:28 PM
I don't understand what you fragment shader has to do with glBlitFramebuffer as your bound GLSL program does not affect glBlitFramebuffer, in fact, this function only performs a simple stretched copy.

SasMaster
07-02-2012, 01:34 PM
I blit the color attachments from FBO. The data to thead attachments comes from the texture which is passed to some fragment shader I am using to render geometry. Now seems logical?

aqnuep
07-02-2012, 04:09 PM
It still isn't. So the blit is not working or the rendering? The attachment is itself a texture. Also what do you mean by "passing the texture to some fragment shader"? Do you render to the texture or fetch from it?

SasMaster
07-02-2012, 11:10 PM
That is GBuffer which I currently checking using blitting.So I attach it , draw some geometry with one of its color attachments active,then blit to viewport. That is what I am doing :)

thokra
07-03-2012, 03:24 AM
You seem to confuse blitting with rendering. Blitting is nothing more than copying a number of pixels from a read framebuffer to a draw framebuffer. Nothing is rendered during a blit.

To be able to blit you need two things:

1. A framebuffer which is bound to GL_READ_FRAMEBUFFER, which serves as the source of pixels, where glReadBuffer(ATTACHMENT_i) defines the concrete attachment to copy from (you'll notice that there is no glReadBuffers())
2. A framebuffer which is bound to GL_DRAW_FRAMEBUFFER, which obviously serves as the target, where glDrawBuffer(ATTACHMANT_i) or glDrawBuffers() specify one or more attachments to copy to

Mind the following call, in part shamelessly copied from the reference pages (http://www.opengl.org/sdk/docs/man3/xhtml/glBlitFramebuffer.xml):


glBlitFramebuffer(srcX0, srcY0, srcX1, srcY1, dstX0, dstY0, dstX1, dstY1, GL_COLOR_BUFFER_BIT, GL_NEAREST);

Assuming that all is well with the FBOs involved, this call will simply copy the area defined by (srcX0, srcY0) to (srcX1, srcY1) to (dstX0, dstY0) to (dstX1, dstY1). If the source and destination areas are equal you get en exact copy of the read buffer. If they aren't the filter argument defines how the resulting image is filtered. You can copy multiple attachments at the same time by choosing an appropriate mask, e.g. GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT to copy both the color attachment set as the read buffer and the depth attachment.


Edit: Note that glBlitFramebuffer() is can also be used with the default framebuffer, which is implicitly active if either one of GL_READ_FRAMEBUFFER or GL_DRAW_FRAMEBUFFER is zero. That means, you can blit from the default framebuffer to a FBO and vice versa. Just set you glReadBuffer() and your glDrawBuffers() accordingly and remember to bind the FBO to the right target.

SasMaster
07-03-2012, 03:49 AM
Man ,you are completely right. That is what I do.let me explain once again.I have an FBO .I render some geometry to attachments of that FBO.Then I switch to the default FBO and read the color attachment from the first FBO ,
then blit. It is all fine.Again ,read my issue in the first post.I don't have a problem with blit procedure.My Problem is that in the fragment shader where I output color map ,if I set the value to be of type vec3 then after the blit to default fbo the screen is empty.If I use vec4 for fragment outputs then my geometry shows after the blitting. Therefore my question is why it happend.My FBO textures are set like this( JAVA WRAPPER FOR OGL:



glBindTexture(GL_TEXTURE_2D, m_textures.get(i));//
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB32F, width, height, 0, GL_RGB, GL_FLOAT, (ByteBuffer) null);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER, GL_COLOR_ATTACHMENT0+i , GL_TEXTURE_2D,m_textures.get(i), 0);

So GL_RGB32F seems to be ok for accepting vec3 output from the fragment?
For the full code here is my post on stackoverflow (http://stackoverflow.com/questions/11298391/glblitframebuffer-renders-empty-screen-when-fragment-out-is-vec3)

Dark Photon
07-03-2012, 05:11 AM
...let me explain once again. I have an FBO ... then blit. It is all fine. Again, read my issue in the first post. I don't have a problem with blit procedure. ... then after the blit to default fbo the screen is empty. If I use vec4 for fragment outputs then my geometry shows after the blitting.

What's confusing about your post is that you first say the blit works fine. But then you say it doesn't work fine due to some mysterious fragment (shader?) output format thing without giving any details.

Post a short GLUT test program that illustrates your problem.

Also (a shot in the dark), Blit in my experience honors the buffer writemasks, so I would make sure that glColorMask, glDepthMask, and glStencilMask are wide-open before you do the Blit.

And when you're doing the mysterious "fragment" piece of this, make sure that you have GL_BLEND and GL_ALPHA_TEST disabled. Just for now. So nothing special gets done with alpha (present or not). To that point, what are you writing in your "fragment shader" for the alpha value (regardless whether the RT format is vec3 or vec4).

SasMaster
07-03-2012, 05:27 AM
the mysterious "fragment" piece of this
He He , like that. I am writing nothing to alpha. Just rgb if it is vec3 .And if it is vec4 I write rgba from the input sampler which is RGBA texture.

Dark Photon
07-03-2012, 05:30 AM
He He , like that. I am writing nothing to alpha. Just rgb if it is vec3 .And if it is vec4 I write rgba from the input sampler which is RGBA texture.
If you have GL_BLEND or GL_ALPHA_TEST enabled, that is potentially a problem, as these are processed before we go writing to the framebuffer.
In the vec3 case, try writing 1 for alpha. Or just disable GL_BLEND and GL_ALPHA_TEST.