heya,
...well, so far so good: no one's having problems with the osx test version...but everyone keeps asking offscreen rendering, which seems to be about rendering different things to different windows...I'm working on an example patch which will show how to do "frustum culled" rendering, where objects are just rendered in different places out of the direction of view of each other, but this isn't doesn't help the idea of pBuffers...
...so, cgc and I chatted last nite, and I'm wondering if it's plausible 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
...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...
...any obvious problems?
jamie
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 ?
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.
...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 !
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] ...
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"
and do we want to be able to connect one [gemhead] to multiple explicit contexts ?
like [gemhead here there everywhere] ?
...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)
mfg.as.dr IOhannes
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
james tittle wrote:
On Feb 2, 2005, at 3:46 AM, IOhannes m zmoelnig wrote:
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!
i don't think that it will be problematic with respect to backward compatibility (which is an absolute _must_)
but what, if we want different priorities for different contexts ?
(this is going to be very complicated, but once we are through it we might gain world dominance)
mfg.asd.r IOhannes
james tittle wrote:
On Feb 2, 2005, at 3:46 AM, IOhannes m zmoelnig wrote:
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)
probably the question should be: "how do we handle this at all ?"
...have to admit I haven't looked much at this, but I will: what are the likely situations that could trip us up?
the simplest situation: when time-based objects (eg particle-systems, i think pix_film (at least on osX (good work!)) does not has this problem), just increment their internal time when getting "rendered" by a value somehow derived from the current frame-rate (if i remember correctly); now if we have 2 windows, an object's render()-method might get called 2 times per frame (once for each window), which would double increment the internal time, leading to (appearent) double speed. currently this problem is solved by compiling the scene into display-lists and just calling these repeatedly (which does not affect any internal time-measurement); however, this is likely to _not_ work under certain circumstances (e.g. i jsut discovered that on linux, you cannot render simultaneously into a local window and a remote window the way it is implemented right now)
but (see below)
...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?
i seldomly use [metro] to run a [pix_film] in "by-the-frame" mode, since the jitter is quite high. instead i get my timing directly from the render-clock (with a [t a b]).
all these problems would not occur, if the render clock would not be exposed to pd's message system. however, i do not really want to go back to the old behaviour (e.g. use [render_trigger] instead of [t b a b])
furthermore, similar problems arise, if we want to do the rendering in a separate thread (which i do want somewhere in the future)
mfg.asd.r IOhannes
On Feb 4, 2005, at 3:25 AM, IOhannes m zmoelnig wrote:
i think pix_film (at least on osX (good work!)) does not has this problem), just increment their internal time when getting "rendered" by a value somehow derived from the current frame-rate (if i remember correctly);
Don't use pix_filmDarwin as a model for anything!! It's complete hack work and I only stand by it because it does work. I would recommend finding a more elegant way to enable objects to have their own internal timing. I don't know what that would be though.
cgc
Hey Jamie,
I've not had a chance to play with your binary distro, but I'm certainly exited about the prospect. Indeed I am also more interested in managing multiple windows with different contents, rather than running multiple instances of Gem to control two windows with different contents.
so [gemwindow onscreen1] would create a new window context with the symbol name "onscreen1" then gemhead 1 "onscreen1" would render only to this nammed context? I think this is a great solution in Gem, certainly quite intuitive.
(what do the negative render-priorities in your examples do?)
This functionality is really making me drool. :)
so would we also name each gemcontrol object to bind it to a particular window's symbol? Would we use gemcontrol to say, colour the background colour of a pbuffer, the way we colour the background of a window?
It would be nice to tell a gemhead to render on a particular context but also a set of them [gemhead 1 onscreen1 onscreen2] but I would say this is probably not needed, since I think most people would want to tell objects to render to some specific window, not a group of them. I'm sure there is some great creative use for having this feature though.
How does the timing work now with multiple-windows? Are they all locked into the same framerate? The only reason I could see needing different frame-rates for each window would be if you wanted to save CPU usage on your personal "preview" window when rendering at 60fps on the second screen... Otherwise I think it would be fine to lock all windows to the same framerate. (I could be misunderstanding the timing issue here).
I'm going to download the test binary now...
B>
james tittle wrote:
heya,
...well, so far so good: no one's having problems with the osx test version...but everyone keeps asking offscreen rendering, which seems to be about rendering different things to different windows...I'm working on an example patch which will show how to do "frustum culled" rendering, where objects are just rendered in different places out of the direction of view of each other, but this isn't doesn't help the idea of pBuffers...
...so, cgc and I chatted last nite, and I'm wondering if it's plausible 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
...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...
...any obvious problems?
jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Hey ben,
On Feb 2, 2005, at 12:57 PM, B. Bogart wrote:
I've not had a chance to play with your binary distro, but I'm certainly exited about the prospect. Indeed I am also more interested in managing multiple windows with different contents, rather than running multiple instances of Gem to control two windows with different contents.
...this is a good point: with multiple machines running independent instances of GEM, you can certainly do something similar to what we're working on...this may still be necessary for some projects (we all know that computers can usually only do just under what we want!)...
so [gemwindow onscreen1] would create a new window context with the symbol name "onscreen1" then gemhead 1 "onscreen1" would render only to this nammed context? I think this is a great solution in Gem, certainly quite intuitive.
...exactly...
(what do the negative render-priorities in your examples do?)
...this stems from IOhannes saying "hmm, if we use an integer to represent 1 to 100, what are we going to do with the unused negative numbers?"...negative render-priorities are rendered after the positive ones, so it kinda goes like this:
- set up viewport/angle - we proceed 1 to 100 (actually don't know if 100 is just an arbitrary end or not?) - reset viewport/angle - proceed -100 (again, don't know if -100 is an arbitrary beginning?) to -1 - end of render
...may be useful, maybe not...
This functionality is really making me drool. :)
...(spittoons not provided)...
so would we also name each gemcontrol object to bind it to a particular window's symbol? Would we use gemcontrol to say, colour the background colour of a pbuffer, the way we colour the background of a window?
...depends on what functionality is built in to the gemoutput: atm, [gemwindow] responds to the same messages that [gemwin] used to...I image many of same commands would work the same for a pbuffer, but some wouldn't (can't understand why we'd want to respond to [border <, [offset <, etc)...
It would be nice to tell a gemhead to render on a particular context but also a set of them [gemhead 1 onscreen1 onscreen2] but I would say this is probably not needed, since I think most people would want to tell objects to render to some specific window, not a group of them. I'm sure there is some great creative use for having this feature though.
...I agree that we'll usually just associate most gemheads with one output, but we always try not to limit ourselves in gem functionality/flexibility...it may be necessary to accept multiple contexts if we restrict asset accesses thru a namespace mechanism...or if we introduce "un-shared" contexts...
How does the timing work now with multiple-windows? Are they all locked into the same framerate? The only reason I could see needing different frame-rates for each window would be if you wanted to save CPU usage on your personal "preview" window when rendering at 60fps on the second screen... Otherwise I think it would be fine to lock all windows to the same framerate. (I could be misunderstanding the timing issue here).
...again, flexibility is paramount! But, [gemcontrol] handles the frame rate message, so all outputs associated with it would have the same frame rate...as it is right now, that means all windows have the same frame rate, because right now you can only have one [gemcontrol]...
...this brings up something I hadn't thought about earlier: on osx, pbuffer creation depends on a pixel format compatibility with the current context...this makes me tend to think that buffers might need to be associated with a certain display...but then, if we're doing everything in a shared-context situation (as we are), this shouldn't be an issue...
I'm going to download the test binary now...
...cool! I always look forward to your new screenshots: I'm trying to play with gem more than code, but it's hard not to code!
jamie