\documentclass[letterpaper,11pt,oneside,onecolumn]{article}
\author{Andrew C Ofisher, Ryan T Mulligan}
\title{Shared Worlds with Syzygy \\ assorted Shared World scripts running on a Phleet \\ Math 198}
\usepackage{hyperref}
\usepackage{graphicx}
%\usepackage{showidx} for debug only
\makeindex

\begin{document}
\maketitle

\begin{abstract}
By operating a Phleet among an arbitrary number of heterogeneous physical machines, one can use Syzygy scripts to create and manipulate a Shared World.
Script demos explore different aspects of Scenegraph sharing.
Detailed documentation of Phleet setup for various configurations is also provided.
Included are the Phleet and Syzygy setups for Windows, Linux 32 bit, Linux 64 bit, Mac OS X, and Mac OS X x86 operating systems. Phleet and Syzygy instructions included for running a Phleet of Virtual Computers on a single physical computer.
\end{abstract}
\pagebreak

\tableofcontents
\listoffigures
%\listoftables

\section{Definitions}
\begin{description}
  \item[Virtual Environment]\index{Virtual Environment} The amalgamation of graphics, sound, and tactile outputs that make up a coherent experience.
  \item[Syzygy]\index{Syzygy} Syzygy is a computer program that allows you to build Virtual Environment computer applications.
  \item[Phleet]\index{Phleet} Any number of Physical Computers and Virtual Computers being serviced by a single Syzygy Server.
  \item[Virtual Computer]\index{Virtual Computer} A single entity which abstracts one or more Physical Computers. A single Physical Computer can run an arbitrary number of Virtual Computers within itself, and belong to an arbitrary number of Virtual Computers spanning multiple Physical Computers.
  \item[Scenegraph]\index{Scenegraph} A collection of information about how to execute a Virtual Environment.
  \item[Shared World]\index{Shared World} The result of sharing a Syzygy Scenegraph among multiple Virtual Computers in the same Phleet \footnote{Though not a requirement, a Shared World typically results in both Virtual Computers displaying the same Virtual Environment.}
  \item[Dex]\index{Dex} D(istributed)ex(ecution). This command runs a Syzygy program on a specific Virtual Computer.
  \item[EZSZG]\index{EZSZG}A unix shell that establishes many of the proper paths for running Syzygy commands and applications on a Physical Computer.
  \item[Batchfile]\index{Batchfile} A batchfile is a plain text file that initializes all of the paths and operating procedures of the Virtual Computers in a Phleet. Only Controller Computers need batch files.
  \item[SZG Daemon]\index{szgd} A daemon program that maintains a local SZG Database, and handles Dex requests.
  \item[Peer Computer]\index{Peer Computer} A physical computer that is part of a Phleet and will be running a SZG Daemon.
  \item[Server Computer]\index{Server Computer}A physical computer that hosts a szgserver for a Phleet. There must be one and only one Server Computer per Phleet.
  \item[Controller Computer]\index{Controller Computer} The computer on which someone executes Dex commands to the rest of the Phleet. An arbitrary number of Controller Computers can exist in a Phleet.

\end{description}


\section{Outline for Creating a Shared World}
\label{section:shared_world_checklist}
\begin{enumerate}
  \item Setup a Phleet (See section \ref{section:phleet_setup})
  \item Create or acquire a shared--world enabled Syzygy script(s)(See section \ref{section:shared_world}).
  \item Dex the script(s) on each Virtual Computer in the Phleet
\end{enumerate}

\section{Setting Up A Phleet}
\label{section:phleet_setup}
Setting up a Phleet\index{Phleet} can be a complicated task, involving permissions, firewall and network issues. For this section it is assumed that you have managed to get all the physical computers in a state where they can communicate with each other.These instructions also assume that reader knows how to enter an EZSZG shell. None of the three Computer Instruction types are mutually exclusive of one another, for instance a single Physical Computer can be a Server, Peer, and Controller Computer.

\subsection{Server Computer Instructions}
\label{subsection:server_computer_instructions}
\begin{enumerate}
  \item Place a szg.conf file in its appropriate location. (See section \ref{section:szg_config_files})
  \item In an EZSZG shell type
  \begin{verbatim}szgserver ServerName Port &\end{verbatim}
  where ``ServerName'' is the arbitrary name of your server, and ``Port'' is the port number on which you want your server to communicate. The ``\&'' indicates that the szgserver should run as a background process. Conventionally szgservers are named with the prefix ``srv''.

  Examples:
  \begin{verbatim}
szgserver srvlab 4343 &
szgserver srvisl 4343 &
szgserver srvhome 4343 &\end{verbatim}
\item Your server is now set up.
\end{enumerate}

\subsection{Peer Computer Instructions}
\label{subsection:peer_computer_instructions}
\begin{enumerate}
  \item Place a szg.conf file in its appropriate location. (See section \ref{section:szg_config_files})
  \item In an EZSZG type
  \begin{verbatim}dlogin ServerName YourName\end{verbatim}
  where ``ServerName'' is the what you called the server and ``YourName'' is your real first name, or any arbitrary identifier. If your server is not broadcasting its name properly you can alternatively dlogin using the server's IP Address by typing
  \begin{verbatim}dlogin ServerIPAddress Port YourName\end{verbatim}
  Examples:
  \begin{verbatim}
  dlogin srvlab ryan
  dlogin 111.111.111.111 4343 ryan\end{verbatim}

  \item Run the SZG Daemon by typing
  \begin{verbatim}szgd&\end{verbatim}
  in an EZSZG.
\end{enumerate}

\subsection{Controller Computer Instructions}
\label{subsection:controller_computer_instructions}
\begin{enumerate}
  \item Place a szg.conf file in its appropriate location. (See section \ref{section:szg_config_files})
  \item In an EZSZG type
  \begin{verbatim}dlogin ServerName YourName\end{verbatim}
  where ``ServerName'' is the what you called the server and ``YourName'' is your real first name, or any arbitrary identifier. If your server is not broadcasting it's name properly you can alternatively dlogin using the server's IP Address by typing
  \begin{verbatim}dlogin ServerIPAddress Port YourName\end{verbatim}
  Examples:
  \begin{verbatim}
  dlogin srvlab ryan
  dlogin 111.111.111.111 4343 ryan\end{verbatim}

  \item In an EZSZG shell type
  \begin{verbatim}dbatch BatchfileName\end{verbatim}
  where BatchfileName the path to the plain text file which contains your Batchfile. (See section \ref{section:batch_files})

  Examples:
  \begin{verbatim}
dbatch debautch
dbatch winprofile
dbatch foo.txt\end{verbatim}
\end{enumerate}

\subsection{Syzygy Config Files}
\label{section:szg_config_files}
Syzygy Config files contain information specific to a Physical Computer. The placement of these files on the local filesystem is crucial. The default path locations can be found in Table \ref{table:szg.conf}. To override the default path location you need to set the SZG\_CONF environment variable on your system\footnote{On Unix, the default szg.conf path is in owned by root, this means to change anything with the command line szg.conf tools you need to use sudo, or define a non-default path for the szg.conf file in a user owned area.}. By default the SZG\_CONF environment variable is NULL. If you set it to a system path, Syzygy will look at that path for a szg.conf file.

\begin{table}
\begin{center}
\begin{tabular}{l l}
Operating System & Path \\
\hline
Microsoft Windows & C:$\backslash$szg$\backslash$szg.conf \\
Unix Based & /etc/szg.conf
\end{tabular}

\caption{default szg.conf paths}{for various operating systems\label{table:szg.conf}}
\end{center}
\end{table}

A sample szg.conf file can be found in Figure \ref{fig:szg_config}. Many of the changes to this file are fairly self-explanatory. To edit them simply change the value between the tags. The name tag is the name of the Physical Computer where the file is located. The first interface should always have the name ``internet'' and it's address tag should be the ip address of the Physical Computer. The mask should be the sub-net mask for this Physical Computer. The ports configuration should be left alone as the default, but should be there so that Syzygy knows what ports to use for communication.

The only tricky thing is the second interface listed in the file. This is the interface corresponding to the other Physical Computer in the Phleet. A szg.conf file needs to have an interface to every other Physical Computer in the Phleet if the Phleet traverses multiple sub-nets, or communicating across the internet\footnote{This means that the Phleet described by this szg.conf file has two computers named laptop and desktop. The laptop's IP address was 192.168.4.1 and the desktop's IP address was 192.168.5.1. Both were being connected to one another in a Shared World.} \footnote{This seems to violate the purpose of a szg.conf file because you are storing stuff about the Phleet in it when it seems that the original purpose of it was to store just information about particular Physical Computers and never require changing. Unfortunately this requirement has been verified by us when doing Syzygy experiments over the Internet.}.

\begin{figure}
\begin{center}
    \hrule
    \begin{verbatim}<computer>
      <name>laptop</name>
    </computer>

    <interface>
      <type>IP</type>
      <name>internet</name>
      <address>192.168.4.1</address>
      <mask>255.255.248.0</mask>
    </interface>

    <interface>
      <type>IP</type>
      <name>desktop</name>
      <address>192.168.5.1</address>
      <mask>255.255.248.0</mask>
    </interface>

    <ports>
      <first>
      4700
      </first>
      <size>
      200
      </size>
    </ports>\end{verbatim}
    \hrule
    \caption{szg.conf file}{}
    \label{fig:szg_config}
\end{center}
\end{figure}

\subsection{Batch Files}
\label{section:batch_files}
A batch file is an XML document. It specifies the workings of a Phleet in such a way that a Controller Computer can figure out what commands to send to the Syzygy Daemons running on the Peer Computers. The file begins with the \begin{verbatim}<szg_config>\end{verbatim} tag and can include \begin{verbatim}<comment></comment> and <assign></assign>\end{verbatim} tags. The file ends with the \begin{verbatim}</szg_config>\end{verbatim} tag. The syntax for assign statements is the same as a when using the dset command.
\begin{verbatim} ComputerName SZG_VariableSpace variable value\end{verbatim}
where ``ComputerName'' is the Physical Computer name defined in a szg.conf file\ref{section:szg_config_files} ~or a name you have picked for a Virtual Computer, and SZG\_VariableSpace is one of the variable spaces talked about below.

\paragraph{Physical Computer Configuration Statements}
\label{subsection:physical_computer_configuration_statements}
Certain paths must be set so that the Controller Computer can tell the Physical Computers of the Phleet where to look for Syzygy files. These paths need to be set for every Physical Computer in the Phleet. Below is a list of the SZG\_VariableSpaces applicable to Physical Computer Configurations.

\begin{description}
  \item[SZG\_EXEC] This stores the path to any program that a Physical Computer depends on to run Syzygy. Examples include: szgrender, inputsimulator, python. This path need not include the path to Python based Syzygy scripts!
  \item[SZG\_PYTHON] This stores the path to any Python based Syzygy script that you wish your controller computer to be able to run.
\end{description}

\begin{figure}
\begin{center}
    \hrule
\begin{verbatim}<comment>
Physical Computer Configuration
</comment>
<assign>
  desktop SZG_EXEC path c:\Python24;c:\szg-1.0\bin
  desktop SZG_PYTHON path c:\szg-1.0\doc\python
  laptop SZG_PYTHON path /usr/local/szg-1.0/doc/python
  laptop SZG_EXEC path /usr/bin;/usr/local/szg-1.0/bin
</assign>\end{verbatim}
    \hrule
    \caption{Physical Computer Configuration part of a Batchfile}{``desktop'' is running Microsoft Windows and ``laptop'' is running Debian Linux. (Note how linux paths still use ; as the seperator)}
    \label{fig:pc_config}
\end{center}
\end{figure}

\paragraph{Virtual Computer Configuration Statements}
\label{subsection:virtual_computer_configuration_statements}

Below is a list of the SZG\_VariableSpaces applicable to Virtual Computer Configurations.
\begin{description}
  \item[SZG\_CONF] This stores various configurations for the Virtual Computer. Variables associated with this Variable Space are listed below.
  \begin{description}
    \item[virtual] A value of true tells the Syzygy Database to treat the ``ComputerName'' as a virtual computer.
    \item[location] This is a local identifier name for Scene Graph Data. Keeping this the same as the Virtual Computer name makes sense in almost all applications.
    \item[relaunch\_all] A value of true means the Syzygy Daemon associated with the Virtual Computer will always restart all processes associated with the Virtual Computer when starting a new application. A value of false means the Syzygy Daemon will only restart processes that are dependant on the application and not already started.
  \end{description}
  \item[SZG\_TRIGGER] This tells the Controller Computer which Physical Computer should be sent szgd requests, when the Virtual Computer is called to do something.\footnote{In figure \ref{fig:vc_config} the Virtual computer is only one computer, more complicated setups were beyond the scope of this paper.} \footnote{Additional information about more complicated trigger mappings can be found by looking at the Cave and Cube batch files directly.}
  \begin{description}
    \item[map] Needs a value of a Physical Computer name.
  \end{description}
  \item[SZG\_DISPLAY] This stores the display configurations for this Virtual Computer that are the same among all the displays.
  \begin{description}
    \item[number\_screens] Specifies the number of screens this Virtual Computer renders
  \end{description}
  \item[SZG\_DISPLAY\#] This stores the display configurations for a certain screen.
  \begin{description}
    \item[map] Specifies a physical computer and a screen name on which to display part of the Virtual Environment.
    \item[networks] Specifies the network on which the Controller Computer should look for the Physical Computer specified in map.
  \end{description}
  \item[SZG\_INPUT\#] This stores the input configurations for a certain input device.
  \begin{description}
    \item[map] Specifies a physical computer and an input device name
    \item[networks] Specifies the network on which the Controller Computer should look for the Physical Computer specified in map.
  \end{description}

\end{description}

\begin{figure}
\begin{center}
    \hrule

\begin{verbatim}<assign>
  vc SZG_CONF virtual true
  vc SZG_CONF location vc
  vc SZG_CONF relaunch_all false
  vc SZG_TRIGGER map desktop
  vc SZG_DISPLAY number_screens 1
  vc SZG_DISPLAY0 map desktop/SZG_DISPLAY0
  vc SZG_DISPLAY0 networks internet
  vc SZG_INPUT0 map desktop/inputsimulator
  vc SZG_INPUT0 networks internet

  vc2 SZG_CONF virtual true
  vc2 SZG_CONF location vc2
  vc2 SZG_CONF relaunch_all false
  vc2 SZG_TRIGGER map laptop
  vc2 SZG_DISPLAY number_screens 1
  vc2 SZG_DISPLAY0 map laptop/SZG_DISPLAY0
  vc2 SZG_DISPLAY0 networks internet
  vc2 SZG_INPUT0 map laptop/inputsimulator
  vc2 SZG_INPUT0 networks internet
</assign>
</szg_config>\end{verbatim}

    \hrule
    \caption{Virtual Computer configuration partial Batchfile}
    \label{fig:vc_config}
\end{center}
\end{figure}



\section{Shared Worlds}
\label{section:shared_world}
A Shared World in Syzygy is implemented through node sharing between two or more different Scenegraphs. Shared Worlds allow a complete Scenegraph tree or parts of a Sceengraph tree to be shared between Virtual Computers. The sharing is accomplished by using the arGraphicsPeerc class. arGraphicsPeer allows for different sharing levels and also includes support for filtering by node level. See section \ref{section:sharing_types} and \ref{section:filtering} respectively.

\subsection{Sharing}
\label{section:sharing_types}

Shared worlds can be created using three different types of sharing. The types of sharing are defined by the type of peers that are used. There are feedback, push, and pull peers. There is also another subset of these peers in which geometry and transformations are not shared but tree structure is shared\cite{bs}.

The first type of sharing, ``feedback'', is the simultaneous sharing of two node trees.  The node tree and updates to this tree are synchronized between the two peers. Updates are defined as changes to nodes such as changes to a transform matrix or color of a material. The second, ``push'', is used when one peer pushes its node tree and updates to another peer but the remote peer does not send any of its own node tree nor any changes to its copy of the originating peers node tree.  The third, ``pull'', is exactly the reverse. A pull peer receives a node tree and updates from a remote peer but does not send its own node tree or any changes it makes.

The sharing type is defined by the pullSerial and pushSerial methods of the arGraphicsPeer class. Both functions take the following arguments: remote node name, remote node id, local node id, send level, remote send level, local send level. Remote node name is the name of the remote node that the link is to be made with. Remote node id is the node id of the remote node from which sharing should take place. Usually this is set to 0 to indicate the root node of the remote arGraphicsPeer.  Local node id is the node id of the local node from which sharing should take place.  Again, this is usually set to 0.  Send level is the level at which nodes with a node level of equal or lower value will be shared. Remote send level is the level at which remote nodes with a node level of equal or lower value will be sent.  Local send level is the level at which local nodes with a nodel level of equal to lower value will be sent.  For a discussion on node levels see the section on filtering (Section \ref{section:filtering}). pushSerial is used to push the current peers node tree to another peer.  pullSerial is used to pull a remote peers current node tree. Some examples:
\\\\\noindent From peer2.py:
\begin{verbatim}
peer.pullSerial("world0", 0, 0, AR_TRANSIENT_NODE, \
   AR_TRANSIENT_NODE, AR_TRANSIENT_NODE)
\end{verbatim}
This command copies the current node tree from world0.  Updates from the remote peer, world0, will be sent to this peer and updates this peer makes to the node tree will be sent to world0.
\\\\\noindent From buildworld.py:
    \begin{verbatim}pullSerial(sys.argv[i], 0, 0, AR_TRANSIENT_NODE, \
                AR_TRANSIENT_NODE, AR_IGNORE_NODE)\end{verbatim}

This command copies the current node tree from one of the worldpart counterparts.  (See the documentation on buildworld and worldpart for more information.)  Remote updates are sent to this peer but any changes that this peer makes to the scene graph will not be sent back.

\subsection{Filtering}
\label{section:filtering}
\begin{figure}[p]
\begin{center}
 \includegraphics[bb=0 0 260 191]{./sharing.jpg}
 % sharing.jpg: 361x265 pixel, 100dpi, 9.17x6.73 cm, bb=0 0 260 191
 \caption{Visualization of filtering}
 \label{fig:filter_diagram}
\end{center}
\end{figure}
Filtering allows for a peer to select which node updates to send. For this to occur, nodes are assigned different levels: AR\_TRANSIENT\_NODE, AR\_OPTIONAL\_NODE, AR\_STABLE\_NODE, AR\_STRUCTURE\_NODE, AR\_IGNORE\_NODE. By default, new node is given the level AR\_STRUCTURE\_NODE. Filtering starts off by taking a node and transversing its tree. Any node below the given node with a node level less than or equal to the filtering level will still send updates. For a better example, see Figure \ref{fig:filter_diagram}. In the diagram, two peers are setup for feedback sharing via the nodes indicated by the arrows. Peer 2, however, is filtering from the root node at level 1, AR\_STABLE\_NODE. This means, the red node, if updated on Peer 2, will not change in Peer 1. The node below the red node, however, will have its updates sent from Peer 2 to Peer 1 and vis versa.
Sharing is accomplished by the remoteFilterDataBelow and localFilterDataBelow methods of the arGraphicsPeer class. Both functions take three arguments: peer name, node id, node level. Peer name is the name of the remote peer. Node id is the id of the node from which filtering will take place. Node level is the level where node updates will be cut off. A node level of AR\_OPTIONAL\_NODE will only block nodes of level AR\_TRANSIENT\_NODE since it is the only level of greater value. For an example of filtering, see \ref{section:feedback_peers}.

\subsection{Running a Shared World on One Computer}
\label{section:single_computer}
In a typical Shared World setup with Syzygy, one or more Physical Computers are used for each Virtual Computer. For example, peer.py \footnote{peer.py is distributed with Syzygy in doc/python} is setup to run on two or more Virtual Computers, each of which make a sphere and share it with the others. In the course of testing and development Shared World scripts, multiple Physical Computer set ups are not always feasible. Fortunately, Syzygy supports multiple Virtual Computers on a single Physical Computer. This set up can be used to test Shared World scripts\footnote{It has been observed that moving from one Physical Computer to an arbitrary number of them is trivial, given the Physical Computers are a properly set up Phleet}

\paragraph{Initial Setup}
\label{subsection:single_computer_initial_setup}
Before attempting to run any of the examples included using one Physical Computer, Syzygy must be configured and setup properly to run multiple Virtual Computers. The Physical Computer must be set up to be a Server, Peer, and Controller Computer\footnote{The Controller Computer portion of the setup is done partly on the fly with use of the -szg flag. Your batchfile only needs to define paths, and not Virtual Computers. You can define the Virtual Computers in the batchfile if you want though, and thus not have to use the -szg flag.}. See section \ref{section:phleet_setup} for more details. The steps to doing so are briefly outlined below\footnote{the steps are to all be performed on the same Physical Computer}:

\begin{enumerate}
  \item Configure a working szg.conf file
  \item Start a szgserver
  \item dlogin to the server
  \item Run a szgd
  \item dbatch singlecomputer.txt (Figure \ref{fig:single_computer_batch})
\end{enumerate}

\begin{figure}[h]
\begin{center}
    \hrule
\begin{verbatim}<szg_config>
  <assign>
    YourComputerName SZG_EXEC path c:\Python24;c:\szg-1.0\bin
    YourComputerName SZG_PYTHON path c:\szg-1.0\doc\python
  </assign>
</szg_config\end{verbatim}
    \hrule
    \caption{singlecomputer.txt}{while the example shows the setup is for Windows, a similiar one can easily be made for Unix}
    \label{fig:single_computer_batch}
\end{center}
\end{figure}

\paragraph{Running}
\label{subsection:single_computer_run}
The next step is to load two copies of szgrender and inputsimulator, one for each Virtual Computer. In this example foo and bar will be used as the Virtual Computer names. From the EZSZG shell, enter the following:

\begin{verbatim}
dex szgrender -szg virtual=foo -szg mode/graphics=SZG_DISPLAY0
dex inputsimulator -szg virtual=foo

dex szgrender -szg virtual=bar -szg mode/graphics=SZG_DISPLAY1
dex inputsimulator -szg virtual=bar
\end{verbatim}

The dex commands use the -szg arguments to determine the Virtual Computer to run the component with respect to. The second -szg argument for the szgrenders is used to make sure each szgrender uses a different display window. If the display window name is not set Syzygy will issue an error stating that the current display slot is already in use.
After these commands are issued, two szgrender windows should be displayed along with two inputsimulator windows\footnote{Warning: the second inputsimulator window will be in the exact location of the first making it seem like only one inputsimulator was launched.}.

Now we can dex scripts on the Virtual Computers. Here is the example syntax for the feedbackpeer. From the EZSZG shell, issue the following commands:

\begin{verbatim}
dex feedbackpeer1.py -szg virtual=foo
dex feedbackpeer2.py -szg virtual=bar
\end{verbatim}

If all has gone well you will now see a sphere and cube in each of the szgrender windows (See section \ref{section:feedback_peers}).

The dex commands use the -szg arguments to determine the Virtual Computer to run the component with respect to. The second -szg argument for the szgrenders is used to make sure each szgrender uses a different display window. If the display window name is not set Syzygy will issue an error stating that the current display slot is already in use.
After these commands are issued, two szgrender windows should be displayed along with two inputsimulator windows\footnote{Warning: the second inputsimulator window will be in the exact location of the first making it seem like only one inputsimulator was launched.}.

Now we can dex scripts on the Virtual Computers. Here is the example syntax for the feedbackpeer. From the EZSZG shell, issue the following commands:

\begin{verbatim}
dex feedbackpeer1.py -szg virtual=foo
dex feedbackpeer2.py -szg virtual=bar
\end{verbatim}

If all has gone well you will now see two spheres in each of the szgrender windows (See section \ref{section:feedback_peers}).

\subsection{Feedback Peers}
\label{section:feedback_peers}
feedbackpeer1.py and feedbackpeer2.py are very simple examples showing two peers which establish a feedback sharing mode and support filtering. feedbackpeer1 creats a sphere while feedbackpeer2 creates a cube. The button 1 changes the color of its object. Button 2 starts and stops bouncing of the local sphere. Button 3 enables filtering of the translation node for the opposite peer. Eg. if feedbackpeer1 enables filtering while the sphere created by feedbackpeer2 is bouncing, the sphere will freeze in its current location on feedbackpeer1 even though it remains bouncing on feedbackpeer2. While filtering is enabled, color changes to the sphere are still sent to feedbackpeer1. If filtering is then disabled, the sphere will once again resume bouncing on feedbackpeer1. See figure \ref{fig:feedback} for a screenshot.

\begin{figure}[!hbp]
\begin{center}
 \includegraphics[bb=0 0 246 146]{feedback.jpg}
 % feedback.jpg: 342x203 pixel, 100dpi, 8.69x5.16 cm, bb=0 0 246 146
 \caption{Screenshot of feedbackpeer1.py.}
 \label{fig:feedback}
\end{center}
\end{figure}

\subsection{Avatar Peers}
\label{section:avatar_peers}
avatarpeer1.py and avatarpeer2.py use feedback sharing one twist. avatarpeer1's Scenegraph contains a sphere and floor. The sphere changes colors via button 0 and will bounce via button 1 similar to feedbackpeer1. feedbackpeer2, however, is a little different. avatarpeer2 creates a blobbyMan avatar which follows the navigator. In other words, the blobbyMan follows the user as the user navigates around the environment. This movement is shared between the two peers so that movement in avatarpeer2 moves the avatar in avatarpeer1. This is behavior emulates the behavior in first person shooter games in which an avatar or characters movement is a function of the users location in the world. Figure \ref{fig:avatar} shows a screenshot.
\begin{figure}[!hbp]
\begin{center}
 \includegraphics[bb=0 0 220 167]{avatar.jpg}
 % avatar.jpg: 306x232 pixel, 100dpi, 7.77x5.89 cm, bb=0 0 220 167
 \caption{Screenshot of avatarpeer1.py.}
 \label{fig:avatar}
\end{center}
\end{figure}

\subsection{Build World and World Part}
\label{section:build_world}
buildworld.py and worldpart.py show how a shared world can be built up using parts from many independent peers who do not see or interact with each other. worldpart.py can be run on an arbitrary number of virtual computers. Each worldpart is completely independent and does not share or recieve any nodes from any other peer. buildworld.py assembles the contents of all the worldpart peers it is told about, and places them in one shared world. Running buildworld and worldpart is different than the other two examples. worldpart takes two arguments.  The first is the name given to identify itself. The second is one of hexahedron, sphere, or plane. buildworld is passed the name of all the worldparts that it should assemble. Here is an example of 3 worldparts and 1 buildworld. The worldparts are assembled on virtual computers vc1, vc2, and vc3. buildworld is run on the virtual computer vc4. In each of the worldparts, navigation is tied to the object just like avatarpeer. Therefore, when an object is moved in any one of its worldpart environments, the movement can be seen in the buildworld environment.
\begin{verbatim}
dex vc1 worldpart.py part1 sphere
dex vc2 worldpart.py part2 hexahedron
dex vc3 worldpart.py part3 plane
dex vc4 buildworld.py part1 part2 part3
\end{verbatim}
Figure \ref{fig:buildworld} shows the resulting image on vc4 after some navigation and color change.

\begin{figure}[!hbp]
\begin{center}
 \includegraphics[bb=0 0 312 179]{buildworld.jpg}
 % buildworld.jpg: 434x249 pixel, 100dpi, 11.02x6.32 cm, bb=0 0 312 179
 \caption{buildworld.py running with three peers.}
 \label{fig:buildworld}
\end{center}
\end{figure}

\section{Syzygy Setup and Configuration}
\subsection{Compiling on Linux 64 bit and Mac OS X x86}
\label{section:syzygy_changes}
64bit linux and Mac OS X on Intel require changes to the Syzygy source code in order to compile and run. These changes are mainly due to assumptions about pointers being 32bits and changes in GCC. The altered source code with the exact changes can be found at http://new.math.uiuc.edu/~ivanhoe/mulligan/src/syzygy/index.html

\section{Conclusions and Future Improvements}
\label{section:conclusion}
\subsection{Conclusions}
Shared Worlds with Syzygy provides the basics for starting a Shared World project in a Virtual Environment.

\subsection{Future Improvements}
Syzygy has a great potential for building interesting Shared World applications. People should be able to use \emph{Shared Worlds with Syzygy} as a stepping stone to projects of more great significance. A few notable examples would be video conferencing between Virtual Environments, psychological experiments with two subjects interacting with each other, and dynamical system viewers with each user being able to point at locations of interest.

It does seem as though it might be possible to teach a course in computer graphics/virtual environments using a Shared World where students and teachers use a client to connect to the world and then use python interactive bound to helpful methods to learn about transformations, lighting, and animation. It may make sense to use VPython as part of such a system as a starting place for placing objects into the shared world, and use python methods bound to Threading objects to facilitate animations through Python interactive without using an infinite loop. For instance the program would start by connecting to the Shared World, then it would start a Thread for the display and navigation devices of the client. After the program would drop into a Python Interactive session, where the user could type things like\begin{verbatim}>>>s = sphere(pos=(0,0,0), color=color.red)\end{verbatim} and then call another Threading Object called Bounce something like\begin{verbatim}>>>b = Bounce(s) \ b.start() \end{verbatim} If setup properly Bounce would cause the sphere to animate in some way in the Virtual Environment. Of course, the Teacher could then just look around inside the Virtual Environment from his computer and see the student's avatars and the sphere's that they had created and watch them bounce.

\section{Special Notes}
\label{section:special_notes}
\subsection{Input Simulator vs. the Cave and Cube}
\label{section:input_simulator}
The inputsimulator and the actual wand in the Cave and Cube are two completely different ways to generate input to a Syzygy application.  When using the inputsimulator, buttons will only work in mode 4 (Translate Wand + Buttons). There are now 4 different sections of buttons, 01, 23, 45, and 67. Different modes are selected by hiting the space bar and ar indicated by the white dot next to the red buttons in the inputsimulator. When in any mode, the left mouse button activates the first button (button 0 in mode 01) and the right mouse button (Apple + Left Click on Macintosh) activates the second button (button 1 in mode 01). In the Cave or Cube, buttons 0, 1, and 2 are the buttons on the bottom right of the controller in that order. These were previously known is left, middle, and right.





\clearpage
\phantomsection
\addcontentsline{toc}{section}{References}
\begin{thebibliography}{99}
\bibitem{bs} Ben Schaeffer, et. al.: \emph{Myriad: scalable VR via peer-to-peer connectivity, PC clustering, and transient inconsistency}, \href{http://www.isl.uiuc.edu/~schaeffr/vrst31-schaeffer.pdf}{http://www.isl.uiuc.edu/~schaeffr/vrst31-schaeffer.pdf}
\bibitem{sd} Integrated Systems Lab: \emph{Syzygy 1.0 Documentation} \href{http://www.isl.uiuc.edu/szg/doc/index.html}{http://www.isl.uiuc.edu/szg/doc/index.html}

\end{thebibliography}

\end{document}

