6.2 - FOM Mapping Overview

The figure illustrates VR-Link's basic architecture for FOM agility.

FOM mapping architecture

The top-level FOM-independent API lets you set and inspect the state of local and remote objects and the data contained in locally generated or received interactions, without regard to how the data is actually represented in a FOM. This top-level API includes the object publishers, reflected objects, reflected object lists, state repositories, and interaction classes.

The FOM Mapping layer routes and converts data between the FOM-independent API and the FOM representations you are using for a particular federation execution.

There are two broad categories of FOM modifications that developers might implement:

• FOMs that contain only those concepts that are already present in VR-Link's top-level API, but which may represent the concepts differently from the way they are represented in the VR-Link API.
• FOMs that include concepts that are not present in VR-Link's API.

If you are implementing FOMs that have the same concepts as the VR-Link API, you can switch from FOM to FOM just by modifying the FOM Mapping layer, which you can do without affecting the top-level API. This means that application code written to the top-level API does not need to change when switching from FOM to FOM. (6.8.2 Passing the Name of A Shared Library, explains how to load a FOM Mapper from a shared library so that your applications do not need to be recompiled when you switch between FOMs.)

For example, in one FOM (such as the RPR FOM), position data may be represented in geocentric coordinates in an attribute named "Position". In another, it might be represented in topographic coordinates in an attribute named "Location". In either case, position data is available to application code through VR-Link in the manner dictated by its FOM-independent API – as geocentric data obtainable using DtEntityStateRepository::location(). FOM Mapping code takes care of converting from the various FOMs' representations to the representation chosen by VR-Link.

If you are using FOMs that contain concepts not found in the VR-Link API, you must follow a two-step FOM-configuration process.

1. Extend the top-level API, by deriving new classes from our base state repository, publisher, reflected object, or reflected object list classes to include your new concepts. Once you have done this, your code is part of the FOM-independent API.
2. Create mappings from arbitrary FOM representations of these concepts to your new API extensions, just as if your extensions were part of the standard VR-Link API. (Typically, you will choose representations for your API that closely match the representation in a particular FOM, meaning that the mapping code will be fairly straightforward.)

[<< Introduction to FOM Agility] [Home] [Top of Page] [FOM Mapping Information Required By VR-Link's API >>]