Graphics packages for teaching graphics

Abstract

The design and implementation of graphics packages has been widely studied and discussed. The special needs of the teaching environment change the requirements of a package in some interesting ways because the details usually hidden from the user are of interest to the students. Here the design of such a package is considered. In order to identify the needs of the package, the structures of CORE (which is used throughout as an example of an applications-oriented package) are compared with a list of topics covered in an elementary graphics course. Some of the nonessential flexibility of CORE can be thrown away, and procedures needed to handle hierarchy and manipulation of the structured display file can be added. A package (the Northwestern University Simple Graphics Package) resulting from this analysis is described. Specific suggestions are made for pruning CORE to a manageable size. A natural way of accessing the structured display files and a system of symbols are included. The resulting package is small, manageable and useful. During the summer of 1983 I was given the opportunity to teach the first computer graphics course to be offered at the University of Chicago. The only available software was PLOT-10 [11], in a version designed to interface to FORTRAN on the DEC-20. The only prerequisite for the course was an elementary programming course which taught PASCAL, hence the students could not be expected to program in FORTRAN. Some experimentation with the versions of FORTRAN, PASCAL, and PLOT-10 on the DEC-20 revealed that interfacing the PLOT-10 routines to PASCAL wasn't going to work. A second, more important, reason for rejecting this option was the lack of segmentation capability in PLOT-10. I was planning to use Principles of Interactive Computer Graphics by Foley and Van Dam [3] and I wanted the students to be able to program in the spirit of the ACM CORE [4] inspired Simple Graphics Package (SGP) used in the text. My solution was to implement this SGP in PASCAL on the DEC-20, with drivers for two of the terminal types available on campus. During the quarter I taught the course I realized that this was not an adequate solution. There were some things I just couldn't demonstrate for the students and some things that I couldn't put into the programming assignments. For example, a fair amount of time was spent discussing package implementation: clipping algorithms, coordinate transformations, the segment data (visibility, detectability), etc. It was impossible, in the UC SGP, to look at this information as an image was constructed and modified. It was equally impossible for the students to manipulate these constructs directly. I would have had similar problems with a full implementation of CORE and with any other package with which I am familiar. Basically, the packages designed for graphics applications hide the details of the implementation and present a high level view to the user. This is great when implementing an interactive graphics program but it is not so great when trying to teach how the packages work. This should not be taken as a blanket condemnation of the use of packages for computer graphics classes, nor as a suggestion that students should always be reduced to programming at the display processor level. There are good reasons for using packages, or at least package-like systems, in an elementary graphics course. Packages provide the user-friendly environment needed to start the students in computer graphics, and to allow the students to become familiar with graphics software as it exists in the real world. The students will learn the style and format of CORE, GKS [6, 12, 13, 14], PLOT-10, or whatever package is chosen. Last, but perhaps most important to a busy instructor (and is there any other kind?), using a package means writing a minimum of new software. Learning from the experience of writing and using the UC SGP, I modified the package to include some extra capabilities. At this time the package was also moved to a VAX 11/780 at Northwestern University. The design described in this paper includes slightly more than either of these packages. (Throughout the discussion the first package is called UC SGP and the second NU SGP.) The design and implementation of a graphics teaching system depends on the available tools. If there is already a sophisticated package, a little bit of extra software may suffice. I'm going to consider the situation in which a new package will be written expressly for use in teaching. Similar considerations are valid when extending an extant package. There are certain objectives to keep in mind. The package should be small so that it runs efficiently and so that it can be implemented with a reasonable effort. The features which will make it a good learning tool should be emphasized and those which further flexibility but not insight can be de-emphasized. The system should be designed to work with dumb terminals, if those are the ones likely to be available in sufficient quantity for student use. (If there are enough smart terminals the package can do a little more and may be easier to produce.) When designing a small system like this one, it is a good idea to keep the available hardware in mind, retaining sufficient flexibility to include other hardware later. (In the real world the flexibility of the package depends somewhat on the shortness of the time available for the implementation.) I'd like to start with the ACM CORE, a well documented and well known system, and sculpt it to the needs of teaching carving away some excess and adding some new capabilities.