OpenGL Renderbuffer vs Texture2D
category: code [glöplog]
I have been thinking in replacing all my Renderbuffers by Texture2D's by default in my Framebuffers simply because Texture2D's are more useful. But I wonder if there is any kind of issue memory- or performance-wise.
I would like to hear what do you guys have to say about it. Is it a good idea?
I would like to hear what do you guys have to say about it. Is it a good idea?
*issue memory- or performance-wise... or even in functionality (cause maybe I am missing something).
From the OpenGL wiki on Renderbuffer objects:
It seems to me that Texture2D is more suited for general usage, and Renderbuffer is more of an optimization for a specific usage pattern.
On this page they mention depth buffer as an example suited for the Renderbuffer, where in many cases you only use that buffer to handle Z ordering of fragments, but you never use the buffer's data otherwise.
Quote:
They are optimized for use as render targets, while Textures may not be, and are the logical choice when you do not need to sample (i.e. in a post-pass shader) from the produced image. If you need to resample (such as when reading depth back in a second shader pass), use Textures instead.
It seems to me that Texture2D is more suited for general usage, and Renderbuffer is more of an optimization for a specific usage pattern.
On this page they mention depth buffer as an example suited for the Renderbuffer, where in many cases you only use that buffer to handle Z ordering of fragments, but you never use the buffer's data otherwise.
can't speak for openGL, but with d3d11 i render everything into textures except the final blit which goes to the backbuffer... you can calc the vram usage by yourself, 2x 1/1, 2x 1/4, 2x 1/16, 2x 1/64, + some targets for blÖr, ssao, normals/depth... you need that for post-processing and it's usefull for visual debuggig purposes...
Renderbuffers were the tool of the trade back in the stone age when there was no multisample texture support in GL. Nowadays they're just a left-over.
Go for it. Flexibility and conceptual simplicity is more important than pseudo-optimization before actually profiling bottlenecks.
I'd say avoid making a system where you'd have to make a global decision about these kinds of things. In fact, avoid making systems. Write your demo in assembly. On your own custom designed system. Made from bread.
self-baked bread. made from wheat from your own garden. fertilized with your own shit.