The console application evolved from what used to be the River Pilot
Simulator. The RPS was a specific activity and most of the content and
interaction was hard-coded. As the console began to become more general,
a lot of the hard-coded functionality was removed and replaced with more
The result is a more general purpose "engine" for interactive 3D exploration
of the type of datasets and content produced by the RiverWeb project. The
engine's flexibility comes from the fact that the content can be configured
with text files and that the running application can be manipulated by
action strings. These action messages can be
triggered in a variety of ways.
I was under the impression that I would have the chance to rewrite the
application but I never had the time to do so. Based on my experiences, if
I could do it all over I would consider the following:
Scene-graph - I would consider an alternative to Performer such as OpenSG. The advantages of such being better portability (Performer is IRIX and Linux only) and more control (can always examine the source). I would also consider
pure OpenGL for even more control and performance tweaking.
Run-time control - the "actions" paradigm works quite well but is limited in its power and requires a centralized "messaging center". A better approach
would be to code all the low level functionality in C++ as before, but to wrap
it with a real scripting language such as python. Then, the running application
would be an interpreter and the higher level functionality could be scripted.
For instance, user interactions would trigger arbitrary command strings to be
interpreted rather than just triggering one of many "action" messages.
Configurability - what developed out of the console application is a
crude configuration file format that is very strictly parsed. I would
consider a more flexible, powerful, and standard mechanism such as XML. This
could add a significant amount of work but may be worth it. Of course, if
the scripting capability was developed as described in the previous
paragraph, perhaps separate configuration files would not even be needed. In
effect, the scripts could contain the configuration information as well as
the run-time behavior.
Of course, this rewrite never happened. Since the code had developed over
several iterations, it was rather ugly. I spent a significant amount of
time cleaning it up, such that the newest version is actually readable. However,
it is still not pretty. :-)
Here I will outline the main components of the application. For more detail,
browse through the actual code.