Syncker Plugin

• The Running Syncker for a custom project article for more details on Syncker initialization and synchronization code.
• The Syncker-specific options article for more details on Syncker command-line options and console commands.
• The Video Wall Output with AppWall Plugin article for more details on using the AppWall plugin for multi-monitor slave configurations.

Syncker API:

• The Manager interface article for more details on managing Syncker via code (C++, UnigineScript).
• The Master interface article for more details on managing Syncker master via code (C++, UnigineScript).
• The Slave interface article for more details on managing Syncker slave via code (C++, UnigineScript).

The order of launching master and slave applications does not matter: you can launch several slaves, then the master, and then the rest of the slaves — synchronization will start automatically. This is achieved by having a buffer of object creation/deletion calls. Each time a new slave connects to the network, the master tells it, which objects are to be created or deleted.

Unigine Syncker uses Interpolated Snapshots (IS) to tackle with the problem of lost packets between the master and slaves. It works by taking two old, but known positions and interpolating the object between them. It is accomplished by having a buffer of received positions and rotations, along with the time they represent. We usually take our current local time minus some predefined amount — interpolation period (40 ms by default), then go into our buffer, find the two indices that are just before and just after this time and interpolate.

If we don't have a received position and rotation for the time we're looking for, the extrapolation (guessing) is used. It also has a limited time — extrapolation period (200 ms by default). If the extrapolation period is over but there are still no packets received, all objects will freeze.

In most cases, this method provides a very accurate representation of the world to each slave, as in general only already known positions of remote objects are rendered and in rare cases the system will try to extrapolate (guess) where an object is. This, however, comes at a cost, as we always render 40 ms (interpolation period) behind current time, so that new packets have time to arrive with data.

The scene contains static and dynamic objects, and "dynamic" doesn't mean that the object's states are changed constantly. Taking this into account, Syncker uses the following strategy:

• For static objects, synchronization packets are sent on their creation and deletion.
• For dynamic objects, synchronization packets are sent only when their state has changed.

Moreover, Syncker offers you a flexible customization of the whole synchronization process, based on custom user TCP/UDP messages. Instead of sending the whole bunch of transformation data for objects that can only be rotated or sending huge amounts of transformation data for all parts of complex objects, when their positions can be determined using just a handful of simple parameters, you can send a single quaternion or a set of parameters.

All packets are compressed before sending (LZ4 or ZLIB). You can choose the desired algorithm and compression quality.

Thus, the excessive load on the network is minimized, while keeping performance high.

Slaves are not silent anymore. If a slave fails to receive a message via UDP protocol, it immediately reports to the master (via TCP) and requests to resend the message. In this case, the master sends the current state of all synchronized objects via UDP to perform update.

Moreover, a slave can control the master and other slaves (e.g. run the profiler on all computers or shutdown all applications) by sending the syncker_console command.

Syncker allows synchronizing views from multiple cameras. There are two types of cameras:

• Main master camera — a single camera that corresponds to the main viewer's position. The screen configuration determines viewports relative to this camera. Example: a camera in the plane's cockpit, corresponding the pilot's point of view.
• Auxiliary camera — an additional camera (static or dynamic) that can be set anywhere in the scene. You can have as many cameras of this type as necessary. Example: a ground-based surveillance camera or a thermal imaging camera mounted on the plane's wing.

Syncker offers you an extreme flexibility of viewport configuration. You can use up to 6 monitors on a single slave, each having it own viewport assigned. For this purpose, you should use the AppWall plugin.

You can set up the desired screen / projection configuration for the Syncker in the screen/projection setup mode. To activate this mode, use the syncker_setup console command from the master or a slave:

syncker_setup 1

Screen configuration for the Syncker has to meet the requirements.

Two types of configuration can be used:

• A multi-monitor setup formed by displays, where each slave renders its viewport on the corresponding monitor (or several monitors).
  Notice

  Projection and modelview matrices are automatically calculated on the basis of the viewer's position.
  The following picture shows the screen configuration for the multi-monitor setup, where each slave renders its viewport to a single monitor.

  

  Screen Configuration (the left picture) for Multi-Monitor Setup (the right picture)
• A multi-projector setup formed by projectors, where each slave renders its viewport via the corresponding projector. By default, the projectors display images as seen from the viewer's position.

  

  Projector Configuration (the left picture) for Multi-Projector Setup (the right picture)
  Notice

  Projection and modelview matrices are automatically calculated on the basis of the viewer's position.
  A special case of the multi-projection setup is CAVE (Cave Automatic Virtual Environment):

  

  Projection Configuration for CAVE

To connect computers and synchronize them, the following pipeline is used:

1. After being launched, the master starts sending broadcast messages that it is available using UDP protocol.
2. All slaves in LAN after being launched listen to the selected UDP port. Upon receiving this message, they connect to the master via TCP protocol.
   Notice

   Actually 2 TCP ports are used:

   • TCP port — for messages.
   • TCP ping port — for latency measurement (to ensure correct interpolation).
3. After the connection was established, both UDP and TCP protocols are used to exchange data between the master and slaves.
   • Over UDP protocol, non-critical messages are sent. This includes messages on render parameters (for example, ambient color, or HDR exposure), position of a player and all nodes and materials that are synchronized. It also includes frame-related information (if the game is enabled, the current frame number, frame duration, a time scale, and even the game seed for random number generators).
   • Over TCP protocol, critical messages are sent. These are messages on creation and deletion of nodes and user messages.

If you have a source SDK, you can use a simple and useful tool to monitor the network messages exchange speed. It is server.usc found in source/tools/Interpreter/scripts/network/.