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