[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