ofFbo bind() and unbind() is confusing #1359

damian0815 opened this Issue Jun 27, 2012 · 8 comments


None yet
4 participants

damian0815 commented Jun 27, 2012

fbo.bind() should bind the FBO's texture, ie behave the same way as ofTexture.bind(). At the moment it actually binds the FBO's framebuffer. this is confusing, and the documentation is inaccurate on this point (

i would suggest making bind() call getTextureReference().bind(), and adding a new function bindFrameBuffer to do what bind() currently does. comments?


kylemcdonald commented Jun 27, 2012

that is confusing. isn't that doing the same thing as begin()/end() then?

@memo @arturoc any thoughts?


elliotwoods commented Jun 27, 2012

begin calls bind with some extra startup:

void ofFbo::begin(bool setupScreen) {
    ofViewport(0, 0, getWidth(), getHeight(), false);
        ofOrientation orient = ofGetOrientation();
        orient = OF_ORIENTATION_DEFAULT;
        ofSetupScreenPerspective(getWidth(), getHeight(), orient, false);

i think bind is confusing here, but that it shouldn't work like ofTexture either.
ofFbo::getTextureReference().bind() is correct, no?


memo commented Jun 27, 2012

ofFbo::bind() is a lower level method. Its if you want to just bind the fbo without doing all the other screen stuff.

ofFbo::getTextureReference::bind() is different. It binds the fbo as a texture, so completely unrelated.


elliotwoods commented Jun 27, 2012

"ofFbo::getTextureReference::bind() is different. It binds the fbo as a texture, so completely unrelated."
it's related to the functionality damian expected from bind, and therefore, likely other users

i think the discussion is whether ofFbo::bind() should be renamed so that it doesn't get confused with ofTexture::bind() (since many people think of an fbo as a texture that you draw to)

"but that it shouldn't work like ofTexture either":
i meant ofFbo::bind() shouldn't wrap ofFbo::getTextureReference().bind()

could we just suggest users use setupScreen=false ? and ditch bind?
since we're presuming that the viewport changes between fbo and full renderer, the 'oF-like pixel viewprojection' will be all fuggered anyway, so perhaps move ofViewport into if(setupScreen), and ditch separate function


damian0815 commented Jun 28, 2012

To clarify my position @memo, I understand an FBO as 2 things: a rendering context, and a texture map. This confusion actually popped up when I replaced an ofTexture in some code that drew a texture mapped ofMesh, with an ofFbo. I spent about 90 minutes trying to debug why nothing was being drawn for the mesh, while calling FBO.draw() was working fine. If bind() didnt exist in the ofFbo class I could have saved 90 minutes.

in short I think I ought to be able to swap an ofTexture for an ofFbo and have things still work fine without changing any other code, since in theory an FBO is in fact a special kind of texture that you can draw into.


memo commented Jun 28, 2012

ok, I understand your confusion. However technically an FBO is not a rendering context and a texture map :). An early version of ofFboTexture (which extended ofTexture) may have caused that misleading assumption. An FBO is an object which you can attach a texture to, in fact you can attach more than one texture to an FBO, e.g. if you want to do MRT, or if you want to work with a depth texture etc.

The vocabulary of 'binding an fbo' is not a vocabulary we made up. It exists and means to set the FBO as a target for rendering or reading (e.g. glBindFrameBuffer(GL_FRAMEBUFFER_EXT, fbo); ) Of course if you have more than one texture attached to an FBO, you need to use glDrawBuffers() to explicitly state out of the textures attached to the FBO, which one(s) you want to write to.

Again the vocabulary of 'binding a texture' is not one we made up. It exists and means which texture we attach to a particular texture target (e.g. glBindTexture(GL_TEXTURE_2D, tex) );


elliotwoods commented Jun 28, 2012

i presume the discussion is about how consistent the API is to oF users
as per:

openFrameworks is consistent and intuitive: it should operate on the principle of least surprise, so that what you learn about one part of openFrameworks can be applied to other parts of it. Beginners can use openFrameworks to learn about common programming patterns, and advanced users will be able to apply their experience from other languages and toolkits.

propose name change to ofFbo::bindBuffer or removing by making begin(false) sufficient


memo commented Jun 28, 2012

I think fbo::bindBuffer makes a lot of sense. I woudl strongly oppose losing the functionality altogether. Always wrap low level functionality, and use that in higher level functionality. Not the other way around.

begin(false) doesn't make sense at all because you can't just read the source code of an app and understand whats going on. Any API that requires you to read the documentation when reading app code is a fail IMO.

micuat referenced this issue in openframeworks/ofSite May 5, 2014


ofFbo::bind() note #275

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment