Copyright © 1995 Walt Davis
Strip Window Framing
Object and BOCL Array
Shape, Scene, and
Plate 1 (3D Surface Wire
Plate 2 (George The
Plate 3 (George Transformed)
This document contains the following type
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
The Graphics Port System, easily understood
when referred to as the windowing system, needs to be completely reworked.
The following changes should be made:
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.
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 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.
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:
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
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.
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.
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."
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 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.
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.
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
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.
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.
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.
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.
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
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.
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.
Copyright © 1995 Walt Davis