Question

I am trying to write a program that writes video camera frames into a quad.
I saw tutorials explaining that with framebuffers can be faster, but still learning how to do it.
But then besides the framebuffer, I found that there is also renderbuffers.

The question is, if the purpose is only to write a texture into a quad that will fill up the screen, do I really need a renderbuffer?

I understand that renderbuffers are for depth testing, which I think is only for checking Z position of the pixel, therefore would be silly to have to create a render buffer for my scenario, correct?

Answer 1

A framebuffer object is a place to stick images so that you can render to them. Color buffers, depth buffers, etc all go into a framebuffer object.

A renderbuffer is like a texture, but with two important differences:

1. It is always 2D and has no mipmaps. So it’s always exactly 1 image.
2. You cannot read from a renderbuffer. You can attach them to an FBO and render to them, but you can’t sample from them with a texture access or something.

So you’re talking about two mostly separate concepts. Renderbuffers do not have to be “for depth testing.” That is a common use case for renderbuffers, because if you’re rendering the colors to a texture, you usually don’t care about the depth. You need a depth because you need depth testing for hidden-surface removal. But you don’t need to sample from that depth. So instead of making a depth texture, you make a depth renderbuffer.

But renderbuffers can also use colors rather than depth formats. You just can’t attach them as textures. You can still blit from/to them, and you can still read them back with glReadPixels. You just can’t read from them in a shader.

Oddly enough, this does nothing to answer your question:

The question is, if the purpose is only to write a texture into a quad that will fill up the screen, do I really need a renderbuffer?

I don’t see why you need a framebuffer or a renderbuffer of any kind. A texture is a texture; just draw a textured quad.