[of-dev] FBOs

Anton Marini anton at vade.info
Tue Jul 20 09:45:19 PDT 2010

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
>> 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
>> 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

Anton Marini //

Post Production Video Effects 
Realtime Video Performance
Video Engineering Services



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.openframeworks.cc/pipermail/of-dev-openframeworks.cc/attachments/20100720/808b3b60/attachment-0003.htm>

More information about the of-dev mailing list