7.7
`
`Appearance-Attribute Handling in Hierarchy
`
`3 19
`
`Fig. 7 .17 (Cont'd.)
`
`(~ ,
`...
`''= I
`' -•
`I "'
`. ...... •
`·~ ,r 2
`..... ,....,.
`
`~I \ t'llll
`
`~·"~·• J,;'
`•• •
`r·~ ·" fU~~.t .,
`
`.:
`
`6
`
`7
`
`, •
`-tt~ln- ·
`I ,, '
`I!
`r1a111
`
`3
`
`4
`
`MY
`
`(b)
`
`-...
`
`5, 8
`
`~
`
`THIMI
`I palrhldlan
`
`\Wtlld prefer to " pass the color as a parameter," so that the child can inherit it the way a
`child inherits the CMTM as its GM.
`Indeed, in SPHIGS, each substructure inherits the traversal state as the latter exists
`at the time of the invocation of the substructure, and can then modify that state at will
`without alfecting its ancestors. In other words, attributes and transformations are bound
`dynamically at traversal time, rather than statically at specification time. This dynamic
`binding is one of the major features of SPHIGS, making it easy to customize instances of a
`substructure.
`What substructures do with the inherited state depends on the type of data involved. We
`saw that, for geometric transformations, the substructure inherits the GM but cannot
`override its inheritance, since it can affect only its own local matrix. Attributes are simpler
`in that the substructure inherits the parent's attributes as the initial values of its local
`attribute state, but can change its local state subsequently. There is no need to distinguish
`between global and local attributes, since there is no notion of composing attributes. Note
`that this mechanism bas the same problem we discovered with transformation inheritance.(cid:173)
`just as our robot's two arm instances cannot have differing thumb transformations, its two
`arm instances cannot have the same color for the fixed part but differing colors for the
`thumb.
`
`TEXAS INSTRUMENTS EX. 1009 - 355/1253
`
`

`
`320
`
`Object Hierarchy and Simple PHIGS (SPHIGS)
`
`In the structure network of Fig. 7 . 18(a), the street structure sets the colors for the house
`substructure. The resulting image is shown in Fig. 7.18(b), and the code generating the
`network is shown in Fig. 7 . 19.
`An auribute can be reset within a substructure to o'lerride the inherited value. The
`following code fragment specifies a revised bouse structure whose chimney is always red.
`
`SPK.openStructure {HOUSE.STRUCT):
`SPH..exccutcStructure {SIMPLE.HOUSE..STRUCT);
`SPH-SetlntcriorColor {COLOR..REO);
`s~1 up lransformarion;
`SPH..exccuteStrucrure (CHIMNEY ..STRUCT);
`SPH..closeStruciUre ();
`
`Let us use this new house structure in conjunction with the street structure generated by the
`code in Fig. 7.19. Figure 7.20 shows the structure network and the resulting image. The
`traverser startS at STREET_STRUCT; the interior· and edge-color anributes have their default
`values. The edge color is set to white, a value it retains throughout display traversal of this
`network. The lirst setlnteri01Color causes yellow to be inherited by the first instance of
`HOUSE..STRUCT. which in tum passes yellow to StMPLE....HOUSE...STRUCT, whose polyhedron is
`shown
`in that color. When
`t.he traverser returns from SIMPLE_HOUSE...STRUCT to
`
`(a)
`
`(b)
`
`STREET
`
`let . . . calor "WhhW
`.. Int. oalar ·; I
`.
`
`11UM
`
`.....
`......
`.,.,.
`
`HOUlE ..
`
`1111 DUll
`
`SMILE
`HOUlE
`
`pctjtlfOII
`
`Fig. 7 .18 Use of attribute inheritance to model street with colored houses. (a)
`Structure network. (b) Resulting image. (Interior colors are simulated by patterns.)
`
`TEXAS INSTRUMENTS EX. 1009 - 356/1253
`
`

`
`7.7
`
`Appearance-Attribute Handling in Hierarchy
`
`321
`
`SPH_openSrructure (STREET- STRUCT);
`SPH..setEdgeColor (COLOR... WHITE);
`
`SPH..setlnteriorColor (COLOR_ YELLOW);
`set up transformation;
`SPH.executeSrructure (HOUSE..sTRUCT};
`
`SPH..setlnteriorColor (COLOR...NAVY);
`set up transfomwtion;
`SPH.executeStructure (HOUSE..STRUCT);
`
`set up transfonnarion;
`SPH.executeStructure (HOUSE..STRUCT);
`SPH.closeStructure ();
`Fig. 7.19 Code used to generate Fig. 7 .18.
`
`HOUSE_STRUCT, the interior-color attribute is immediately changed to red by the next
`element. The invocation ofCHlMNEY_STRUCT therefore results in a red chimney with wh.it.e
`edges. None of these operations affect the attribute group for STREET_STRUCT, of course;
`when the traverser returns from HOUSB_STRUCT, STRBET_STRUCT's interior-color attribute is
`restored to yellow. The interior-color attribute is then changed to navy to prepare for
`drawing two navy houses.
`
`(a)
`
`(b)
`
`STREET
`
`1181 edge color "White'
`
`11811nt. color "yeelow'
`
`1181 LM
`
`execute
`
`set Int. color "navy"
`
`1181 LM
`
`execute
`
`sel lM
`
`HOUSE
`
`execute
`
`eel Int. color "red'
`
`1181 LM
`
`SIMPLE
`HOUSE
`
`CHIMNEY
`
`Fig. 7 .20 Subordinate structure overriding an inherited attribute. (a) Structure
`network. (b) Resulting view.
`
`TEXAS INSTRUMENTS EX. 1009 - 357/1253
`
`

`
`322
`
`Object Hierarchy and Simple PHIGS (SPHIGS)
`
`(a)
`
`(b)
`
`Fig. 7.21 The nongeometric nature of text in SPHIGS. (a) Before transformation.
`(b) After transformation.
`
`7.7 .2 SPHIGS Attributes and Text Unaffected By Transformations
`In true PHIGS implementations, text can be subjected to transformations like any other
`primitive. Thus, the text characters on the sides of a truck, displayed in perspective, are
`rotated and shown with appropriate perspective foreshortening, as though the letters ~re
`made out of individual polylines or fill areas. Similarly, dashes in dashed lines should be
`subject to geometric transformations and perspective foreshortening. Ho~ver, just as
`attributes in SPHIGS are nongeometric for performance reasons, so is text. As in SRGP,
`the font of the text determines the text's screen size, and a text string cannot even be
`rotated-the image of a text string is always upright in the plane of the screen, and is never
`compressed or expanded. Thus, rotation and scaling affect text's origin, but not its size and
`orientation (Fig. 7.21). SPHIGS primitive text is thus useful primarily for labeling.
`
`7 .8 SCREEN UPDATING AND RENDERING MODES
`
`SPHIGS constantly updates the screen image to mat.ch the current status of the CSS and
`view table. The following actions all can make an arbitrary amount of the screen image
`obsolete:
`•
`•
`•
`•
`
`An entry in the view table is changed
`A structure is closed (after having been opened and edited)
`A structure is deleted
`A structure is posted or unposted .
`
`Whenever SPHIGS is called to perform one of these actions. it must regenerate the
`screen image to display the current state of all posted networks. How SPHIGS chooses to
`generate the image is a function of the rendering mode the application has selected. These
`modes present a choice bet~en quality and speed of regeneration: The higher the quality,
`the longer it takes to render the image. The rendering mode is set by
`
`procedure SPH_setRenderiogMode (mode : WIREFRAME I PLAT I LIT __FLAT I GOURAUD);
`
`TEXAS INSTRUMENTS EX. 1009 - 358/1253
`
`

`
`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.
`
`TEXAS INSTRUMENTS EX. 1009 - 359/1253
`
`

`
`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.
`
`TEXAS INSTRUMENTS EX. 1009 - 360/1253
`
`

`
`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.
`
`TEXAS INSTRUMENTS EX. 1009 - 361/1253
`
`

`
`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.)
`
`TEXAS INSTRUMENTS EX. 1009 - 362/1253
`
`

`
`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
`
`TEXAS INSTRUMENTS EX. 1009 - 363/1253
`
`

`
`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).
`
`TEXAS INSTRUMENTS EX. 1009 - 364/1253
`
`

`
`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
`
`TEXAS INSTRUMENTS EX. 1009 - 365/1253
`
`

`
`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.
`
`TEXAS INSTRUMENTS EX. 1009 - 366/1253
`
`

`
`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.
`
`TEXAS INSTRUMENTS EX. 1009 - 367/1253
`
`

`
`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 definit