Code

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 general code.

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.