The question is simple (I’m afraid the answer might not, however):
Within the context of a Framebuffer Object, what is the use of a renderbuffer object when texture objects are capable of providing the same functionality? Consider GL 3.3+ context.
I’ve been trying to find information about this, but all the hits I get mostly just speak of each object without contrasting their pros and cons.
The best reference to explain why one would use a RBO instead of a texture as an attachment was a mention to textures being unable to represent depth and stencil buffers, however that is not true anymore.
Are there any performance advatages that RBOs give over textures? Functionality wise, a texture provides more advantages and flexibility and its setup is only about two or three function calls longer.
So, to me, RBOs seem like an archaic backwards compatibility object.
Any information you could share? Thanks in advance.
RBOs are like a texture with a hint - that you won’t expect some functionality from them. The driver can speedup rendering to them. Yet, on most modern cards, the performance difference is almost zero. Only on mobile hardware they can make any difference, to save battery - if the driver detects you’re properly using glClear on frame-start.
Basically use RBs only if you know you’ll never need the data to be used as a texture.
Thank you for your reply, it is in tone with what I expected.
Continuing with my begginer level questions about framebuffers, I do have another if anyone would be so kind to answer:
I’m comparing the glFramebuferTexture* functions and I’m seeing little (actualy none right now) reason to use the 1D and 2D versions. The 3D version seems only useful to specify a 2D layer within a 3D texture instead of using glFramebufferTexture… however, there’s also glFramebufferTextureLayer, which pretty much seems to be made for that exact purpose.
Thus, are the 1D,2D and 3D versions of this function obsolete when the GL context provides access to the other two?
Finaly, is this part of some redesign going on in the API? Because in some cases it has quite a lot of redundancy with the binding and targeting paradigm while other functions (aparently newer) go on to skip the targeting and binding steps. For example the one in question (which removes the TEXTURE_* targeting) or the glTransformFeedbackVaryings which takes a program ID directly, among others.
Thus, are the 1D,2D and 3D versions of this function obsolete when the GL context provides access to the other two?
FramebufferTexture1D and 3D is indeed superfluous with FramebufferTextureLayer and FramebufferTexture. But you still need 2D for cubemaps, because of how you have to attach them to textures.
This API change is mostly a simplification, but it was purely accidental. FramebufferTextureLayer was specifically for dealing with layered types (1D/2D arrays, 3D textures, etc), but it did make FramebufferTexture3D entirely superfluous.
FramebufferTexture was added with geometry shaders in order to support layered rendering. The thing is that FramebufferTexture was specified such that it would work for non-layered formats, and therefore instantly make almost all uses of FramebufferTexture*D superfluous.
Finaly, is this part of some redesign going on in the API?
More or less. I think the case of FramebufferTexture was more that the ARB had to add a new function to handle layered rendering, and they saw an opportunity to simplify the API a bit in the process. Though why they never bothered to allow FramebufferTextureLayer to attach cubemap faces still perplexes me, as it is the only reason to use the *D functions anymore.