[GEM-dev] musings on multiple_window

[B. Bogart]

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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20050202/ee6607cd/attachment.pgp>