[of-dev] FBOs

Keith Pasko keith.pasko at gmail.com
Tue Jul 20 18:02:28 PDT 2010

I would imagine a lot of newcomers to the FBO world would want to call an
allocate or setup function once, and automatically have a texture bound so
that simplest use case is as minimal as possible, i.e.

while it may not have bells and whistles, this is crazy easy to use and a
big asset on its own over only a screen buffer...and then, probably enough
for a lot of peoples' uses.

That said, the advanced users (obviously) want sweet bonuses all kinds.
Depth, stencil, samples, and format can all be default params as below from
Kyle, making it work well for both cases; which leaves, I think, only the
issue of textures?

Agreed, the conceptual distinction that an FBO is not a texture is a valid
one, so it probably shouldn't extend ofTexture but probably just include
one, out of convenience.

What about adding another default param in the setup for a texture
reference, defaulting to NULL or somesuch, so that the beginner use can test
against NULL positively and generate a texture, while advanced users test
negatively by passing in a texture ref they'd like to use. Naturally you
could add further texture attachments after initialization in either case.
Only use case this doesn't cover I think is if you really want a full on
nulled out FBO sans-texture-whatsoever.

I think that allowing for a very simple fbo-babystep is crucial, for those
who simply want an easy off-screen buffer to draw into (and get pixels from,
which is also easy now). Any further and fancier use of FBO I feel is
probably for those who really do want to use and control it all, and I think
(perhaps wrongly) that there are few users that would fall in between. I
suppose philosophically what I'm proposing is the most advanced version
possible as the baseline with options for everything you'd want, and then
defaulting everything for people who don't care to use with ease.

Anyhow, my 2c.


On Tue, Jul 20, 2010 at 2:38 PM, Kyle McDonald <kyle at kylemcdonald.net>wrote:

> One more place worth looking for inspiration is Cinder:
> http://github.com/cinder/Cinder/blob/master/include/cinder/gl/Fbo.h
> http://github.com/cinder/Cinder/blob/master/src/cinder/gl/Fbo.cpp
> 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.
> Thoughts?
> Kyle
> 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
> _______________________________________________
> of-dev mailing list
> of-dev at dev.openframeworks.cc
> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.openframeworks.cc/pipermail/of-dev-openframeworks.cc/attachments/20100720/ea8ee99d/attachment-0003.htm>

More information about the of-dev mailing list