Beckman Institute            University of Illinois at Urbana-Champaign             

Documentation Table of Contents

This tutorial will intreoduce you to the concept of peer-to-peer reality. To work along with the examples, you'll need to either have compiled the szg library and the Syzygy Python bindings or have installed a Syzygy SDK as appropriate for your system.

First, note that you must be running in Cluster Mode (see the Distributed OS chapter).

You will open three fresh terminal windows on your desktop.

In the first, run szgd.

In the second, type:

    dex <computer> szgrender -szg virtual=foo -szg mode/graphics=SZG_DISPLAY7
    dex <computer> inputsimulator -szg virtual=foo

Substitute the name of your computer as printed by dconfig for <computer>.

The virtual=foo parameter corresponds to a virtual computer name, though you need not have a virtual computer named foo defined for this to work. Syzygy programs using the same virtual computer will communicate with one another to the exclusion of others.

Note the mode/graphics=SZG_DISPLAY7 parameter. This tells szgrender to configure its window and camera according to the XML configuration stored in the global parameter whose name is stored in SZG_DISPLAY7/name. We picked SZG_DISPLAY7 so that we would be very likely to get a default window configuration (i.e. SZG_DISPLAY7/name is undefined).

In the third window, type:

    dex <computer> szgrender -szg virtual=bar -szg mode/graphics=SZG_DISPLAY8
    dex <computer> inputsimulator -szg virtual=bar

The second szgrender window and the second inputsimulator windows will likely come up on top of their predecessors. Consequently, you might (mistakenly) think that they failed to launch. Note that SZG_DISPLAY8 is used here instead of SZG_DISPLAY7. Syzygy only lets one program at a time use a particular (virtual) display on a single computer. Hence, these must be different.

Now, to launch the sample applications (or peers). Unfortunately the -szg virtual=foo trick will not work with Python programs so we have to get this information in some other way. In window 2, type the following:

    export SZGCONTEXT="virtual=foo"

Now, run the example peer program like so:

    python peer.py world0

A sphere will appear in one of the szgrender windows and start changing colors rapidly.

Your local geometry (the sphere) is attached to the shared world's world0 part, which is also the name of your peer. Valid peer names (for this particular example) are world0 through world99 (see the code).

Now, go to window 3 and type:

    python peer.py world1 world0

This peer's geometry will attach to shared world's world1 part. Furthermore, we attach to peer world0 (the one we launched before) to grab its geometry and send ours over.

A second sphere will now appear in the first szgrender window (the foo window) and two spheres will appear in the bar szgrender. The scenes are now the same. The foo peer is responsible for the foo sphere but also displays the bar sphere, as received from the bar peer and vice-versa.

It is possible to navigate independently.

It is possible to move the observers' heads independently.

This very simple example could be easily extended to have a complex shared virtual world based on the Myriad scene graph (peer-to-peer reality). For instance, if you had two CAVEs, CAVE1 and CAVE2, which were controlled by virtual computers cave1 and cave2 respectively, you could build an application shared_world such that

    dex cave1 shared_world
    dex cave2 shared_world

would bring up a shared virtual environment.

[Schedule] [Labs] [Beckman Meeting Rooms] [Equipment] [Projects] [CUBE Projects] [Syzygy] [VSS] [People] [Events] [Publications]