[PD] multiple_window feature of Gem?
mike at ozmediasolutions.com
Mon Mar 21 18:59:41 CET 2005
Thanks for the input,
It's funny that you've pointed me to Sebastien Roy and the Open Territories
project, since I'm actually working with the Zack Settel - who's quite
affiliated with Open Territories and the SAT. (To Zack: welcome to the
I guess we could strengthen our ties on this? ...we seem to be working on
things that would mutually benefit each other.
To Sebastien: What kind of rendering engine does the Open Territories
immersive projection system use? If you use Pd, how good is your
communication between Pd and your rendering engine? Have you thought about
displaying Gem output in your environment?
We would really like to display Gem in our immersive environment because our
graphical output is highly coupled with our audio processing. The main
problem is how to distribute the processing for the displays among the
various machines? B. Bogart offered the solution below of sending graphic
control messages via OSC. This is what we've been thinking, and the fact
that v_oscout and v_oscin objects exist that sync the patches on remote
machines is quite nice.
Ideally, we would probably like the multiple_window feature of Gem work
across remote machines... but IOhannes has responded:
"the problem is that as multiple_window is done right now, it depends on
display-list sharing, which is not possible across multiple machines. thus
it doesn't yet work to have one "master" machine running the gem-patch and
several slaves which do the actual drawing."
He also mentioned that we could try using Chromium (http://chromium.sf.net)
instead. Perhaps it's possible to develop some Chromium objects for Gem? I
really have no idea if this is possible... any comments?
P.S. In addition to myself, we have some summer students at McGill that will
be working on this problem. So we could probably make a decent effort into
extending Gem to work in immersive environments!
----- Original Message -----
From: "B. Bogart" <ben at ekran.org>
To: "Mike Wozniewski" <mike at ozmediasolutions.com>
Cc: <pd-list at iem.at>; "Sebastien Roy" <roys at iro.umontreal.ca>
Sent: Monday, March 21, 2005 11:04 AM
Subject: Re: [PD] multiple_window feature of Gem?
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.
Mike Wozniewski wrote:
> 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
> 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
> Thanks a ton,
> Mike Wozniewski
More information about the Pd-list