TUGS - - A Tool For Teaching Computer Graphics John Clevenger Rick Chaddock Roger Bendig Department of Computer Science California State University, Sacramento Sacramento, CA 95819

Abstract One of the best methods of teaching students about the principles underlying computer graphics systems is to have them develop an implementation of a "graphics pipeline" supporting modeling, viewing, and rendering operations. When completed, such an implementation represents a sophisticated package capable of producing complex images. However, these complex images typically cannot be generated until at or very near the completion of the project. We describe a tool called TUGS which has been developed to support the incremental development of a complex graphics system and which provides the ability to produce complex images early in the development process. TUGS is a complete graphics modeling and rendering system built from a highiy-modularized set of primitive operations. Students can replace individual pieces of the TUGS system with their own implementations, while retaining use of the remaining TUGS routines. This allows incremental development of a complete system, while at the same time providing the abifity to generate complete images. It also provides a vehicle for selective consideration of the many issues involved in modeling and rendering systems; those areas deemed most important can be assigned to students for implementation, while TUGS can be relied on to provide compatible implementations for the others. TUGS also includes a substantial collection of support routines to help reduce the "overhead" incurred in implementation efforts. These include command input parsing, 3D transformations, vector and matrix algebra operations, metafile storage, and support for device-independent low-level graphics, as well as many others. 1. Introduction

1.1. Teaching the Graphics Pipeline One of the stxongest motivations for students in Computer Graphics is the abifity to see the results of their work. High motivation is frequently easier to maintain when students are able to produce sophisticated images early in their studies. Instructors are thus faced with the challenge of providing a learnPermission to cop), without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the tille of the publicatipn and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. © 1991 ACM 0-89791-435-X/91/0007/015851.50

158/Computer Graphics • Volume25 • Number 3 • July 1991

ing environment which supports the ability to produce complex renderings at an early stage while at the same time providing a basis for solid comprehension of the underlying principles. One approach to supporting file ability of students to create advanced images is to use a commercial graphics package which allows complex pictures to be generated with relatively few commands. However, the internals of such packages are frequently proprietary and thus not available for study. Even if package internals are available for examination, such a "case study" approach does not necessarily provide the basis for "solid comprehension of the underlying principles". An alternative approach is incremental development, or "learn by doing". The instructor covers the complete graphics pipeline (Figure 1) [FOLE90], including the basics of model

building, model traversal, viewing, and rendering techniques (visible-surface determination, scan conversion, shading, shadows, texture, etc.). For each of the elements in the pipeline, students are given an assignment to write a program implementing the concept. With some care these assignments can be designed to be "upward compatible' '. The end result is that the student has developed a relatively complete and sophisticated graphics package which is capable of producing the types of images which motivated the student's interest in the first place. More importantly, the student is likely to have gained a good understanding of the principles involved. The problem with the incremental development approach is that the early stages of the development effort do not produce the "visual results" which enhance sttddent motivation. In addition, the sequential nature of the development makes it difficult for students to see problems which may result later when interfacing to subsequent stages of the graphics pipeline. Further, there are frequently a large number of implementation details (for example, command-line parsing) which hinder the development effort disproportionately in relation to their importance in understanding the basic grapttics concepts.

1.2. Integrated Development It is desirable to have a tool for teaching Computer Graphics which integrates the incremental development of a complete graptfics system with the ability to generate complex images at any point in the development effort. Such a tool would utilize those pieces of code which the student has already developed at any stage and would automatically supply the missing pieces, producing a complete system capable of advanced image generation.

Model Building

Model Traversal

~_~

Modeling ~_~ Transformations

Viewing Operations

Renderng I Image

Figure 1. The Graphics Pipeline

There are a number of clear advantages to using such an

integrated development tool. Students would be able to produce advanced images in a very short time, since the tool could initially provide nearly all of the elements of the graphics pipeline, requiring the student to provide only the initial inputs - - the description of the world to be modeled and the viewing and rendering specifications. Subsequently, students could develop their own code for early stages of the pipeline, relying on the tool to provide the later stages. The early images generated entirely by the tool would then function as a "benchmark" against which to compare later results. In addition, student code could be developed incrementally in small pieces, simplifying the debugging process. Further, students would receive early warning of potential problems with interfacing their code to subsequent stages of the pipeline. Finally, loss of time due to implementation and debugging of essential but non-graphical code could be reduced by using tool-supplied versions of those features. The remainder of this paper describes a tool somewhat immodestly called TUGS (The Universal Graphics System) which has been developed at California State University, Sacramento (CSUS). The term Universal is not intended to imply that TUGS contains every conceivable form of graphics operation, but rather that TUGS was designed with the intent of providing as wide a range of support for teactfi_ng Computer Graptfics as possible. TUGS has been used as the primary support tool for CS 155 - Intermediate Computer Graphics at CSUS for the past year and a half. Section 2 provides an overview of TUGS and discusses how the TUGS command processing structure supports both incremental development and early generation of complex images. Section 3 presents additional detail on the internal structure of TUGS and describes how this s~'ucture lends itself to subdividing the stages of the graphics pipeline for student implementation. Section 4 presents a brief discussion of certain implementation characteristics of TUGS and discusses some of our plans for future work. Section 5 presents a summary and points out some related work. 2. TUGS Overview

2.1. Command File Processing TUGS consists of a large collection of (relatively small) library modules, each implementing some piece of the overall graphics command processing and graphics pipeline steps. The user builds a graphics system by creating a program containing a (possibly empty) set of user-supplied graphics routines, linked with a collection of TUGS routines. The user then provides as input to this graphics system a collection of graphic coeunatMs describing a desired image; the system, processes the commands and produces the specified output.

Initially, students provide a graphic command file which is processed entirely by TUGS. That is, the first graphics system incarnation nora:ally contains a TUGS-supplied "front-end" (main program) called tsh, the TUGS Shell. tsh reads graphic commands and in turn calls TUGS routines to accomplish all processing (Figure 2). The graphic commands define both the world to be modeled and the viewing and rendering characteristics to be applied in producing a specific image. The set of graphic commands is similar to, albeit more extensive than, that described in [BLIN87]. Basic command categories include the ability to define polygons, polyhedra, and assemblies; to specify material and scene-illumination characteristics; to define views by controlling various attributes of a synthetic camera; and to select arbitrary objects for rendering using a variety of rendering modes (wireframe, hidden-surface removal, facet or smooth shading, shadows, etc.). Using the TUGS Shell allows the student to concentrate initially on the nature of graphic commands, without the necessity of dealing with the implementation of those commands. Once students understand the command set, they can immediately produce complex images. This provides the motivational feedback discussed earlier, and at the same time gives the student a basic familiarity with the general concepts of modeling, viewing specifications, and rendering characteristics without the burden of dealing with implementation issues. 2.2. User C o m m a n d Parsing The second incarnation of a TUGS-based system is typically one wherein the student replaces the T-Shell front-end with his/her own main program. The main program is conceptually a loop containing two steps: a call to a Get_Command procedure, followed by a CASE statement with one case element for each possible command. The body of each case element invokes a procedure to process the corresponding command. Initially these are all calls to TUGS routines (see Figure 3). TUGS contains a separate routine to process each of the defined commands. The TUGS front-end can be completely replaced to derive this second incarnation, requiring the student to perform all command parsing operations (i.e., to completely implement the Get Cotmnand routine). Alternatively, the instructor can allow the student to take advantage of a separate T U G S I n p u t module which causes a command file to appear as a tokenized input stream and which contains routines to return the next elen:ent(s) of that input stream. For example, a program can invoke a TUGS Input routine which rettwns the next command token (verb), or which returns one or more command parameters. The TUGS_Input module thus provides lexical analysis of the input, reducing the coding effort required of the student while not significantly reducing the understanding of the graphics-related issues.

Computer Graphics • Volume 25 ° Number 3 ° July 1991/159

TUGS Graphics

Module

Module

TUGS Shell (Main Program)

TUGS Output Module

Module

Image

Figure 2. TUGS Command Processing

2.3. Command Implementation The main program structure shown in Figure 3 is simple to implement, and once completed it forms the basis for incremental user-implementation of any command in the command set: the call to tile TUGS routine implementing the command is simply replaced by a call to the user's implementation of that same command. This yields the system shown in Figure 4, wherein some of the graphic commands are processed by user-written code while others continue to be processed by TUGS, Figure 4 also depicts the use of the T U G S _ ~ p u t module for command parsing, and points out the fact that user modules may make internal calls to TUGS modules (this is discussed further below). Procedure MAIN ;



Begin Repeat Get_Command ; Case Command of command_A : TUGS.Process Conmlmld_A ; command_B : TUGS.Process_Command B ;

End Case ; Until Command = 'QU1T' ; End MAIN. Figure 3. User Main Program Structure This scheme of graphic command implementation provides the instructor with considerable flexibility in the approach used in teaching the material. It is easy to selectively concentrate on any subset of the graphic commands, requiring the student to implement certain commands early while delaying (or eliminating altogether) implementations of others by allowing the use of TUGS implementations. The scheme also provides a strong organizational and developmental tool for tile student; commands are easily implemented one-at-a-time, and cross-check debugging help cart be obtained by comparing the results of the

160/Computer Graphics * Volume 25 • Number 3 • July 1991

student's implementation of any command with the result produced by file same command when processed by TUGS. 3. T U G S Graphics Pipeline

3.1. Modeling Structures In order that User modules and TUGS modules both be able to access and manipulate the Model Database (world description), they must share an understanding of the structure of that database. TUGS provides for this by defining an extensive and flexible set of data types which govern the data structures in the model. These data types are "exported' ' from TUGS and are available for use by students. For example, TUGS maintains a smaeture, called the

Object Symbol Table (OST), of all the objects in the world. Each OST object is of a TYPE which is defined by TUGS declarations. The graphic command Define_Polygon creates new objects of type polygon, made up of elements of type vertex, in the OST. Thus if a user program contains an implementation of D e f i n e P o l y g o n , the user code must " i m p o r t " the relevant type declarations and structure-access values (pointers), and use them in adding new objects to the OST. Considerable effort was put into defining the TUGS structure declarations in as general and flexible a manner as possible. TUGS maintains separate lists for all major structures, and each object on each list contains a number of attribute fields which allow manipulation of the characteristics of the object. TUGS also contains utility routines for allocation of new objects, and new objects thus allocated receive default values in all attribute fields. This allows the user to avoid dealing with fields which may be necessary at some point later in the graplfics pipeline but which are not relevant in considering the routines at hand. Tile overall effect of these characteristics of the TUGS modeling structures is that students are only required to deal with those portions of the database which are necessary for the command implementation under consideration. Our experience has been that students have no more difficulty in dealing with the

TUGS Graphics

Module

]

TUGS Output Module

TUGS Input

hnage Module

User Main Program

User Graphics

m l

]

] S

Module I

Module

Figure 4. User Command Processing TUGS data structures than with development of their own independent ones; if anytlfing, they benefit from having the structures well-defined in advance. 3.2. Command Decomposition Many of the graphics commands supported by TUGS are conceptually "indivisible"; that is, their implementations are not clearly separable into distinct sub-steps within the graphics pipeline as depicted in Figure 1. This includes commands which add objects to the world (e.g., Define_Polygon, Define Material, etc.); and those wtfich alter characteristics of existing objects (e.g., Alter_Assembly, Alter_Light, etc.). Likewise, some commands can be considered indivisible simply because their implementations are essentially trivial. This is true, for example, for commands which control viewing and rendering specifications (e.g., SetBackgroundColor, Set HSR Mode, and Set_Camera Position), because these conr~aland~essentially just compute and store values in TUGS global variables which are subsequently used by other cormnands to control image generation. In a few cases, a single TUGS command implies a large number of distinguishable sub-steps in the graptfics pipeline. Ctfief among these is the Render command, which requests generation of an image of a specified object, rendered according to the previously defined (perhaps default) settings of various view-

ing and rendering values such as camera position and orientation, hidden-surface mode (on or @ , shading mode (Phong, Gouraud, faceted, or none), and so forth. Thus, processing the Render command implies a series of graphical operations: application of modeling and viewing transformations, 3D clipping, perspective transformation, hidden-surface removal, shading, etc. In order to support the integrated incremental development environment discussed previously, TUGS implements commands such as Render via a series of discrete steps, each corresponding to one conceptual element of the graphics pipeline. Each of these steps is invoked via a distinct TUGS routine, coupled to other routines via a clearly defined interface. It is therefore possible for the user to "replace" some of these TUGS routines with his/her own cede while invoking TUGS routines to perform the other steps, in a manner similar to the replacement of entire command-processing modules as discussed above. As an example, consider the algorithm for the TUGS Render_Object operation (Figure 5), invoked from within the Render command procedure to generate an image of a specific object. (The term object in this sense is very general; it refers to any element of the model world, including an assembly which is itself composed of arbitrary subobjects). Each of the steps shown in Figure 5 can be accomplished by invoking a TUGS module by the same name. For example, Compose PVPL is invoked to walk the Model Database tree in

Computer Graphics • Volume 25 ° Number 3 • July 1991/161

recursive fashion, building a global list made up of all the Potentially Visible Polygons (or other primitives) defining the object (including its subobjects) being rendered. Apply_Viewing_Transform applies the current (or default) Viewing Transformation, as defined by the most recent Set Camera Position command, to the items on the PVPL. ClilTTo_Viev~ Volume applies the Sutherland-Hodgrnan polygon clipping algorffhm [ROGE85] to the PVPL; etc. Each of these TUGS procedures conforms to the standard TUGS modeling structure interfaces, and can be selectively used and then later replaced by user-provided code which implements the corresponding function. Students can thus implement the top-level structure shown in Figure 5, and can then concentrate on one (set of) issues, for example recursive Model Tree walking, clipping, backface culling, etc., while invoking TUGS modules to handle the other steps. The student can thus incrementally develop his/her own graphics system implementation, relying on TUGS to provide all the "missing" pieces. The result at any stage is a graphics system capable of generating images of considerable complexity.

Some of the routines invoked by Render_Object are themselves composed of many distinct sub-operations, and most of these are further subdivided in TUGS using the same concept as described above. For example, TUGS uses the Watkins Spanning Scanline algorithm [ROGE85] as the primary hidden-surface removal technique (there are embedded hooks for a number of other HSR methods; these are not shown in the simplified algorithm given in Figure 5). The Watkins algorithm requires a number of steps, including building Edge-lists, updating Active Polygon lists, determining polygon shading (in the case of FACET shading mode), etc. Many of these steps are broken down into discrete routines which cart be either used in their TUGS form or replaced by user-written routines. For example, the TUGS Draw_Watkins routine calls a function named Calculate_Polygon_Shade which computes a shade for a facet-shaded polygon. A student can develop a complete HSR implementation, calling this TUGS function to perform shading calculations in lieu of implementing shading on their own. Later, the student can easily insert their shading algorithm, including use of various smooth shading tectmiques. 3.3, Additional Facilities

Procedure Render_Object ; Begin TUGS_Output.Begin_Rendering ; Compose_PVPL ; Apply_Viewing_Transform ; Case Current_HSR_Mode of Wire_Frame: ClipTo_View_Volume ; Apply_Perspective_Transform ; Apply_Homogeneous_Transform ; Calculate_Plane_Coe fficients ; I F Backface_Culling_On THEN B ackface_Cull ; Project_Onto_ViewPlane ; Draw_Wireframe ; Hidden_Surface: Case Current_Shading_Mode of None: Clip To View_Volume ; Facet: Transform_Lights To Scene; ClipTo_View_Volume ; Calcul ate_Surface_Normals ; Gouraud I Phong: Transform_LightsTo_Scene ; C alculate_Surface_Normals ; Calculate_Vertex_Normals ; ClipTo_View_Volume ; End Case ; Apply_Perspective_Transform ; Apply_Homogeneous_Transform ; Calculate_Plane_Coe fficients ; I F Backface_Culling_On THEN Backface_Cull ; Project_Onto_ViewPlane ; Draw_Walkins ; End Case ; TUGS_Output.End_Rendering ; End Render_Object.

Figure 5. Algorithm for Render_Object.

162/Computer Graphics • Volume 25 ° Number 3 • July 1991

TUGS contains an extensive library of common graphical operations. These include 3D transformations, vector operations, mathematical functions, and geometric operations such as finding the coefficients of a plane defined by specified points. These routines are used internally by TUGS procedures, but can optionally be made available to students by the instructor. Another powerf-al feature of TUGS is the availability of a collection of generic linked-list manipulation routines. TUGS contains packages which support common list operations such as allocate, insert, delete, append, return length of, and return node contents for both singly- and doubly-linked lists made up of nodes of arbitrary structure. TUGS uses these routines to manipulate the predefined Model Database structures. Students can use them likewise, and cart also instantiate them to operate on newly-defined data structures within their own routines. This capability can thus significantly reduce the overhead involved in implementing complex fist structures. The T U G S _ O u t p u t module is another important feature of the TUGS system. TUGS_Output acts as an interface to various output devices, and provides entry points for controlling the output device as shown in Figure 5. In addition, TUGS_Output provides support for four output modes: device, metafile, debug, and ASCII_Plot. In device mode, TUGS_Output provides a set of entry points for low-level graphics operations such as Move, Draw, and Set Plxel; these operations are mapped to corresponding low-level operations on the underlying device. In the rnetafile mode, all TUGS rendering output is directed to a rnetafile [FOLE90, ARNO88]; a separate module can then be used to regenerate and display the rendered image on a physical device. In debug mode, all graphical output primitives are "interpreted" and displayed on the screen in textual form. For example, a graptfics operation which results in moving the cursor to a specific location produces a text line of the form "MoveTo(x,y)" on the screen rather than actually moving the cursor. Finally, ASCII Plot mode produces a simple representation of a rendered imag-e on the screen in "print-plot' '. This provides a method of generating preliminary output rapidly, and also provides primitive support for non-graphics devices (e.g. an ASCII terminal). TUGS_Output also contains a set of color quantization routines. These routines use an octree decomposition method [BURG89] to map the pixel color values generated by the current rendering into the number of distinct colors available on the out-

put device. In device mode, the resulting color map is used to control the color lookup table of the graphics device. For metafile mode, the color quantization information is stored in a separate file, which is subsequently used by the TUGS routines which read metafiles and reproduce a rendering. As with most TUGS routines, the Color Quantization module can be replaced by a user implementation, giving the user freedom to investigate various color mapping schemes while providing a robust implementation for default usage.

tation of Unix) with very few changes. In fact, the present version of TUGS contains a small number of "conditional compilation" statements which control all of the differences between versions; generating new versions is simply a matter of recompiling on each target system. We expect to be able to extend TUGS to run under DEC Ultrix and AT&T System V Unix with little trouble, and a port to the MS/DOS environment in the PC world is also under investigation. The latter effort has several significant ramifications, in particular the tradeoffs of wide-spread access versus generally lower device resolution and speed.

4. Implementation

cross-language development would be a useful feature. That is,

4.1. Language TUGS is implemented in Ada and consists of approximately 17,000 lines of source code in about one hundred separateIy-compiled modules. The decision to use Ada was based on a number of factors, including portability across a wide range of environments and provision for highly modular progranmaing constructs with strong data abstraction and interface specification mechanisms. The Ada package construct [ADA83] provides exactly the tightly-controlled interface methodology needed to support easy replacement of TUGS modules with user-defined implementations of the same modules. Further, Ada lends itself well to the design of a system such as TUGS by providing capabilities such as generics (wlfich are used to implement many of the TUGS library routines), exceptiot~9 which can be easily propagated to other modules to help inform the user of problems, and default assigmnents to data objects, which are used to specify attribute values which are " h i d d e n " from the TUGS user during the early stages of the development of a graphics system. 4.2. Graphics Devices All access to physical graphics devices is isolated in one location in TUGS, the Low-level Graphics component of tile TUGS_Output module. In order to extend TUGS to support a new graphics device, it is only necessary to provide a new Ada "implementation" ((package body) for this component. The implementation is responsible for providing each of the entry points (Ada procedure bodies) defined in the package specification, and mapping these to equivalent operations on the new device. This mapping can be accomplished in several ways: by direct access to the hardware; by interfacing to an existing driver for the device, or by interfacing with another graphics package which contains routines which in tuna access file device. Since most graphics devices already have one or more such drivers and/or packages, this makes it relatively easy to extend TUGS to support new devices. In addition, this structure lends itself to use irt environments where the goal is to investigate low-level device control, since the Low-level Graptfics component is replaceable by user-provided routines just like any other TUGS routine. We currently have several working implementations of Low-level Graphics routines for TUGS, including interfaces to the Template Graphics Package [MEGA] for driving Tektronix 41xx series terminals and the SunView [SUN82] windowing system for Sun workstations. An X-window interface is plarmed, as well as support for several other devices.

4.3. User Environments In order for a tool such as TUGS to be of general use, it is desirable that it run in a variety of user environments. We have ported TUGS from the DEC VAX/VMS operating system, where it was first developed, to SunOS (Sun MicroSystem's implemen-

In addition to multiple operating system environments, it is desirable to be able to allow users to provide replacements for TUGS modules in the language of their choice, even though TUGS itself is written in Ada. In principle, the design of TUGS supports this cleanly, since all user interfaces (and therefore all user code accesses to TUGS) take place at well-defined module boundaries. In practice, however, this is a difficult issue. It is clear that the problems are reduced if the host system itself supports combining multiple-language modules at the Linker level. However, linker support will not solve the problem entirely. An important unresolved issue is data structure access; it nmst be possible to provide a direct one-to-one translation of each of the TUGS data structure implementations in Ada into tile desired target language, and to insure equivalence of access to those data structures in compiler-generated code. We are currently investigating the area of nmltiple-language support in TUGS.

5. S u m m a r y We have implemented a graphics system called TUGS - The Universal Graphics System - - to support education in Computer Graphics. TUGS is based on the notion that students are likely to learn more about the principles underlying inq~lementation of advanced graphics systems by actually developing such a system, but are hampered by the fact that it takes a significant anlotmt of effort to produce code to generate even moderately complex graphic images. TUGS provides a complete graphics system which accepts input commands describing a model world and a set of viewing and rendering specifications, and generates as output an image of the world. The unique feature of TUGS centers on the replacea bility of its code modules. Each TUGS module implements some portion of the graphics pipeline, comprised of modeling, viewing, and rendering components. Each of these components has been broken down into small discrete elements; each element is implemented via a separate TUGS module. Users can freely replace any TUGS module with their own implementation of the corresponding function, while continuing to use TUGS for the remaining operations. This allows a user to develop his/her own implementation incrementally, while at the same time being able to generate output as if they had a complete implementation. TUGS also provides an extensive support library containing a variety of routines which the user can access in lieu of providing their own implementation. Examples include support for input command parsing, 3D transformations, vector operations, rectagraphics output, and low-level graphics device control. TUGS has already proven to be a powerful and useful tool for use in Computer Graphics 'education. Students are able to progress much farther in the implementation of a graphics system than previously, and appear at the same time to gain a more thorough understanding of the fundamental principles of Computer Graphics.

Computer Graphics • Volume 25 • Number 3 ' July 1991/163

The TUGS system has much in common with a number other development efforts (e.g., [WHIT82, CROW82]), although these efforts did not emphasize the teaching-tool aspect which is perhaps the most important underlying principle in TUGS. The FRAMES system [POTM87] utilizes the notion of subdividing the graphics pipeline in a manner similar to TUGS, but is designed with an emphasis on the extensibility of the system rather than a concentration on instructional support and portability. More recently, [CARL90] describes an educational-suFport system which is similar to TUGS. References

[ADA83]

Reference Manual for the Ada Programming Language, ANSI/MIL-STD-1815A-1983, United States Department of Defense, 1983. [ARNO88] Arnold, D.B., and P.R. Bono, CGM and CGI: Metafile and Interface Standards for Computer Graphics, SpringerVerlag, 1988. [BLIN87] Blinn, LF. "Jim Blinn's Comer", IEEE Computer Graphics and Applications, 7(10), October 1987. [BURG89] Burger, P., and Duncan Gillies, Interactive Computer

Graphics: Functional, Procedural, and Device-level Methods, Addison-Wesley, 1989. [CARLg0] Carlson, W.E. "An Environment for a Graduate Curriculum in Computer Graphics", SIGCSE Bulletin, 22(2), June 1990. [CROW82] Crow, F.C. " A More Flexible Image Generation Environment' ', Computer Graphics, 16(3), July 1982. [FOLE90] Foley, J., A. van Darn, S. Feiner, and J. Hughes. Computer Graphics: Principles and Practice, 2nd Ed., AddisonWesley, 1990. [MEGA] Template Reference Manual, Megatek Corp. [POTM87] Potmesil, M., and Hoffert, E.M. "FRAMES: Software Tools for Modeling, Rendering and Animation of 3D Scenes", Computer Graphics, 21(4), July 1987. [ROGE85] Rogers, D. Procedural Elements For Computer Graphics, McGraw-Hill, 1985. [SUN82]

SunView 1 Programmer's Guide, Sun MicroSystems, 1982. [WHrr82] Whitted, T., and Weimer, D.M. " A Software Testbed for the Development of 3D Raster Graphics Systems", ACM Transactions on Graphics, 1(1), January 1982.

164/Computer Graphics • Volume 25 • Number 3 * July 1991