Tandem's architrecture places a strong emphasis on the use of design patterns both in documenting the framework and in solving key design issues.
Tandem is designed for collaborative VR, hence much of its design was done with distributed computing environments in mind. Consequently many components are searchable by string and/or are geared for interaction with network events. Tandem currently uses the services of CavernSoft to enable its networking module with its own TcNetCav layer. CavernSoft provides several broker like features that make distributed designs easier to develop.
Tandem Core classes are prefixed by Tc.
Those core classes made available to developers are abstract and hence can only be used through inheritance.
Tandem Development classes are prefixed by Td and are meant to be instantiated within an application.
In classes that are not directly part of the Tandem Core following Tc or Td is the module to which a given class belongs, currently Net, Gfx or Ut.
As an example
the TcActionEvent class is from the Tc module and is included by the compiler
directive
#include <Tandem/Tc/TcActionEvent.hxx>
Clients must
inherit from the TcActionEvent class.
An instance of the TdGfxPfObject class is instantiated directly and is from the Gfx module.
The Tandem Core classes are divided into the following categories corresponding to the directory structure: Tc, Gfx (Graphics), Net (Network), and Ut (Utility).
In addition there are several logical packages
which have evolved from the analysis and design of Tandem but are not mapped
to unique directories.
These are TcApp (TcApplication), TcEx
(TcExecution), TcAv (TcAvatars), TcInteraction, TcTracker and TcTrav (TcTraveler).
These form the highest level of Tandem's
architecure.
Please refer to the following diagram.
TcApplication
TcLoader
TcExControl
TcAvatarManager
TcInteractionManager
TcNetManager
This module makes use of both Template Method and Factory method. The TcApplication is responsible for creating these classes through factory methods, and plays the role of creator. Ownership of these classes remains with TcApplication and consequently it is also responsible for destroying them.
Please refer to the following diagram.
The Gfx module also maintains iterators for traversing its structures. In addition it is reponsible for initializing the desired graphics display library (currently implemented using Performer 2.2 and CAVElib) .
IIt also interacts with TcTraveler to control the users viewpoint while travelling through a Virtual Environment.
Refer the following diagrams:
Graphics Manager
Graphics Iterators
Graphics Component Hierarchy
Graphics Performer Component Adapters
The NetworkEventManager is the processor of network events passed between a Tandem Client Application and the NetworkConnectionManager. It packages Client requests into NetworkEvents to be sent over the network. It also unpackages incoming network events and distributes them to the approriate modules.
The ConnectionManager is the shipper/receivier. It knows nothing about the semantics of a Network event, or its data. It knows simply how to send and receive events over a connection.
This design is similar to the Broker pattern, particularily with respect to the client and client proxy as well as the server and server proxy, since these classes can be used in both client and server applications.
See the TcNet diagram.
The first is to create and update core interactions and provide hooks for client interactions.
The second is to maintain a collection of classes that enable development of user interactions.
Core interaction updates are handled by the InteractionManager. This aggregate class is comprised of an InputManager, TrackerManager, a GraphicsIntersectionManager and a Traveler. These classes enable the updateInteractions() factory method to update trackers, input devices and intersections once per iteration of the control loop.
The view point is updated through a strategized algorithm encapsulated in TcTravelScheme and associated with TcTraveler.
After the core interactions are updated control is passed to client classes.
This is done through the use of factory and template methods that enable extension of the TcInteractionManager.
See the following class diagram.
Tandem provides a collection of classes that enable the development of various behavior and interaction metaphors that commonly occur in collaborative VR.
These are separted into three categories:
- ActionEvents
- Actions & ActionHandlers
- Visitors/Controllers
An Action Event is an event that triggers an Action. They are based on the command pattern and may be associated with any TcGfxComponent. They are the foundation for two graphics interactions: triggered events and iterative events. The former occurs asynchronously, while the latter occurs once per iteration as in the case of an animated graphic event.
Actions & Handlers
Actions and Handlers are
based on the Multicast pattern, a variation of Observer.
Actions are defined by clients
by inheriting from TcAction. Each class derived from TcAction automatically
generates and encapsulate a nested template class Handler from which action
handlers must inherit.
When an Action occurs all
registered handlers are automatically notified. Handlers can be configured
for both implicit handling (automatic registration with action instances)
or explicit handling (user controlled registration) and can dynamically
register and unregister interest in an action.
Visitors/Controllers
These components are modelled
after the visitor pattern and are designed to extend the behavior of the
Tandem Graphics Component hierarchy. The term controller is chosen because
they are a mechanism used to carry out an action. Both actions and
handlers may use Visitors and Controllers to carry out the occurrence of
or response to a given action.
An example is the TdTransformController.
This controller is used to transform (scale, rotate, translate) a dynamic
graphics component. Clients may also develop their own controllers based
on the visitor pattern.
These entities do not necessarily
have to be used in this configuration, this is only a description of how
they were conceived. They may be used as design contructs in contexts
that may not have anything to do with interactions. For example the Actions
and Actions handlers work very nicely in any situation where you want a
publish-subscribe relationship. The nice feature of the Action and Action
Handlers is that they work well in both one-to-many and many-to-one subject
to listener configurations.
See the following diagram.
See the following diagram
Tandem Home