PERS

BUTTERFLY White Paper

Introduction
Graphics Port System

Convert To Singleton

Strip Window Framing

Class Hierarchy
Transformer
Graphic Object Class
BOCL Object and BOCL Array
Graphic Object
Graphic Array
Shape, Scene, and World Shape

Scene

World

Plate 1 (3D Surface Wire Frame)
Plate 2 (George The Robot)
Plate 3 (George Transformed)
Conclusion

Introduction

This document contains the following type of information:

Bug Reporting
Incomplete Functionality
Further Research
Further Testing
Additions/Changes
Personal Comments

It may be helpful to read this document in conjunction with the header files document. In addition to the class defining code, BUTTERFLY code also contains the above type of information.

Individuals having little or no exposure to this project should consider reading "BUTTERFLY Theory."

Graphics Port System The Graphics Port System, easily understood when referred to as the windowing system, needs to be completely reworked. The following changes should be made:

Convert To Singleton

Conversion of the windowing system to a singleton type object having multi-module linkage should be done. This can be achieved using a non-singleton class having a private default constructor and a friend function that performs the object's construction.

Strip Window Framing

The current window framing functionality should be stripped from the windowing system singleton and a windows type class that is separate from the windowing system should be provided. This would allow developers to use a generic window object having no framing or to derive new window types having specific window framing. The window objects would be instantiated and then further initialized upon being passed to the windowing system singleton.

Incorporate Primitive Buffer

Incorporate into the windowing system singleton the graphics primitive buffer functionality. This entails a buffer of function pointers containing the addresses of the current set of graphics primitives being used; where, the current set of graphics primitives is determined by the coordinate system and window access being used.

Class Hierarchy Below is a class hierarchy illustrating the final object oriented design of project BUTTERFLY. It seems to be well suited within the domain of this project. As for whether or not this design will work for a three dimensional graphics system I dare not say. Nevertheless, given my inexperience with high end graphics functionality (animation, ray tracing, texture mapping, etc.), I feel good about the designs' graphics potential. As for the object oriented aspects of this project, I feel as though I have successfully put together my first tricycle. The following class hierachy is based on Grady Booch design methodogly:

Transformer

The Transformer class with perhaps the exception of additional testing is structurally sound. Nevertheless, I purpose the following additions and modifications:

Increase the matrix functionality of Transformer so to support N-dimensional transformations. That is, increase the matrix transformation base to N-dimensions, not the member function interface to N-dimensions.

Provide a generic transformation class that can be used as is or modified via inheritance. Such a transformation class, with modification to the Graphic Object Class (the metaclass), could then be passed to and used by a graphic object; thus, allowing a graphic object to posses specific N-dimensional transformation ability.

Graphic Object Class

The Graphic Object Class except for two of the graphics primitive function sets is functionally complete. The active graphics ports (active windows) set of graphics primitive is fully functional. The current access and display access sets of graphics primitives, who’s purpose may be questionable, have yet to be implemented.

The original plan to use the windowing system graphics primitives, as function calls within the Graphic Object Class primitives, was ignored. Instead, I chose to use the windowing system data structures and directly hardcode the graphics primitives. This results in significant speed hits.

BOCL Object and BOCL Array I chose to use BOCL (Borlands Object Class Library) to implement the container technology needed to develop the containment functionality of the scene and world graphic objects. I had hoped this would save time by not having to develop my own arbitrary containment objects. However, I found myself spending curious amounts of time, for lack of a better word, learning how to use BOCL. After figuring out how to use BOCL I found myself spending equivalent amounts of time figuring out what to do with unnecessary functionality and trying to predict what functionality may or may not be useful in the future.

In retrospect I am not sure if I would rather have developed my own container objects or used someone else’s. BOCL is definitely at the bottom of my list of choices. For future development I recommend trying a more professional library package such as "Tools.h++" by "ROGUE WAVE Software."

Graphic Object More experimentation with Graphic Object should be conducted. There seems to be some when deriving a new graphic object class from two or more classes having been derived from Graphic Object, mostly ambiguities. I’m not exactly sure where the problems are coming from, but I know that some of them, if not all, are in BOCL. In a nut shell, extensive exploration of Graphic Object’s application must be conducted before determining exactly what and where the problems are.

Graphic Array Graphic Array has all the same problems found in Graphic Object. These problems, unfortunately, are nothing more than the unavoidable and in this case unfavorable property of inheritance. Nevertheless, some additional problems have managed to work their way into Graphic Array. Again I believe these problems to be the use of BOCL. Specifically, the additional problems occur when attaching a Graphic Array object to another Graphic Array object. Like Graphic Object, extensive exploration of Graphic Array’s application must be conducted before determining exactly what and where the problems are.

Shape, Scene, and World The shape, scene, and world class where not developed. This is because their implementation should be simple and I was hesitant to begin development of extended layers of the class hierarchy until the lower layers could be thoroughly tested. Thus, I exhausted most of my time in the class hierarchy layers residing between and including the Graphic Object Class and Graphic Array. Upon working out the problems existing in these layers it should be safe to begin development of the shape, scene, world, and other extended layers.

Shape

The Shape class should be fairly simple to implement. Add to the Graphic Object class a virtual function (YourTypePlease) that returns an identifier representing the type of graphic object, shape, scene, world, or whatever. Once this function has been added then any class derived from Graphic Object should redefine the function YourTypePlease so that

it returns a unique identifier representing its class. Borlands class ‘Object’ contains such a function, but uses a different name, and may be used provided that one chooses not to strip out of the class hierarchy the use of BOCL.

Scene

The scene class should be developed after completing the shape class. Simply derive a new class, called Scene, from the Graphic Array class. In the Scene class, redefine the virtual attachment functions so to check for the type of graphic object being attached. If the type of object is shape or scene, continue the attachment by calling the attachment functions inherited from Graphic Array. Like shape, Scene must also redefine the virtual function YourTypePlease.

World

Once the scene class has been developed and thoroughly tested, the world class can be implemented. Simply derive a new class, called World, from the Scene class and redefine the virtual function YourTypePlease. Because the function YourTypePlease will return something other than shape or scene, in this case world, there is no need to modify the virtual attachment functions.

Plate 1 (3D Surface Wire Frame) Wire frame plot of a 3D surface viewed at four different rotations, generated using a single wire frame type object and one member function call. All four images are rendered simultaneously. Each window has its own object that provides a specified transformation(s). Each wire frame image consists of 6,400 line segments, resulting in a total of 76,800 transformations and the drawing of 25,600 lines.

Plate 2 (George The Robot) George the robot is a single object composed of 12 other objects (circles, rectangles, spirals, and more). All objects are polygon approximations. George has 4,366 line segments. In all, 17,464 lines are drawn and 34,928 transformations are performed. All four images are rendered simultaneously. The different views are achieved using camera like functionality. Each window is a lens looking in a specified direction and magnification.

Plate 3 (George Transformed) Here five George objects have been instantiated, transformed, and rendered. 1) No transformation. 2) Yshear<2>, Scale<2,2>, and Translate<70,2>. 3) Scale<1,4> and Translate<-40,-40>. 4) Xshear<2>, Scale<2,2>, and Translate<-50,30>. 5) Scale<6,1> and Translate<0,75>. Transformations build upon one another and propagate in the order sequenced.

Conclusion To say the least, this project has been full of discovery and mental challenge. In closing, I’m no longer hyped about the notion of object oriented design being a solution to the software crisis. Inexperienced team users of OOPL’s are, at first, more than likely better off designing object-based software systems. For now lets just say that OOD is a powerful tool when used appropriately and by experienced individuals.