On Feb 2, 2005, at 3:46 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
heya, ...so, cgc and I chatted last nite, and I'm wondering if it's plausible
men, where do you do it ?
...hacked hotline server ("underline") with crypto: it was late...I have been poking in to #dataflow, so maybe we should set up a time? Or, I can try to log in earlier...
to add another symbol to gemhead for gemman to manage...the priority system would still be used for rendering order, but the new symbol would be used to determine which output/glcontext the render would go to (kinda like pd's send/receive objects): by default (ie. no extra symbol), output would go to the "main" gemwindow...if there is a symbol, then the output would go to the associated display output: so we'd need to add a symbol to each gemoutput: [gembuffer offscreen1]: this would be for pBuffer [gemwindow onscreen1]: this would be for primary display [gemdv onscreen2]: this would be a dv stream of the onscreen2 render [gemwindow onscreen2]: this would be for 2nd monitor display
i would rather associate the "context" with the [gemcontrol] object.
...if you prefer "context" over "output", I was talking about them as the same thing (by context I mean the gl environment, which at the moment is just associated with windows)
...then the gemheads would be something like the following: [gemhead 43 offscreen1]: this then renders to a pBuffer [gemhead -1 onscreen1]: this renders to the primary display [gemhead -2 onscreen2]: this renders to the 2nd monitor ...we'd then need the output [gembuffer offscreen1] to allow binding to texture for texturing on objects, which could then perhaps be rendered into another buffer, textured, then rendered into a scene for screen display...
that is exactly how i imagined it !
...yeah! Althought it could mean we're all crazy...
just one remark: the ordering of the context-name and the priority should be arbitrary: eg: [gemhead 10 offscreen] [gemhead blur] (==[gemhead 50 blur]) [gemhead bibs 32] ...
...no problem there, but I was thinking it'd be easier for backwards compatibility if we kept an ordering of priority then context name: if we can manage backwards compat. with arbitrary ordering, even better!
and probably "main" (or rather "") is attached to all contexts, like
[gemcontrol] context "" [gemcontrol offscreen] context "offscreen" [gemcontrol ot] context "ot"
[gemhead] renders to "", "offscreen", "ot" [gemhead ot] renders to "", "ot"
...yes, this is ok, but it may get confusing: how do we define which is the "main"/"" context? The first one created? The last one in the priority chain (because everyone would be rendered prior to it)?
and do we want to be able to connect one [gemhead] to multiple explicit contexts ?
like [gemhead here there everywhere]
...yep, this'd be good...
...any obvious problems?
yes, timing. i guess it would/could/should be possible to somehow handle [gemcontrol]s at different rates, e.g. only render once a second into a pbuffer (or even better: on demand!)
how do we handle this efficiently ? (esp. with respect to "time-based" objects, like [pix_movie] in auto-mode or particle-systems)
...have to admit I haven't looked much at this, but I will: what are the likely situations that could trip us up?
...otoh, couldn't we duplicate what is done now i pix_film? I mean, it's possible atm to run one film in auto-mode, and another in metro/"by-the-frame" mode: wouldn't this be our solution?
...another thought to take us further: glGenTextures() and glGenPrograms() both return unique id's for their association: I think these should also be globally accessible, perhaps by symbol or patch connection...this would be useful for manipulating the different texture units for multitexturing, plus it allows us to load a vertex or fragment program once into memory and continuously refer to it as needed, rather than loading the whole program every frame...
whew, jamie