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).
OpenGL and OpenGL ES (e.g. iPhone)
rendering to surfaces (e.g. iPhone)
extracting pixel data for saving to file or CPU processing
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.
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.
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
* 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…
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.
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.
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
Yeah I think we should remove it.
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…