is a framework designed to aid the rapid development of VR applications.
It provides a starting point for the basic requirements of VR applications
so that developers don't have to spend time designing and implementing
these features. It places emphasis on object-oriented design and takes
advantage of advanced language features that appear in standardized C++.
It requires full template support and for this reason is currently available
only for the SGI IRIX 6.5.3 platform.
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.
|Class Naming Conventions||Throughout
the design and implementation there are two conventions which I have used.
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
An instance of the TdGfxPfObject class is instantiated directly and is from the Gfx module.
|Tandem Core||The Tandem Core
is comprised of a set of classes that support the core features of a Tandem
application. These classes are not meant to be used directly.
One can inherit from certain core classes if additional functionality or
specialization is required.
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.
Please refer to the following diagram.
module is the foundation of a Tandem application. It is made of the following
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.
|TcEx||The TcExcecution module is a logical separation of concerns, rather than a module that is distinct from the others. It is made of classes that are created by the TcApplication class. The TcExControl class encapsulates the main thread of control for a Tandem application. The other classes passed to it are the TcInteranctionManager, TcNetManager, TcGfxManager and the TcAvatarManager. TcExControl contains a template method whose functionality is supported by the aggregation of these classes.|
|TcGfx||This module is reponsible
for all core Tandem graphics. It maintains a hierarchical structure of
TcGfxComponent classes using the Composite pattern. This hierarchical structure
maintains associations between TcGfxComponents, user behavior and data
classes as well as display library components. This functionality is supported
by various abstract base classes that clients must inherit from. The Gfx
module provides a group of adapter classes derived from TcGfxDspLibComponent.
These adapt the components of a display library for use within Tandem.
Tandem includes a set of development Performer adapters for this purpose.
(See TcActionEvent, TcUserComponent , TcGfxDspLibComponent
and TcGfxVisitor for further
details on how to extend the TcGfxComponent hierarchy.)
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 Component Hierarchy
Graphics Performer Component Adapters
|TcNet||This module is
responsible for making Tandem applications collaborative and distributed.
It is composed of three main components. The principle class is the Network
manager which is an aggregation of a NetworkEventManager and a NetworkConnectionManager.
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.
|TcInteraction||This module plays two key
roles that comprise several layers of interaction within Tandem.
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.
Interactions In Tandem
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:
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
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.
|TcUt||This is a collection of utility
classes used by Tandem core classes. It contains things like Tandem Utility
strings, and hashtables. Clients could potentially use these classes if
they needed them. TcUtStrings and TcUtVector3f classes are serialized through
the use of CavernSoft.
See the following diagram