Computer Graphics Programming

The Data Processing Vocabulary of the International Organization for Standardization (ISO) [ISO84] defines Computer Graphics as follows:

“Methods and techniques for converting data to and from a graphic display via computer.”

Part I of this book gives an overview of principles and concepts of computer graphics on the basis of the Graphical Kernel System. Although the concepts described are closely related to GKS, most of them are in fact common to a wide spectrum of computer graphics systems. This is true of interfaces, including the computer graphics user interface, and of the principles and goals of computer graphics standards as well as of the basic concepts of GKS. A discussion of concepts and methods has to be based on a common understanding, which in turn requires a suitable terminology. The terminology used in this book is taken from the ISO Data Processing Vocabulary [ISO 84]. The set of terms defined in the GKS standard document [GKS 85] overlaps with the ISO definitions for computer graphics to a great extent. The terms from both documents that are most important in our context are defined and explained in the following chapters. Most of the definitions are taken literally from the GKS document.

Computer graphics is “used” in many different ways, for different purposes and by people with different skills and educational backgrounds. A person struggling with space invaders in a video game arcade is a computer graphics user, as is a programmer calling plotting routines in order to generate a diagram on a plotter. Broadly speaking, however, three important classes of users can be identified: system implementors, application programmers, and graphical workstation operators. Figure 3.1 shows the relationships between the different types of computer graphics users.

The GKS standard document defines in a language-independent way a set of functions for performing graphical tasks. However, in an implementation of the system these functions have to be realized as subroutines (or procedures) in a given programming language. Such a language-specific realization, in which the language-independent system nucleus is embedded, is called a language layer. Language layers for FORTRAN and Pascal are available (see examples in Part III, Part IV and Chapter V.4). The functions provided by the language layer can be used by the application programmer, together with operating system functions. In addition, special application-dependent layers can be built on top of the GKS language layer. An example using an application layer for data representation graphics is shown in Figure C7 (page 620), while Figure C8 (page 621) shows a mapping application and Figure C3 (page 619) a CAD application.

The information contained in this chapter was first presented in a paper of the DIN Computer Graphics group [ENDE 81], based on work done by the ANSI Computer Graphics group ANSC X3H3. It was later included in the GKS draft standard in order to offer explanations and justifications for design decisions taken during the development of GKS. GKS was designed to provide a set of functions for computer graphics programming which can be used in the majority of applications that produce computer generated pictures.

The main concepts of a graphics system are closely related to the tasks which such a system is intended to perform.

Pictures which are produced solely by output functions, without interaction with an operator, are referred to as passive output. The application programmer checks the result of his graphics program by looking at the output picture and changing the program if he wishes to have a different result. The opposite of passive output is interactive computer graphics (see Chapter 10). According to the type of output device used, output can be classified as line graphics or raster graphics.

The application programmer wants to define his graphical elements in a coordinate system that is related to his application. However, the devices that are available for presenting a visual image of these elements normally need to use a device-specific coordinate system. In order to meet these requirements while maintaining device independence, three coordinate systems have been defined in GKS. Firstly (the following information is related to 2D GKS), there is the world coordinate (WC) system which the application programmer uses to specify the elements of the picture. The world coordinate system is the standard user coordinate system.

In GKS, the graphical workstations are an abstraction of physical devices.

If a graphics system can not only generate pictures on the display surface of a graphical output device, but can also receive input that an operator has entered at a graphical workstation, a new dimension is added to the computer graphics world. It is this new dimension of interaction that has resulted in the ever faster growing use of computer graphics devices and systems. The actions of pointing, selecting, sketching, placing or erasing in a direct manner and the instantaneous system response to these actions are truly adapted to the way humans deal with their environment. Interactive computer graphics makes such interactions possible. It is the most powerful instrument in adapting the humancomputer interface to human needs.

A picture is composed of output primitives. These can be grouped together in parts which can be addressed and manipulated as a whole. These picture parts are called segments.

GKS offers functions for storing pictures on an external file and for retrieving them from there as an integral part of the system. Files which are used to store pictures are called graphics metafiles.

At any time during the execution of a program using GKS, GKS will be in a precisely defined state. This state is defined by the operating state and by the values of the state variables contained in a number of state lists, present in a GKS system. When GKS functions are called this can change the values in the state lists: these changes are part of the definition of the functions.

The description of every GKS function contains a list of the anticipated errors. Every GKS implementation must realize an error handling facility which is able to discover these errors and record at least one of the errors which have occurred in a message file. There the identification of the error and the identification of the GKS function detecting the error will be filed. The application program can replace the standard error handling procedure by its own routine which can react to specific errors. The user error procedure is supplied by GKS with the identification of both the error and the GKS routine which has detected it. It can also inspect the GKS state list by using inquiry functions.

Most computer graphics applications only need two-dimensional (2D) pictures. This is why the GKS effort first concentrated on standardization of a 2D graphics system. Now, GKS is well developed and the GKS working group can devote more effort to a three-dimensional (3D) extension of GKS. In important application areas, 3D graphics are needed to represent 3D geometrical objects. Computer aided design is an important example, but also such areas as chemistry or medicine often require 3D graphics. A major influence has come from presentation graphics (3D bar charts, 3D geographic representations) and from computer animation.

Before a standard can be established, a subject must be ready for it.

Based on the evolution of different graphics packages and a desire to get started, working groups and formal committees have been working in the field of computer graphics standardization since about 1975. Major efforts were undertaken in the United States, in Germany, in the United Kingdom, and at an international level in the International Organization for Standardization (ISO).

At the beginning, the GKS document was developed in the DIN in the following way: The DIN committee, comprising some 20 people, discussed the major design issues in the GKS concept and gave directives to an editorial board.An editorial board, comprising four persons from the DIN committee, discussed the consequences of the global decisions and worked out in detail the changes to the document.The document was compiled and kept up to date by one person.

Whereas Part I of this book presented a general overview of the principles and concepts of the Graphical Kernel System, and Part II described the process of creating this standard, Part III gives a detailed description of the functional capabilities of GKS. Therefore, this part provides the basic reference for the application programmer using GKS. It also serves as a framework for teaching and learning computer graphics on the basis of GKS. For every one of the different areas of the system, a detailed explanation of the concept is given. Every GKS function and every GKS data structure relevant to that area is explained extensively. For all functions, both the language-independent definition from the GKS standard and the FORTRAN programming language interface are given.

GKS, as a general-purpose graphical kernel system, is designed to address most of the existing graphics devices as well as most graphics applications. GKS implementations have to serve a wide range of applications, from static plotting to dynamic motion and real time interaction. In addition, GKS systems have to support a large variety of graphics devices, from simple plotters, microfilms, and storage tubes, to highly sophisticated vector devices and real time raster-scan devices. Furthermore, they have to be installed on various processors which differ in aspects such as their word length (starting from 8 bits/word) and storage handling facilities (restricted memory size, slow external storage media, up to virtual memory management).

This chapter deals with the states of GKS and the data structures describing them. The operating states of GKS form a central concept within GKS and make a strict structure in graphics programming necessary. For example, a workstation can be accessed only after a certain sequence of initializing functions has been invoked; output can be generated only after a workstation has been activated; workstation attributes can be set only after the workstation has been allocated. Therefore, the novice should read Sections 3.2 and 3.3 carefully. There the different operating states are introduced and those functions listed which are allowed in the respective operating states. Section 3.4 describes the content of some state lists. It is aimed primarily at implementors and experienced users of GKS. Section 3.5 introduces the first two GKS functions: OPEN GKS and CLOSE GKS.

GKS provides a set of output functions for computer graphics which may generate output on any device in the whole range of graphics devices, including plotter and interactive devices, vector and raster displays, storage tube and refresh displays, black-and-white and colour displays.

Pictures to be generated by GKS will be derived from data provided by the application program. This data may include results from measurements with arbitrary physical dimensions, such as temperature, weight, time, etc. By digitizing an object, data with metrical dimensions will be generated. Numerical calculations may generate data without units. These user coordinates have to be mapped onto the device coordinates which describe the display surface of a workstation.

The graphical output which is generated by GKS consists of two groups of basis elements: output primitivesoutput primitive attributes

A picture consists of output primitives. After having generated the corresponding graphical output on a display surface, the primitives are no longer accessible.

Computer graphics input is a rather complex area and accordingly the GKS input concept has to consider many application and implementation details. In many cases, the reader of this book will only need to know some aspects. Therefore, we want to provide some information as to how to study this chapter.

For each GKS function, a finite number of error situations is specified, any of which will cause the ERROR HANDLING procedure to be called. Every GKS implementation must support this error checking. The ERROR HANDLING procedure provides an interface between GKS and the application program.

Inquiry functions allow the application program to get information about the current state of GKS. As explained in Chapter 3, the complete state of GKS is stored in a number of state lists and description tables. Every value present in one of the üsts can be retrieved by the application program by using an inquiry function.

Graphics metafiles are a facility for the long-term storage of pictures. GKS provides an interface to graphics metafiles. One metafile format, the GKS Metafile (GKSM), is described in an appendix to the GKS standard. Whereas the GKS workstation-independent segment storage is available for the storage of segments only during a GKS application, i.e. between OPEN GKS and CLOSE GKS, the metafile is retained for an unlimited time.

The real world is three-dimensional. As a consequence, a system drawing images of real world objects on a display surface has to support 3D graphics. When standardization efforts in the field of Computer Graphics began in the years 1974–1977, the primary goal was a standard for 3D graphics. It seemed pointless spending time and effort on 2D graphics when a 3D standard could cover both and a 2D standard could be easily derived from it.

The scope of GKS-3D is deliberately restricted to the functionality which is present in many current 3D systems. It excludes areas where it seems difficult to reach common agreement (e.g., defining primitives for solid objects and curved surfaces), while including all 3D features which are needed in today’s 3D graphics applications.

The extension of GKS to 3D has an effect on the state lists. All entries containing geometrical data have to be changed to accept a third coordinate. New primitives and new attributes give rise to new entries. The GKS state list, the workstation state list, the workstation description table and the segment state list are all affected by these changes. Tables 3.1, 4.1, 4.2 and 7.1 list all changes which must be made to produce the respective lists or tables in GKS-3D. The operating state, the GKS description table, and the error state list remain unchanged.

Workstations are grouped together in workstation types according to characteristics and capabilities. Each workstation type is characterized by a GKS-3D workstation description table which is an extension of the GKS workstation description table. Changes are listed in Table 4.1.

GKS-3D adopts all coordinate systems and transformations present in the 2D transformation pipeline of GKS and extends them to 3D. This set of 3D coordinate systems and transformations would be sufficient if only 3D devices had to be considered. However, in practice, true 3D devices are rare. To do 3D graphics on 2D display surfaces, a projection function with hidden line/hidden surface removal is needed. For this reason, a workstation-dependent viewing function has been introduced into GKS-3D. It is applied immediately before the workstation transformation.

3D output primitives are generally defined as 3D counterparts of the 2D output primitives of GKS. They differ, however, in that positions can be specified in 3D space.

Segments in GKS-3D differ from those in GKS in that they contain exclusively 3D primitives and their attributes. As far as segment generation and manipulation is concerned, the functions of Chapter III.7 apply. For the transformation of segments, two new functions SET SEGMENT TRANSFORMATION 3 and INSERT SEGMENT 3 are provided, which extend the functionality of the respective GKS functions by accepting 3 × 4 transformation matrices rather than 2 × 3 matrices as in the case of 2D. The extended transformation matrix has to be recorded in the segment state list.

The input model and the input classes as described in Chapter III.8 also apply for GKS-3D. The input classes PICK, CHOICE, VALUATOR and TEXT handle non-geometric data and, therefore, are not affected by dimensionality. Only the INITIALISE functions adopt a geometric parameter, echo area, which is extended to a 3D echo volume in the respective INITIALISE 3 functions.

In addition to the errors listed in Section III.9.6, some new errors may occur in GKS-3D. These errors are numbered from 400 onwards. It is anticipated that there will be a need for more error messages in the future. New error messages will be registered by a registration authority, established by the International Organization for Standardization, and this registration will be similar to the registration of new linetypes or generalized drawing primitives.

As a consequence of the 3D extension of GKS, some entries in the GKS state list, the workstation state list, and the workstation description table have had to be added or changed because of the new primitives, attributes, and the third coordinate introduced for all geometrical entries (cf. Chapter 3). The following inquiry functions give access to these entries.

All the GKS functions are also present in GKS-3D and have the same effect in both GKS and GKS-3D. This is easily accomplished for all GKS functions which are not related to geometry, such as OPEN WORKSTATION. All other GKS functions have a counterpart in GKS-3D which has a similar functionality but a different parameter set. The process of embedding consists primarily in mapping the parameter set of a GKS function onto the parameter set of its GKS-3D counterpart. However, this does not necessarily imply that the respective 3D function is really called but it serves to give a precise definition of the effect of the corresponding 2D function in the 3D environment. Furthermore, to ensure that the functionality is not altered, the default settings of the various GKS-3D state lists (cf. Chapter 3) have been chosen appropriately.

s a successor of the Core, a new proposal called Programmer’s Hierarchical Interactive Graphics Standard (PHIGS) [ANSI85] has been developed by the working group X3H31 of the American National Standards Institute (ANSI) and has been accepted as a work item by ISO in 1985. PHIGS not only provides 3D functionality but also puts some emphasis on a multilevel hierarchical data structure. This structure contains graphical output primitives, attributes and transformations which can all be edited interactively. Furthermore, substructures can be copied or referenced. By referencing other structures, a multilevel hierarchical structure can be created which is very useful if a subpicture is to occur several times on the display surface where the definition of this subpicture has been stored only once within the data structure. Attributes are stacked when executing a substructure and are restored afterwards. This all allows a higher degree of interaction compared to GKS.

An important concept within the GKS standard is the concept of input/output primitives being capabilities of logical input/output devices. To a certain extent, abstracting from physical devices to logical devices allows a device-independent access to physical devices. However, the implementor of logical input/output devices has to reverse this process of abstraction and has to map the logical devices onto the capabilities of the available physical devices. This chapter describes major aspects of this mapping process for output primitives and attributes. The subsequent chapter will discuss the mapping process for input primitives.

In order to bring some unification into the great variety of hardware input devices, a small number of well-defined, abstract input devices has been identified. The concept of virtual input devices was enunciated by Wallace [WALL76] as a means whereby interactive graphics applications could be insulated from the peculiarities of the input devices at particular terminals.

GKS has been defined in a device-and processor-independent way. It is therefore possible to implement GKS on nearly all computers, starting with 16 bit microprocessors, and to support most of the common graphics devices. The only device facilities which cannot be utilized are those which are not covered by the GKS functionality, such as three-dimensional primitives and projection hardware. At the time of writing this book, we know of implementations for the following processor types : CDC, CRAY, DEC, GOULD, IBM, SIEMENS, SPERRY, BULL, NIXDORF, PRIME, APOLLO, AT + T, HEWLETT PACKARD, MOTOROLA, SUN MICRO, INTEL, IBM Personal Computers and Compatibles, and others. More detailed information can be obtained from [GKSVER]. Some of the graphics devices supported by these implementations are: HEWLETT PACKARD plotters and displays, CALCOMP, VERSATEC and TEWIDATA plotters, TEKTRONIX displays and plotters, MEGATEK, DEC VT100, and many others. Depending on the level of GKS, the facilities within the supported level, and the intelligence of the connected graphics devices, the memory sizes needed vary from 4 kbytes to 200 kbytes. The size, of course, also depends on the quality of the particular compiler and the facilities of the available linkage editor.

The standard is described in abstract terms, in order that it may be useful for applications written in a wide range of programming languages (host languages).

GKS is based on the concept of abstract workstations. A GKS workstation represents a unit consisting of zero or one display surfaces and zero or more input devices, such as a keyboard, tablet and/or lightpen. The workstation presents these devices to the application program as a configuration of abstract devices, thereby abstracting from the hardware peculiarities. Workstations provide the logical interface through which the application program controls physical devices. Certain special workstations provide facilities for the storage and exchange of graphical information. In Table 4.3 in Chapter III.4.4 on page 133, all GKS functions are listed, together with the workstation categories to which they directly or indirectly apply. Output, attribute, transformation and segment functions, for example, apply to all output, output/input, and metafile output workstations, whereas they do not apply to input and metafile input workstations.

Graphics metafiles have been used for a considerable time for storing and transmitting pictures. GKS includes a metafile interface as part of the standard (cf. Chapter III.11). An appendix of the GKS document gives the definition of the GKS metafile that can be used together with this interface. However, it is not part of the ISO standard. Efforts have been started within ISO to standardize a single graphics metafile.

Following on from the GKS definition process, there then began the certification process for graphics systems in 1981. A special subgroup for this was set up within ISO/TC97/SC5/WG 2 and the EEC decided to sponsor a number of workshops with the aim of developing a certification/validation scheme and guiding the GKS reviewing process in its final stages. It was recognized that a standard is largely worthless unless there is a procedure to test whether or not the implementations conform to it. Two major aims were identified: the more-or-less informal specification of GKS should be improved and eventually a formal specification of the GKS functions should be developed which could accompany the standard and help implementors of GKS systems with more precise definitions. A sub-subgroup concentrated on the issues arising from such a formal specification for graphics standards. Some of their results are contained in [EEC82 d]. In this chapter we focus on the second goal, i.e., to test and ensure that an implementation of GKS adheres to the standard. We refer however, to the results of formal specification research where appropriate.

Human communication needs a common language in order to succeed. Of course, in a new and rapidly developing field like Computer Graphics, different groups will develop their own basis for communication. Many conflicts and misunderstandings in the course of GKS design and review were caused by not having a common language. Different terms were used for the same object, or different objects were given the same name by different people. This was true not only in the international field, where English is used as the main language of communication, but also in various other languages. In order to avoid any difficulties which might arise from designing GKS in two languages at the same time, DIN decided at a very early stage to develop the GKS standard in English, and later translate the finished document into German.