Hi all,

Here is an updated ofxFBOTexture which I believe hasn’t been updated in a while. This is based on the original addon by Zach Gage, with various mods I’ve been collecting and adding as time passes (with major contribs from Theo, e.g. multitsampling and iPhone support).


  • alpha
  • custom Field-of-view
  • float textures
  • half-float textures
  • multi-sampling
  • OpenGL and OpenGL ES (e.g. iPhone)
  • rendering to surfaces (e.g. iPhone)
  • extracting pixel data for saving to file or CPU processing


oh wow tight!
thats a lot of features :slight_smile:

Oh one thing it lost though is the ability to set autoClear to be false on allocate.
Would be great to keep that feature as people use it quite a lot to do drawing and effects.

Maybe it could be

void allocate(int w, int h, bool autoClear = true, int internalGlDataType = GL_RGBA, int numSamples = 0);

As autoClear is one people set quite often.


Hey Theo, yea the FBO does not autoclear. If you want to clear it, from your app you can call myFBO.clear() or myFBO.clear(1, 0, 0, 1); etc. This is how I’ve always used it. I do vaguely remember an autoclear flag, but I don’t remember removing it, I must have branched ofxFBOtexture at a time when it didn’t have the autoclear flag.

Ahh strange - Mind if I update it?

I think a lot of the ofxFBO example projects on the forum ( eg rendermanager / warping example, shader examples etc ) use the autoclear one so it behaves like the normal OF screen unless you explicitly state to not do autoclear.

Mind if I update it?

of course not! :stuck_out_tongue:

btw where do these addons live these days?

great changes ! thanks for throwing this up.

we’ve been talking about putting ofxFBO and ofxShader into the core addons for next release, so having it GIT will make alot of sense (that way, folks can branch it and expand on it). We’re planning something along the lines of glgraphics, the p5 library for advanced graphics with a ping-pong FBO class, gridded texture class, etc. All with one H file, and with good examples, etc.

it would be great to open up a branch on the main line for that – I suspect there are some changes needed to OF in the core that will help as we push this*. I’ll take a look at that later today – I spent yesterday getting into multitexture glsl stuff. it was a bit hard at first to deal with RECTANGLE_ARB vs normal textures, but as soon as I had a working setup, I saw that it’s seriously powerful stuff and will make compositing so much more fun :wink:

* a few changes off the bat – (a) having a ofGetHeight() and ofGetDrawHeight() so that as you use an FBO with begin(), calls that flip vertically (like ofImage::grabScreen()) will use the current viewport / size as opposed to the window size. (b) having more multitexture support in ofTexture and advanced options like unbound drawing, etc.

look forward to giving this FBO class a spin… thanks again…

Hey Zach, having FBO and Shaders in the core addons would be great. All the extra stuff you’re mentioning sounds awesome! looking forward to it…


I am actually currently developing a more advanced system to manage shaders for the rendering engine I am working on from time to time.

With more advanced I mean that custom systax like #pragma include is allowed in shaders.-
The shader system is bound to my resource manager though (so that every shader is in memory only once and you dont reload it for each #pragma include for example).

Anyways, maybe such a glPackage should also have some sort of resource manager to take care of memory managment and things like that? That would make it really userfriendly and easy to use.

Good plan!

I’d also vote for getting these into git so we (by which I mean “I”) can keep up with them. As it is I’m grabbing them from wherever they happen to pop up on the forums.

ok, here’s a new version for you.

getPixels() was not working at all. Argument #6 of the glReadPixels() call should not be typeInternal (a color format). It was changed to pixelType (a data type). Also, the function needed to have “return pixels;” as the last line. Also, you can’t use swapIn() for getting the multisampled pixels because it binds the mfbo (multi fbo) when it should be binding the fbo (non-multi fbo, the multi blit destination). So I created a boolean bReading informing swapIn() to use fbo instead of mfbo. Now getPixels works.

allocate( _ , _ , HERE , _ ) is no longer a boolean like the old version of the code. Beware that you have to pass a color type. If you use a boolean, the FBO fails to initialize. In this version, there are more helpful errors messages.

now GL_RGB, and GL_RGBA work as color formats, and use unsigned char for getPixels(). Other color formats are not working, and cause the GL_FRAMEBUFFER_COMPLETE_EXT error to happen. The init error has been updated to suggest that might be the problem. I would love to see LUMINANCE work.

validations and error checks also added to allocate():

  • seeing if OpenGL will support the required extensions and falling back if necessary.
  • seeing that width and height are within limits.
  • seeing that the number of samples is within limits.

Joshua Nimoy and Keith Pasko


Hey Josh & Keith!

Looks like some great stuff in there!
The checks and fallbacks are awesome.

Then only thing I would say is to remove the std::exit(1); as we try to avoid doing that in OF.

Curious to try it on on some projects!

looking forward to trying this out, unfortunately i keep getting:
…/testApp.h:36: error: ‘ofxFBOTexture’ does not name a type

declared in testApp.h in an otherwise empty project.
strangely xcode is throwing that same error twice.

xcode 3.0 / os x 10.5.8 / intel core duo if that matters.
anyway thanks everyone for a great resource
and inspiring development community.


general note:
main.cpp should probably also have

window.setGlutDisplayString(“rgba double samples>=4 depth”);

between lines 8 and 9. unfortunately, glEnable(GL_MULTISAMPLE) isn’t quite enough…

std:exit(1) is just legacy from both previous versions of ofxFBOTexture.cpp…I’ve got no problem with removing it, especially since its logged as OF_LOG_ERROR

it would help to see your testApp.h file…do you have #include “ofxFBOTexture.h” somewhere?


erm, yes that would do it.
worked like a charm…


[quote author=“piovertwo”]general note:
main.cpp should probably also have

window.setGlutDisplayString(“rgba double samples>=4 depth”);

between lines 8 and 9. unfortunately, glEnable(GL_MULTISAMPLE) isn’t quite enough…

Actually thats what is funny about FBOs and why I hooked up the multisample fbo stuff - as far as I can tell setting FSAA with “rgba double samples>=4 depth” has no effect on the FBO rendering as the FSAA happens at one of the final stages of rendering, whereas when rendering to an FBO you are doing the rendering before the FSAA stage happens. Once its in the texture the OpenGL FSAA can’t touch it. ( I think thats right )

It also brings up another issue I have with Multisampled FBOs - when rendering thin lines to the FBO you see the clear color of the FBO being blended with the line. So if you have a completely transparent FBO with a clear of (0, 0, 0, 0) and render a thing red line into it - you see black pixels of different transparency rendered along the edges of the line. Changing the clear color to ( 1, 1, 1, 0) gives a similar effect but with white to gray pixels along the edges.

I am wondering if this is expected behavior - in a way it makes sense as all the FBO can do is blend your pixels with what it already has. Curious if anyone has any ideas how to handle this as currently FBO multisampling doesn’t look as good as FSAA, especially when detailed graphics are concerned.

Ahh didn’t realize it was already in there :slight_smile:
Yeah I think we should remove it.



i cant compile

appear this error

ofxFOBTexture\src\ofxFBOTexture.cpp|143|error: ‘struct ofTextureData’ has no member named ‘pixelType’|



i have 0.06

i need 0.061?

yep, that’s introduced in 0.061


if you add that line of code to the example project josh uploaded, then zoom in on your screen you can absolutely tell the difference between setting up with samples. The way its drawing is getting the pixels from the fbo then drawing them as glVerts, so the actual drawing to the screen is in the context of the main draw loop’s multisampled buffer…if you bind the fbo as a texture and draw that as well, you can see that the glVert method gives you slightly better AA, perhaps because of the rendering order you mentioned. However, comment out the multisampled glut display string and you can see both methods are significantly more jagged. Even when doing something like myOfImage.setFromPixels(fbo.getPixels()…), myOfImage.saveImage(“test.png”) you can see alpha edges when enabling the glut string and none without.

I think this is to be expected…as for workarounds, haven’t found one in particular yet…maybe blendFunc? maybe GL_ENABLE(GL_SAMPLE_ALPHA_TO_MASK_SGIS) or something like that? Will try some stuff out…

i’m trying the last version and i think there’s a problem in bindAsTexture, this:

void ofxFBOTexture::bindAsTexture(){  
	glBindTexture(GL_TEXTURE_2D, (GLuint)&texData.textureID);  

shouldn’t be?

void ofxFBOTexture::bindAsTexture(){  
	glBindTexture(GL_TEXTURE_2D, (GLuint)texData.textureID);  

note the & in the second parameter.