PLG

MISSING IMAGE

Material Information

Title:
PLG a model for high resolution, three-dimensional, object-oriented computer graphics on personal computers
Physical Description:
vi, 76 leaves : ill. ; 28 cm.
Language:
English
Creator:
Krell, Mitchell, 1955-
Publication Date:

Subjects

Subjects / Keywords:
Computer graphics -- Data processing   ( lcsh )
Computer graphics -- Computer programs   ( lcsh )
Three-dimensional display systems   ( lcsh )
Object-oriented programming (Computer science)   ( lcsh )
Genre:
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )

Notes

Thesis:
Thesis (Ph. D.)--University of Florida, 1989.
Bibliography:
Includes bibliographical references (leaves 74-75).
Statement of Responsibility:
by Mitchell Krell.
General Note:
Typescript.
General Note:
Vita.

Record Information

Source Institution:
University of Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 001529326
notis - AHE2686
oclc - 22287938
System ID:
AA00003769:00001

Full Text











PLG: A MODEL FOR HIGH RESOLUTION,
THREE-DIMENSIONAL, OBJECT-ORIENTED COMPUTER GRAPHICS
ON PERSONAL COMPUTERS












By

MITCHELL KRELL


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


1989


















Copyright 1989


Mitchell Krell















ACKNOWLEDGEMENTS

It is important to acknowledge all the help which I

have received to get me to this point. First, I would like

to thank my parents, George and Selma Krell for their

guidance during the early years of my life. I am

also grateful to Dr. John Staudhammer for serving as the

chairman of my committee. His assistance has enabled me to

complete this dissertation in a timely manner.

I am appreciative of the aid which I received from

Danny Carter. His suggestions, editing services, and moral

support in the early stages were invaluable. Additional

moral support from Dr. Bruce "Harrumph Harrumph" Krell was

instrumental in reminding me that "against stupidity even

the Gods struggle in vain."

Last but not least, I wish to thank my family for the

major effort and sacrifice that they have endured to this

point. My wife, Lynn, has borne the burden of difficult

times to allow us to continue in the face of adversity as

well as the good times. My children, Gabriel and Matthew,

have had to patiently do without their "Dad" for long

periods of time and I hope to make it up to them. I thank

all of you from the bottom of my heart.


iii
















TABLE OF CONTENTS

page

ACKNOWLEDGEMENTS... .... ....................... ......... iii

ABSTRACT........... ..................................... v

INTRODUCTION............................................ 1

Overview................... .......................... 1
Description of Proposed Graphics Standards......... 8
Proposed Research. ................................ 12

A SIMPLE SOFTWARE ENVIRONMENT FOR 3-D GRAPHICS.......... 16

PLG DATA STRUCTURE SUPPORT.............................. 24

PLG ALGORITHM SUPPORT ................................... 33

CONCLUSION.............................................. 40

Summary....................................... .... 40
Future Work......................................... 46

APPENDIX A PLG PROPOSED FUNCTIONS....................... 49

APPENDIX B SAMPLE PROGRAMS............................. 66

REFERENCES..... .......... ............................... 74

BIOGRAPHICAL SKETCH..................................... 76















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

PLG: A MODEL FOR HIGH RESOLUTION,
THREE-DIMENSIONAL, OBJECT-ORIENTED COMPUTER GRAPHICS
ON PERSONAL COMPUTERS

By

MITCHELL KRELL

December, 1989

Chairman: John Staudhammer
Major Department: Computer and Information Sciences

The hardware to produce reasonably fast and high-

quality computer graphics on relatively inexpensive 286- and

386-based personal computers is currently available. The

main disadvantage with this hardware is that its price is

well beyond what the average user and potential researcher

or educational facility can afford. However, this problem

can be alleviated by simulating this hardware through the

use of sophisticated software.

This research attempts to define a model for producing

fast and simple three-dimensional high-resolution object-

oriented graphics on personal computers. This involves the

efficient storage and manipulation of a graphics environment

and graphics database. This graphics database allows the

real-time definition and modification of graphics data.









The storage of graphics information can be achieved

through a complex set of graphics data structures providing

the status of the graphics environment, storage of graphics

primitives and object definitions, and maintenance of an

active display list (i.e., organization of objects on the

screen). This data storage is transparent to the user when

implemented.

The other area which is addressed is the process of

manipulation and display of graphical data. A number of

algorithms are introduced which make these processes useful

and fast on PCs. In addition, methods for handling both

hierarchical and geometrical data organizations are

discussed.

This model, when implemented, provides a sophisticated

low-cost, high-speed, three-dimensional graphics environment

for the PC. Its low overhead and fast processing provide

the average user with a useful package which can be used on

existing or new MS-DOS-based equipment.















INTRODUCTION


Overview


"Although the public is mostly unaware of the computing

component, computer graphics are, perhaps, the primary

exposure that the lay public has to computing. This once

mysterious, innovative theory now serves multiple purposes

with powerful social impact. It touches many parts of our

lives--from watching scrubbing bubbles television

commercials, to providing X-ray views of soft tissue for

doctors, to viewing pictures of distant worlds transmitted

by space probes[KOC89]."

The last four years have brought great technological

advances in personal computer hardware, specifically in the

area of computer graphics. These advances have allowed the

PC to be used for computer graphics research and

applications by a much larger group of users than ever

before. Continued advances promise to expand that audience

to an even greater degree.

The PC with graphics capability has come into wide

usage in Computer Aided Design and Manufacturing (CAD/CAM)

and there are approximately twice as many PC workstations

being used as there are conventional workstations. The PC

is finding acceptance by scientists and engineers of all










disciplines including but not limited to process control

applications, lab instrumentation, business graphics and

image processing[MAC87].

Before now PCs were not used extensively in three-

dimensional (3-D) computer graphics for three basic

reasons[MAC87]: 1) poor response time (processing speed),

2) low-resolution controllers and displays, and 3) lack

of quality standard 3-D graphics software.

The problem of processing speed has been addressed by

the latest PC's, such as the Apple Macintosh IIcx, the IBM

Personal System/2, and a plethora of PC-AT class machines in

the 12- to 33-MHZ speed range. These systems have high

speed CPU's (such as the 80286) and are capable of much

faster graphics. It is these and the next generation of 32-

bit processors (such as the 80386 and the 68020) that allow

the use of PCs for serious graphics research and

applications (i.e., three-dimensional algorithms and the

like)[GUP87].

Display or graphics controllers have progressed to

a stage which allows them to be useful in this area.

Current controllers can be divided into two groups based on

capabilities and compatibilities. The first group is those

which are based upon the Video Graphics Array (VGA) standard

developed by IBM (and the Super VGA) and have no independent

graphics processor (see figure 1.1). The second group of

controllers generally are not based on any particular































41-)







r.4
P4
u



04
a,

c12


0

oo








pt1
>






C)
(O



0
0







U)
E
0




.r-









standard, have their own graphics coprocessor, and usually

have some sort of 3-D engine or capabilities built in.

VGA was introduced in mid 1987 and was quickly accepted

as a future standard by the video board industry. The VGA

board offered several enhancements to the boards available

at that time. These include higher resolution (640 by 480

pixel resolution in 16 colors) and crisper, clearer text and

graphics.

As VGA became more widely accepted, vendors sought to

give the user more capabilities than IBM and included higher

resolutions. Resolutions of 800 by 600 and 1024 by 768

pixels in 256 and 16 colors, respectively, began to appear.

These boards obtain the higher resolutions by simply adding

more video memory (up to 512k)[DOU89].

These boards are characterized by a 16-bit data bus and

graphics functions using chips such as the TI 34010[PON89].

Performance level for these boards is in the 2.5 million to

10 million pixel per second range. Prices for these boards

vary anywhere from $400 to $2000[JAM87].

The second set of controllers, termed "independent

graphics pipelines" or "3-D graphics engines" are developed

and manufactured by several vendors, such as Matrox, Metheus

Corporation, and Nth Graphics[DRE89]. The main goal of

these boards is to provide high speed and interaction

through the use of a dedicated graphics processor.

"Recognizing that high interactivity was vital to a

visual user interface and that maintaining a display with









higher resolution and realism required more processing

capability than was available from the CPU, several

manufacturers designed and built PCs with dedicated

graphics processing[GUP87]."

Providing a dedicated graphics processor has two

benefits: 1) faster screen management, and 2) achievement

of a small amount of parallelism[GUP87].

Screen resolutions for these boards range as high as

1280 by 1024 pixels with 60 Hz non-interlaced refresh rates.

In addition, there is a choice of 256 colors displayed from

a palette of up to 16.8 million colors.

However, the key for these boards is speed. "You can

never have enough speed[WES89]." The trick is to find the

best combination of drawing speed with color and screen

resolution to keep ahead of the competition, yet remain

affordable.

One method of producing speed in these boards is to use

"display list processing.[DRE89]" This is a means of

depicting a drawing as a list of graphic primitives (i.e.

vectors, etc.) that comprise the drawing (see figure 1.2).

This means that the list of graphic vectors in memory (on

the PC) is the drawing rendered on the screen. This display

list is processed by the display processor during each

refresh cycle of the screen and its contents are displayed.

Changing the screen requires that the display list be

changed prior to or between refresh cycles so that the cycle

is not interrupted.































U,
m











4 :
4-1





0
02
a)
UCN
0




*r3 t(
' *H
Cd
0(

U,

La


Q,


0




'-4
U)


U)

0l
C)

0
m
U)






Cd

U





Cd


C)1









Processing proceeds in two basic steps: 1) clipping and

transforming the vectors as the active drawing is modified,

and 2) rendering the results on the screen. While each step

is handled separately, both are integrated into a single

graphics pipeline. Each graphics step is performed by a

dedicated chip or suite of chips, such as the Intel N10

chip, optimized for the job[BR089] [NEF89].

Speed can be further improved by keeping a copy of the

display list in memory on the board instead of on the PC's

hard disk or RAM. The PC's list gets updated from time to

time or only after the drawing is complete.

This class of boards may use anywhere from 24 to 64

bits per pixel[RAS89]. Performance levels on these boards

is up to the 20 million pixels per second range. The major

drawback is the fact that they cost between $3000 and

$10,000.

The ability to work well on AT class machines is a

major advantage of these boards. A PC AT with a high-end

3-D board runs at 10 times the speed of a 386-class machine,

while retaining a wider choice of applications. The result

is a DOS-based graphics workstation costing $5500 to $12,500

that performs 3-D wire-frame and shading functions at speeds

found only in $50,000 to $70,000 workstations.

In summary, the hardware to produce reasonably fast and

high-quality, three-dimensional computer graphics on 286-

and 386-based PCs is now available. The main disadvantage

with this hardware is that its price is well beyond what the









average user and potential researcher or educational

facility can afford. However, this problem can be

alleviated by simulating this hardware through the use of

sophisticated software. This is, in part, the secondary

goal of this research. The third and final problem is that

of software.


Descriptions of Proposed Graphics Standards

Three-dimensional computer graphics software remains

somewhat in the infant stage in both design and usage. Most

people usually end up re-developing known procedures when

they write graphics applications, especially working on a

PC. There are, however, several standards and proposed

standards for graphics software. Two to be considered in

greater detail are the Graphical Kernel System 3-D (GKS 3-D)

and the Programmers Hierarchical Interactive Graphics System

(PHIGS)[BON86]. These are the most actively used and

discussed software systems in the computer graphics

industry.


GKS 3-D

GKS 3-D is a proposed three-dimensional superset of the

current GKS standard. It is designed to provide a basic set

of 3-D functions with provisions for incorporating hidden

line/hidden surface removal. It is upwardly compatible with

GKS so that GKS programs can run unmodified in the GKS 3-D

environment. GKS 3-D provides a full set of viewing

operations that can support not only the widely known









synthetic camera model but also any special viewing model

tailored to the application[PUK86].

GKS 3-D is entirely a 3-D system. This means that all

geometric operations within GKS 3-D occur in three

dimensions. At the heart of the GKS 3-D model is the

concept of a single transformation pipeline that supports

only 3-D constructs and treats two-dimensional (2-D)

operations as shortened 3-D operations. Data stored in GKS

3-D, such as segments, are kept in 3-D form. All data which

GKS 3-D uses is three dimensional even though its original

specification may have been two dimensional[PUK86].

GKS 3-D extends each GKS primitive to three dimensions.

The GKS 3-D primitives include the following[PUK86]:

POLYLINE -- a sequence of straight line segments connecting

a series of 3-D points; POLYMARKER -- a symbol referenced to

one or more 3-D points; TEXT -- a string of characters in a

specified place; FILL_AREA -- a planar polygonal region that

may be filled with a solid color or pattern, or

crosshatched; FILL AREASET -- one or more planar polygonal

regions, each of which has edges; CELL_ARRAY -- a

parallelogram composed of individual color cells; and

GENERALIZED_DRAWING_PRIMITIVE -- for accessing non-standard

3-D graphical output capabilities.

While GKS 3-D defines both a 2-D and 3-D form of each

output function, it defines only one form of each output

primitive. So 2-D functions generate 3-D primitives with a









Z value of zero. The geometry of each primitive is

contained entirely within the primitive[PUK86].

GKS 3-D supports four types of transformations:

normalization, segment and insert, viewing, and workstation.

The viewing transformation is unique to GKS 3-D, while the

other three are supported in GKS in 2-D form. Together

these transformations form the GKS 3-D transformation

pipeline[PUK86].

GKS 3-D is designed to provide a strict extension of

GKS to support 3-D functionality. It allows existing GKS

programs to operate in a 3-D environment and also allows

existing GKS code to be included in 3-D applications[PUK86].


PHIGS

PHIGS is the other proposed standard for 3-D computer

graphics. PHIGS is useful for applications that manipulate

complex displays of 2-D or 3-D data in a highly interactive

environment. Its major advantage is in its hierarchical

data organization and flexible editing capabilities.

The primary purpose of PHIGS is to free applications

programmers of the burden of developing systems that

effectively and rapidly display and manipulate their

application models. It, perhaps, could be considered the

"interaction toolset for graphical model building and

manipulation[SHU86]."

"The key features of PHIGS are its ability to

efficiently describe the application model in the graphics

system and to rapidly update the graphics model and


I










corresponding rendering as the application model changes.

The organization, content, and modifiability of the graphics

data are the key aspects that make PHIGS a model

manipulator's graphical toolset[SHU86]."

PHIGS has a set of primitives similar to those of GKS

3-D, including a very powerful hierarchical graphical data

structure known as a STRUCTURE. This hierarchical data

organization is commonly used in many applications and can

easily be mapped onto and from other data

organizations[SHU86].


Maior Differences Between PHIGS and GKS 3-D

Some of the major differences between PHIGS and GKS 3-D

are[SCH86]: 1) GKS's data structure, the segment, is

restricted to a single level and is used to represent

information about a graphics image rather than information

about a graphics model (such as in PHIGS). In addition, the

segment stores normalized data while the PHIGS structures

are defined in modeling coordinates. 2) Once a GKS segment

is created its contents cannot be modified. Only aspects

affecting the whole segment such as visibility or segment

transformation can be changed. PHIGS allows any part of a

structure to be modified at any time. 3) GKS binds or

associates attributes(i.e., line color, style, etc.) to

primitives when they are created and before they are stored

in the graphics data structure. Modifying primitive

attributes after a segment is created requires deleting the









segment and recreating it with different attributes. In

PHIGS, output primitive elements become output primitives

only when a structure is traversed for display. This is

also the point at which attribute structure elements are

bound to output primitives. The traversal-time binding of

attributes allows flexible, easy modification of graphics

data. 4) GKS provides a limited modeling transformation,

called a normalization transformation, that is applied

once to a given set of data. PHIGS allows multiple,

cumulative modeling transformations to be applied in

modeling space at traversal time.

GKS 3-D and PHIGS differ primarily in these areas only.

In fact, PHIGS actually, in terms of primitives, is a

superset of GKS 3-D.

The current implementations of GKS available for the PC

are the 2-D versions, and none of the implementations

address the new equipment in the PC realm other than VGA

(640 by 480 in 16 colors). There is an implementation of

PHIGS for the 286- and 386-based PCs[CGA89]. However,

because of its high cost and complexity, it is not useful

for the average user. In addition, it only supports the

standard VGA mode.


Proposed Research

There exists a need for a new graphics software

standard[PUK88], one which will be better oriented for the

PC environment. It should have an object-oriented data

structure (like PHIGS) that allows the programmer to develop










a graphics model. It should be device independent so as to

allow the user to take advantage of new hardware for the PC.

And finally, it should use a simpler 3-D graphics viewing

pipeline which allows the programmer to do everything in

terms of modeling space.

The system which is to be designed through this

research could be used as a model for a much-needed PC

graphics software standard mentioned above. This system

would have some of the best features of both GKS 3-D and

PHIGS while still taking into account some of the PC's

limitations, such as memory allocation and data storage.

The system should be defined in terms of[BR085] 1)

control functions, 2) output primitive functions, 3)

attribute setting functions, 4) workstation table setting

functions, 5) structure operations, 6) input functions,

7) display functions, 8) transformations functions, and 9)

utility functions (which includes error condition actions

and inquiry).

The language binding for this system will be the C

language although it can easily be extended to include other

languages such as Pascal, Modula-2, and Ada. The graphics

software and display list processing, because of C's

low-level functionality, will be most effective and faster

in C. Since C is a high-level language and is widely used

in academic environments, it is a natural selection for the

user interface. In addition, many graphics algorithms are









currently defined in terms of C-like languages and therefore

would increase the system's versatility and friendliness.

The minimum hardware required for such a system is an

Intel 80286-based 10 MHz system. The minimum graphics

hardware should be IBM's VGA, which has a resolution of at

least 640 by 480 pixels (although resolutions of 800 by 600

or 1024 by 768 are preferred). Additionally, a math

coprocessor will enhance the system. Graphical input can be

obtained through the use of a pointing device. This will

allow a wide variety of applications, including but not

limited to algorithm research, computer vision, image

processing, robotics, user interface design, and education.

Total cost for the system is in the $2500 to $3500 range.

The primary aim of this research is to develop a model

of a user-interface for a low-cost high-resolution graphics

system on which the average user can easily produce object-

oriented 3-D graphics. The model is targeted for users

such as universities where funds are limited and there is

already existing PC equipment which could be utilized for

this type of research. "Producing interesting pictures of

objects with expensive equipment is easy, but producing the

same quality imagery with inexpensive equipment is

interesting[STA89]." This model, when implemented,

simulates the operations which are performed by dedicated

graphics processors on more expensive systems and provide a

simple and useful three-dimensional graphics environment.






15


The purpose of this research is threefold: 1) to

determine the problems that need to be addressed by a 3-D

software system for the PC environment, 2) to design (and

implement a subset of) a 3-D graphics system which addresses

these problems, and 3) to determine the feasibility of

effectively using this system in a PC environment for 3-D

graphics applications and research.














A SIMPLE SOFTWARE ENVIRONMENT FOR 3-D GRAPHICS


PHIGS-Like-Graphics (PLG) is a model for a software

environment for 3-D graphics on personal computers which

consists of a robust set of functions loosely based on the

PHIGS standard. The hierarchical organization of data,

storage of data, methods of local and global

transformations, and object- oriented approach [BRO85] are

all necessary for the system to be useful, yet remain

simple.

The ultimate goal of PLG is to produce a picture on the

screen. In PLG, as in PHIGS, objects are defined by a

sequence of structure elements which includes output

primitives, attributes, transformations, and instances of

other objects. Since views are nothing more than groups of

objects, the workstation or screen is constructed from one

or more views.

Any graphics system, such as PLG, must possess certain

characteristics similar to the ones discussed in the

following paragraphs. Pictures built from geometric models

(organized for use of relative positioning and movement)

have a clearly defined structure. This structure could

easily be seen in repeated use of symbols, connections, or

overall organization of a complex image. An example of this

would be a robot arm where the movement of parts of the arm













Geometric Data Organization

Robot Arm


Geometric Data Organization
Figure 2.1









are dependent on the position of the parts to which they are

connected (see figure 2.1). If the object's structure is

not clear, its underlying data organization should be

understood by the application (hierarchical organization --

for ease of picture construction). For example, take an

image of a table constructed of various parts (i.e., table

top and legs), some of which may be the same object (a leg)

positioned differently (see figure 2.2). The software

should support both cases by separating the definition of

graphics data from the actions required to display them

[BR085].

The structured definition of graphics data inherently

reduces repetition and connectivity problems. The repeated

use of object components and relationships between them

should be a part of an object's definition.

Picture component construction should also be

supported. The structured definition of data will allow

objects to share components. This allows faster and easier

definition and modification of picture descriptions. This

also reduces storage requirements for graphics data.

There is a need for interactivity. Whenever possible

the software should support real-time definition and

modification of graphics data. The ability to add or delete

individual primitives is desirable though not necessary.

The system should perform 3-D modeling transformations

and 3-D viewing projections (perspective and parallel).

General modeling will provide the flexibility of defining





































4-)





0
N







0 *

4




*4

a,
.-i









objects in their natural coordinate system and then

positioning them (using scaling, rotation, or translations)

in some other coordinate system. There is no need for a

workstation transformation (in the traditional sense) since

only a single workstation is supported. However, if a

network version were to be needed, the workstation

transformation might be of some use.

A good graphics system should relieve the applications

programmer of certain tasks. Specifically, it should manage

the storage and display of 3-D graphical data. A

hierarchical database will be created and maintained to

relieve the application of a large amount of overhead. It

should allow the user to select any view of the data and

then generate 2-D drawings of 3-D objects.

Areas in which this type of graphics system would be

useful include, but are not limited to computer aided

engineering (i.e., drafting, VLSI design, and finite element

modeling); process control (i.e., numerical control data and

tool path simulation, process monitoring, and robotics);

command and control (i.e., defense simulation, weapons

system management, and traffic control simulation); and

others such as molecular modeling, architectural design, and

mapping.

The proposed system needs to include the following nine

groups of functions: 1) control functions, 2) output

primitive functions, 3) attribute setting functions,

4) workstation table setting functions, 5) structure


i









operations, 6) input functions, 7) display functions,

8) transformation functions, and 9) utility functions.

These functions and the environment which they manipulate

are the key areas which make the system useful [IBM85].

The first area, control functions, is used to modify

system states and does not store or modify graphics data.

These functions include initialization and termination

functions as well as commands to control screen updating

operations.

The output primitives address the specification and

creation of drawing elements (i.e. structure elements).

They have a 3-D form (i.e. an x, y, and z coordinate) and

are displayed when the structure in which they are contained

is encountered during structure traversal. The output

primitives should include specifications for drawing lines,

generating text, creating polygons (hollow or filled), and

possibly pixel arrays, the latter being less useful than

the rest. These primitives require that functions to

initialize the graphics system be called prior to their use

and may only be inserted into open structures.

The attribute functions are used to describe the

characteristics of output primitives, including size, shape,

style, and color. These functions should set environmental

parameters which are inherited by structure elements. They

are bound to the primitives at creation time but may be

changed at any time. These attributes are applied at

traversal time. They include basic functions such as line









color, interior color and style for polygons, and text size

factors.

The workstation functions are less useful in a PC-based

system such as this one, but they do include some important

operations. The ability to set characteristics for each

existing view is a necessity. These characteristics include

setting viewing projection (parallel or perspective), view

reference point (the viewer's eye position), and visibility.

The structure operation functions allow an application

program to manipulate structures and their contents. These

include operations to create (open and close) a structure,

delete a structure, edit a structure, and execute a

structure, the latter being useful for creating

hierarchically structured objects.

Input functions allow the application to interact with

the user. These functions should support the major input

devices used on PCs. These include the mouse, the

joystick, and a general input device using the serial port.

The display functions are also a small but necessary

set of functions. These include the method for associating

structures with views. This allows for an N to M

relationship between views and structures (i.e. many

structures may be associated with multiple views and vice-

versa).

Transformation functions fall into two categories:

modeling and viewing. The modeling transformations are used

globally (when applied to an entire view) or locally (when









applied within a structure). They allow the application

program to move and place objects. The viewing

transformations are used for setting window and viewport

limits and for mapping from world coordinates to device

coordinates.

Utility functions include anything which does not fit

into the above categories. They may include mechanisms for

creation and manipulation of matrices and functions which

"query" the system to determine information about its

current status. This information is usually stored in

environmental variables, and these functions shield the

environment from abuse by the application while still

allowing access to the information.

The above areas are the minimum necessary for a useful

3-D graphics system. The main objective is for the system

to be robust without encountering too much system and

compute time overhead. The methods for accomplishing this

are discussed in the next two sections. More specific

information concerning the functional specifications for

each area is contained in Appendix A.















PLG DATA STRUCTURE SUPPORT


The development of a graphics software environment,

such as PLG, requires the use of several data structures for

determining the graphics environment's status, maintaining

graphics data structures, and managing the display list.

The key to graphics data management is to develop a set of

data structures which allow us the storage of the most information

in the least amount of space, yet still be quickly

accessible when it is needed. It is important to calculate

and store as much useful data as possible prior to the

traversal or refresh cycle where it is used. This can speed

up the refresh cycle by a large factor since many of the

calculations required for projection are floating point

functions (such as sine and cosine).

The data structure used for maintaining the graphics

environment has a fixed size (approximately 600 bytes), yet

uses very little overhead. It contains various information

about the graphics environment state including whether or

not the graphics environment has been initialized. Current

attribute states regarding line color, polygon interior

style and color, and text color also reside here. Other

information useful to the system encompasses window and

viewport limits (for the current view), pointers to the









graphics data structures and the display list, a pointer to

the top of the transformation state stack, temporary-use

global matrices, pointers to the current view and current

open structure (together with a pointer to its tail), video

configuration, and the current video memory page in use (for

use in animation through video page switching).

The storage of graphics data on the PC is a problem

that must be carefully addressed. A method must be

developed which fits either a geometrical or hierarchical

form. This method of storage should be transparent to the

user and still address problems such as memory management

and speed of access which are necessary for a useful

graphics system.

It is necessary, at this point, to clarify the terms

data structure, graphics data structure, and STRUCTURE.

Data structures are language level (and sometimes

application-dependent) arrangements of information accessed

by a program. This may involve instances or combinations of

arrays, records, lists, stacks, trees, and/or files. A

graphics data structure (GDS) is simply an implementation of

a data structure which stores specific graphics information.

A STRUCTURE is a logical representation which allows for the

creation, modification, and display of graphical objects.

These consist of structure elements (primitives) and are

implemented through the use of graphical data structures.

The other graphics data structures that are required

store two types of screen update lists. One list


































0


a)



0
4n
o







4
'-I

a)

i.n



J2
cr -
ff u
*^
1-
0r









(STRUCTURES_LIST) stores the actual graphics or picture

information. The second list (VIEWS_LIST) is a fast-access

display list.

The STRUCTURESLIST is constructed of STRUCTURES.

These STRUCTURES are made up of 5 basic primitives: 1)

transformations, 2) polylines, 3) polygons, 4) other

STRUCTURES (this is an execute STRUCTURE command), and 5)

text. The STRUCTURES are used to define objects in

pictures. This STRUCTURESLIST is a linked list of

STRUCTURES as they are created (in chronological order).

The order is unimportant and is not used for picture

generation. Each node in the linked list contains the

structure number, visibility flag, and a pointer to another

linked list which stores the actual primitives and

attributes associated with a particular STRUCTURE (see

figure 3.1). This allows each STRUCTURE to be stored only

once and saves memory and overhead later. This construction

is similar to those suggested in [CAH86] and [BR085]. All

information is stored in world coordinates.

The method for storing each STRUCTURE required creating

a variant record which could store information and

attributes about a particular primitive or STRUCTURE element

(see figure 3.2). This method of attribute storage is

different from PHIGS which binds attributes at traversal

time. This is important because it allows the refresh cycle

(structure traversal) to occur faster since all the

necessary information is immediately available. It is not,




























0 CO -m

~d c~ cCI)


0

a
o





4-1




C0
4-) -


4JW

ri







U
1u2
H,
Hi


0
o




oI
o












E


-0 0

0
C 0 o)


F-O Om
0CL,
Q)









however, a disadvantage due to the easy methods for

modification of STRUCTURES after they have been created. In

fact, the STRUCTURE's makeup and attributes may be changed

between refresh cycles to create animated effects. This

method of storage allows the system to dynamically allocate

any memory it needs to store data during the creation of the

STRUCTURES and therefore requires very little fixed

overhead. A STRUCTURE element for a polygon, for example,

contains the number of points in the polygon; line color for

the polygon; whether the polygon has a hollow, solid,

hatched, or patterned interior; the interior color or

pattern style of the polygon; a calculated interior point

(used as a seed for filling); and a pointer which indicates

the dynamic array where the x, y, z coordinates of the

vertices of the polygon are stored. The same element for an

execute STRUCTURE instruction only contains the address of

the STRUCTURE to execute or process. This list also has all

the information necessary for refreshing the screen (in

regards to the structures themselves) and nothing must be

recalculated during that process.

The second list which must be maintained is a list of

the active views (VIEWS_LIST). This contains information

about each view including the view number, and whether or

not the view is currently active (or visible). Since

multiple views are supported, more than one view can share

the same structures. Again, this allows for more efficient

storage of the data.









The VIEWSLIST contains a node for each view which has

been defined by the application. Each node contains a

pointer to a linked list of STRUCTURES and transformations

which have been associated with a particular view. Only

transformations and execute STRUCTURE instructions are

actually contained in this list (see figure 3.3). As

previously noted, the actual address of the STRUCTURE is

stored so as to facilitate quicker refresh. The structures

are redrawn in chronological order. The order may be

changed by setting priorities (in relation to other

structures). This requires only a manipulation of pointers

to change structure priorities. The refresh cycle now

requires that we simply traverse the VIEWS_LIST applying any

transformations encountered and executing any structures

encountered. The algorithms used in this process are

discussed in the next section.

Additionally, the VIEWS_LIST contains two special

transformation matrices used by the system. The first is

the view mapping matrix. This matrix is used to maintain

window and viewport for the view and to transform from eye

coordinates to device coordinates using formulas suggested

in [NEW79]. The second special matrix is known as the

viewing matrix. This transformation is used to maintain the

user's viewing reference point. It converts points from the

world coordinate system to the eye coordinate system. The

algorithm for this is discussed in the next section.

































CI- ) C. 0

a) *
-"











I>
Z I Z w 2 I


3 C I





Q) 04
a )
o a 3


a) Cl)
a, 3 (





0 e















0- E- 2

s ~- Ei __

*^c ___ 3






32


In summary, the advantages of this method of data

storage are 1) low overhead (each node only takes 36 bytes

of overhead), 2) high speed of access (all needed

information is immediately accessible), 3) versatile and

easy modification of objects, 4) dynamic use of memory

(using extended memory PLG can store more than two million

line segments on a PC AT with eight megabytes), and 5) a

direct, simple method for archival processing of images.















PLG ALGORITHM SUPPORT


A number of algorithms are needed to support a system

such as PLG. Three areas are particularly important: 1) the

viewing pipeline, 2) transformation application and

inheritance, and 3) the screen refresh algorithm (structure

traversal).

The viewing pipeline is similar to ones suggested in

[HEA86], [NEW79], and [FOL82] which include three-

dimensional clipping, viewing projection, and conversion to

device coordinates. In addition, provisions have been added

for hidden surface removal, lighting, and shading models as

suggested in the PHIGS+ [VAN87] specification (see figure

4.1).

The viewing process is simplified by storing all

transformations as matrices, as suggested in [NEW79] and

[VAN87]. As usual, the transformation matrices are

concatenated so very few are directly applied to points thus

greatly speeding execution. This concatenation process

allows global and local transformations to be easily applied

and inherited. The method for this will be discussed below.

The viewing pipeline is simple. First, any modeling

transformations (local and global) are applied, then the

results are transformed to viewing coordinates. The viewing










































L)

>
Cl)

C/)O LI)



AEO


a)








P40
*H *
0)l









coordinates are clipped and projected to the window.

At this point, hidden surface elimination and lighting (and

shading) algorithms would be applied. Then the coordinates

(which up to this point have all been three-dimensional) are

transformed to a two-dimensional viewport and finally to

device coordinates for actual drawing.

PROCESS STRUCTURE
INITIALIZE LOCAL STACK COUNT
SET CURRENT TO HEAD OF STRUCTURE
WHILE MORE STRUCTURE TO PROCESS DO
PROCESS EACH PRIMITIVE IN STRUCTURE
CASE TAG OF
CASE 1 : TRANSFORMATION- PUSH V, INCREMENT
STACK_COUNT, SET V TO V x XFORM.
CASE 2 : POLYLINE- EXECUTE POLYLINE
CASE 3 : POLYGON- EXECUTE POLYGON
CASE 4 : EXECUTE STRUCTURE- CALL PROCESS
STRUCTURE RECURSIVEE)
CASE 5 : TEXT- EXECUTE TEXT
END CASE
GET NEXT PRIMITIVE
FOR I = STACK COUNT DOWNTO 0 DO
POP V. /* V IS VIEWING TRANSFORMATION */
END PROCESS STRUCTURE


Process Structure Algorithm
Figure 4.2


The method for handling local and global

transformations is similar to that suggested in [BRO85] and

[CAH86]. The mechanism for implementing this is

significant. Inherited transformations are handled with a

stack. Each time a new local transformation is encountered

the previous concatenated viewing matrix is stored on a

stack and a new viewing matrix is calculated using the new

local transformation. When we leave the level containing

the local transformation, rather than recalculating the









previous viewing matrix by applying the inverse of the local

transformation, we simply pop the last viewing matrix off

the stack. This involves no recalculation and very little

overhead. This works for one or more local transformations

on the same or different levels (see figure 4.2).

Consider the structures pictured in figure 4.3.

Initially, transformation one is applied to the polygon

which forms the table top to place it in its proper

position. Then structure two is processed as part of

structure one.

The first thing encountered is local transformation

two. At this point transformation one is saved on the stack

and a new viewing matrix is created by concatenating

transformation one and transformation two. Next the leg is

drawn using the new viewing matrix. This concludes

structure two and before leaving this structure the previous

viewing matrix is restored from the stack so that any

additional primitives at the level of transformation one

will use only transformation one. This process would

continue in the same manner for the other three structures.

This particular method works well for both geometrical and

hierarchical structures.

The last algorithm, the structure traversal (see figure

4.4), incorporates the two previous algorithms. The process

begins with the first view and processes each structure

within that view. The nodes associated with each view in

the update list (see figure 3.3) consist only of






































a)

i-4
0
4-)

U)






(a,
a,


$4




H









transformations and execute structure instructions. This

allows faster processing of these structures. After the

last structure is processed the next view is processed and

so on until all views are processed or refreshed.


PROCESS UPDATE WORKSTATION
INITALIZE STACK
CLEAR SCREEN
SET CURRENT TO BEGINNING OF VIEWS LIST
WHILE MORE VIEWS TO PROCESS DO
IF THE VIEW IS VISIBLE THEN
INITIALIZE VIEW MAP
INITIALIZE VIEW MATRIX
INITIALIZE VIEW TRANSFORMATION
PROCESS EACH NODE
/* PROCESSING EACH STRUCTURE AND TRANSFORMATION
ASSOCIATED WITH THIS VIEW */
WHILE MORE NODES TO PROCESS DO
CASE TAG OF
CASE 1 : VIEW TRANSFORMATION- SAME PROCESS
AS IN PROCESS STRUCTURE
CASE 4 : EXECUTE STRUCTURE- CALL PROCESS
STRUCTURE
END CASE
GET NEXT NODE
GET NEXT VIEW
END PROCESS UPDATE WORKSTATION

Process Update Workstation Algorithm
Figure 4.4


Note that this processing is a simple linear

processing, even when nested structures and local

transformations are involved. It is easy to see that for

each active view the STRUCTURES associated with it are

visited (executed) once and requires the same amount of work

or processing for a visit.

When nested structures and local transformations are

encountered they are handled in a recursive fashion which

allows ease of inheritance for hierarchical and geometrical






39


organizations. This method of processing requires much less

overhead, since it only uses recursion under special cases,

and therefore is much faster.















CONCLUSION


Summary

The primary aim of this research was to design a three-

dimensional graphics model which is low-cost, more user-

friendly than PHIGS, more versatile than GKS 3-D, yet still

addresses the constraints of the PC. This model allows both

simple graphics to be produced along with complex objects

defined through the use of STRUCTURES as in PHIGS. These

STRUCTURES are more versatile than the segments created by

GKS 3-D and can easily be edited and manipulated through the

use of scaling translation, and rotation transformations.

The real time capabilities for updating the workstation add

a dimension for dynamic graphics which GKS 3-D does not

have. In addition, the user-interface for this model is

simpler than PHIGS requiring much less information to be

supplied by the user in order to be used. However, the

model still addresses and solves some of the problems of

memory management through the use of a sophisticated and

efficient method for storage and manipulation of graphics

information. It allows the user to define and manipulate

three-dimensional objects in a simple PHIGS-like fashion.

This model identifies a subset of PHIGS-like capabilities

that comfortably work within the confines of a PC.









PLG allows the programmer to define objects in terms

of geometric or hierarchical relationships. In addition, it

does so with a minimum of effort on the part of the user.

This is because a three-dimensional graphics database is created a

maintained by the PLG environment to alleviate the user's

need for extra programming which is not related to the

application. This greatly simplifies the programmer's work

and frees him to concentrate on developing the application.

Through the use of structures, PLG supports

construction and definition of objects in terms of graphics

components. This allows faster and easier manipulation and

modification of pictures. The addition of an interactive

feature, through the real-time definition and modification

of graphics data, allows the user to change individual

primitives.

Since PLG is a single-user system, much of the overhead

for maintaining workstations has been eliminated leaving a

slimmed-down, speedier processing pipeline. The use of

modeling matrices simplifies this processing even further.

PLG also supports local and global transformations for

STRUCTURES and views which are used for manipulations of

object and scenes. These transformations are also handled

through the use of matrices.

PLG addresses the six ground rules for graphics

software design provided by [NEW79] of simplicity,

consistency, completeness, robustness, performance, and

economy. PLG meets these rules as follows:









1) It is simple. There are no features or functions

included which are too complex for the application

programmer to understand. The model for the system is based

on PHIGS which has been explained in many publications.

2) PLG is consistent and behaves in a predictable

manner. All functions are specifically defined and follow a

consistent pattern to allow the programmer to easily build a

conceptual model of the graphics system.

3) PLG is a complete model in that it contains a

reasonably small set of functions which can handle a wide

variety of applications. This does not imply

comprehensiveness (i.e., every imaginable graphics

facility).

4) The model defines a number of defaults allowing a

certain amount of omission, abuse and mistreatment with a

minimum of complaint providing a robust system. It calls for

termination of execution only in extreme circumstances.

5) Since it is a single-user system, has a consistent

performance response for any user. It offers no special

advantages to one who understands the system's internal

workings.

6) An implementation of this model is economical, (it

adds only about 15K bytes in its current form) and may be

added to almost any application.

PLG's set of functions is used to manipulate the

graphics on the screen and maintain the graphics

environment. These functions address the nine areas









discussed previously which include graphics system control,

output primitives, setting attributes, workstation table

settings, structure operations, graphical input, display,

transformations, and various utilities. They work with any

currently existing and future MS-DOS-based computers.

PLG handles the problems of data storage and graphics

processing speed by defining several special data structures

and some unique algorithms to manipulate these data

structures. One data structure is used for maintaining the

graphics status and environment This data structure is

never accessed directly by the user, but is manipulated

indirectly by PLG functions. A second data structure is

used to store the graphics objects defined by STRUCTURES.

This stores actual graphical information by way of graphics

primitives. The last data structure is for maintaining the

display list to refresh the screen. It stores information

concerning which STRUCTURES and transformations are

associated with each view and which views are currently

active (or displayed) on the screen. As with the

environment, the user never directly interacts with these

data structures but indirectly manipulates them through PLG

functions making any implementation transparent.

The development of algorithms for transformation

application and inheritance allowed the support of both the

geometrical and hierarchical object organization. The use

of a stack for storing and retrieving viewing transformation

matrices helps speed the inheritance process by eliminating









calculations of inverse matrices and unnecessary extra

matrix multiplication.

The structure traversal algorithm, used to update

graphics and refresh the screen, is linear (see table 5.1)

and provides a depth-first processing of nested STRUCTURES.

This simulates the display processor which might be present

in the more expensive graphics hardware for PCs.


PLG Performance Results
Table 5.1

Vectors Time to Traverse (in seconds)
625 1.15
1225 2.08
2425 4.01
3025 4.95
4825 7.74
6025 9.86
9625 15.03


PLG offers the average user a model which is useful on

the PC by defining storage methods for 3-D graphics models

which allow easier manipulation and processing of graphics

information. In addition, a number of algorithms are

offered as part of the model which are fast and efficient

when used with the PLG storage methods while still

maintaining a versatile graphics manipulation model. These

algorithms include unique methods for easy implementation

and maintenance of dynamic object definitions and methods

for manipulation of these objects, as well as methods for

dynamic screen updating.

PLG supplies a low-cost alternative for sophisticated

high-speed, three-dimensional, object-oriented graphics on






45


PCs. It's low overhead (approximately 15K bytes) and fast

processing (almost 600 vectors per second on an AT-class PC)

provide the average user with a useful package. An

implementation of a subset of PLG, using C bindings, is

available from the Computer Graphics Research Lab at the

University of Florida. This makes PLG easily accessible and

well within the reach of the average user or educational

facility which wants to use it on existing or new equipment.









Future Work

Several areas of research pertaining to PLG remain to

be explored. The first step is to implement the complete

system, rather than the current subset implementation.

Components which remain to be implemented, after further

definition, include 1) the text output primitive, 2) the

graphical input functions, 3) the ability to create and use

programmer supplied color tables, and 4) the functions for

editing STRUCTURES and STRUCTURE elements. Current methods

of editing STRUCTURES involves deleting the complete

STRUCTURE and recreating it.

The text output primitives require some further detail

and decisions as to whether geometric text capabilities

should be added. This is generally determined by the

available hardware and must be considered.

The graphical input functions need to be expanded to

include more types of input devices. Another possibility

concerning input functions would be the definition of string

devices and an event queue which would allow the system to

determine what, if any, input events have occurred.

The ability to create and use different color tables

needs to be researched as well as the definition and use of

color systems other than RGB.

Another area of interest is the description of

additional device drivers, such as 800 by 600 and 1024 by

768 pixel resolutions. The structure of PLG allows the









extra device drivers to be easily integrated by using a

modular driver-oriented approach.

An important consideration for PLG is the investigation

of methods for directly accessing and segmenting the video

memory. This is necessary in order to implement video page

switching which is used for smoother animation. The price

of video memory has been decreasing for some time, and low-

cost graphics cards are now available with as much as 512K

bytes of video memory on the board. Large amounts of memory

allow additional video pages, even at the higher

resolutions (i.e., 800 by 600 and 1024 by 768 pixels), which

are not currently accessible due to limitations of the

current driver methods.

One subject which PLG does not address (but GKS 3-D and

PHIGS do) is archival processing. This is a method of

storing and retrieving images external to the PLG

environment, such as on disk or other forms of auxiliary

storage. Methods for adapting PLG for archival processing

need to be explored.

The addition of a set of two-dimensional graphics

functions and the extension of PLG to other structured

languages, such as Ada and Pascal, would enhance the

software's usefulness. The two-dimensional functions may be

created by simply storing a zero value for the Z coordinate

and then internally using the three-dimensional functions.

The computing overhead costs for this are actually quite

inexpensive and very desirable.






48


Finally, a topic of great interest is the

identification of PLG functions which may be replaced by

future hardware. The cost of graphics hardware is beginning

a slow decline[BR089][PON89], and within the next six to ten

years the high-end graphics co-processor boards will be

priced such that the average user can afford them. It would

be quite advantageous to design a graphics co-processor

board which implemented PLG's fast algorithms for processing

3-D data.















APPENDIX A


PLG PROPOSED FUNCTIONS

All functions are presented in the following form:

FUNCTION NAME AND CALLING SEQUENCE

ARGUMENTS

DESCRIPTION OF ARGUMENTS

DESCRIPTION OF FUNCTION OPERATION AND RESULTS



CONTROL FUNCTIONS:



graphics_close()

no arguments

This function closes the PLG graphics system and

terminates all graphics processing.



graphics_open(device)

int device;

device is a manifest constant which indicates

the graphics output device (i.e. CGA, EGA, etc.) and implies

the device's capabilities (resolution, number of colors,

etc.).

This function initializes the PLG graphics system

and makes all PLG functions available.










graphics update workstation()

no arguments

This function generates the refresh cycle (i.e.

structure traversal). All structures associated with active

or visible views are redisplayed.



OUTPUT PRIMITIVE FUNCTIONS:





graphics_polygon3(number, zyz_points, width)

int number;

float xyz_points[];

int width;

number is the number of vertices or points in

the polygon.

xyzpoints is an array of floating point values

which are the X, Y, Z coordinate values for each vertex of

the polygon.

width is the number of array elements between

subsequent X values.

This function specifies a three-dimensional

polygon primitive element and inserts it into the current

open structure following the current position pointer.










graphics_polyline3(number, xyz_points, width)

int number;

float xyz_points[];

int width;

number is the number of vertices in the

polyline.

xyz_points is an array of floating point values

which are the X, Y, Z coordinates values for each vertex of

the polyline.

width is the number of array elements between

subsequent X values.

This function creates a three-dimensional polyline

element and inserts it into the current open structure

following the current position pointer.









graphicstext (xyzpoint, length, string)

float xyz_point[3];

int length;

char string;

xyz_point is an array of three floating point

values which are the X, Y, Z coordinate of the text

position.

length is the length of the text string in

characters.

string is a variable length character string

which is the text to be displayed.

This function inserts a text element into the

current open structure following the current position

pointer.


ATTRIBUTE SETTING FUNCTIONS:



graphicsset fillcolor(color)

int color;

color is the index number of the fill color.

This function sets an environment variable which

determines the interior color of any polygons created. This

color is utilized only if the polygon interior style is

solid.









graphicsset_interiorstyle(style)

int style;

style is the interior style (l=hollow, 2=solid,

3=pattern, 4=hatched).

This function sets an environment variable which

determines the interior style of any polygons created.



graphics_set_line_color(color)

int color;

color is the index number of the line color.

This function sets an environment variable which

determines the color of any polylines created.




graphicssettextcolor(color)

int color;

color is the index color to be used for text.

This function sets an environment variable which

determines the color of any text created.



graphics_set_textfont (font)

int font;

font is the index number of the font.

This function sets an environment variable which

determines the font used for any text created.









graphics_set_text_precision(precision)

int precision;

precision is the number indicating the way which

text is treated.

This function sets an environment variable which

determines the precision which text is created with

(l=string, 2=character, 3=stroke).





WORKSTATION SETTING FUNCTIONS:



graphicsset_color_representation(number, colors)

int number;

float colors[];

number is the number of colors to load.

colors is an array of three times number

floating point values which are the color table values to be

loaded (0.0 <= value <= 1.0). The assumed order is red,

green, blue.

This function loads red, green, blue values for a

given color table into the graphics environment.









graphics_set_view_character(view_number, visibility,

projection, VRP)

int viewnumber;

int visibility;

int projection;

float VRP[3];

viewnumber is the number of the view you wish

to set characteristics for.

visibility is a flag which determines whether

the view is posted (visible) or not (0=not visible,

l=visible).

projection is the viewing projection for the

view (0=parallel, 1=perspective).

VRP is an array of three floating point values

which contains the X, Y, Z coordinate of the view reference

point (i.e. the user's point of view).

This function sets the basic characteristics of a

view, including whether or not the view is visible. This

must be called initially for all views because by default

all views created are not active (i.e. not visible).









STRUCTURE OPERATION FUNCTIONS:



graphics_close_structure()

no arguments

This function sets the current open structure to a

closed state (i.e. no more elements may be added at this

time).



graphicsdelete_all_structures()

no arguments

This function deletes all existing structures from

the system.



graphicsdelete_element()

no arguments

This function deletes the element indicated by the

current element pointer from the current open structure.



graphicsdelete_structure (structure_number)

int structure_number;

structurenumber is the number of the structure

to be deleted.

This function is used to delete the contents of

the specified structure. This is effectively the same as

emptying the structure.









graphicssetelement pointer(element)

int element;

element is the element position number.

This function sets the current element pointer to

a particular element in the current open structure. If the

value of element is less than one, the pointer is set to the

first element. If the value of element is greater than the

number of elements in the structure, the pointer is set to

the last element.



graphicsexecute_structure(structure_number)

int structure_number;

structurenumber is the number of the structure

to invoke.

This function inserts an execute structure element

into the current open structure. Traversal of the structure

in which the execute structure element exists causes

invocation of the target structure as soon as the execute

structure element is encountered.



graphicsopen_structure(structure_number)

int structure_number;

structurenumber is the number of the structure

to create or open.

This function opens a structure. If the specified

structure doesn't exist, then it is created. The element

pointer is positioned at the last element of the structure.











INPUT FUNCTIONS:



graphics_initialize_inputdevice(device)

int device;

device is the index number of the input device

(0=mouse, 1=joystick, >1=generalized input device via serial

port).

This function identifies the input device and

loads its driver, if necessary.



graphics_getxyz(device, xyz_point, button)

int device;

float xyz_point[3];

int button;

device is the index number of the input device.

xyz_point is an array of three floating point

values in which the X, Y, Z coordinate of the input point is

returned.

button is the number of the button indicated on

the input device.

This function searches for graphic input from

device# device and returns the point in xyz_point and the

value of the button pushed in button.









DISPLAY FUNCTIONS:



graphicsassocroot with view(view_number,

structure_nmber)

int view_number;

int structure_number;

viewnumber is the index number of the view to

be attached to.

structurenumber the index number of the

structure to be associated with view viewnumber.

This function associates structure

structure_number with view view_number, so that structure

structure number is included in the traversal list for that

view. If the structure doesn't exist an error flag is

raised. If the structure is already associated, then no new

action is taken. If the view doesn't exist, then it is

automatically created.









graphics disassoc_rootfrom view(vie _number,

structure_number)

int viewnumber;

int structure_number;

viewnumber is the index number of the view to

be affected.

structure number is the structure number to be

removed.

This function allows structure structure number to

be removed from the traversal list of view view number. The

structure is removed from the structure during the next

structure traversal.



TRANSFORMATION FUNCTIONS:


graphics_set_model_xform3(matrix, type)

float matrix[4][4];

int type;

matrix is a 4 by 4 array of floating point

values which defines the modeling transformation to be

applied locally.

type is the composition type (0=replace,

l=preconcatenate, 2=postconcatenate).

This function inserts a three-dimensional

modeling transformation element into the current open

structure following the current position pointer. During

traversal, this element modifies the current local

transformation as specified by the composition type.












graphics_set_view_ apping(viewnumber, window,

viewport)

int viewnumber;

float window[6];

float viewport[6];

viewnumber is the index number of the view.

window is an array of six floating point values

which define the window limits in world coordinates (XMIN,

XMAX, YMIN, YMAX, ZMIN, ZMAX).

viewport is an array of six floating point

values which define the viewport limits in normalized device

(0.0 <= value <= 1.0) coordinates (XMIN, XMAX, YMIN, YMAX,

ZMIN, ZMAX).



graphics_set viewxform3(matrix, type)

float matrix[4][4];

int type;

matrix is a 4 by 4 array of floating point

values which define the modeling transformation to be

applied globally.

type is the composition type (0=replace,

l=preconcatenate, 2=postconcatenate).

This function sets up a global transformation

which is applied to all structures of the specified view at

traversal time.










UTILITY AND MISCELLANEOUS FUNCTIONS:



graphicsconcatenatematrix(matrix&, matrixB, matrixC)

float matrixA[4][4];

float matrixB[4][4];

float matrixC[4][4];

matrixA, matrixB, matrixC are 4 by 4 arrays of

floating point values which contain three-dimensional

transformations.

This function multiplies matrixA times matrixB and

returns the result in matrixC.


graphics_rotate X(angle, matrix)

float angle;

float matrix[4][4];

angle is the rotation angle in radians.

matrix is a 4 by 4 array of floating point

values which represents a three-dimensional transformation

matrix.

This function calculates a rotation transformation

around the X-axis using a given angle of rotation. The

transformation is returned in matrix.









graphics_rotate_Y(angle, matrix)

float angle;

float matrix[4][4];

angle is the rotation angle in radians.

matrix is a 4 by 4 array of floating point

values which represents a three-dimensional transformation

matrix.

This function calculates a rotation transformation

around the Y-axis using a given angle of rotation. The

transformation is returned in matrix.




graphicsrotateZ(angle, matrix)

float angle;

float matrix[4][4];

angle is the rotation angle in radians.

matrix is a 4 by 4 array of floating point

values which represents a three-dimensional transformation

matrix.

This function calculates a rotation transformation

around the Z-axis using a given angle of rotation. The

transformation is returned in matrix.









graphics_scale3 (scale, matrix)

float scale[3];

float matrix[4][4];

scale is an array of three floating point values

which represent the scale factors in the X, Y, Z directions.

matrix is a 4 by 4 array of floating point

values representing a transformation matrix.

This function calculates a three-dimensional

scaling transformation using a given three-dimensional

vector containing X, Y, and Z scale factors. The

transformation is returned in matrix.



graphicstranslate3(vector, matrix)

float vector[3];

float matrix[4][4];

vector is an array of three floating point

values containing X, Y, and Z translation components.

matrix is a 4 by 4 array of floating point

values containing a transformation matrix.

This function calculates a three-dimensional

translation transformation using a given three-dimensional

translation vector containing X, Y, and Z translation

components. The transformation is returned in matrix.









graphics_xforapoint3(point, matrix, result)

float point[3];

float matrix[4][4];

float result[3];

point is an array of three floating point values

which represent X, Y, and Z coordinates of a point.

matrix is a 4 by 4 array of floating point

values which represents a transformation.

result is an array of three floating point

values which represents the X, Y, and Z coordinate of a

point.

This function transforms a three-dimensional point

using a specified three-dimensional transformation matrix.

The result of multiplying the given point by the

transformation matrix is returned in result.



Other functions include inquiry and error handling

functions as needed.















APPENDIX B


SAMPLE PROGRAMS

Program 1

#include "phigs.c"
/* Program 1
This program draws a three-dimensional solid cube on the
screen and rotates it in real time applying back face
removal to insure that the proper faces are drawn */


int count;
/* Data points for cube
float PTS[24] = { -0.5,
-0.5,
-0.5,
-0.5,


faces
0.5,
-0.5,
0.5,
-0.5,


*/
0.5,
0.5,
-0.5,
-0.5,


float rotation;
/* Point indices for cube faces */
int FACES[6][4] = { {1, 2, 4, 3},
{6, 5, 7, 8},
{5, 6, 2, 1},


0.5,
0.5,
0.5,
0.5,


0.5,
-0.5,
0.5,
-0.5,


0.5,
0.5,
-0.5,
-0.5 } ;


{2, 6, 8, 4},
{5, 1, 3, 7},
{3, 4, 8, 7} };


float vrp[3] = { 0.0, 0.0, 5.0}; /* view reference point */
float window[6] = {-2.0, 2.0, -2.0, 2.0, -2.0, 2.0};
float viewport[6] = { 0.1, 0.9, 0.0, 1.0, 0.0, 1.0 };

void drawfaces(rotation)
float rotation;
{
/* This function constructs the cube faces and draws
them */
int h, i, j, k, 1, m;
float a_face[12];
float c;
float MATA[4][4], MATB[4][4], MATC[4][4];
float test[3];

/* Calculate transformation matrices */
graphics_rotate_y(rotation, MATA);
graphics_rotate_x(-1.17*3.1415926, MATB);
graphics_concatenate_matrix(MATA, MATB, MATC);








/* Construct a cube face */
for (h=0; h<=5; h++)
{
j=0;
for (k=0; k<=3; k++)
{
i = (FACES[h][k] 1) 3;
for (1=0; 1<=2; 1++)
{
a_face[j] = PTS[i+l];
j++;
}
graphics_set_fillcolor(h+l); /* set fill color */
for (1=0; 1<=11; 1+=3)
{
test[0] = aface[l]; test[l] = a_face[l+l];
test[2] = a_face[l+2];
graphics_apply_pt tomatrix(test, MATC,test);
a_face[l] = test[0]; a_face[l+l] = test[l];
a_face[l+2] = test[2];
}
/* apply backface removal */
c = a face[0] (a_face[4] aface[7] ) +
a_face[3] (a_face[7] a_face[l] ) +
a_face[6] (a_face[l] a_face[4] )

if (c <= 0.0)
graphics_polygon3(4, a_face, 3);

}




main()
{
int count;
graphics_open(_ERESCOLOR);
graphicssetview_character(1, 1, 0, vrp);
graphics_set_viewmapping(1, window, viewport);
graphics_open_structure(1);
graphicsclose_structure();






68


/* Create and draw cube 63 times */
for (count=l; count <=63; count++)
{
graphicsdeletestructure(1);
graphics_openstructure(1);
graphics_setinterior style(1); /* solid */
rotation = (3.14*2.0/30.0) (float) count;
drawfaces( rotation);
graphics_close_structure();

graphicsassocrootwithview(1, 1);
graphics_update_workstation();
}
while ( !kbhit() ); /* Pause */
graphics_close();










Program 2

#include "phigs.c"

/* Program 2
This program creates and rotates a simple 3-D wire-frame
cube in real time by changing only the viewers reference
point */

main ()
{
float rp[3], pts[12];
float matrix[4][4];
int i;
float angle;

graphicsopen(_ERESCOLOR);
graphics_openstructure(l); /* Create polygons for cube */

pts[0] = -0.5; pts[l] = -0.5; pts[3] = -0.5;
pts[4] = 0.5; pts[6] = 0.5; pts[7] = 0.5;
pts[9] = 0.5; pts[10] = -0.5;
for (i=2; i<12; i+=3)
pts[i] = 0.5;

graphics_polygon3(4, pts, 3);

for (i=2; i<12; i+=3)
pts[i] = -0.5;

graphics_polygon3(4, pts, 3);

pts[0] = -0.5; pts[l] = 0.5; pts[2] = 0.5;
pts[9] = 0.5; pts[10]= 0.5; pts[ll]= 0.5;

graphics_polygon3(4, pts, 3);

for (i=l; i<12; i+=3)
pts[i] = -0.5;

graphics_polygon3(4, pts, 3);

graphics_close_structure();

graphicsassocrootwithview(1, 1);

rp[0] = 2.0; rp[l] = 0.0; rp[2] = 0.3;
graphicsset_view_character(1, 1, 0, rp);

graphicsupdate_workstation();

angle = 6.28 / 60.0;






70


graphics_rotate_z(angle, matrix);
for (i=O; i<60; i++) /* Rotate cube 60 times */
{
float tempx, tempy;
graphics_set_view_character(l, 1, 0, rp);
graphics_update_workstation();
graphics_apply_pt to_matrix(rp, matrix, rp);
}
while ( Ikbhit() ) ; /* Pause */

graphics_close();

}








Program 3

#include "phigs.c"

/* Program 3
This program reads in data from a disk file and produces
an object (in this case a wire-frame teapot) from it. */

main ()
{
float pts[21], win[6], rp[3];
FILE fp;
int dummy, i, j;

fp = fopen("teapot.dat", "r");
graphicsopen(_VRES16COLOR);

graphicsopenstructure(l);

for (i=0; i<448; i++)
{
fscanf(fp, "%d", &dummy);
for (j=0; j<21; j += 3)
{
fscanf(fp, "%f %f %f", &pts[j], &pts[j+l], &pts[j+2] );
}
graphics_polyline3(7, pts, 3);
}

graphicsclosestructure();

graphicsassoc rootwithview(1,1);

win[0] = -4.0; win[l] = 4.0; win[2] = -1.0; win[3] = 4.0;
win[4] = -4.0; win[5] = 4.0;

graphicsset_viewmapping(1, win, graphics.viewport);

rp[0] = 0.0; rp[l] = 5.0; rp[2] = 0.0;
graphicsset_view_character(1, 1, 0, rp);

graphicsupdate_workstation();

while ( Ikbhit() )
graphicsclose();

fclose(fp);








Program 4

#include "phigs.c"
#include

/* Program 4
This program creates a 3-D surface. This program was
generated to produce performance results listed in
the conclusion. */

float VRP[3] = {40.0, 10.0, 10.0};
float window[6] = {-15.0, 15.0, -15.0, 15.0, -15.0,15.0};
union REGS inreg, outregl, outreg2;

float fnz( float x, float y)
{
float w, e, c;
w = x*x + y*y;
e = exp( (double) (-0.04 w) );
c = cos( (double) ( 0.15 w) );
return( 14.0 e c);
}
main()
{
float far table[3*1211;
float x, y;
int i, j;
inreg.h.ah = Ox2c;

graphics_open(_VRES16COLOR);
graphics_open_structure(1);

for (y=12.0, i=0; y>=-12.0; y-=1.0, i++)
{
for (x=-12.0, j=0; x<=12.0; x+=0.2, j+=3)
{
table[j] = x; table[j+l] = y;
table[j+2] = fnz(x,y);
}
graphics_polyline3(121, table, 3);


graphicsclose_structure();

graphicssetviewcharacter(l, 1, 0, VRP);
graphicssetviewmapping(1, window, graphics.viewport);
graphicsassoc_rootwith_view(l, 1);
intdos(&inreg, &outregl);
graphicsupdate_workstation();
intdos(&inreg, &outreg2);


while ( Ikbhit() ) ;






73



graphics_close();

printf("%d:%d:%d.%d \n", outregl.h.ch, outregl.h.cl,
outregl.h.dh, outregl.h.dl);
printf("%d:%d:%d.%d \n", outreg2.h.ch, outreg2.h.cl,
outreg2.h.dh, outreg2.h.dl);

}















REFERENCES


[BON86] Bono, Peter R., "Graphics Standards", IEEE Computer
Graphics & Applications, Volume 6, Number 8, August
1986.

[BR085] Brown, Maxine, Understanding PHIGS, Megatek
Corporation, San Diego, California, 1985.

[BR089] Brownstein, Mark and Copeland, Ron, "Intel N-10 to
Speed Up PC Graphics", Infoworld, Volume 11, Issue
8, February 1989.

[CAH86] Cahn, Deborah, "An Introduction to PHIGS", SIGGRAPH
Course Notes, SIGGRAPH, Dallas, Texas, 1986.

[CGA89] "Run PHIGS and CGI on an AT", IEEE Computer
Graphics & Applications, Volume 9, Number 4, July
1989.

[DOU89] Douglas, Sally J. and Capen, Tracey, "Exposing
VGA", Infoworld, Volume 11, Issue 22, May 1989.

[DRE89] Dressler, Fritz, "3-D Boards Turn PCs Into
Workstations", PC Week, Volume 16, Number 18, May
1989, pg. 90.

[FOL82] Foley, James D. and Van Dam, A., Fundamentals of
Interactive Computer Graphics, Addison-Wesley
Publishing Company, Reading, Massachusetts, 1982.

[GUP87] Gupta, Satish and McCabe, Daniel H., "Personal
Computer Displays", IEEE Computer Graphics &
Applications, Volume 7, Number 10, October 1987,
pp. 17-23.

[HEA86] Hearn, Donald and Baker, M. Pauline, Computer
Graphics, Prentice-Hall, Englewood Cliffs, New
Jersey, 1986.

[IBM85] Programmer's Reference for graPHIGS, International
Business Machines, New York, New York, 1985.

[JAM87] James, J. Michael, "The Third Generation of PC
Graphics Controllers", IEEE Computer Graphics &
Applications, Volume 7, Number 10, October 1987.









[KOC89] Kocher, Bryan, "President's Letter", Communications
of the ACM, Volume 32, Number 7, July 1989,
pg. 779.

[MAC87] Machover, Carl, "Personal Computers", IEEE Computer
Graphics & Applications, Volume 7, Number 10,
October 1987.

[NEF89] Neff, Andrew, "Intel's 64-Bit Microprocessor May Be
the Life of the RISC Party", PC Week, Volume 6,
Number 16, April 1989.

[NEW79] Newman, William and Sproull, Robert, Principles of
Interactive Computer Graphics, McGraw-Hill Book
Company, New York, New York, 1979.

[PON89] Ponting, Bob, "Beyond VGA", Infoworld, Volume 11,
Issue 26, June 1989.

[PUK86] Puk, Richard F., and McConnell, John I., "GKS-3D: A
Three-Dimensional Extension to the Graphical Kernel
System", IEEE Computer Graphics & Applications,
Volume 6, Number 8, August 1986.

[PUK88] Puk, Richard F., "Are Graphics Standards Winds
Blowing in PC Land?", Computer Graphics, Volume 22,
Number 2, April 1988.

[RAS89] Raskin, Robin, "24-Bit Video Boards Capture 'True'
Color", PC Week, Volume 6, Number 8, February 1989.

[SCH86] Schoenhut, Jurgen, "Are PHIGS and GKS Necessarily
Incompatible?", IEEE Computer Graphics &
Applications, Volume 6, Number 7, July 1986.


[SHU86] Shuey, David, Bailey, David, and Morrissey, Thomas
P., "PHIGS: A Standard, Dynamic, Interactive
Graphics Interface", IEEE Computer Graphics &
Applications, Volume 6, Number 8, August 1986,
pp. 50-57.

[STA89] Staudhammer, John, Personal Interview, SIGGRAPH
89, Boston, Massachusetts, August 1989.

[VAN87] Van Dam, Andy, PHIGS+ Functional Description, ANSI
X3.144-198x, Newton, Massachusetts, July 1987.

[WES89] Westerman, Bill, Direct Quote, PC Week, Volume 16,
Number 18, May 1989, pg. 90.















BIOGRAPHICAL SKETCH

Mitchell Krell is the son of George Krell and the late

Selma Pevsner Krell. He was born on February 23, 1955, in

Hattiesburg, Mississippi, where he lived for most of his

childhood. He attended Hattiesburg High School, graduating

in May, 1973. He graduated cum laude from the University of

Southern Mississippi receiving a Bachelor of Science degree

in photojournalism and a Master of Science degree in

computer science and statistics. After completing his

doctoral degree, he will be returning to teach computer

science at the University of Southern Mississippi. Mitchell

is married to the former Lynn Carter and has two children,

Christopher Gabriel Krell and Matthew Reid Krell.









I certify that I have read this study and that in my
opinion it conforms to acceptable standards of scholarly
presentation and is fully adequate, in scope and quality, as
a dissertation for the degree of Doctor of Philosophy.



hn Staudhammer, Chair
Professor of Computer and
Information Sciences


I certify that I have read this study and that in my
opinion it conforms to acceptable standards of scholarly
presentation and is fully adequate, in scope and quality, as
a dissertation for the degree of Doctor of Philosophy.


L-rt^-L A.
Ralph G. Selfridge
Professor of Computer and
Information Sciences


I certify that I have read this study and that in my
opinion it conforms to acceptable standards of scholarly
presentation and is fully adequate, in scope and quality, as
a dissertation for the degree of Doctor of Philosophy.



Joseph Duff
Graduate Research Professor
of Mechanical Engineering


I certify that I have read this study and that in my
opinion it conforms to acceptable standards of scholarly
presentation and is fully adequate, in scope and quality, as
a dissertation for the degree of Doctor of Philosophy.



Rick L. Smith
Associate Professor of
Mathematics








This dissertation was submitted to the Graduate Faculty
of the College of Engineering and to the Graduate School and
was accepted as partial fulfillment of the requirements for
the degree of Doctor of Philosophy.


December, 1989


Dean, College of Engineering



Dean, Graduate School

























































UNIVERSITY OF FLORIDA


3 1262 08553 6661