Framebuffer objects - OpenGL群23186719 - C++博客

Framebuffer objects

Framebuffer objects
Simon Green, NVIDIA
The long awaited EXT_framebuffer_object was released last month. This extension was a result of the efforts of the uberbuffers workgroup, and although it does not currently contain all of the functionality promised by uberbuffers, it does include much of it, most importantly a much-improved render-to-texture capability. It also is designed to have additional functionality (e.g. rendering to vertex attributes) built on top of it.

By way of review, render-to-texture is used for procedural textures, reflections, and various multipass techniques (e.g. anti-aliasing, motion blur, depth of field, image processing, GPGPU). It allows you to have to the contents of the framebuffer placed directly into a texture. The advantage of this is that it avoids a copy and uses less memory (since there is only one copy of the image). However, in practice, the driver may have to perform a copy anyway, due to using separate memory for the framebuffer and textures, or because of different internal representations.

Pbuffers were introduced as a solution for render-to-texture. They are designed for off-screen rendering. The available formats for pbuffers are determined using the ChoosePixelFormat()/DescribePixelFormat() APIs.

Pbuffers come with a number of major drawbacks. Each requires its own OpenGL rendering context (though of course, texture objects and display lists can be shared between contexts using wglShareLists()). Besides being painful to manage and bug-prone, switching between pbuffers requires an expensive context switch. In addition, each has its own depth, stencil, and aux buffers, which are often not necessary.

The Windows-specific WGL_ARB_render_texture was built on top of pbuffers to improve their functionality. It allows you to bind the color or depth buffer of a pbuffer directly to a texture (using wglBindTexImageARB() and wglReleaseTexImageARB. When using this extension, the format of the texture is determined by the pixel format of the pbuffer. In order to write portable applications, you need to have a separate pbuffer for each renderable texture. To make this slightly more efficient, you can bind the front and back buffers of the pbuffer to separate textures (using glDrawBuffer(GL_FRONT/GL_BACK), giving you two textures per buffer/context.

Besides the previously listed limitations of existing render-to-texture methods, using it with antialiasing is complicated at best. It doesn't work with multisampling, because current hardware can't ready from a multisample buffer into a texture (though a slow copy could be done in the driver). One solution to this is creating a normal multisampled pbuffer and using glCopyTexImage(), which will downsample automatically. The application can also do supersampling itself if necessary for post-processing effects, but this will be much more expensive.

The framebuffer object (FBO) extension presents a much better and more simplified method of doing render-to-texture. Its advantages include:

• 
  
• It only requires a single GL context, so switching between framebuffers faster than switching between pbuffers.
  
• It doesn't require the complex pixel format selection that pbuffers uses, since the format of the framebuffer is determined by texture or renderbuffer format. This puts the burden of finding compatible formats on developers.
  
• It's much more similar to D3D's render target model, making code porting easier.
  
• Renderbuffer images and texture images can be shared among framebuffers (for example, sharing a single depth buffer between multiple color targets), resulting in memory savings.

So what exactly does the framebuffer object extension entail? You'll recall that in OpenGL, the framebuffer is a collection of logical buffers, including the color, depth, stencil, and accumulation buffers. With the FBO extension, you can render to destinations other than those provided by the window system, allowing you to render-to-texture in a window system independent manner (notice that this is a GL extension, not a WGL extension). These destinations are known as "framebuffer-attachable images" (2D arrays of pixels that can be attached to a framebuffer). They can be off-screen buffers (Renderbuffers) or texture images. Each texture image in a texture object can be attached to a buffer in a framebuffer object. Renderbuffer images can be attached as well.

FBO architecture

Two new objects have been added to OpenGL as part of this extension. The first, framebuffer objects, consist of a collection of framebuffer-attachable images. They are equivalent to a window system drawable. The second, renderbuffer objects, can be rendered to but can't be used as texture images.

Managing FBOs (as well as renderbuffers) is similar to texture objects. They are created and deleted with glGenFrameBuffersEXT() and glDeleteFramebuffersEXT(), and they are bound with glBindFramebufferEXT(). When an FBO is bound, its attached images are the source and destination for fragment operations. Binding an FBO id of 0 causes operations to occur on the default framebuffer.

Textures can be attached to a framebuffer using glFramebufferTexture2D (or the 1D or 3D variations). This API allows you to attach images from a texture object to one of the logical buffers of the currently bound framebuffer.

When using renderbuffers, glRenderbufferStorageEXT() is used to define the format and dimensions of the render buffer. This call is similar to glTexImage, but doesn't include any image data. The contents of a renderbuffer can be read or written to using glReadPixels()/glDrawPixels, or similar APIs. A renderbuffer can be attached to a framebuffer by using glFramebufferRenderbufferEXT().

Finally, you can automatically generate mipmaps for texture images attached to a target by using glGenerateMipmapEXT().

Similar to textures, framebuffers define a "completeness" that must be satisfied when rendering in order to work properly. A framebuffer is considered complete if the following condition