I've finally started to code. So far I'm doing the things I've spec'ed out. This basically means that I'm loading basic objects (spheres, teapots, cones, tori, and cubes) and displaying them. To give an example, the following file:
Sphr 0.0 0.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 Cone -3.0 0.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 2.0 Tpot 3.0 0.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 Tors 0.0 3.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 2.0 Cube 0.0 -3.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0 2.0
This results in the picture on the left. Although this might seem rather simplistic, the basic structure is quite extensible. First of all, the various object types that can be handled are registered (a four letter code is associated with a class). Then when the model attempts to load the file, it gets the code from the file, and calls the appropriate class. All of these classes (currently
Cube3D) are derived from a base class (
Object3D). The base class takes care of a few common things (when creating/destroying the object it takes care of maintaining the linked list, when loading, the first three sets of coordinates are the position, rotation and scale and when displaying it sets up the model matrix). The rest of the data represents object specific information.
When displaying, the list of objects is iterated through, and the Display function of each object is called in turn (the main class treats them all as being of type
Object3D, but in reality the appropriate Display function is called). A similar appropach will be taken when dealing with user input.
There is no user interface right now, I'm just using GLUT (GL Utility Toolkit) for the windowing. My plan is to add camera control (right now it's hardcoded, I want to create a
Camera3D class which I can manipulate in order to change the viewpoint, perhaps even create two sub-classes of that,
OrthographicCamera3D, for the two projection types) and then implement the other half of the project, the window-based interface. This will require me to first learn about the Mac-specific OpenGL calls (which would be required for setting up a drawing context and rendering into a GWorld), and then figuring out the architecture of the UI (Iconographer's isn't very C++ like, but I'm not sure if I want to go as far as have each control be a separate class).
I also have to implement the mesh tool, which will be one of the harder parts, especially when it comes to editing it. But I'm delaying it until after I have an UI up, since it'll be a lot easier to debug when I can view it from different directions and manipulate it. And of course I musn't forget colors (I guess this will be another attribute that will be handled by the base class, since I'm not planning for texture mapping, although I might have the option of adding colors to each vertex of the mesh). The reason why I can get away with no texture mapping is because I'm only doing a modeler, not a fancy renderer, and besides texture mapping would be too slow in software rendering (which I have to use since the current (third-party, unsupported) OpenGL driver for my Voodoo3 doesn't do windowed or offscreen rendering, only on the whole screen).