🔒 Locked

glBlitFramebufferEXT usage

Started by spek Nov 19, 2009 at 9:05 AM 4 replies 3.8k views

Original Post

Nov 19, 2009 at 9:05 AM

Hi, I'm trying to copy the current screen content to a texture. I always used glcopyteximage2d example for that, but now I came accross "glBlitFramebufferEXT". Is this a faster way? This is my situation: 1- Activate FBO, render everything to texture X 2- At halfway, I want to copy the current content from texture X to another texture Y 3- Continue rendering transparent objects on texture X. 4- Disable FBO At step 2 (copying stage), I call:


            glBindFramebufferEXT( GL_READ_FRAMEBUFFER_EXT, 0 );       // Set source, current window
            glBindFramebufferEXT( GL_DRAW_FRAMEBUFFER_EXT, target.handle );       // Set target
            glBlitFramebufferEXT( 0, 0, width , height, // Copy
                                  0, 0, target.width , target.height,
                                  GL_COLOR_BUFFER_BIT, GL_LINEAR );

            // Continue normal rendering
            // Don't know if this is ok, but I skip the last line the 
            // final result is messed up, everything that follows is rendered 
            // on top.
            glBindFramebufferEXT( GL_FRAMEBUFFER_EXT, handle );

However, the target texture is still black. It has the same resolution and color depth than the source. Maybe I forgot something? Rick

HuntsMan

Nov 19, 2009 at 9:29 AM

Why don't simply attach a texture to a color attachment in the FBO, and draw the scene directly to the texture?

spek

Nov 19, 2009 at 9:39 AM

Well, I'm already doing that. Everything gets rendered to a texture via a FBO. But somewhere in between, I want a copy of that texture so I can use it for other transparent objects that are rendered into the main texture. This copy is used for refractions and stuff like that.

In the past I would use the same texture. So while writing pixels on textureX, I also used it as input for shaders with refractions (glass, water, etc.). It worked, but often with strange lines/artifacts. I guess it's not recommended to write and read at the same time.

Rick

idinev

Nov 19, 2009 at 4:33 PM

Don't forget about glCopyTexSubImage2D

spek

Nov 20, 2009 at 7:35 AM

That's an option, and used that with success. But since I saw something about the blit function, I wondered what is faster in my case. And why the code above doesn't work...

Rick

idinev

Nov 20, 2009 at 11:29 AM

glCopyTexSubImage2D has always been HW-accelerated :). And as it isn't a deprecated func in 3.x, speed comparisons will either return equal or slightly-different on different implementations; possibly never always in favour of one direction.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.