The emergence of standards in computer graphics was a long time coming. Some standards activities date back to the early 1960s but it was not until the IFIP Seillac Workshop in 1976 in France and the activities of the Graphic Standards Planning Committee in the USA during the 1970s that any real progress was made.
A fundamental decision made at the Seillac Workshop was to concentrate initially on the application programmer interface or API initially. The API is the set of function calls required by an application programmer to make use of a substantial graphics system. The main alternative was to attempt to do the initial standardization at a lower level, say the device order code level or the device driver level. The other major decision was to split graphics into two separate parts. The first was concerned with constructing the graphical scene to be output while the second was concerned with viewing that scene. In 3 dimensions, viewing will require projection of the 3D scene on to a plane producing a picture to be rendered on a display for the operator to look at and interact with. That sentence contains a number of key words that we will use throughout the book to identify specific parts of the graphics system. Early systems had tended to blur the two activities of modelling (that is constructing the model of an object from which the scene is generated) and viewing often using the same function for two quite distinct purposes. This in turn led to poor understanding of the system by the application programmer.
After Seillac, the decision was made to concentrate initially on a standard that was primarily concerned with displaying a 20 picture. The standardization activities were carried on within the International Organization for Standardization (ISO). This resulted in 1985 in the Graphical Kernel System (GKS) being published [6] [10] [16] as the first computer graphics standard. Work then continued in a number of separate directions. A standard for the transmission and storage of 2D pictures, the Computer Graphics Metafile (CGM) was actively worked on and resulted in this standard being established in 1987 [2] [7] [11] [17]. This was initially a 2D standard like GKS but work since has extended the functionality and is adding 3D capabilities in a number of Amendments. Work also proceeded in the production of a device level standard called the Computer Graphics Interface (CGI) [2] [21].
GKS was followed by two further API standards, GKS-3D [19] and PHIGS [20]. While GKS-3D was a straightforward extension of GKS to 3 dimensions, PHIGS was the first standard aimed at providing facilities for modelling, that is constructing models of objects from which some part could be extracted as a scene of the object and this scene viewed by projection and display.
The three API standards and the related standards have been developed with compatibility in mind. Consequently, the viewing system used by PHIGS is primarily the one developed for GKS-3D with some minor changes. The major area of innovation in PHIGS is the model building. Neither GKS or GKS-3D satisfied the requirement of application programs where modification of the graphical data is required in an efficient manner, where the objects to be displayed consist of geometrically related parts, and where rapid dynamic articulation of graphical entities is required. This is the area addressed by PHIGS and from which the name derives, the Programmer's Hierarchical Interactive Graphics System.
Discussion of the process by which international standards are developed would be out of place in this book; for a discussion the reader is referred to the book by Arnold and Duce [3]. The reader should note that prior to 1988 Computer Graphics Standards were published by ISO. Since that date, a joint technical committee of ISO and the International Electrotechnical Commission (IEC), known as ISO/IEC JTC1, has been responsible for standards in the information technology area. This explains why the earlier standards are referred to as ISO standards and the later ones (such as PHIGS) are ISO/IEC standards.
The API standards share a set of common concepts. The realization of the concepts varies from standard to standard but the overall concepts remain the same. The aim is to base all three API standards on sound principles. By having common concepts, application program and application programmer portability is also improved. This section will attempt to give an overview to those concepts that are relevant to PHIGS.
All three standards are defined in a language independent way as a set of functions with a description of their meaning that is not dependent on any one programming language [13] [14] [15] [26]. Separate standards exist that bind the API standard to a particular language. A language binding defines how the language independent functions and data types described in the PHIGS standard are to be realized as subroutines or procedures and the actual data types of a particular programming language. PHIGS has language bindings for Fortran and Ada. A C language binding standard is expected to be completed during 1991. A Pascal language binding is being worked upon but no dates currently exist for its completion.
In consequence, we have chosen to use the Fortran binding as the basis for the examples in this book. Clearly, the language binding has to comply with the constraints of the language standard itself. In the case of Fortran, this means that all identifiers, such as subroutine names, are limited to six characters. A brief summary of the Fortran language binding is given in Chapter 15. As the ISO Fortran language binding document [14] is 213 pages long, this is inevitably a summary rather than the complete definition. It should be sufficient to allow real PHIGS programs to be written.
The aim is to give an introduction to PHIGS. Inevitably, the user of PHIGS will need to read the manual that comes with his implementation as in many places the richness of the implementation may effect what he decides to do.
The API standards make a clean separation of those parts of the standard that are dependent on the characteristics of the device where output is to appear and input originates and those parts which are the same for all devices.
The key concept providing device independence is the workstation. This is not a physical device such as a SUN workstation but all the functions and data that are device dependent. This hypothetical workstation has at most one display surface, a number of input devices and quite a bit of storage space for tables and some intelligence. How it is realized in a specific implementation can be quite varied. For example, an implementation of PHIGS running on a mainframe with an intelligent device such as a physical workstation attached might have the device independent code in the mainframe and the device dependent part (the PHIGS workstation) executing in the physical workstation. Alternatively, PHIGS might run on the mainframe with quite straightforward unintelligent devices attached. In this case. the device driver and device dependent parts would also run on the mainframe. At the other extreme, PHIGS could reside completely in the physical workstation in which case both the device independent and device dependent parts of the system will reside there.
In this book, the word workstation will be used to define the device dependent part of PHIGS. An application may use a number of PHIGS workstations at the same time. This could be to provide different views of the scene created or could be to allow the interactive display to be captured on a plotter. The physical realization of this could be two displays and a plotter attached to a mainframe or separate windows on a SUN workstation with an ethernet connection to a laserprinter. Conceptually, PHIGS would treat them the same.
In PHIGS, a scene is created which needs to be seen at the workstation. The device independent scene has to be viewed by the workstation. Each workstation specifies its views independent of any other workstation. Viewing creates a picture of the scene at the workstation. For example, the projection of a 3D scene onto a 2D plane would be performed by the workstation. The 2D picture created must be displayed on the display surface of the workstation. This requires the picture, which is still a set of commands in memory, to be rendered. This can be as simple as ensuring the bits representing a line are turned on in a bit-mapped display or can be quite complex including hidden line or hidden surface removal.
The API standards each define some basic building blocks from which a scene is created and these are called output primitives. The simplest output primitive is a polyline which draws a sequence of connected line segments. There is a strong commonality between the output primitives of the three API standards. The major difference is the added complexity of the primitives in 3D compared with 2D. Also, the primitive set has grown as the standards develop. PHIGS has the richest set of primitives of the three standards.
The application needs to define models of objects in coordinate systems appropriate to the application. The scene created when part of the model is to be displayed needs to be defined in a neutral coordinate system that is neither specific to the application nor the device.
The philosophy in all the API standards is to create a scene in some device independent coordinate system (called world coordinates in PHIGS). The scene is created from some part of the model defined by the application in coordinates appropriate to the application (called modelling coordinates in PHIGS). The world coordinate scene is viewed creating a picture in a device independent coordinate system (called Normalized Projection Coordinates in PHIGS). Some part of this picture is displayed on the workstation's display surface using the coordinate system appropriate to the display device (called Device Coordinates).
The appearance of output primitives on a display surface is controlled by aspects associated with the primitive. The three API standards use the same aspects where appropriate. Aspects can be global, that is they are defined in the device independent scene and workstations should present them the same on every display surface. For example, if text is to be output, its height is set globally. All workstations are required to generate text of the appropriate size on the display.
Aspects can be workstation dependent. For example, line style may be very dependent on the display's capabilities. The length of the individual dashes in a dashed line or the frequency of dots in a dotted line may be dependent on the device hardware available. For workstation dependent aspects, all three API standards allow the aspect to be bound to the primitive in the device independent scene or to be left partially defined at that stage. In the latter case, the actual binding of the aspects to the primitives is left to the workstation to decide under the control of the application. A set of flags decide what method is used for each aspect. This facility allows, for example, an application to specify that every fifth contour should be differentiated and the workstation can choose whether to do this by changing line thickness, the line style of the contour or its colour or a combination of these.
A major difference in the API standards is how they store graphical information for later reuse. GKS and GKS-3D provide a low-level segment storage to which only minor changes can be made once it is defined. PHIGS, on the other hand, retains graphical information close to the application level in modelling coordinates in entities called structures. These can be linked together into structure networks. The scene to be viewed is derived from one or more structure networks that the application wishes to view on one or more workstations.
By providing facilities for editing structures interactively with immediate feedback of the changes on the display, high quality interaction between the operator and the application can take place.
All three API standards have a common model of input. As for output, input is defined in a device independent way. Input is categorized into a set of classes corresponding to the different values provided. The values are associated with the scene. For example, they may be positions in world coordinates, real numbers, integers from a limited range, and so on. The workstation receives input from the physical devices and converts these into virtual input values so that it looks as though the workstation has a number of logical input devices attached. There may be no correlation between the workstation's logical input devices and the physical devices provided. For example, a workstation may have a single mouse attached to it which might be used to input values, positions, select from menus and, in general, act like a set of logical input devices. Alternatively, a keyboard and two thumb wheels may be required to input a single position. How physical devices are mapped onto logical input devices is the responsibility of the workstation implementation. The class of the logical input device defines the value it delivers to the application.
All three API standards support a range of input styles. The simplest is a dialogue where the operator and application take it in turns to take action. An asynchronous style is provided where the application samples logical input values as it requires them. The values are being updated by the operator but the application only takes the new values it requires. The most complex is an event driven mode of input where the operator places input values on a queue for the application to deal with. This range of application interaction styles allows applications to be written in PHIGS with styles that are appropriate for the application and the devices that it will interact with.
Both GKS-3D and PHIGS, being 3D systems, are capable of producing 3D scenes to be displayed on 2D devices. This requires a projection of the 3D scene onto a 2D plane creating a picture to be displayed [4]. The way viewing is defined is the same in the two standards and is sufficiently general to provide most of the standard projections in common use.
PHIGS is the ISO/IEC standard number 9592 [20]. It was completed in 1989 and many implementations of the standard were available on the market during 1990 particularly on the range of physical workstations provided by manufacturers such as SUN, DEC, IBM, Hewlett Packard and Stardent.
This book aims to give an introduction to PHIGS concentrating on the major features, the structure store and viewing. However, it contains sufficient description to allow a reader to construct his own PHIGS programs. A drawback of PHIGS when used on the more sophisticated systems is that it provides little control of sophisticated rendering features such as multiple light sources illuminating an object producing shadows and reflections (see Section 4.7.3). As these can often be provided by the hardware of the more modern devices, some method needs to be provided to accommodate such requirements. To provide this, an extension to PHIGS is being developed called PH1GS PLUS. It is hoped that this extension will be completed in 1991 or early in 1992 [22].
Unfortunately, many PHIGS implementations have attempted to add PHIGS PLUS features while the extension is being developed. In consequence, several of the PHIGS implementations contain PHIGS PLUS-like extensions which do not correspond to the standard being developed. It will be necessary for such implementations to be updated to the standard when it is complete.
In this book, no attempt has been made to describe the PHIGS PLUS extensions. At the time of writing (early 1991), it is not possible as the final form of PHIGS PLUS is not known. A more sensible approach is to follow the standard and produce a companion volume when the PHIGS PLUS functionality is frozen.
1. S.S. Abi-Ezzi and A.J. Bunshaft (1986), "An Implementor's View of PHIGS", IEEE Computer Graphics and Applications 6(2).
2. D.B. Arnold and P.R. Bono (1988), CGM and CGI - Metafile and Interface Standards for Computer Graphics, Springer-Verlag.
3. D.B. Arnold and D.A. Duce (1990), ISO Standards for Computer Graphics - The First Generation, Butterworths.
4. I. Carlbom and J. Paciorek (December 1978), "Planar Geometric Projections and Viewing Transformations", Computing Surveys 10(4), pp.465-502.
5. W.R. Clifford, J.I. McConnell, and J.S. Saltz (1988), "The Development of PEX, a 3D Graphics Extension to X11", in Proceedings of EUROGRAPHICS '88. ed. D.A Duce and P. Jancene. North-Holland.
6. G. Enderle, K. Kansy, and G. Pfaff (1987), Computer Graphics Programming, GKS - The Graphics Standard, Springer-Verlag. (Second Edition)
7. L.R. Henderson and AM. Mumford (1990), The Computer Graphics Metafile, Butterworths.
8. I. Herman and J. Reviczky (1987), "A Means to Improve the GKS 3D/PHIGS Output Pipeline Implementation", in Proceedings of EUROGRAPHICS ' 87, ed. G. Marechal, North-Holland.
9. I. Herman and J. Reviczky (1988), "Some Remarks on the Modelling Clip Problem", Computer Graphics Forum 7(4), pp.265-271.
10. F. R. A. Hopgood, D. A Duce, J. R. Gallop, and D. C. Sutcliffe (1986), Introduction to the Graphical Kernel System (GKS), Academic Press. (Second Edition)
11. F. R. A. Hopgood, RJ. Hubbold, and D.A Duce (Eds) (1986), Advances in Computer Graphics II, Springer-Verlag.
12. T.L.J. Howard (1989), "An Annotated PHIGS Bibliography", Computer Graphics Forum 8(3), pp.262-265.
13. ISO, "Information processing systems - Computer graphics - Graphical Kernel System for Three Dimensions (GKS-3D) language bindings - Part I: Fortran ISO 8806-1 (to be published)", Part 2: Pascal ISO 8806-2 (to be published), Part 3: Ada ISO 8806-3 (to be published), Part 4: C ISO 8806-4 (to be published), ISO Central Secretariat.
14. ISO, "Information processing systems - Computer graphics - Programmer's Hierarchical Interactive Graphics System (PHIGS) language bindings - Part 1: Fortran ISO 9593-1 (1990)", Part 2: Pascal ISO 9593-2 (to be published), Part 3: Ada ISO 9593-3 (1990), Part 4: C ISO 9593-4 (to be published), ISO Central Secretariat.
15. ISO, "Information processing systems - Computer graphics - Graphical Kernel System (GKS) language bindings - Part I: Fortran ISO 8651-1 (1988)", Part 2: Pascal ISO 8651-2 (1988), Part 3: Ada ISO 8651-3 (1988), Part 4: C ISO 8651-4 (to be published), ISO Central Secretariat.
16. ISO (August 1985), "Information processing systems - Computer graphics - Graphical Kernel System (GKS) functional description", ISO 7942, ISO Central Secretariat.
17. ISO (1987), "Information processing systems - Computer graphics - Metafile for the storage and transfer of picture description information", ISO 8632, ISO Central Secretariat.
18. ISO (1988), "Procedures for the Registration of Graphical Items", ISO/TR 9973, ISO Central Secretariat, Geneva, Switzerland.
19. ISO (1988), "Information processing systems - Computer graphics - Graphical Kernel System (GKS) for three dimensions (GKS-3D) functional description", ISOIIEC 8805.
20. ISO (1989), "Information processing systems - Computer graphics - Programmer's Hierarchical Interactive Graphics System functional description", ISOIIEC 9592: 1.
21. ISO (1990), "Information processing systems - Computer graphics - Interface techniques for dialogues with graphical devices,", DIS 9636, ISO Central Secretariat.
22. ISO/IEC (1990), "Information processing systems - Computer graphics - Programmer's Hierarchical Graphics System (PHIGS) - Part 4: Plus Lumiere und Surfaces (PHIGS PLUS)", ISO/IEC JTCI/SC 24 N454.
23. M.A. Penna and R.R. Patterson (1986), Projective Geometry and its applications to computer graphics, Prentice-Hall.
24. K. Singleton (1987), "An Implementation of the GKS-3DIPHIGS Viewing Pipeline", in GKS Theory and Practice, ed. I. Herman and P.R. Bono, Springer- Verlag.
25. M.W. Skall (1986), "NBS's Role in Computer Graphics Standards", IEEE Computer Graphics and Applications 6(8), pp.50-57.
26. M. R. Sparks and J. R. Gallop (1987), "Computer graphics language bindings: programmer interface standards", Computer-Aided Design 19(8), pp.418-424.
27. K.M. Wyrwas and W.T. Hewitt (1989), "A Survey of GKS and PHIGS Implementations", Computer Graphics Forum 8(1), pp.49-59.
