I’ve just ventured into FBOs. My code works but I have to remove all subsequent calls to glDrawBuffer(GL_BACK) glDrawBuffer(GL_FRONT_AND_BACK) etc. since I have defined only one FBO/RBO. Defining more is of course not the problem, it’s how to define a pair that emulate front and back framebuffers so that the calls don’t cause OpenGL errors.
I have a whole system in existence that writes sometimes to back buffers (then swaps) and at other times simply writes to both buffers. I want to use my system to occasionally capture images that are larger than the screen so I’m rendering to an FBO/RBO and then saving the result as a TIF image.
I could add a bunch of conditional compilation stuff but I’m hoping for a more elegant solution.
Defining more is of course not the problem, it’s how to define a pair that emulate front and back framebuffers so that the calls don’t cause OpenGL errors.
You don’t. FBO buffers replace FRONT, BACK, etc, so long as the FBO is bound. FBO buffers have different names.
I have a whole system in existence that writes sometimes to back buffers (then swaps) and at other times simply writes to both buffers.
That’s not a nice system. Writing to the front buffer is in many cases a dicey concept, and doubly so for GL_FRONT_AND_BACK. Particularly if the user has done things like tell the driver to force multisampling.
You should just inform this system when you are rendering to the FBO and have it use different draw buffers.
I could add a bunch of conditional compilation stuff but I’m hoping for a more elegant solution.
This is a runtime matter, not a compile-time matter.
Thanks.
You write: “FBO buffers replace FRONT, BACK” but how can OpenGL know which is the virtual front and the virtual back buffer?
My code isn’t portable. It runs on Nvidia ION hardware with their driver under Linux and I’m the only user, though the hardware is replicated.
Imagine using a compiler as if it were an interpreter – of C – so it’s a compile-time issue because I can remove all the calls to glDrawBuffer() from my system whenever I’m using it to capture large images. Then any rendering will work just fine.
An important FYI: the “values” passed to glDrawBuffer(s) is a part of FBO state, i.e. when you change from your FBO back to rendering to the screen, GL will “restore” what of front/back/left/right buffers you were drawing to.
The problem I encounter is that a call to glDrawBuffer(GL_BACK) causes an OpenGL error (undefined!) if the FBO/RBO is active. This makes sense because there is no front and back to the FBO/RBO (I carefully check for OpenGL errors at every OpenGL call as I develop my code). It seems a little pedantic of OpenGL to complain but it does.
The system is fully restored, context re-established and is entirely operational, as you would expect, when the FBO/RBO is subsequently unbound & deleted.
I’m simply wondering if there is a way to artificially create a front and back FBO/RBO framebuffer to keep OpenGL happy while retaining calls to glDrawBuffer() ?
For example: if I pass glDrawBuffer the ID of the FBO instead of GL_BACK. This would make sense but I suspect that GL_BACK is just an enumerant whereas the ID is a variable?
It seems a little pedantic of OpenGL to complain but it does.
Why? FBOs don’t have a back buffer.
GL_FRONT and GL_BACK specify particular buffers in the default frame buffer. GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1, etc are the names of the particular buffers in FBOs.
I’m simply wondering if there is a way to artificially create a front and back FBO/RBO framebuffer to keep OpenGL happy while retaining calls to glDrawBuffer() ?
Was “You don’t?” somehow unclear? You cannot do this. So change your compiled-into-interpreted code to take a variable that describes what buffer you should be rendering to.
It’s an issue of semantics but “You don’t” does not mean the same thing as “You can’t”.
It remains an issue if glDrawBuffer() can’t be used at all with FBOs.
Unless it is permissable to write: glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT) and for me to then attach two color RBOs to the FBO ? In which case my problem has a good solution.