OpenGL is a cutting-edge industry standard for the creation of fast, portable 3D graphics images. As defined by Silicon Graphics, Inc., it is strictly "a software interface to graphics hardware". As such, OpenGL covers only the actually rendering of 3D scenes interaction is outside its scope.
A great challenge for 3D programmers lies in developing OpenGL applications that end users can interact with. Similarly, defining 3D scenes must be possible for an end user who should require no knowledge of OpenGL programming. The goal of this project then was to create both an engine capable of producing real-time interactive 3D scenes and a facility for defining new ones. This 3D engine would need to have an interface that was as familiar as those in video games such as Doom or Quake. Scene building would also need to be straightforward.
To implement such a system, I first had to research whether or not OpenGL was in fact the correct foundation on which to build. When that was confirmed, it was necessary to choose both the hardware and software platforms I would use. I decided to use Windows NT 4.0 due to my familiarity with it, NTs native support for OpenGL and its extensive hardware compatibility list. The choice of Microsoft Visual C++ as my development tool stemmed from its OpenGL support (the OpenGL API was written in C) as well as my assumption that if I was programming for a Microsoft OS that I should be using a Microsoft compiler. Finally, my choice of 3Dfx's Voodoo2 3D graphics accelerator card was based on its price/performance factor, on-board OpenGL support and industry-leading acceptance.
Nearly all of the developmental difficulties I encountered were due to the scale of this project and the ungainliness of my tools. While I had anticipated that I would need to expand upon my knowledge of C++ and OpenGL, learning how to operate Visual C++ was an ordeal I wish on no one. With respect to project scale, I learned that the procedural development methodology was not always the one that was best-suited for my system. Having heard about Object-Oriented Technology and possessing some notion of its potential, I enrolled in the Object Technology course. Once armed with the representational power of OO, I gained a clearer idea of how to proceed and began to make better progress via an iterative development cycle.
Over time, keeping a daily log of my work helped to keep me on schedule, and the use of white-boards provided ample space for brainstorming and diagramming. Overall, the greater part of my development cycle was spent in designing the basic classes and theories behind how my engine should work. Since OpenGL itself is not object-oriented, my design and code were neither purely OO, nor was this necessary. The iterative development process and the OO aspects of my data structures were highly beneficial, but using OO for everything would have been illogical. Because I selectively utilized the best aspects of each paradigm, I experienced a shorter coding phase and found program expansion and debugging easier than I originally anticipated.
The end result is GLOBE: an OpenGL Object Engine that reads user-specified input files, and renders a scene via the hardware accelerator. Specifying GLOBE scenes is about as easy as HTML and its navigation interface is as familiar as Quakes. It is a fast, easy to use and portable 3D graphics engine that is limited only by its platforms 3D hardware support!
Advisor: Susan Reiser