This is a presentation of a standardized approach to the design of graphics systems.
In attempting to solve a detailed problem, we became aware that more fundamental issues were involved. When we turned our attention from the detailed problem to the fundamental one, we were able to find a solution, and the detailed problem went away. We feel it is important to present not only the solution, but the surrounding argument that led to it.
One of the sources of difficulty was the concept of the current position, and its behaviour under transformation. The problem is illustrated by this sequence:
MOVETO (0,0) set beam position to origin of coordinate system α DRAWTO (1,2) draw absolute vector TRANSLATE (3,3) translate into coordinate system β DRAWTO (2,1) draw absolute vector
Possible results are either the broken line (current position not transformed) or the dotted one (current position transformed). This is an artificial example, but the problem is a real one: in an alternate example, the application programmer may wish to connect two points each in a separately transformed instance.
We may view this as either a fault in the graphics package, or an example of bad practice. We may adopt the attitude either that the fault in the graphics package should be corrected, or that the programmer should be advised against such practices. The following discussion pursues the first of these attitudes, but leads to the conclusion that a solution lies, not so much in correcting any fault, as in distinguishing between two different kinds of function, which can be provided by two different but closely coupled systems.
The problem is that transformations may be used for two purposes, viewing and modelling. Viewing transformations, such as windowing or perspective, are generally different from the modelling transformations used to combine the various parts of the picture, even though they both employ the same basic matrix operations. The example given above involves the use of a modelling transformation in the middle of a viewing operation; it indicates the need to keep the two types of transformation separate.
The solution appears to lie in dividing the required facilities into two parts, the graphic system and the modelling system. The modelling system allows objects to be defined in their own local coordinates; it provides functions for composing and combining transformations, and for applying these transformations to local coordinates. The result of the transformations is typically to produce a definition of the viewed information in a world coordinate system, suitable for application of the viewing transformation. Using the graphics system we set up the appropriate viewing transformation, and then generate the picture using the definition in world coordinates; this will typically be done by calling line-drawing functions with world-coordinate arguments.
This approach avoids the problem of the current position. In the modelling phase, no such concept exists: each transformation takes one point in local coordinates, and produces a point in world coordinates. The line-drawing functions that generate the picture may very well depend on the concept of a current beam position, but any potential difficulty is avoided by preventing any change in viewing transformation during the generation of a picture.
The modelling system will tend to contain a basic set of functions that include the following:
There will, however, tend to be a need for many different types of modelling systems, to suit the many different applications that involve modelling. (Examples will follow). Despite this diversity, we can expect all modelling systems to contain the functions listed above in one form or another; furthermore, it is feasible to suggest a basic modelling system as a starting point for the development of more application dependent systems.
The graphics system will include primitive functions for drawing lines and text; attribute functions; viewing transformations; input functions; and other functions for such things as segmentation and initialization. These functions will be accessible to the application programmer. In addition, certain functions will be designed so that they may be called by the modelling system. The resulting interface between the two systems will require careful design.
Whereas we anticipate the need for a variety of different modelling systems to suit different applications, it may be possible to design a single, universal example of the graphics system. It is quite likely, however, that the requirements of different applications and different hardware capabilities will make this impossible. There will be a need for considerable study of applications, hardware configurations and graphics system support before we can determine the magnitude of this problem.
It is important that we recognize that no added inconvenience to the application programmer is necessarily created by the separation into two systems. He or she continues to use standard methods of generating pictures, using viewing transformations functions provided by the one package, and modelling transformations provided by the other.
Application programmers who are using both systems together may see the two systems as one combined system. This suggests the need to consider the programmer's interface with this combined system, with the idea of bringing this interface under eventual control.
There are a number of issues relating to the interface between the two systems, and how this is affected by considerations of efficiency and special hardware configurations. We should point out that the aim in defining a standard interface is to promote portability, There are ways in which adherence to this standard may be relaxed, without total loss of portability.
We see the need for increased performance as the main justification for relaxing the standard. For example, the operation of displaying a line conceptually involves two stages of transformation, first by modelling system, then by the graphics system's viewing transformation. It is desirable to combine these transformations into one, to achieve greater speed; and this can be done (show Tom's example). The solution involves the use of special system routines that bypass the separate modelling and graphics system stages of transformation by a single transformation stage.
In such a situation, all the standard interface functions still exist; the modelling system can still deliver world coordinate points when required, and these points can still be delivered to the graphics system. All we have done is to add a 'short cut' that bypasses two transformation stages, replacing them with a single one that may be performed by hardware.
In other situations, we may find it more expedient to construct a combined modelling and graphics system in which the standard interface is not present. This might be done to achieve the desired performance on a high-speed display where stringent memory or timing constraints ruled out implementation of the complete interface. In such a case, portability is inevitably reduced. A degree of portability can be ensured, however, by taking care to use the hardware components that implement individual parts of the standard graphics system, and specifying an explicit, but non-standard, interface between these hardware functions and the rest of the combined modelling-graphics system. Use of this approach guarantees that some portability can be retained when the application is moved to another configuration where the standard interface is supported: only the modelling portion of the program will require change.
Thus our earlier proposal can be viewed as a way of achieving standardized graphics packages for use on their own. If there is no need for a basic graphics package of this kind, it is possible to relax the standards in a manner that retains portability with a small controlled additional cost in re-programming. It will be possible to transport applications that employ the relaxed standard to sites where the standard is enforced, and run the application after minor program changes. It will not, however, generally be possible to take applications that use the standard, and transport them to a site where only a relaxed standard interface is available.
The interface also helps in situations where non-standard modelling systems are in use, but where they interface in the standard manner to the graphics system. In these cases, only the modelling system must be rewritten when the application is transported elsewhere.
This outlines our proposal for a two-part approach to graphics system standardization. We contrast this approach with the concept of a single system supporting both modelling and basic graphics. We believe the single-system approach can lead to difficulties, because it leaves the programmer unaware of the distinction between modelling and viewing transformations. The two-system approach appears to offer a solution to this problem.
