Purpose and Goals
A scene graph system is most interesting when hooked into a good simulation. For years the DIS protocol was the method of choice for hooking up distributed simulations. In the last 5 years, HLA has become a popular method to connect distributed simulations. This project's goal is to develop the following:

• A framework for using the RTI1.3NG - This framework's main purpose is to map between application level objects/methods and the RTI calls/callbacks, providing a level of automation to the interaction. It also gives me an excuse to work with the RTI.
• A stealth module visualizing a simulation - The SceneGraph project will be connected with the new framework to develop a 3D visualization node of the on-going simulation.

Platform and Tools
This project is developed on Windows 2000, using DMSO's RTI1.3NG. The project is in C++.

Status
About half of the framework has been built. Time management and some threading safety issues still need to be addressed.

Framework: Basic Design
The basic concept that drives the design of the framework is that the framework should provide the following capabilities:

• Application objects should be created and destroyed when the appropriate object discoveries and removes occur via the FederateAmbassador
• It should be possible for the framework to drive when the application objects issue attribute updates.
• Most of the maintenance of lists of objects entering and exiting the simulation should be maintained by the framework.
• Attribute updates should be automatically delivered by the framework to the appropriate application objects.

The driving concept is that the framework is a bridge which maps back and forth between application level simulation entities and the RTI (object handles & object class handles.) The framework accomplishes this by using look-up tables, between object class handles and the object factories. The table is built as the simulation subscribes to object classes. When discoveries are reported to the FederateAmbassador, the appropriate factory is used to create an application level entity (for the given object class). This entity is then tracked by the framework, such that it can later deliver attribute reflections to it. The procedure is similar for application objects that are published by by the simulation.

When I get a chance, I will publish some UML diagrams illustrating the class hierarchy and the interactions.