Zitiere Daniel Heckenberg daniel@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.