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

[Daniel Heckenberg]

From: <zmoelnig at iem.at>
> 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

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