« Creating multi-headed displays | EDGE User’s Guide | Allowing For Offscreen Light Flares And Blooms »

To force frame locking an additional process, called "broadcaster", needs to be run. This process takes care of the timing commands to force each of the frame locked clients to swap frames at the same time. To specify that a client should be frame locked use the "-mode mc_client" option on the command line. So a minimal configuration to run clients with frame locking would be:

run_manager

run_broadcaster

run_client -mode mc_client

run_client -mode mc_client

run_client -mode mc_client

This set of commands would start a server, the broadcaster and three frame locked clients.

The broadcaster needs to know how many clients to manage. The default value is 3. If you want to frame lock some other number of clients, then you must set the "BCAST_NUM_SUBS" environment variable. The best way to do this is by using the "-D" command line option. So to frame lock 2 clients the commands would be:

run_manager

run_broadcaster -DBCAST_NUM_SUBS=2

run_client -mode mc_client

run_client -mode mc_client

That's all there is to it. Just be sure to check out the "Important Considerations" section below.

Frame locking means to synchronize two or more video displays so that they will redraw at the same time. Note that frame lock is different from genlock. In genlock, the horizontal and vertical sync signals are synchronized. In frame locking not only is the redraw synchronized, but the content of the scene is also synchronized. In other words, frame locking assures that all clients have received the same scene updates before commanding a synchronized redraw.

Typically frame locking is used when two or more displays are combined into a single view or single canvas. Common examples are a dome projection system or the right/left eyes of a virtual reality helmet mounted display. Without frame locking the displays would update out of phase, with each display showing the scene at a slightly different time with a slightly different set of updates. The result is a tearing effect, with the edges were the displays meet becoming very apparent, destroying the desired single canvas effect. Frame locking solves this problem by forcing the graphical clients to wait until all of them have reached a uniform state of updates, then commanding a redraw.

• The broadcaster process does not parse the userdata/user.cfg file! Therefore changing any of the dcomm or bcast environment variables in the user.cfg file will have no effect. If dcomm or bcast environment variables need to be altered they must be set using the "-D" command line option as show above.

• When running in "mc_client" mode, the clients are in a receive-only mode. Changes made to the scene by a client in "mc_client" mode will not be transmitted out and will not affect other clients.

• In order to synchronize the clients, the broadcaster will force the faster updating clients to wait for the slower clients before commanding a redraw. As a result all clients will update at the same frame rate and this will be the frame rate of the slowest client. Because of this the machines should usually be matched in graphical capability as much as possible. For example, frame locking four machines, three running with 480 GTX graphics cards and one of them running an older 8800 card is going to waste a lot of the capability of the 480's.

The broadcaster process connects to the server using a standard dcomm connection. The frame locked clients do not connect to the server directly. They receive scene updates from the broadcaster. For each packet of data that the broadcaster sends to the clients, a unique packet id is added. In addition to the scene update packets the broadcast also gives the clients a target packet id. Each client processes the updates until they reach this target packet, notifies the broadcaster they are ready to perform a swap buffer (frame redraw) and wait for a sync command from the broadcaster. When all clients have checked in the broadcaster sends out the sync command (via a single multi-cast packet) and gives the clients the new target packet id. The clients redraw, then start processing data again until they get to the new target packet.

(Okay, it's actually a bit more complicated then this, with multiple threading on both the broadcaster and clients to make sure that "waiting time" is not actually spent waiting, but that data is being sent, received and processed at all times. But the above description captures the general idea.)

So there are really only two sets of data that the user can customize. The dcomm parameters for the broadcaster connection to the server, and the "bcast" parameters for the broadcaster connection to the clients. These environment variables are:

BCAST_DATA_GROUP    <IP Address>       (default value 225.0.0.51)
   BCAST_SYNC_GROUP    <IP Address>       (default value 225.0.0.52)
   BCAST_DATA_PORT     <Port Number>      (default value 12101)
   BCAST_SYNC_PORT     <Port Number>      (default value 12102)
   BCAST_LISTEN        <Port Number>      (default value 12103)
   BCAST_NUM_SUBS      <int>              (default value 3)
   BCAST_TIMEOUT       <float>            (default value 10 seconds)

   MC_TAG              <string>           (default value "cev_comm_${USER}")
   MC_PORT             <Port Number>      (default value 12349)
   MC_GROUP            <IP Address>       (default value 225.0.0.48)
   TCP_PORT            <Port Number>      (default value 8000)
   UDS_NODE            <string>           (default value "/tmp/cev_comm_${USER}")

« Creating multi-headed displays | EDGE User’s Guide | Allowing For Offscreen Light Flares And Blooms »