This strategy is called SGAB (SceneGraph as Bus). It consists of wrapping layers that intercept the communication between an application and its scenegraph. The wrapping layers at various physical sites communicate with each other and transfer information about the instantaneous state of objects in each other's simulations.
In this way, objects from diverse simulations are able to merge without the rewriting of any code. Each host machine is responsible for locally defined computation chores related to dynamics (motion, object transformation, interaction, and other behaviors), whether applied to objects generated locally or at a remote site. Objects effectively "pop in" to each other's scenegraphs, and are moved and changed by any of a number of local or remote hosts.
SGAB is not without its challenges. The usefulness of this technique depends on how "smart" the heuristics are which guess at the semantics of the objects that are transported between scenegraphs. For instance, one simulation might have Cartesian coordinate grid lines, as well as objects that move over them. If a remote simulation wishes to manipulate these items, it must be able to distinguish the moving objects from the gird lines. Furthermore, SGAB requires an elaborate strategy for managing locus of control. A simple example is the case in which two sites wish to manipulate the same object at the same time, or the even more common case in which a local site becomes confused if a remote site manipulates its native objects.
While SGAB was conceived as a tool for use over long distances, and latency management, including predictive algorithms, is a central design feature, it has turned out to be rather useful in LAN applications. For instance, a geometry modeling application that runs only on one workstation can be used to tweak the shape of an object inside a dynamics simulation that runs on a different workstation, while the simulation is running. In the LAN configuration, the SGAB overhead and latency are quite small.
The two primary universities engaged in the research are the Naval Postgraduate School and Brown University. This is an interesting combination, because these two institutions have almost opposite "cultures" of simulation.
NPS develops battle simulations with large numbers of participants, but small numbers of types of objects and behaviors. That is, there might be perhaps a dozen different types moving players (such as tanks and helicopters), each of which can engage in perhaps a dozen behaviors (such as moving and firing), but there might be thousands of individual players.
Brown, on the other hand, specializes in simulations with no more than two participants, but with much richer varieties of objects, relationships between them, and behaviors and interactivity that can be elicited from them. Brown develops collaborative tools for designing and testing complex simulated mechanical assemblies, for example, as well as applications to surgical simulation. In these cases, the number of potential behaviors is not enumerable as it is with NPS, and the data base of object types can grow without bounds.
SGAB has enabled a blending of the simulations of NPS and Brown. For instance, an accelerated simulation of skin growth at Brown has been applied to a moving tank in an NPS battle simulation.
While SGAB presents its own challenges, it illuminates a possible pathway to improved interoperability among real time 3D simulation systems. It is essential to explore such possibilities because real-time 3D has suffered from a lower level of tool reusability than any other sector of information systems. This has had a negative effect not only on the economics of simulation, but the resultant sluggishness of development has probably dampened intellectual exploration of new ideas in user interface and applications.
Hopefully SGAB represents the beginning of a new period of re-examination of strategies in simulation networking.