memo at memo.tv
Tue Jul 20 14:14:19 PDT 2010
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!
Studio 107. 7 Westgate St. London E8 3RL
mob: +44 7958 783 832
tel: +44 20 8123 9986
fax: +44 20 8986 5496
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
>>> example you would pass this to ofTexture instead, so it wouldn't
>>> things that much.
>>> What do you mean by depth maps not being handled? I thought they were
>>>> 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.
>>>> 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).
>>>> 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.
>>>> 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
>>>> it relies on ofTexture.
>>>> So how can we combine these? What problems do people forsee? What use
>>>> cases aren't handled (depth maps, etc.)?
>>>> of-dev mailing list
>>>> of-dev at dev.openframeworks.cc
>>> of-dev mailing list
>>> of-dev at dev.openframeworks.cc
>> Anton Marini //
>> Post Production Video Effects
>> Realtime Video Performance
>> Video Engineering Services
>> of-dev mailing list
>> of-dev at dev.openframeworks.cc
> of-dev mailing list
> of-dev at dev.openframeworks.cc
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the of-dev