[GEM-dev] Re: [PD] multiple_window feature of Gem?

[B. Bogart]

Hey all,

I've moved the discussion onto the gem-dev list. I think the pders have
had enough of this discussion!

I did not see a link to any in depth documentation from chromium. It
does sound very promising... I'm not a c++ programmer so I'm not sure
what it would involve to build these functions into GL wappers for Gem.
I'm not sure how the functions latch onto an existing context, and how
the whole thing works architecturally (what parts run on what machines,
master slave connections etc..

Since Gem is a library you can use gem-dependant objects anyware but
inside Gem. Due to this I think all "externals" for Gem have been
included in Gem proper. (why not?) The tiled display and multiple view
stuff looks quite useful. Sebastien, do you think lighTWIST could end up
being a set of objects for pd/Gem? Perhaps based on something like
chromium (is it GPL?) plus your distortion stuff?

I just wonder about performance, considering the speed of the AGP bus
for texture transfers vs ethernet transport between the source and
destination for the texture! especially if your talking about moving
video... (are you guys even using video in your cave application?)

Anyhow gem-devers this discussion does sound interesting, I'm sure some
of you have ideas about Gem clustering for N projectors/machines.

B.

Mike Wozniewski wrote:
> B. Bogart wrote:
>
>> The IDEAL solution would be a system that could take the RENDER data
>> from the pixelTANGO gem-chains (well the whole context) pass the entire
>> thing onto the multicast network and somehow dynamically build a copy of
>> the pixelTANGO patch in a non-Gem host. That is you have a magic little
>> application that just dynamically clones an exitsing GL context over
>> network. Once we have the copy in the projector machine we can crop it
>> for that projector, and apply the deformation grid. Of course references
>> to pixel textures in memory, framegrabbers etc.. would not be
>> interpreted propely. I don't see how chromium deals with this part of
>> transporting the texture/video data...
>
>
> Although I've just learned of Chromium, it sounds like it may be the
> ideal solution we're looking. From what I can tell, all that Chromium
> does is intercept openGL commands from arbitrary OpenGL applications,
> bundles them in a "stream", and passes them thru a 'Stream Processing
> Unit' (SPU) chain. At the OS-level, Chromium pretends that it IS the
> OpenGL library, hence it is transparent to the application.
>
> Some side-notes:
> -This means that Gem might not need to be modified at all (!) ...and it
> looks like Chromium supports pretty much all of standard OpenGL through
> version 1.5, which should be sufficient.
> - There exists a Tilesort SPU. This distributes the stream to various
> machines, creating a tiled display (ie, each machine gets one tile to
> render). Furthermore, there is a non-planar version of Tilesort SPU
> where you can specify different viewing frustums for each machine -
> Perfect for a CAVE, or immersive environment! (see
> http://chromium.sourceforge.net/doc/nonplanar.html for more details).
> - To answer your texture question: there's a distributed texture SPU...
> from the Chromium docs: "The idea is that a program can use write-mode
> to distribute texture image data on a rendering cluster the first time
> the program is run. Then, the second and subsequent runs can use
> read-mode to quickly read the texture data from the render servers,
> instead of passing it all through the Chromium tilesort SPU."
> - I didn't see any mention of dynamic textures though :(  ...but if
> you're talking about video files that already exist on disk somewhere,
> then perhaps it's possible. See
> http://brighton.ncsa.uiuc.edu/%7Eprajlich/wall/ppb.html for an example
> of showing movies on a tiled wall display using Chromium.
>
> I'm going to look into Chromium a bit more. We'll be in touch again
> sometime soon.
>
> Cheers,
> Mike Wozniewski
>
> P.S. I've added one more person to the discussion: Jeremy Cooperstock,
> who is our project supervisor. I believe that some of you probably know
> each other already.
>
>
-------------- 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/20050321/b937f079/attachment.pgp>