7.8
`
`Screen Updating and Rendering Modes
`
`323
`
`We summarize the four SPH1GS rendering modes here; they are discussed much more fully
`io Chapters 14 through 16.
`
`Wireframe rendering mode. WIREFRAME mode is the fastest but least realistic form of
`display. Objects are drawn as though made of wire, with only their edges showing. The
`visible (within the view volume) portions of all edges of all objects are shown in their
`entirety, with no hidden-edge removal. Primitives are drawn in temporal order-that is, in
`the order in which the traverser encounters them in the posted structure networks in the
`database; this order is affected by the display-priority determined by the view index, as
`mentioned in Section 7 .3.4.
`All edge attributes affect screen appearance in their designated way in this mode; in
`fact, when the edge flag is set to EDGtUNVISffiLE, fill areas and polyhedra are entirely
`invisible in this mode.
`
`In its other three rendering modes, SPHIGS displays fill areas
`S haded rendering modes.
`and polyhedra in a more realistic fashion by drawing fill areas and facets as filled polygons.
`The addition of shaded areas to the rendering process increases the complexity significant(cid:173)
`ly, because spatial ordering becomes important-portions of objects that are bidden
`(because they are obscured by portions of " closer" objects) must not be displayed.
`Methods for determining visible surfaces (also known as hidden-surface removal) are
`discussed in Chapter 15.
`For the three shaded rendering modes, SPfflGS "shades" the interior pixels of visible
`portions of the facets; the quality of the rendering varies with the mode. For FLAT shading,
`the mode used often in this chapter's figures, all facets of a polyhedron are rendered in the
`current interior color, without being influenced by any light sources in the scene. Visible
`portions of edges are shown (if the edge flag is EDGE_ VISIBLE) as they would appear in
`W!REFRAME mode. If the interior color is set to match the screen background, only the
`edges show-this use of f1.4T rendering, which produced Figs. 7.9(a) and 7.14(c),
`simulates wireframe with bidden-edge removal.
`The two highest-quality rendering modes produce images illuminated by a light
`source;'0 illumination and shading models are discussed in Chapter 16. These images are
`nonuniformly "shaded;" the colors of the pixels are based on, but are not exactly, the value
`of the interior-color attribute. In LIT ....FLAT mode, all the pixels on a particular facet have the
`same color, determined by the angle at which the light hits the facet. Because each facet is
`of a uniform color, the image has a "faceted" look, and the contrast between adjacent faces
`at their shared edge is noticeable. GOURAUD mode colors the pixels to provide a smooth
`shaded appearance that elirnJnates the faceted look.
`In FLAT mode, the edge-flag attribute should be set to EDGE... VISmLE, because, without
`visible edges, the viewer can determine only the silhouette boundary of the object. In the
`two highest-quality mod.es, however, edge visibility is usually turned off, since the shading
`helps the user to determine the shape of the object.
`
`10 The PHIGS + extension provides many facilities for controlling rendering, including specification of
`the placement and colors of multiple light sources, of the material properties of objects characterizing
`thei.r interaction with light, and so on: see Chapters 14 through 16.
`
`0359
`
`

`
`324
`
`Object Hierarchy and Simple PHIGS (SPHIGS)
`
`7 .9 STRUCTURE NETWORK EDITING FOR DYNAMIC EFFECTS
`As with any database, we must be able not only to create and query (in order to display) the
`SPHJGS structure database, but also to edit it in a convenient way. An application edits a
`structure via the procedures described in this section; if the application also maintains an
`application model, it must ensure that the two representations are edited in tandem. Motion
`dynamics requires modification of viewing or modeling transformations; update dynamics
`requires changes in or replacement of structures. The programmer may choose to edit a
`structure's internal element list if the changes are relatively minor; otherwise, for major
`editing, it is common to delete and then to respecify the structure in its entirety.
`In the remainder of this section, we present methods for intrastructure editing; see the
`SPHIGS reference manual for information on editing operations that affect entire structures
`(e.g., deletion, emptying), and for more detailed descriptions of the procedures presented
`here.
`
`7 .9.1 Accessing Elements with Indices and Labels
`
`The rudimentary editing facilities of both SPHlGS and PHIGS resemble those of
`old-fashioned line-oriented program editors that use Line numbers. The elements in a
`structure are indexed from I toN; whenever an element is inserted or deleted, the index
`associated with each higher-indexed element in the same structure is incremented or
`decremented. The unique current element is that element whose index is stored in the
`element-pointer state variable. When a structure is opened with the SPH_openStructure
`call, the element pointer is set to N (pointing to the last element) or to 0 for an empty
`structure. The pointer is incremented when a new element is inserted after the current
`element, and is decremented when the current element is deleted. The pointer may also be
`set explicitly by the programmer using absolute and relative positioning commands:
`
`void SPH..setEiemcmPoimer (inl index);
`void SPA_offsetEiemenlPointer (in I delta);
`
`I• + for forward, - for backward +I
`
`Because the index of an element changes when a preceding element is added or deleted in its
`parent structure, using element indices to position the element pointer is liable to error.
`Thus, SPHIGS allows an application to place "landmark" elements, called labels, within a
`structure. A label element is given an integer identifier when it is generated:
`
`void SPHJabel (lot id);
`
`The application can move the element pointer via
`
`void SPH..moveEiemenlPointerToLabel (int id);
`
`The pointer is then moved forward in search of the specified label . lf the end of the structure
`is reached before the label is found, the search terminates unsuccessfully. Thus, it is
`advisable to move the pointer to the very front of the structure (index 0) before searching for
`a label.
`
`0360
`
`

`
`7.9
`
`Structure Network Editing for Dynamic Effects
`
`325
`
`7.9 .2
`
`lntrastructure Editing Operations
`
`The most common editing action is insertion of new elements into a structure. Whenever an
`element-generating procedure is called, the new element is placed immed lately after the
`current element, and the element pointer is incremented to point to the new element. 11
`Another form of insertion entails copying all the elements of a given structure into the
`open structure (immediately after the current element):
`
`void SPH.copyStructure (In! srructure/D);
`
`Elements are deleted by the following procedures:
`
`void SPH-deleteEiement (void );
`void SPH..deleteEiementslnRange (lntfirsrlndex, in! secondlndex);
`void SPH.deleteEiementsBetweenLabels (int firsrl..llbel, lot secondl..llbel);
`
`In all cases, after the deletion is made, the element pointer is moved to the element
`immediately preceding the ones deleted, and all survivors are renumbered. The first
`procedure deletes the current element. The second procedure deletes the elements lying
`between and including the two specified elements. The third procedure is si milar, but does
`not delete the two label elements.
`Note that these editing faciJities aJJ affect an entire element or a set of elements; there
`are no provisions for selective editing of data fields within an element. Thus, for example,
`when a single vertex needs to be updated the programmer must respecify the entire
`polyhedron.
`
`An editing example. Let us look at a modification of our simple street example. Our
`street now consists of ooJy tbe first house and the cottage, the former being fixed and the
`latter being movable. We create a label in front of the cottage, so we can subsequently edit
`the transformation in order to move the cottage.
`To move the cottage, we reopen the street structure, move t.he pointer to the label, and
`then offset to the transformation element, replace the transformation element, and close the
`structure. The screen is automatically updated after the structure is closed, to show the
`cottage in its new position. This code is shown in Fig. 7 .22(a), and its sequence of
`operations is illustrated in (b).
`
`7.9.3
`
`Instance Blocks for Editing Convenience
`
`The previous editing example suggests that we place a label in front of each clement we wish
`to edit, but creating so many labels is clearly too laborious. There are several techniques for
`avoiding this tedium. The first is to bracket an editable group of elements with tWO labels,
`and to use the labels in deleting or replacing the entire group. Another common technique is
`to group the set of elements in a fixed format and to introduce the group with a single label.
`
`11 We show the use of insert "'mode" in our editing examples; however, SPHIGS also supports a
`"replace" editing mode in which new elements write over extant ones. See the reference manual for
`details.
`
`0361
`
`

`
`326
`
`Object Hierarchy and Simple PHIGS (SPHIGS)
`
`SPH_openStructure (STREEL.STRUCf);
`I• When a structure is opened, the element pointer is initially at its very end. We •I
`I• must first move the pointer to the beginning, so we can search for labels. •I
`SPH..setElementPoimer (0);
`SPHJlloveElementPointerToLabcl (COTTAGE..TRANSLATIQN_LABEL);
`I• Pointer now points at transform element. •I
`SPH_offsetEiemcntPointer ( I);
`I• We replace here via a deletelinsert combination •I
`SPH..deleteEiement ():
`SPH..setLocaiTransfom1ation (newCottageTtonslotionMatrix, PRECONCATENATE) ;
`SPH..closeStructure ();
`
`(a)
`
`Fig. 7.22 Editing operations. (a) Code performing editing. (b) Snapshot sequence of
`structure during editing. The black triangle shows the element pointer's position.
`(Syntax of calls abbreviated for illustrative purposes.)
`
`0362
`
`

`
`7.9
`
`Structure Network Editing for Dynamic Effects
`
`327
`
`Fig. 7.23 Sample instance-block format.
`
`To edit any member of the group, one moves the element pointer to the label, then offsets
`the pointer from that label into the group itself. Because the group's format is fixed, the
`offset is an easily determined small integer.
`A special case of this t.echnique is to design a slandard way of instantiating
`substructures by preceding the structure-execution element with a common list of
`attribute-setting elements. A typical format of such a sequence of elements, called an
`insrance block, is shown in Fig. 7 .23; first comes the label uniquely identifying the entire
`block, then an interior-color setting, then the three basic transformations, and finally the
`invocation of the symbol structure.
`We can create a set of symbolic constants to provide the offsets:
`
`const int !NfERIOR..COLOR.OFFSET = I:
`const int SCALE.OFFSET = 2;
`const int ROTATION.OFFSET = 3:
`const int TRANSLATION.OFFSBT = 4;
`
`Using the fixed format for the block guarantees that a particular attribute is modified in the
`same way for any instance. To change the rotation transformation of a particular inslance,
`we use the following code:
`
`SPH.openSll'Ucture (LD of stntcture to be edited):
`SPH.setElementPointer (0);
`SPH.moveEiementPointerToLabel (the desired i11stance-b/ock label);
`SPH.offsetEiementPointer (ROTATION.OFFSET);
`SPH.deleteEiement ();
`SPH.setLocaiTransforrnation (11ewMatrix, mode);
`SPH..closeStTucture ();
`
`Another nice feature of instance blocks is that the label introducing each block is easy to
`define: If the application keeps an internal database identifying all instances of objects, as is
`common, the label can be set to the unique number that the applica.tion itself uses to identify
`the instance internally.
`
`7.9 .4 Controlling Automatic Regeneration of the Screen Image
`
`SPHIGS constantly updates the screen image to reflect the current status of its structure
`storage database and its view table. On occasion, however, we want to inhibit this
`regeneration, either to increase efficiency or to avoid presenting the user with a continuously
`
`0363
`
`

`
`328
`
`Object Hierarchy and Simple PHIGS (SPHIGS)
`
`changing image that is confusing and that shows irrelevant intermediate stages of editing.
`As we have seen, SPHIGS itself suppresses regeneration during the editing of a
`structure; no matter how many changes are made, an image is regenerated only when the
`structure is closed. This ''hatching' · of updates is done for efficiency, since any deletion or
`transformation of a primitive can cause an arbitrary amount of damage to the screen
`image-damage that requires either selective damage repair or brute-force retraversal of aU
`posted net~~rks in one or more views. It is clearly faster for SPHIGS to calculate the
`cumulative effect of a number of consecutive edits just once, before regeneration.
`A similar situation arises when several consecutive changes are made to different
`structures-
`for instance, when a structure and its substructures are deleted via consecutive
`calls to deleteStructure. To avoid this problem, an application can suppress automatic
`regeneration before making a series of changes, and allow it again afterward:
`
`void SPtLsetlmplicitRegenerationMode (ALLOWED / SUPPRESSED value);
`
`Even while implicit regeneration is suppressed, the application may explicitly demand a
`sereen regeneration by calling
`
`void SPHJcgenerateScreen (void);
`
`7 .10
`
`INTERACTION
`
`Both SRGP's and SPHIGS's interaction modules are based on the PHIGS specification, and
`thus they have the same facilities for setting device modes and attributes, and for obtaining
`measures. The SPHIGS keyboard device is identical to that of SRGP, except that the echo
`origin is specified in NPC space with the z coordinate ignored. The SPHIGS locator
`device's measure has an additional field for the z coordinate, but is otherwise unchanged.
`SPHIGS also adds two new interaction faciUties. The first is pick correlation, augmenting
`the locator functionality to provide identification of an object picked by the user. The
`second is the choice device, described in the reference manual , which supports menus.
`Section 10.1 provides a critical review of the PHIGS interaction devices in general.
`
`7 .1 0 .1 Locator
`The SPHlGS locator returns the cursor position in NPC coordinates, with z NPC = 0. 12 It also
`returns the index of the highest-priority view whose viewport encloses the cursor.
`
`typedef struct {
`I• )x, y. O)NPC screen position •/
`point position:
`I• Index of view whose viewport encloses lhe cursor •I
`int viewbulex;
`int buttonOjMostRecentTrtmsition:
`enum { UP, DOWN} buuonChoro(MAXJ!UTION_COUNT] ;
`} locatorMeasure:
`
`12 In PHIGS. the loca10r reiUrns poims in the 3D world~oordinate system . Many implementations.
`however, cannot return a meaningful z value; o nly high-performance workstations that support control
`dia.ls and multiple real-time views can offer a comfortable user interface for pointing in 3D (see
`Chapter 8).
`
`0364
`
`

`
`7.10
`
`Interaction
`
`329
`
`When two viewpons overlap and the cursor position lies in the intersection of their bounds,
`the viewport having the highest index (in the view table) is returned in the second field.
`Thus, the view index is used to establish view priority for input as well as for output. The
`view-index field is useful for a variety of reasons. Consider an application that allows the
`user to specify bounds of a viewport interactively, much as one can move or resize a
`window manager's windows. In response to a prompt to resize, the user can pick any
`location within the viewport. The application program can then use the viewlndex field to
`determine which view was picked, rather than doing a point-in-rectangle test on viewport
`boundaries. The view index is also used in applications with some output-only views; such
`applications can examine the returned view index to determine whether the correlation
`procedure even needs to be called.
`
`7.1 0.2 Pick Correlation
`
`Because the SPHIGS programmer thinks in terms of modeled objects rather than of the
`pixels composing their images, it is useful for the application to be able to determine the
`identity of an object whose image a user has picked. The primary use of the locator,
`therefore, is to provide an NPC point for input to the pick-correlation procedure discussed
`in this section. As we saw with SRGP, pick correlation in a flat-earth world is a
`straightforward matter of detecting hits-primitives whose images lie close enough to the
`locator position to be considered chosen by the user. If there is more than one hit, due to
`overlapping primitives near the cursor, we disambiguate by choosing the one most recently
`drawn, since that is the one that lies "on top." Thus, a 20 pick correlator examines the
`primitives in inverse temporal order, and picks the first hit. Picking objects in a 30,
`hierarchical world is a great deal more complex, for the reasons described next; fortunately,
`SPHTGS relieves an application of this task.
`Picking i.n a hierarchy. Consider the complexity introduced by hierarchy. First, what
`information should be returned by the pick-correlation utility to identify the picked object?
`A structure fD is not enough, because it does not distinguish between multiple instances of
`a structure. Only the full path-a description of the complete ancestry from root to picked
`primitive-provides unique identification.
`Second, when a particular primitive is picked, which level of the hierarchy did the user
`mean? For example, if the cursor is placed near one of our robot's thumbs, does the user
`mean to select the thumb, the arm, the upper body, or the entire robot? At times, the actual
`primitive is intended, at times the leaf structure is intended, and any other level is possibly
`intended, up to the very root! Some applications resolve this problem by providing a
`feedback mechanism allowing the user to step through the levels from primitive to root, in
`order to specify exactly which level is desired (see Exercise 7.13).
`Comparison criterion. How is proximity to an object defined when the comparison
`should really be done in 30? Since the locator device effectively yields a 20 NPC value,
`there is no basis for comparing the z coordinates of primitives to the locator position. Thus,
`SPHIGS can compare the cursor position only to the screen images of the primitives, not to
`the WC locations of the primitives. IJ a primitive is a bit, it is deemed a candidate for
`correlation. ln wireframe mode, SPHTGS picks the very first candidate encountered during
`
`0365
`
`

`
`330 Object Hierarchy and Simple PHIGS (SPHIGS)
`
`traversal; the reason for this strategy is that there is no obvious depth information in a
`wireframe image, so the user does not expect pick correlation to take relative depth into
`account. (A side effect of the strategy is that it optimizes pick correlation.) In shaded
`rendering modes, SPHIGS picks the candidate whose hit point (the NPC point, on the
`primitive' s normalized (30 NPC) surface, to which the user pointed directly) is closest to
`the viewpoint-the one "in front," as discussed in Section 7.12.2.
`
`P ick-correlation utility. To perform pick correlation, the application program calls a
`SPHlGS pick-correlation utilityl8 with an NPC point and a view index, typically returned
`by a previous interaction with the locator:
`
`void SPH..pickCorrelate (
`point position, lnt viewlndex, picklnformation •picklnfo);
`
`The returned information identifies the primitive picked and its ancestry via a pick path, as
`described by Pascal data types in Fig. 7.24.
`When no primitive is close enough to the cursor position, the value of pickLevel
`returned is 0 and the path field is undefined. When pickLevel is greater than 0, it specifies
`the length of the path from the root to the picked primitive-that is, the primitive's depth
`within the network. In this latter case, entries [I] through [pickLevel] of the path array
`return the identification of the structure elements involved in the path leading from root to
`picked primitive. At tile deepest level (entry [pickLevel]) , the element identified is the
`primitive tllat was picked; at all other levels (entries [pickLevel-l) througll [ I]), the
`elements are all structure executions. Eacll entry in path identifies one element with a record
`that gives the structure lD of the structure containing the element, the index of the element
`
`13Full PHIGS has the Pick logical
`SPH__pickCorrelate procedure.
`
`input device
`
`that returns
`
`the same measure as the
`
`typeder struct {
`int SlniCIUre/D;
`int elementbtdex;
`I• Enumerated type: polyline, polyhedron, execute-structure, etc. •I
`e lementTypeCode elemenrType;
`iot pic kiD;
`} pickPathltem ;
`
`typedef pickPathltem pickPath[MAX.HIERARCHY .LEVEL):
`
`typeder struct {
`lnt pickLevel;
`pickPalh path;
`} picklnforrnation;
`
`Fig. 7 .24 Pick-path storage types.
`
`0366
`
`

`
`7.10
`
`Interaction
`
`331
`
`in that structure, a code presenting the type of the element, and the pick ID of the element
`(discussed next).
`Figure 7.25 uses the structure networic of Fig. 7.15 for the robot's upper body, and
`shows the pick information returned by several picks within the structure's displayed image.
`How does the pick path uniquely identify each instance of a structure that is invoked
`arbitrarily many times within the hierarchy? For ex.ample, how do we distinguish a pick on
`the robot's left thumb from a pick on its right thumb? The pick paths for the two thumbs are
`identical except at the root level, as demonstrated by points a and e in Fig. 7.25.
`The pick identifier can provide pick correlation at a finer resolution than does a
`structure ID. Although the element index can be used to identify individual elements, it is
`subject to change when the structure is edited. Therefore, using the pick ID is easier,
`because the pick lD is not affected by editing of other elements. It has a default value of 0
`and is modally set within a structure. One generates a pick-10 element via
`
`void SPH.setPickldeutifier {lnl id):
`
`The pick-10 element is ignored during display traversal. Also, a pick £D has no notion of
`inheritance: it is initially 0 when SPHIGS begins the traversal of any structure, whether it is
`a root or a subStructure. Because of these two aspects, pick IDs do not behave like
`attributes. Multiple primitives within a structure may have unique £Ds or share the same
`one; this permits arbitrarily fine resolution of pick correlation within a structure, as needed
`by the application. Although labels and pick IDs arc thus different mechanisms, the fom1er
`used for editing and the latter for pick correlation, they are often used in conjunction. In
`particular, when structures are organized using the instance-block technique described in
`Section 7. 9.2, a pick-ID element is also part of the block, and the pick lD itself is typically
`set to the same integer value as that of the block label.
`
`I ~ ·d
`C:;
`
`left
`arm
`
`[lJ1
`
`a
`
`·C
`
`b"
`
`Tight
`arm
`
`/
`e
`
`Refer to the structure ne!WOII< shown in Ftg. 7.15.
`
`(a) level• 3
`path[! ) : struct UPPER _BODY, element 7
`path[2) : struct ARM, element 3
`path[3) : struC1 THUMB, element 1
`
`(b) level• 2
`path{ I ) : struC1 UPPER_BODY, element 11
`pa1h(2) : StruC1 ARM, element 1
`
`(c) level · 1
`path(!) : StruC1 UPPER_BOOY, element 1
`
`(d) level = 0
`
`(e) level • 3
`path(!) : struct UPPER_BODY, element 11
`path[2) : struct ARM, element 3
`path(3) : struC1 THUMB. element 1
`
`Fig. 7.25 Example of pick correlation.
`
`0367
`
`

`
`332
`
`Object Hierarchy and Simple PHIGS (SPHIGS)
`
`7 .11 ADDITIONAL OUTPUT FEATURES
`
`7 .11 .1 Attribute Bundles
`
`Standard PHIGS provides a mechanism for setting attribute values indirectly. An
`application can, during its initializ.ation sequence, store a collection of attribute values in an
`auributt bundlt. Each type of primitive has its own type of bundle, and a PHIGS package
`provides storage for many bundles, each bundle identified by an integer 10. For example,
`we could store a "favorite'' polyline attribute set in bundle I. Subsequently, while editing a
`structure, we would prepare for the specification of a polyline primitive by insening an
`element that, when executed during traversal , specifies that polyline attributes are to be
`taken from bundle I (rather than from the explicitly specified traversal attribute state).
`Attribute bundles are often used as a "shonhand" to simplify the task of specifying
`attributes. Consider an application in which a large number of unrelated primitives must
`appear with identical attributes. Because the primitives are not related, the inheritance
`mechanism does not help. Indeed, without attribute bundles, the application would have to
`specify the desired attribute set redundantly, at various places throughout the structure
`networts.
`lmplementors of PHIGS packages sometimes initialize the attribute bundles in order to
`provide wortstation-dependent preselected attribute sets that take advantage of the
`workstation's best features. The application programmer can choose to accept the bundles'
`initial values, as "suggestions" from the implementor, or to modify them with the
`bundle-editing commands. Changing definitions of bundles in the bundle table without
`changing structure networks is a simple mechanism for dynamically changing the
`appearance of objects.
`
`7 .11 .2 Name Sets for Highlighting and Invisibility
`
`SPHIGS suppons two traditional feedback techniques that applications commonly use in
`conjunction with the SPHIGS picking facility: highlighting objects and making objects
`invisible. The fonner technique is typically used to provide feedback when the user picks an
`object; the latter declutters the screen by showing only desired detail. By default, all
`primitives that are part of a posted network are visible and unhigWighted. A set of
`primitives may be given an integer name, to identify the primitives for subsequent toggling
`of their visibility or highlighting status.
`Because a group of unrelated primitives can share a name, and because a single
`primitive can have any number of names. the name feature can allow a complex object to be
`organized in several ways onhogonal to the structure hierarchy induced by structure
`invocation. For instance, an office-building model represented as a set of floor substructures
`could also be represented as a union of several systems: the plumbing network. the electrical
`wiring, and so on. Simply by giving all pipe primitives a common name (PWMBINO), we
`ensure that, even though the pipe primitives may be scanered among the actual structure
`hierarchy, we can nevertheless refer to them as a single unit.
`When we want, say, to make the plumbing subsystem invisible, we add the name
`PWMBIN<i to the global invisibility filter; the screen is immediately updated to remove
`images of pipe objects. Similarly, by setting the invisibility filter to the names of all the
`
`0368
`
`

`
`7 .11
`
`Additional Output Features
`
`333
`
`subsystems except the electrical subsystem, we can display the electrical subsystem in
`isolation. The highHghting filter works similarly. Both filters are initially empty, and are
`affected only by explicit calls that add or remove names. 14 Note that changing a filter, like
`changing a viewing specification, triggers screen regeneration; indeed, these operations
`change the rendered view of the CSS much as queries in traditional database programs are
`used to show different "views" of data.
`The method used to bind names to primitives dynamically is very similar to the way
`attributes are assigned to primitives. SPHIGS maintains, as part of display traversal state, a
`traversal rrame set of zero or more names. A root inherits an empty name set. A child
`inherits the parent's name set when it is invoked, as it does attributes in general; thus,
`multiple instances of a building-block object can either share names or be named
`individually. The SPHIGS reference manual describes structure elements that, when
`executed during traversal, add names or remove names from this name set.
`
`7 .11 .3 Picture Interchange and Metafiles
`
`Although PHlGS and other standard graphics packages are system- and device-independent
`to promote portability, a given implementation of such packages in a particular environ(cid:173)
`ment is likely to be highly optimized in a nonportable way for performance reasons. The
`internal representation of the CSS, for example, may contain machine-specific information
`for structures and elements. To provide a medium of exchange among different implementa(cid:173)
`tions of PHIGS, the graphics standards committee has defined an archive file format. This
`portion of the standard is a machine- and environment-independent form of the contents of
`the CSS, without any viewing information. The PHIGS archive file thus is a portable
`snapshot of the structure database at a given time and permits PHIGS implementations to
`share geometric models.
`PHIGS implementations may also support the writing of a metafile, which can contain
`a snapshot of what the application is currently presenting on the display surface. When
`these metafiles conform to the ANSI and ISO Computer Graphics Metafile (CGM) standard
`[ARN088], the pictures contained in them can be transferred to such application
`environments as desktop publishing and interactive graphics art enhancement workstations.
`A CGM file is also a machine- and device-independent form of the CSS, but, unlike archive
`files, viewing infom1ation is also used in the creation of the picture represented in the
`CGM.
`The CGM is typically created by having a PHIGS output device driver traverse the CSS
`to produce code for the CGM ·'virtual device,'' much as an ordinary device driver produces
`display code for a real display system. Other systems then can read the metafile into their
`CSS via an input device driver that converts from the prescribed metafile format to whatever
`is used by the particular implementation. Because the metafile i.s a 20 view of a 30 scene,
`any application obtaining the picture information via a CGM will have only the 20 view to
`work with: the original 30 geometry will be lost. 1f the 30 model is to be exchanged in a
`standard format , archive files must be used.
`
`"The PHIGS delectability filter allows the application to specify primitives thai cannot be picked.
`Moreover, PHIGS ' filter scheme is more powerful , having separate inclusion and exclusion filters.
`
`0369
`
`

`
`334
`
`Object Hierarchy and Simple PHIGS (SPHIGS)
`
`Other types of metafiles might be useful for debugging and backup purposes. An audit
`trail metafile is an historical transcript file containing a list of all calls to the graphics
`package procedures (and the values sent to t.hem as parameters) in temporal order. It would,
`therefore, need to be run from start to finish, in order to recreate the CSS at the end of the
`session. Another type of transcript file records user actions: Running the application
`program with that transcript file reproduces the original sequence of PHIGS calls and thus
`the same CSS/image. No standards eJtist nor are standards planned for such transcript files,
`and neither a CGM nor a PHIGS archive file contains any historical information.
`
`IMPLEMENTATION ISSUES
`7 .12
`Much of the internal functionality of SPHIGS involves the maintenance (editing) and use
`(traversal) of the view table and the CSS. We do not discuss maintenance here, since it is
`essentially a conventional data-structu.res problem and not graphics-specific. Rather, this
`section focuses on the mechanics of displaying structures and of doing pick correlation.
`The display traverser is invoked whenever the screen image must be updated. When
`implicit regeneration is allowed, the following operations prompt traversal: closing a
`structure, posting and unposting, changing a viewing transformation, changing rendering
`mode, and changing a filter. To generate the contents of a view, each structure posted to the
`view is traversed.
`To display a posted structure network, SPHJGS visits the component structures'
`elements using a recursive descent, depth-first traversal, and performs the appropriate
`action for each element, based on the element's type. This display process that maps a
`model to an image on screen (or hardcopy) is referred to as display traversa