[of-dev] FBOs

Pierre Proske pierre at digitalstar.net
Sat Jul 24 03:31:12 PDT 2010


Just a quick question  - what is the advantage of passing in textures?
Couldn't we just have internal dynamically allocated ofTextures instead as
well? As it was rightly pointed out in a previous post, all textures must
be the same size as the FBO, so you are kinda asking for trouble by
allowing people to specify their own sizes. If it was done internally,
this wouldn't be a problem, and would also result in less verbose code  -
my personal favourite ;)

> I've started writing a new FBO addon that combines all the features of
> this discussion, and have a quick question for everyone.
>
> I feel like you should only be able to pass in your own color
> attachments, and not custom depth or stencil attachments. The reason for
> this is that there's no OF wrapper/analog for render buffers. You could
> use a texture instead, but as I understand it, textures don't have the
> same features as render buffers when it comes to depth and stencil
> attachments.
>
> If no one has any objections/suggestions, I'm going to go ahead with
> making the depth and stencil attachments purely internal (but still
> toggle-able).
>
> Also, Keith, regarding your "fully nulled out FBO": I call it setup()
> rather than allocate() because it only tells the FBO what to expect. I
> was thinking that when you call begin() the first time it could do a
> quick check to see if you set a color attachment. If not, it would
> create an internal attachment. This would be transparent to the newbie,
> and have no drawbacks for the advanced user.
>
> Anton: definitely error messages if someone tries to use an FBO in a way
> other than how it was set up :)
>
> Kyle
>
> Keith Pasko wrote:
>> 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.
>> myFBO.allocate(width,height);
>> myFBO.begin();
>> myFBO.end();
>>
>> 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.
>>
>> k
>>
>> On Tue, Jul 20, 2010 at 2:38 PM, Kyle McDonald <kyle at kylemcdonald.net
>> <mailto: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://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 <http://www.msavisuals.com>*
>>         <file:///Users/memo/Documents/Branding/email%20sig/www.msavisuals.com
>>         <http://www.msavisuals.com>>
>>         play: *www.memo.tv <http://www.memo.tv>*
>>         <file:///Users/memo/Documents/Branding/email%20sig/www.memo.tv
>>         <http://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>
>>                         <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>
>>                         <mailto: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>
>>                     <mailto: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>
>>                 <mailto: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>
>>             <mailto: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 <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
>





More information about the of-dev mailing list