[PD-dev] [GEM] rendering context (gem2pdp)

zmoelnig at iem.at zmoelnig at iem.at
Wed Mar 5 09:17:14 CET 2003


Zitiere Daniel Heckenberg <daniel at bogusfront.org>:

> How about this:  
> - you can name a rendering context in each gemhead and have that
> rendering
> chain render to the context (be it a window, pbuffer or whatever).
> 
> -Each gemwin can also be named.

hi daniel, et al.

my plan (which might be influenced too much by other 3d-rendering software) was 
rather not make completely independent rendering-chains (by naming them and 
connecting them via the name to a gemwin) but use the [gemhead]s rendering-
chains globally connected to multiple [gemwin]s.
The [gemwin]s could be controlled independently with respect to 
camera/viewpoint, bg-color, size, but also offscreen-rendering.
This is really heavily influenced by the "camera"-idea of other software.

but on the other hand it is a lot of work to be done


> -A new gembuffer object which manages pbuffer rendering and takes a
> name
> argument also...?.  It outputs a bitmap in pix_ compatible form that may
> be
> connected to pix_ object or the pdp bridge.

there is this [pix_snap]-object that does exactly this.

thinking out loud: [gemwinOFF] (like offscreen) should have an outlet for 
imageStruct-data (used by but not compatible with pix_ -- since we don't need 
all the cache and newimage-overhead)

mfg.a.srd
IOhannes

PS: i'm still not sure, whether it's a good idea, to have rendering-sinks (like 
pix_write) directly in the rendering-chain - but i guess it's not so good, 
although it is more flexible.






More information about the Pd-dev mailing list