Using a Render Buffer to store Color data (considering it can't be sampled)?

As far as I understand (feel free to correct):

An FBO has attachments which determine what buffers to use when drawing, some being optional. A render buffer can be used for any buffers as they sometimes provide optimizations if not being used for sampling later.

My question is: I am wondering if there are any plausible scenarios where a render buffer is the best choice to store the color buffer rather than storing the color in a sample-able texture? Screenshotting perhaps…?

I can’t think of any time where this would be needed, but guides online suggest that a render buffer could be used to hold a color buffer. What’s the point in rendering to it if you can’t sample from it later?

Still new to the API and am only just learning framebuffers so take this with a pinch of salt. It may be one of the “possible, but useless in practice” type of things.

[QUOTE=ThomasRue;1289904]An FBO has attachments … A render buffer can be used for any buffers as they sometimes provide optimizations … [versus] a sample-able texture?

…What’s the point in rendering to [a render buffer] if you can’t sample from it later?[/QUOTE]

You don’t always want to sample from an FBO by feeding it into a subsequent shader pass. For instance: 1) Render to off-screen FBO, 2) Call glBlitFramebuffer() to copy from FBO to window framebuffer. Renderbuffers for the attachments work just fine in this case.

Renderbuffers give the driver more flexibility in choosing how to lay out the render target for optimal rendering performance and/or features than textures. One example of this is CSAA (NV_framebuffer_multisample_coverage), where you can create a renderbuffer that supports it, but not a texture.

[QUOTE=Dark Photon;1289905]You don’t always want to sample from an FBO by feeding it into a subsequent shader pass. For instance: 1) Render to off-screen FBO, 2) Call glBlitFramebuffer() to copy from FBO to window framebuffer. Renderbuffers for the attachments work just fine in this case.

Renderbuffers give the driver more flexibility in choosing how to lay out the render target for optimal rendering performance and/or features than textures. One example of this is CSAA (NV_framebuffer_multisample_coverage), where you can create a renderbuffer that supports it, but not a texture.[/QUOTE]

Thanks; that’s a good explanation to put my mind at ease!

It’s always hard to tell what to use when there are a few different ways to give similar results.