From: zmoelnig@iem.at
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
hmm. this would be quite nice, certainly.
but if i understand correctly, if you actually wanted independent content on different displays then you'd have to carefully physically separate the objects in the scene?
also, in openGL you would actually need to send the geometry to each rendering context independently anyway, no?
perhaps we could get the best of both worlds with the default (unnamed) gemheads rendering to every gemwin or gemwinOFF... and others having a list of rendering contexts to which they will render?
-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)
yup, I was thinking of something like "gemwinOFF" when I said gembuffer.
pix_snap does do what tom needs to do for screen buffers. however it is hideously slow, at least on my hardware.
we need to ensure that wherever possible, fast paths are allowed or provided. ie once you've rendered to an offscreen context which is a pbuffer, you can use that as a texture straight away without extracting the pixels and reloading it as a texture. (that reminds me: i have a pix_snap2tex object that does this in a pix_snap kind of way and runs 100 times faster on my box)
i suspect that on most hardware, any method for getting rendered output back into main memory will be slow... but we should certainly support it. anyone using mesa or an sgi would not see any speed problems. actually, i've read that os x has good, fast readback support. is this true, mac people?
daniel