MetaVR Multi-Channel Viewpoint Protocol

MetaVR's multi-channel viewpoint protocol enables your simulation to control and update an arbitrary number of VRSG views. This lightweight, platform-independent protocol can be readily incorporated into your existing simulation models while providing a migration path to high-quality, low-cost visuals. Terrain feedback is provided by the MetaVR MDX read API. This technology has been extensively fielded.

View from the cockpit of a Lockheed Martin F-16 simulator using MetaVR multi-channel visual systems.

The multi-channel viewpoint protocol is a network-based interface to the VRSG Windows-based PC-based image generator. It enables a simulation host, running on a separate computer, to control an unlimited set of VRSG visual channels dedicated to that simulator. The viewpoint protocol is not an Application Programmer's Interface (API), but rather a set of messages exchanged between the simulation host and the VRSG channels

Your simulation code may be modified to use the multi-channel viewpoint protocol messages directly wherever interaction with the IG is necessary, or encapsulate the viewpoint protocol within a generic IG interface API on the simulation host side. Both approaches have met with success, but we recommend the latter approach as it promotes an IG-independent simulation host. To date, the GT111 interface API libcif, and the Virtual Battlespace Interface (VBI), have been implemented using MetaVR's multi-channel viewpoint protocol.

There are two sets of multi-channel messages, those sent from the host to the channels, and those sent from the channels to the host. Messages sent from the host to the channels are sent using broadcast UDP on port 5069. The channels send their messages to the host using broadcast UDP on port 5070. All multi-channel messages use Intel(tm) byte order, also known as little-endian. Your simulation may not need to process messages returned from the VRSG channels, as these messages are optional. If your application is not interested in laser range returns, or in processing acknowledgements, then there is no need for you application to read messages from the VRSG channels.

Multi-channel viewpoint protocol messages use a similar header to that used by the Distributed Interactive Simulation (DIS) V2.0.4 protocol. VRSG uses a similar header to DIS because the VRSG can support its multi-channel protocol messages and DIS messages at the same time, even on the same network and port address. The VRSG uses the values in the header to distinguish multi-channel protocol messages from DIS messages.

Controlling the VRSG from a Simulation Host

The VRSG can be run as an autonomous "stealth", or as a dedicated channel to a simulation host running on another computer. When the VRSG application is initially launched the control GUI (Dashboard) is displayed before the VRSG enters an active state. While the control GUI is displayed, the VRSG is waiting for either a user to click the "Start VRSG" button, or receive a message from a host instructing the VRSG to start remotely. If a user launches the VRSG into the active state by clicking the "Start VRSG" button, the VRSG is autonomous and will not respond to viewpoint protocol messages. Likewise, if the VRSG is started remotely by the simulation host via the viewpoint protocol, the VRSG becomes coupled to the simulation host and will not respond to local joystick control inputs.

The life cycle of a simulation host controlling a set of VRSG channels follows the following outline:

1. The host sends a StartClientMsg to each VRSG channel to launch the channels into an active state.
2. The host sends a single ClientUpdateMsg every simulation cycle providing the channels with the current position and orientation of the simulated platform. This continues as long as the simulation is active.
3. The host sends a ExitMsg or RestartMsg to terminate the VRSG channels.

Commanding the Overlay Processor

The VRSG contains an internal emulator of the GT111 overlay processor emulator. The OverlayCommandMsg is a viewpoint protocol message that enables you to transmit a binary opcode stream to the VRSG's overlay processor. This message contains a single field, buffer, which contains the binary opcode stream. For more information about the Overlay Processor Emulator, see the VRSG User's Guide.

Displaying Special Effects

The ShowEffectMsg enables you to instruct the VRSG to display a transient special effect. The location field identifies the coordinates of the special effect. These are given in database coordinates, meters relative to the southwest corner. The index field identifies the effect to be displayed. This is a zero-based index into the Effects\ClientMap.ini effect-mapping file on the VRSG channel.

Requesting Laser Range

The host may request a laser range return from set of VRSG channels by sending a single LosRequestMsg. The LosRequestMsg is broadcast to all channels and contains an array of LosRequest structures. Each visual channel inspects this array to see if a laser range return is being requested of the channel. If so, the channel will send a LaserRangeMsg on port 5070 after the scene is rendered and the range is computed. One LosRequestMsg may elicit the return of several LaserRangeMsgs from multiple visual channels. The laser range of an arbitrary pixel may be queried. The azimuth and elevation of the desired pixel is specified in the LosRequest entry. An azimuth and elevation of (0.0, 0.0) corresponds to the center pixel.

Changing Time Of Day Conditions

Lighting conditions may be changed via the TimeOfDayMsg. Only a single message need be sent to update all channels. In this message you can set the lighting ambient and diffuse colors, the light angle, and the sky/fog colors. Colors are specified in packed unsigned long formats. For example, yellow would be given as 0x00FFFF00. Color intensity values should be scaled into the range 0..255.

Displaying Moving Models

There are two methods to get moving models into the scene; you can use even both methods concurrently. The first method involves just forwarding DIS PDUs to the visual channels. The second method allows you to explicitly create, update, and remove visual models in a more host-coupled manner.

If your application is DIS, using DIS for moving models may be the easiest approach. Your application need only forward DIS PDUs from the DIS network onto the private visual channel network on port 5069. It is recommended the host perform range-relevance filtering of any PDUs before forwarding them to the private LAN. When using this method, the VRSG will automatically dead-reckon, perform time-out processing, spatial, orientation, and articulated part smoothing, and render DIS moving models.

The multi-channel viewpoint protocol has messages for creating, updating, and removing visual models from the scene; you can use these messages in lieu of DIS, or as a supplement to DIS models. For example, you can use DIS to display remote models, but explicitly create the ownship. If desired, your application can perform all its own DIS processing and have explicit control of all models drawn. The following three messages apply to moving model management:

The CreateModelMsg is broadcast to all visual channels to create an instance of a moving model. The message contains a DIS enumeration of the model to be created. The VRSG will use the local ModelMap.ini to associate the enumeration with a visual model. A modelId is also supplied which is unique for the moving model instance to be created. If a modelId by the same ID already exists, the existing instance will be replaced with a new one. The CreateModelMsg also contains an array of DIS articulated part Ids. These parts IDs will be updated in the UpdateModelMsg described next. Part ID zero corresponds to the models hull. A model should have at least one part, which is a hull.

The UpdateModelMsg is used to update the values of a moving model. This is a very cryptic message for efficiency sake. Several model updates can be packed into a single message. Several messages may need to be sent per frame depending on how moving models there are and how many attributes of the moving models have changed. A moving model has a hull and potentially several articulated parts. This message allows you to update 6DOF data for the hull and all of the articulated parts of a model. Only the values that change need to be sent in a given message. The message provides a way to code which values are present.

The numModels field should be set to the number of moving models that are being updated by the message.

The ox, oy, and oz fields specify an origin which model hull positions are relative to. This is done so that 32-bit floating-point numbers can be used for model locations with sufficient accuracy. Typically a host uses the ownship position as the origin. The X, Y, and Z positions of part 0 (the hull) only should be translated by this offset. The X, Y, and Z positions of other parts should be respect to the parent part.

Next in the message is a variable number of 32-bit values for each model in the message. The first 32-bit value encountered following the oz field is a model ID. This is the same ID used in the CreateModelMsg, which created the model instance. Following the model ID is a 32-bit change mask. The change mask bits indicate which values are present in the data to follow. The change mask allows up to 5 parts and the appearance mask to be coded into this 32-bit word. For each of the 5 parts, X, Y, Z, azimuth, elevation, roll may be present in the data to follow. Bits 0..5 indicate which values are present for part 0. Bits 6..11 indicate which values are present for part 1, and so on. If the appearance mask is present, the high-order bit will be set and the appearance mask will follow all the 6DOF values for the parts. The 6DOF data is provided in 32-bit floating-point numbers. Following the 6DOF data and potentially the appearance mask for a model, is the model ID for the next model in the message. This model ID is then followed by the change mask for the next model, and so on for each model in the message.

The RemoveModelMsg is sent to all visual channels when a moving model needs to be removed from the scene. The RemoveModelMsg contains a single field, which is the ID of the model to be removed.

For more information about MetaVR's multi-channel viewpoint protocol, see the VRSG User's Guide.