hi,
may be you should check out the developer's list, apparently James had done something on it.
Cheers, SFS
On 21 Mar 05, at 5:04 PM, B. Bogart wrote:
The simplist solution:
#1. Make your world in pd/Gem. #2. Make your patch OSC controllable (have an OSC name for each object you want to control.) #3. Copy the patch to each machine running each projector. #4. for each copy (each machine) change the view via the "view" gemwin method. #5. On your "control" machine send the OSC values out that you use to set each gem paramter.
Ideally you could multicast the OSC data over the projection machines so you only need to send the data once... (no support in pd for multicasting netsend yet...)
I've cced Sebastien Roy of UofMontreal who is working on the Open Territories immersive projection system. It is controlled by pure-data but pure-data is not doing the rendering part.
Also my v_ abstractions that are GOPS that send their values over OSC and will also receive on OSC. You just make one patch with the abstractions, copy it. On the client (master) you put in a v_oscout and on the server (slave) you put in a v_oscin then like magic both patches are synced... This project is not longer being supported, and hopefully all the functionality will eventually get rolled into pixelTANGO.
b>
Mike Wozniewski wrote:
Hi.
I've found some mention to the "multiple_window" of Gem. How do I get started with this? Are there any docs that describe how to get Gem working in multiple windows?
Also, we're trying to run Gem in an immersive environment, with several projectors maintained by different machines. Originally, we were going to have multiple copies of the same Pd/Gem environment running on each machine, with some synchronization controls being sent through the network. But I'm excited about using the multiple_window feature to perhaps have only one machine running the environment, and just sending the other Gem windows to the other machines. Can someone explain how I would go about doing this?
At some point, IOhannes said:
"it is kind of X-forwarding; my guess was, that since X is forwarding only the openGL-instructions (instead of the window "pixel" contents) this should be fast enough (except when big textures are involved, where we are at the stage of normal pixel-forwarding)"
How do I send the multiple Gem windows to various other machines in this lite fashion so that only openGL instructions are sent, and not the full contents?
Also, if James Tittle is out there:
Did you ever finish your example patch that shows how to do "frustum culled" rendering with multiple windows in Gem? It is quite essential that we be able to display different views of our 3D environment on each of the screens, and that the viewing frustums line up according to screen geometry. Any examples that you have of this would be greatly appreciated.
Thanks a ton, Mike Wozniewski
slimboyfatboyslim http://www.slimboyfatboyslim.org