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.