[GEM-dev] Offscreen naming poll!
ben at ekran.org
Tue Nov 29 19:03:44 CET 2005
does the buffer store pixels? or gemlist info?
manips makes sense I think, or a buffer folder?
I think the buffer calling should be like the pix_buffer stuff, where
you have a name [symbol] that stands for that buffer. I've not started
using the pix_buffer stuff yet, but I hope you can also use a "float" as
the name for looping through the buffers...
I've not looked at multitexture yet... I need more time.. I'm already
taking time off work to do all the PD stuff on my plate.
I'm not getting the whole picture on how the buffers will work exactly,
could you post a screenshot of an example patch?
Thanks for all the effort Jamie!
I'll get to pd 0.39 as soon as I can!!!
james tittle wrote:
> ...this weekend I wrote an object that allows offscreen rendering (or
> "render-to-texture") on a per renderchain basis, using framebuffer
> objects (FBO's, GL_EXT_framebuffer_object): it is really useful for
> playing with multiple rendering passes and shaders...I'd like to commit
> it, but it occurred to me that it might be good to see what we should
> name it, and where it should go in the folder hierarchy? Currently
> it's named [gemframebuffer], but really I think [gemoffscreen] would be
> better, since it could be implemented using pbuffers instead of FBO's,
> which would allow for some backward's compatibility (I think)...?
> ...also, on my harddrive I put it in src/controls (it would be inserted
> into a gemchain after [gemhead]), but I guess it could also go in
> src/manips, or even src/Nongeos?
> ...to give a bit more overview, it works by setting up color/depth/
> stencil rgb or float buffer(s) that you can render into, and basically
> it get's enabled at the start of render() and disabled in the
> postrender() call...the buffer is also bound to a texture ID, which can
> then be used in later gemchains (currently via [pix_multitexture]),
> where it currently requires using the glwrappers to make a geo to
> display on: I'd like to fix this so that there's an easier way to pass
> textures around based on their ID's: any ideas? Unless there's a way
> to determine width/height from a given texture ID, I think that
> dimension data will also have to be passed...
> GEM-dev mailing list
> GEM-dev at iem.at
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 256 bytes
Desc: OpenPGP digital signature
More information about the GEM-dev