Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future

The Conceptual Framework and Related Issues

Editors Notes of the Final Session

The following transcript is a condensation of the tapes and notes from the final sessions of the Workshop. It indicates the general feeling and level of understanding which the Workshop attained.

In application programs using graphics, various transformations are used at different phases of the process i.e. viewing and modelling situations. All transformations employ the same basic matrix operations. However their corresponding natural interpretations differ and depend on the context. The practice of using transformations interactively has often lead to some confusion of concepts and consequently can strained the portability of the whole application; for instance to use a transformation usually associated with modelling during the viewing phase or vice versa.

To avoid possible confusions, it seems helpful to look at transformations according to their intended interpretation and to enforce, even artificially if necessary, classification into subsystems. The transformations of sets of points are really intended for two different purposes, viewing and modelling.

Viewing transformations, such as perspectives, (e.g. display a 3-dimensional object), are intended to be generally different from modelling transformations such as used to compose solid objects into complete structures, or to assemble 2-dimensional objects into a diagram.

Generally speaking the viewing transformations applied to an object are concerned with representation on a particular screen and what an observer sees of that particular object (when looking from a viewpoint in a particular direction). The modelling transformations are concerned with building, composing, assembling an object (be it a diagram) from parts, without any viewing considerations. The viewing transformations should be part of what will be called a graphics subsystem or a core. This subsystem is expected to be certainly application independent and to some extent device-independent.

The modelling subsystem, responsible for the relevant transformations, may be very much dependent on the application ; although it is felt that modelling subsystems could be designed for large classes of applications.

1. The modelling subsystem.
The notation used here is to think of objects as defined in their own local coordinates, with an intended interpretation - sets of isolated points, polylines, stars, etc. ..., solids, surfaces, 2-D line-drawings.
The modelling system should contain functions for composing the transformations to deliver at one-time to the graphics system, responsible for the viewing process, only one meaningful object, the one to be viewed. It should also have functions for storing and retrieving the current, composite transformation. If transformations are stored using a stack, then the function will have to push and pop the stack before the evaluation process. It also should have functions to transform from local coordinates to world coordinates and vice-versa. The modelling subsystem does not contain the model, but just the functions that deliver the coordinates of the points to the graphics system for viewing purposes.
2. The graphics subsystem.
This subsystem addresses the problem of viewing an object. It requires the definition of that object in specified coordinates called world coordinates , and will transform these into screen or plotter coordinates. Therefore, it must have the right drawing primitives - see contribution on attributes and on drawing primitives.
3. Interaction
Interaction is the responsibility of the graphics subsystem. It must provide a mechanism to communicate with the application program, which in turn communicates with the modelling system. Therefore the graphics system is responsible for the correlation of information needed by the modelling system.
4. Interface with the graphic subsystem.
For the sake of sheer performance of special hardware systems, needed for some applications, certain graphics functions must be directly accessible to the modelling system. Building the interface to making them properly accessible may degrade portability.
5. Picture structure issue
Picture structure is still not fully understood - see the picture structure preliminary report. Using only one level of segmented display files has been suggested. However, the application program may then set up segments of display files for interaction purposes. In the display file so produced, the segment may not have a close relationship to the structure of the model. The graphic system is not, need not be and should not be aware of the model's structure.
6. On the technique of Display Procedures (5)
It appears that a display procedure should be thought of as a modelling technique. Implementers of these should not make them available for viewing transformations as well.
7. Real-Time or high performance considerations
Concern was expressed that for some real-time applications the graphic system would get from the application program, through the modelling system, the information needed for real time transformation of the structured display file (see Remark 3 on picture structure issue).
8. Window and viewport
Since a window is set up in world coordinates, and a viewport in screen coordinates, the associated transformations may belong to different subsystems, depending on the interpretation. Whatever windowing techniques are used for composition of an object, they should be within the modelling subsystem, else they are part of the viewing transformation.
9. Simultaneous design of the subsystem
The concern about portability, device independence and, to a lesser extent, performance, should be strongly reflected in the design of the two subsystems - graphics and modelling - and the relevant interface with the application (see Remark 2). {This reflects the concern that the graphics system may not be extensible).
10. Relationship with existing packages
A consensus of opinion believed that existing packages could be transformed to fit to the new concept of modelling and graphics subsystems. Previous work is not invalidated, instead new structure is provided to clarify previous thought or entangled implementation.
11. On structured display files and segmentation
The notion of structured display files offers:
  1. Splitting display files in pieces for efficient replacement, modification and detection. One level of segmentation is sufficient for this purpose.
  2. Using display files for sharing. This implies changing the viewing transformations in the middle of a picture which should be avoided.
  3. Identification or naming for input correlation.
Remark on multi-level segmentation
The argument that one could always build multi-level segmentation on top, is valid as long as one does not identify any of those links with transmission lines between one piece of equipment and another. Bandwidth restrictions may force things around that are no longer the same.
12. On subpicturing as opposed to macro-expansion
Jump to a section of code that represents a template value: the ability rather than using a macro expansion, at execution time to change all instances at once seems convenient for the applications programmer. This convenience for the applications programmer probably degrades portability. Some existing systems may not be able to subscribe to this clear demarcation.
⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site