First, here's the model that DIVERSE uses for managing displays. It is a
series of nested class objects. Objects of one class contain one or more
objects of other classes.
At the top level is a class called "pipe". There is one pipe object per
graphics display. In our RAVE there are four pipe objects, one for the console
and three for the RAVE walls.
Contained in pipe each object are one or more "window" objects. A window is
a rectangular area of the pipe, and is managed by the window manager. A
window can have window decorations, be moved/raised/lowered, and can overlap
other windows. A window can be either stereo or mono. Our RAVE has one
window object per pipe.
Each window object contains one or more "screen" objects, and each screen
object is used to describe a viewing frustum. In our RAVE, the desktop
window's screen object has a symmetric frusta, and is described in terms of
field-of-view and offset from the origin. Each wall of the RAVE has a
screen object with a head-tracked asymmetric frustum described by the
physical size and position of a RAVE wall.
Each screen object contains one or more "viewport" objects. A viewport is a
rectangular area of a window which is the base of a screen object's frustum.
In our RAVE, the desktop screen has a viewport occupying the entire window.
The RAVE's front and left walls have viewport objects which leave the left
and right few inches of the window unmapped, and a floor viewport which uses
the entire window.
These set of nested classes can be used to describe any virtual environment
hardware display configuration.
How does this relate to Producer? Producer is used by DIVERSE to create
windows and viewports within the windows, and to access the keyboard and
mouse in a device independent manner.
Producer uses a very different model than DIVERSE. See
http://www.andesengineering.com/Producer/Tutorial/index.html for a nice
picture called "Sorting Out the Terminology".
Producer has a class called "SceneHandler" which is hook into the
three-dimensional scene. The scene is captured by an object of the "Camera"
class. The Camera has objects of the "Lens", "ProjectionRectangle" and
"RenderSurface" classes.
The Camera has a position in the world. The Camera's Lens object calculates
the view frustum, and the base of the frustum is a ProjectionRectangle. The
ProjectionRectangle is placed on the RenderSurface.
Additionally, Producer provides the "KeyboardMouse" class to access the
keyboard and mouse.
Here is how DIVERSE use Producer:
Every viewport object in DIVERSE creates an object based on the Producer
SceneHandler class. That is, every DIVERSE viewport is a picture of the
three-dimensional scene. Every viewport object also creates a Producer
Camera object, as it needs to project the three-dimensional scene onto a
two-dimensional viewport rectangle. The Camera contains a Lens,
RenderSurface and ProjectionRectangle. The attributes in the DIVERSE
classes are used to set the attributes of the various Producer classes.
Producer has some higher-level classes which we have been unable to get to
work in a multi-pipe multi-processor threaded environment. The "CameraGroup"
is not used, as we could not get it to work in a multi-threaded environment.
Therefore, we manage individual cameras and provide our own threading code.
Threading is probably our largest problem with Producer.
DIVERSE uses Producer's KeyboardMouse class to access the keyboard and mouse
devices. Although Producer's aim is to provide a platform independent API,
some methods are only implemented in X11, such as cursor positioning. It
would be desirable to have an API that is truly platform independent, so
DIVERSE could be used on all supported platforms- Linux, OS X, Windows.
The purpose of the project is to investigate if Qt can be used a replacement
API for Producer. This will require:
1) Learning about Qt's capabilities
2) Learning about DIVERSE's needs in a windowing package
3) Determining if Qt can be used to replace all of the functionality
provided by Producer. Also to determine if Qt can be used to offload
some of the functionality coded into DIVERSE, such as multi-threading and
device independent keyboard/mouse access.
4) Programming the changes to DIVERSE
5) Testing in various environments for correctness and speed
==================================================================================
DIVERSE is comprise of several packages.
DTK, the DIVERSE toolkit, is contains utility functions and base classes.
It contains no graphics code. Two classes are referenced here:
A dtkAugment object contains specific predefined callbacks.
The dtkManager class implements a callback manager by loading objects based
on the dtkAugment class, and invoking their callbacks at specific times.
dtkAugment objects can be loaded into the dtkManager object via a load()
method inside of an application, or as is more often the case, by creating a
DSO object and having the dtkManager object load the DSO at run time.
All the FLTK code is used by DTK applications, so for the Producer to Qt
port, FLTK isn't in the picture either.
DGL, DIVERSE for OpenGL, creates a single object of the DGL class. The DGL
class is based on the dtkManager class. It defines additional callbacks
commonly needed by graphics applications. Since the DGL object is a
"singleton" it uses static data and methods to make it easier to use.
DGL also provides the dglAugment class, based on the dtkAugment class.
Objects based on either the dtkAugment or dglAugment class can be loaded
into the DGL object.
DGL also has other classes used to define windows, get input, calculate view
frusta and so forth. It is in these other classes that all of the Producer
code is contained.
All of the graphics display configurations and user interactions are
specified with DSOs loaded at run time. This allows a single application to
run on a variety of hardware, or with different user interactions, without
modification.
DOSG, DIVERSE for OpenSceneGraph, is a class based on dglAugment. Its
callbacks are invoked by the DGL object. All of the OpenSceneGraph code is
in the DOSG class. None of your work will involve modifying DOSG.
Back to Producer-
Here are all of ther DGL classes that use Producer, and what Producer
classes are used:
> find . -name \*.h | xargs grep include | grep 'Producer'
./dgl/DGLCameraThread.h:
#include
./dgl/DGLWindow.h:#include
./dgl/DGLWindow.h:#include
./dgl/DProducerInputCallback.h:#include
./dgl/DGLScreenHandler.h:#include
./dgl/DGLOrthoHandler.h:#include
./dgl/DGLViewport.h:#include
./dgl/DGLDisplay.h:#include
./dgl/DGLPerspectiveHandler.h:#include
