[of-dev] FBOs

Kyle McDonald kyle at kylemcdonald.net
Tue Jul 20 14:38:44 PDT 2010

One more place worth looking for inspiration is Cinder:


They pass a "Format" object that indicates things like GL_TEXTURE_2D vs 
GL_TEXTURE_RECTANGLE_ARB, color format, MSAA samples, wrap mode, and 
min/mag filter.

The FBO object itself works as expected:

class Fbo {
	Texture& getTexture();
	Texture& getDepthTexture();
	void bindTexture(int textureUnit = 0);
	void unbindTexture();
	void bindDepthTexture(int textureUnit = 0);
	void bindFramebuffer();
	static void unbindFramebuffer();

The main difference between my ofxFBO and every other FBO wrapper 
(Cinder, ofxFrameBuffer, and ofxFBOTexture) is that I expect the user to 
provide the texture rather than generating and storing them internally.

Personally, I think this clarifies what an FBO actually is: it's 
responsible for redirecting things from the screen; it doesn't actually 
store anything.

Maybe the best solution would be a mashup, like Pierre's in that when 
you enable things they are stored inside the ofxFBO by default -- but 
then you can override the internal attachment by setting your own manually?

class ofxFBO {
	void setup(int width, int height, int samples = 1, bool useDepth = 
true, bool useStencil = false);
	void addColor(ofTexture&, int location = 0);
	ofTexture& getColor(int location = 0);
	void clearColor();
	void addDepth(ofTexture&);
	void addStencil(ofTexture&);
	void begin();
	void end();
	wrapping, min/mag, fov, etc.

This way it's easy to do easy stuff (i.e., the standard usage of 
ofxFBOTexture) and only slightly harder to do harder stuff.



Memo Akten wrote:
> I've only just had a chance to look at this. Being a big fan of 
> code-reuse I really like Kyle's approach. Having to develop and add 
> various texture formats, features etc to ofxFBO and ofTexture isn't 
> ideal. Personally I would prefer if instead of ofImage it used ofTexture 
> (since ofImage is more about loading and saving files and image 
> processing, and ofTexture is an opengl texture wrapper). Obviously 
> Pierres one has MRT support, which is great. So a combo of the two would 
> be perfect!
> The Mega Super Awesome Visuals Company <http://www.msavisuals.com/>
> memo.tv <http://www.memo.tv/>	
> Studio 107. 7 Westgate St. London E8 3RL
> mob: +44 7958 783 832
> tel: +44 20 8123 9986
> fax: +44 20 8986 5496
> work: *www.msavisuals.com* 
> <file:///Users/memo/Documents/Branding/email%20sig/www.msavisuals.com>
> play: *www.memo.tv* 
> <file:///Users/memo/Documents/Branding/email%20sig/www.memo.tv>
> On 20 Jul 2010, at 18:56, Pierre Proske wrote:
>> That's pretty much why I had to come up with a new FBO because I was using
>> MRT and gl_FragData[] etc. I also made significant use of the depth
>> buffer, because I've used it for deferred shading, depth of field and
>> screen space ambient occlusion.
>> Having ofxShader and ofxFBO share similar method names would be great.
>>> For what its worth, I would 100% love to see a unified FBO and Shader
>>> setup for the next OF. I know i'm a bit of the odd man out here, but it i
>>> think it would make life a lot easier to have those standardized. I
>>> personally went digging through these the other day, only to notice the
>>> lack of standardized FBO addon
>>> As far as FBO functionality, optional attachments, opt in or out of depth
>>> buffer (its not needed for image processing 99% of the time), and 
>>> optional
>>> multiple render attachments (for FBO MRT - multiple render targets) would
>>> e the way to do it I think.
>>> You can attach multiple textures to the same FBO, and by using
>>> gl_FragData[X] rather than gl_FragColor, you can simultaneously write to
>>> multiple textures within one pass in the same FBO, using a shader.
>>> This allows you to do really fun things and do them really fast in one
>>> pass, and I think should be supported. You could initialize your FBO by
>>> pointing to an existing ofImage or ofTexture which would be
>>> GL_COLOR_ATTACHMENT_0, any additional ofTextures you add would be
>>> ATTACHMENT 1, 2, etc. This is very standard these days in terms of 
>>> support
>>> in drivers, and by having it optional (call
>>> ofxFBO.addTextureAttachment(ofTexture *someTexture, 1 / 2 / 3) or what
>>> not), its opt in, so advanced users could use multiple render 
>>> targets, and
>>> basic usage examples still work. MRT enables some really powerful and
>>> optimized rendering methods, and Im sure folks could really do fun things
>>> with it.
>>> Thats just a thought, but for what little its worth, 100% - combine the
>>> various FBO addons and standardize the basic functionality across the
>>> board (I like the begin() and end() semantics personally, both FBO and
>>> whatever ends up being ofxShader ought to use it I think).
>>> On Jul 19, 2010, at 5:29 PM, Pierre Proske wrote:
>>>> I guess I don't have a problem using a unified FBO that is more OF
>>>> friendly... but I'd like to see a full version demonstrating multiple
>>>> textures first. By the way, manually attaching the depth texture is done
>>>> on purpose. Because in some cases you may not want a depth texture. You
>>>> may want a stencil buffer instead, or something like that.
>>>> Also in some cases you would still want to use GL_RGBA16F_ARB, but in
>>>> your
>>>> example you would pass this to ofTexture instead, so it wouldn't
>>>> simplify
>>>> things that much.
>>>> What do you mean by depth maps not being handled? I thought they were
>>>> already.
>>>>> Hi everyone,
>>>>> I was just talking to Zach about the different FBOs, and some things I
>>>>> learned hacking my own ofxFBO last night. I thought it would be good to
>>>>> have a discussion about merging all the different features of the
>>>>> different ofxFBOs into a single really useful addon.
>>>>> ofxFBOTexture
>>>>> http://www.openframeworks.cc/forum/viewtopic.php?f=10&t=3143 
>>>>> <http://www.openframeworks.cc/forum/viewtopic.php?f=10&t=3143>
>>>>> I think this is the "original"? Has gone through many iterations and
>>>>> appeared in lots of repositories. The main advantage is that it's been
>>>>> tested across different systems (including iPhone/iPad). It's also easy
>>>>> to set up. But it is kind of messy, and hard coded to work with one
>>>>> texture (this is a major limitation).
>>>>> ofxFrameBuffer
>>>>> http://www.openframeworks.cc/forum/viewtopic.php?p=22035#p22035
>>>>> From Pierre, a wrapper for code on gamedev. Huge advantage is that it
>>>>> allows multiple textures to be attached and copied in/out. But it is
>>>>> more verbose and not as intuitive as ofxFBOTexture -- you have to
>>>>> manually attach the depth texture for example.
>>>>> ofxFBO
>>>>> http://www.openframeworks.cc/forum/viewtopic.php?p=22157#p22157
>>>>> Super minimalist FBO wrapper I wrote last night. I really like that you
>>>>> call setTarget(ofImage) to draw into an already allocated texture. This
>>>>> makes it easy to swap targets/attachments. I think this style, coupled
>>>>> with some warnings (e.g., your texture is not the same size as the FBO)
>>>>> and cross-operating system checks (like on iPhone) could be really
>>>>> intuitive but powerful. Instead of requiring you to pass
>>>>> GL_RGBA16F_ARB,
>>>>> it relies on ofTexture.
>>>>> So how can we combine these? What problems do people forsee? What use
>>>>> cases aren't handled (depth maps, etc.)?
>>>>> Best,
>>>>> Kyle
>>>>> _______________________________________________
>>>>> of-dev mailing list
>>>>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>>>>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>>>> _______________________________________________
>>>> of-dev mailing list
>>>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>>>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>>> Anton Marini //
>>> Post Production Video Effects
>>> Realtime Video Performance
>>> Video Engineering Services
>>> cell://646.309.1015
>>> http://noiseindustries.com
>>> http://vade.info
>>> http://yatesparks.com
>>> _______________________________________________
>>> of-dev mailing list
>>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>> _______________________________________________
>> of-dev mailing list
>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
> ------------------------------------------------------------------------
> _______________________________________________
> of-dev mailing list
> of-dev at dev.openframeworks.cc
> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc

More information about the of-dev mailing list