 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer graphics systems. More
specifically, this invention is a facility for perforating the geometric
processing of a view model, which is configured by an application program
in a computer graphics system.
2. Background Information
In computer graphics systems, a view model defines operations to be
performed on geometry to be rendered. The view model has a number of
coordinate systems where application programs specify operations. For
example, in some prior art systems, a three-dimensional view model
typically defines four coordinate systems: Model Coordinates (MC), Global
Model Coordinates (GMC), World Coordinates (WC), Virtual Device
Coordinates (VDC), and Device Coordinates (DC). Each coordinate system is
a convenient place to specify operations. For example, the application
specifies geometry in MC, lights in WC, view clip planes in VDC, and a
pick aperture in DC. A sequence of matrices transform geometry from
coordinate system to coordinate system where operations such as lighting,
view clipping, and picking are performed. The MC-to-WC mapping is called
the model matrix and the WC-to-VDC mapping is called the view matrix. The
model matrix, view matrix, lights, and view clip planes are all context
attributes of the view model. Applications specify these to configure the
view model.
The view model is conceptual in the sense that an implementation on a
graphics device actually may perform an operation in a coordinate system
other than the one where the application specifics it as long as the
result is the same. Device pipelines do this for improved performance.
Prior art high performance graphics devices typically retain view model
states such as matrices, lights, and clip planes. But they are more
restrictive than the conceptual view model. For example, they typically
require the MC-to-CC and CC-to-DC matrices (CC is Clipping Coordinates,
which is not exposed at the application program interface [API] level),
and lights in MC and LC (LC is Lighting Coordinates, which is not exposed
at the API level). These items are derived from the API view model
attributes. When an application changes an attribute, an item derived from
that attribute becomes invalid. It must be recalculated, and the device
must be informed of the change so that the device pipeline can reload the
derived item into the device. In some prior art systems, when an
application program sets a view model attribute in the context, all
invalidated items are recalculated at the time of change to the attribute.
This results in unnecessary calculations at every stage in the pipeline
and consumes unnecessary system overhead because an application may change
several view model attributes before sending a graphics primitive. Each
attribute change results in a complete recalculation.
A graphics primitive is a function that takes geometry in MC, passes it
through the geometry pipeline for transformation and clipping, and renders
it in DC. An example of a primitive is polyline, which is an ordered set
of vertices with each pair connected by a line segment. The polyline
primitive takes at least two vertices in MC, transforms the vertices to
CC, clips the polyline so that no geometry extends outside or the viewing
rectangle, transforms the clipped vertices to DC, and renders the line
segments between each pair of vertices.
Another example of a primitive is annotation text, which is a character
string where each character is rendered with polylines. Font files hold a
description of the polyline representation of each character. The
annotation text primitive takes a character string and a reference point
in MC and transforms the reference point to VDC. If the reference point is
inside the viewing rectangle, it builds a polyline representation of the
character string in VDC. It would be extremely convenient if a pipeline
could send these polylines to the polyline primitive above so that the
annotation primitive does not have to duplicate the remainder of the
geometric pipeline and the entire rendering pipeline. Unfortunately, the
text is in VDC now, and the polyline primitive expects geometry in MC.
This poses a problem. Therefore, it would be desirable if a device
interface would support entry of items from a variety of coordinate
systems, as the device pipeline requires.
One prior art method of changing context and its effect on the graphics
pipeline will now be discussed. This method will be known as "dumb
evaluation" because the system does not account for subsequent changes to
the specified or subsequent contexts prior to performing calculations.
Using this prior art technique, first, an application may set view model
attributes in context. Upon a detection of this change, the system will
then store the values in memory and calculate nothing. Subsequent to this
operation, the application may then call a graphics primitive, such as
that requiring the rendering of an object. The geometry can then be passed
to the device pipeline (DP), and the DP calculates "derived" items (those
changing in subsequent view models due to the changes in the specified
context) from view model attributes specified in the given context. The DP
loads derived items into a device (sometimes a hardware graphics
accelerator), and the DP sends the geometry to the device. The
disadvantage of this technique is that if the view model attributes do not
change between graphics primitives (a very common occurrence) then derived
items are calculated and loaded unnecessarily into the device. These
calculations reduce overall system performance.
A second prior art technique is known as "automatic evaluation." Using this
technique, an application program can set a view model's attributes in a
specified context, and those changes are stored into memory. Then, the
derived items, may be recalculated from the view model attributes and they
are stored into memory referenced by the context. Subsequent to these
operations, the application program may call a graphics primitive. At this
point, geometry is passed to the DP and the DP gets precalculated derived
items (from the changes in context performed above) from the context and
loads them into the device. Then, the DP sends the geometry to the device.
The disadvantages of this technique are that if the application sets
several view model attributes between graphics primitives (a not uncommon
occurrence) then all derived items from the changes in contexts will be
re-evaluated after each change to the view model. All calculations
occurring before the last change to the view model thus are unnecessary.
These extraneous calculations reduce overall graphics performance. Also, a
DP may need only a small subset of the derived items supported for the
given changes to the context(s).
Thus, prior art computer graphics systems suffer from numerous
deficiencies.
SUMMARY OF THE INVENTION
A method and apparatus in a computer system, for maintaining a computer
graphics interface between an application program and device pipeline. The
computer system implements a view model including a plurality of
coordinate systems. An acyclic graph is stored, wherein the acyclic graph
represents dependencies between various items in each of the plurality of
coordinate systems. Then, upon a creation of an item in a first coordinate
system of the plurality of coordinate systems, an object is associated
with the item. The object associates all derived items from the item in
others of the plurality of coordinate systems. The object includes a first
flag for indicating whether the current item is valid within the first
coordinate system. The object further includes a second flag for
indicating that at least one of the derived items is not valid in its
respective coordinate system. Upon requests for the item by the
application program, it is determined whether the item is valid, and if
not, then the acyclic graph is descended to determine when one of the
derived items is valid. When one valid item is found, the item is
calculated and it is indicated that the one item is valid. Then, the
acyclic graph is ascended, each derived item is calculated, and it is
indicated that each derived item is valid until reaching the requested
item. Then, the requested item is calculated, indicating that it is valid
and the requested item is presented to the application program. The
storage of the object further allows entry of geometric data from multiple
coordinate systems, and provides a fast test to indicate that derived
items are invalid.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation
in the figures of the accompanying in which like references indicate
similar elements and in which:
FIG. 1 illustrates a system upon which one embodiment of the present
invention may be implemented.
FIG. 2 illustrates the software architecture used in implemented
embodiments of the present invention, including an application program,
the device interface and device pipelines.
FIG. 3 illustrates a view model used in implemented embodiments of the
present invention.
FIG. 4 illustrates the set of objects used in implemented embodiments of
the present invention.
FIGS. 5a and 5b illustrate an acyclic graph used for representing
dependencies and derived items in implemented embodiments of the present
invention.
FIG. 6 illustrates a method performed during the update of items in a
current view model.
FIGS. 7a and 7b illustrate a method performed when invalid item(s) are
requested by a device pipeline.
DETAILED DESCRIPTION
The present invention describes a computer graphics system which improves
performance by setting values in specified coordinate systems, and only
calculating derived items from those values at such time as absolutely
necessary. In the following description, for the purposes of explanation,
certain specific embodiments are set forth describing specific signals,
representations of data, specific hardware platforms upon which certain
components may be implemented, and method steps, in order to provide a
thorough understanding of the present invention. It will be apparent to
one skilled in the art, however, that the present invention may be
practiced without some of the specific details. Also, in the following
description, certain well known circuits and certain method steps are
illustrated in block-diagram form in order to not unnecessarily obscure
the present invention.
A portion of the disclosure of this patent document contains material which
is subject to copyright protection and to which a claim of copyright
protection is made. The copyright owner has no objection to the facsimile
reproduction by anyone of the patent disclosure, as it appears in the
Patent and Trademark Office patent files or records, but otherwise
reserves all copyrights and similar rights whatsoever. .COPYRGT.Copyright
1993 Sun Microsystems Inc., all rights reserved.
System in One Embodiment of the Present Invention
Referring to FIG. 1, a system upon which one implementation of the present
invention is implemented is shown as 100. 100 comprises a bus or other
communication means 101 for communicating information, and a processing
means 102 coupled with bus 101 for processing information. System 100
further comprises a random access memory (RAM) or other volatile storage
device 104 (referred to as main memory), coupled to bus 101 for storing
information and instructions to be executed by processor 102. Main memory
104 also may be used for storing temporary variables or other intermediate
information during execution of instructions by processor 102. System 100
also comprises a read only memory (ROM) and/or other static storage device
106 coupled to bus 101 for storing static information and instructions for
processor 102, and a data storage device 107 such as a magnetic disk or
optical disk and its corresponding disk drive. Data storage device 107 is
coupled to bus 101 for storing information and instructions. This may be
used for storage of the databases to be described here which maintain
information about currently defined problem descriptions using
commercially available software products.
System 100 may further be coupled to a display device 121, such as a
cathode ray tube (CRT) or liquid crystal display (LCD) coupled to bus 101
for displaying information to a computer user. Such a display 121 may
further be coupled to bus 101 via a frame buffer 110, which information
such as a single or multiple frames or images for display upon display
device 121. An alphanumeric input device 122, including alphanumeric and
other keys, may also be coupled to bus 101 for communicating information
and command selections to processor 102. An additional user input device
is cursor control 123, such as a mouse, a trackball, stylus, or cursor
direction keys, coupled to bus 101 for communicating direction information
and command selections to processor 102, and for controlling cursor
movement on display 121.
Note, also, that any or all of the components of system 100 and associated
hardware may be used in various embodiments, however, it can be
appreciated that any configuration of the system may be used for various
purposes according to the particular implementation.
In one embodiment, system 100 is one of the Sun Microsystems.RTM. brand
family of workstations such as the SPARCstation workstations manufactured
by Sun Microsystems.RTM. of Mountain View, Calif. Processor 102 may be one
of the SPARC brand microprocessors manufactured by Sun Microsystems.RTM.
of Mountain View, Calif. (Sun Microsystems.RTM. of Mountain View, Calif.).
Note that the following discussion of various embodiments discussed herein
will refer specifically to a series of routines which are generated in a
high-level programming language (e.g., the C++ language) and compiled,
linked, and then run as object code in system 100 during run-time, for
example by the SPARCompiler available from Sun Microsystems.RTM. of
Mountain View, Calif. Specifically, the present invention is operative in
conjunction with various software libraries, such as the Solaris.RTM. XGL
computer graphics package available from SunSoft, Inc. of Mountain View,
Calif. (Sun, Sun Microsystems, XGL, and Solaris are trademarks of Sun
Microsystems of Mountain View, Calif. SPARC and SPARCstation are
trademarks of SPARC International, Inc. and are licensed exclusively to
Sun Microsystems). It can be appreciated by one skilled in the art,
however, that the following methods and apparatus may be implemented in
special purpose hardware devices, such as discrete logic devices, large
scale integrated circuits (LSI's), application-specific integrated
circuits (ASIC's), or other specialized hardware. The description here has
equal application to apparatus having similar function.
Software Architecture
Implemented embodiments of the present invention run within a window
environment managed by an X11-R5 compatible server, such as the
X11/NeWS.TM. servers within the Sun.RTM. Microsystems brand
OpenWindows.TM. environment. Application programs perform various graphics
operations by calling graphics operations from an Application Program
interface (API). The API provides the functionality here to support
derived items. The API's which may be used in various implementations of
the present invention include those using a GKS and PHIGS interface.
As illustrated in FIG. 2, the software architecture in implemented
embodiments of the present invention relies upon application programs 201
transmitting requests to a device-independent graphics framework 202
which, based on calls from application programs 201, provides certain
information either to a device pipeline 204 or a software pipeline 203. In
this way, when graphics primitives are invoked by an application program,
calculations and other operations required by the primitives may be
performed and the geometry required by the program may be passed to either
the device pipeline 204 or the software pipeline 203. As will be
discussed, if operations do not need to be performed immediately, that is,
they can be deferred to some later time, the framework 202 will not pass
any data directly to the pipelines 203 or 204. The framework will
therefore perform operations such as calculations and/or passing data to
the pipelines only when absolutely required and when it is most efficient.
In this way, performance of the overall system is improved.
In implemented embodiments, a view model is a series of coordinate systems
in which various parameters may be specified. One example of a view model
which is used in implemented embodiments of the present invention is
illustrated with reference to FIG. 3. 300 of FIG. 3 shows a
three-dimensional view model which includes a plurality of coordinate
systems at which various attributes may be set. In FIG. 3, coordinate
systems are shown with a simple abbreviation (e.g. GMC for Global Model
Coordinates, as discussed in the background above), and transforms or
matrices used for calculating items in one coordinate system to another
are shown with an abbreviation surrounded by a square (e.g. the matrix L
311 for the MC 301 to GMC 302 transform). These coordinate systems are
similar in application to those used in other prior art systems, including
PHIGS, which is described in Foley, van Dam, Feiner and Hughes, Computer
Graphics: Principles and Practice (2d Ed. 1990), at pp. 279-281. The
coordinate systems used in implemented embodiments of the present
invention include those available to and settable by application programs
(known as "API-visible" coordinate systems and transforms) which are shown
to the left of the partition line 350 in FIG. 3, and those used internally
in the embodiments of the present invention shown to the right of the
partition line 350.
For example, as shown in FIG. 3, the application program may specify
attributes in Global Model Coordinates 302 which may be then transformed
by the matrix known as the K or Global Model transform 312. In addition,
certain coordinate systems use transforms which are visible to the
application program and those which are not. For example, certain items in
the Virtual Device Coordinate system 304 relies upon data transformed from
the World Coordinate system 303 by the View Transform 313, and data in
Lighting Coordinates 361 transformed by the QG transform 352. Model
transforms provided in implemented embodiments of the present invention
may also be concatenated for transforming items created in a first
coordinate system and a second succeeding coordinate system. For example,
items created in Model Coordinates 301 may be transformed into items
residing in World Coordinates 303 by concatenating the matrix 311 with the
matrix 312. Thus a single transform, the MC-to-WC transform may be created
which is used for transforming items in Model Coordinates 301 to items in
World Coordinates 303.
View Model Derived Data
Items calculated from the view model attributes specified by the
application are known as derived items.
Implemented embodiments of the present invention define a conceptual view
model consisting of a number of coordinate systems wherein an application
at layer 201 in FIG. 2 can specify certain operations. Implemented
embodiments of the present invention provide a facility in the pipeline
interface named View Model Derived data to assist pipelines with
implementation of the view model's operations.
Derived data maintains a cache of items derived from a context's view model
attributes. The derived items include Transforms, such as those discussed
above, for mapping geometry between coordinate systems as well as items in
various coordinate systems such as the view clip bounds, lights, eye
positions or eye vectors, model clip planes, and depth cue reference
planes. For example, derived data calculates the VDC-to-DC Transform from
the Context attributes for the VDC map, VDC orientation, VDC window, DC
viewport, and jitter offset, and the Device attribute for DC orientation.
Thus, a derived item can depend on only API-set attributes, on only
derived items, or on a combination or both.
Components of the Derived Data Mechanism
Implemented embodiments of the present invention use an object-oriented
approach to supporting the implementation of derived data. The central
object of the derived data mechanism is the view cache object. The view
cache consists of derived items and functions for deferred evaluation of
the items. Each Context has a pointer to its own view cache, which
maintains the derived items specific to that Context. A view cache object
is created at Context creation time by a constructor in the Context
object.
The Context constructor creates a set of Transform objects that represent
its default transformations (Local Model Transform, etc.) and creates the
view cache object. The view cache constructor creates internal Transforms
that are needed by derived data. The view cache constructor also creates a
set of view group configuration objects, each of which represents a
coordinate system from which geometry can enter a LI-1 (the loadable
interface) primitive.
The view group interface object is the pipeline's interface to the view
model derived data. It informs a pipeline when derived items have changed
as a result of either the application changing a view model attribute or a
pipeline changing the coordinate system from which geometry enters the
next primitive. The view group interface constructor is created when the
pipeline context object is created.
The view group interface has functions for creating and destroying view
concern objects. A view concern object is a description of all the derived
items about which a pipeline is concerned. A pipeline may create as many
view concern objects as it needs.
FIG. 4 illustrates the set of objects in the derived data mechanism in a
three-dimensional context. This example shows a 3D Context 420 with one
view concern object for stroke primitives 427 and another for surface
primitives 426. Note that for 3D Contexts, them are five view group
configuration ViewCache objects 400. The derived items in this figure
include the transforms, for various coordinate systems, 401-405. A view
cache object consists of derived items and functions for deferred
evaluation of the items. Each Context has a pointer to its own view cache
object, which maintains the derived items specific to that Context.
A view group configuration object (e.g. each of items 400) holds static
configuration information for each coordinate system from which geometry
can enter LI-1. Each view cache has an array of view group configuration
objects, one for each coordinate system that the view cache supports. A 2D
view cache supports MC, VDC, CC, and DC. A 3D view cache supports these
four as well as LC, as illustrated in FIG. 3. The configuration
information is static: it is invariant once initialized and is common to
all view caches of a particular dimension.
A view group interface object (e.g. 424 or 425) is a pipeline's interface
to the view model derived data. This object informs a pipeline when
derived items have changed as a result of either the application changing
a view model attribute or a pipeline changing the coordinate system from
which geometry enters the next LI-1 primitive. The view group interface
also maintains functions for returning the items appropriate to the
current coordinate system.
A view concern object (e.g. 426 or 427) is a description of all the derived
items whose changes a pipeline is concerned with. This object is a
parameter of the view group interface's fast test for changes to derived
items.
Each pipeline has a pointer to a view group interface object (e.g. 424 or
425). The view group interlace has functions for creating and destroying
view concern objects. A pipeline may create as many view concern objects
as it needs. For example, it can have one for stroke primitives and one
for surface primitives (e.g. 426 and/or 427).
How Derived Data Gets Information From the Context
There are two ways that Context state can change: the application can
directly set a Context attribute, or the application can change an object
used by the Context, causing the object to send a message to the Context
about the change. Either of these two types of changes can cause derived
data to change.
The Context has a number of attributes that the application can set, among
which are the view model attributes. For example, if the application
changes the VDC window using a function object.sub.-- set() to set a
context variable CTX.sub.-- VDC.sub.-- WINDOW, a number of derived items
that are dependent on the value of the VDC window become invalid. But,
because the changes are evaluated lazily, the derived data items are not
recalculated until the pipeline requests the items.
If the member datum in the Context of the VDC window is changed, the
Context informs the view cache object that the application changed the VDC
window by calling a function in the view cache object. This function
invalidates the derived items that depend on the VDC window. A set of bits
records which derived items changed.
Some Context attributes that are objects, such as Lights, Transforms, or
the Device, can change, causing derived data items to change. For example,
if an application gets the Local Model Transform and changes it, the
Transform sends a message to each Context that uses the Transform. If the
Context is interested in the change to the Transform, it will call a view
cache function to invalidate derived items that depend on the Local Model
Transform. This process is similar for changes to Lights and for Device
resizes.
Derived Data and the Interface Manager
Derived data changes are propagated from the Context's view cache to the
pipeline's view group interface object by the interface manager. When the
Context stores changes in the view cache object, the information is not
sent to the pipelines until the interface manager is invoked at rendering
time. At this time, the interface manager tells the view group interface
to mark its set of change bits to reflect the changes in the view cache
object. The view group interface object accesses the derived data
information in the view cache object to get the current change bits and
marks its bits. The pipeline will call the function changedComposite() to
determine whether a derived item has changed. If changedComposite()
returns TRUE, the pipeline checks the change functions for individual
items to determine which ones changed.
Acyclic Graph
Implemented embodiments of the present invention use an acyclic graph to
determine which item(s) are derived from other item(s). As discussed
previously, these include transforms and other items, including viewer
position, light position, clip planes, viewports, etc. Each derived item
declined in the system in implemented embodiments contains references, in
the form of direct function calls for evaluating other items which have
validity flags. In this way, when a view model attribute is modified by
the application program, derived items dependent upon that attribute
change, are invalidated during the change. No calculations are performed
at the time of an attribute change. Once the device pipeline requests one
of the invalid derived items, then the calculations may be performed. This
is performed by descending the acyclic graph until valid item(s) are
reached, and then calculating invalid item(s) back up the acyclic graph,
clearing invalid flags for the item(s) until the item requested is
reached, whose invalid flag is then cleared.
The acyclic directed graph describes the derived items that become invalid
upon a change in value to any view model attribute. It also describes the
dependencies of each derived item on other items, and hence an optimal
evaluation traversal for any derived item requested by a pipeline. The
acyclic graph used in implemented embodiments of the present invention is
illustrated with reference to FIGS. 5a and 5b. Although FIGS. 5a and 5b
illustrate a complex series of interdependencies used in derived data in
one implemented embodiment in order to determine whether item(s) are
valid/invalid, and/or have to be recalculated, it can be appreciated by
one skilled in the arts that a system using a different view model than
that described with reference to FIG. 3 may use a different acyclic
directed graph. It is important, however, that the dependencies be
represented in some form (e.g. a data structure such as a linked list, an
array or series of direct function calls, etc.) in some manner so that the
advantages of derived data may be exploited.
In the acyclic directed graph represented in FIGS. 5a and 5b, dependencies
are represented in the direction of the arrows and, therefore, the order
for evaluating derived items is opposite the direction of the arrows.
Also, although direct function calls are used in implemented embodiments
for the acyclic directed graph, it can be appreciated that in alternative
embodiments that pointers, indices or other references can be used to
determine derived items, and whether the derived item(s) have been
updated.
In the graph, the matrices required by specific coordinate systems are
shown in table 1 below. As can be appreciated by one skilled in the art,
the matrices L and K change frequently because their corresponding
coordinate systems (Model Coordinates and Global Model Coordinates) are
most frequently updated by an application program:
TABLE 1
__________________________________________________________________________
Coordinate System
Matrices Purpose
__________________________________________________________________________
MC- > GMC (local)
L API modeling
GMC- > WC (Global)
K API modeling
WC- > VDC (View)
V = EQG API viewing, to be factored
VDC- > DC (Device)
D Device mapping (derived from API)
DC- > VDC D.sup.-1 Intermediate step
VDC- > CC C View clip planes
CC- > VDC C.sup.-1 Intermediate step
VDC-WC ((QG).sup.-1) )E.sup.-1)
Intermediate step
WC- > CC VC Model clip planes
CC- > WC (C.sup.-1) ((QG).sup.-1) (E.sup.-1)
Model clip planes
WC- > DC VD Model clip planes
DC- > WC (D.sup.-1) ((QG).sup.-1) (E.sup.-1)
Model clip planes
DC- > MC (D.sup.-1) ((QG).sup.-1) (E.sup.-1)N
Eye, facet nominal
DC- > LC (D.sup.-1) ((QG).sup.-1))
Eye
MC- > WC (Model)
M = LK Lights, model clip planes, eye
WC- > MC (Normal)
N = M.sup.-1
Lights, model clip planes, eye
WC- > LC E Lights
LC- > WC E.sup.-1 Lights
MC- > DC M(VD) Points
MC- > CC M(VC) Points
CC- > DC (C.sup.-1)D Points
LC- > VDC QG Intermediate Step (sparse)
VDC- > LC (QG).sup.-1 Intermediate Step (sparse)
CC- > LC (C.sup.-) (QG).sup.-1)
Points
LC- > DC (QG)D Points
MC- > LC ME Points
LC- > MC (E.sup.-1)N Normals
__________________________________________________________________________
Note that similar labels in FIGS. 5a and 5b refer to the same items, and
the graph represented has been partitioned into two figures for
convenience.
Fast Test
Implemented embodiments of the present invention also use a fast test in
order to enable the determination of whether derived items are valid or
invalid. The fast test is also known and referred to as the
changedComposite() function in implemented embodiments of the present
invention. If the fast test yields that a particular derived item is
changing because an item upon which that item is derived changed, then
individual items are checked for changes. The pipeline requests changed
items, causing a traversal of the directed graph, in the manner discussed
above, until an item is reached that is valid, and the invalid item(s) are
calculated back through the graph until the requested item is reached,
which may be then calculated.
Derived data allows device pipelines to specify the derived items about
which they are concerned with changes so that irrelevant changes are
filtered out. Each pipeline has an interface to the derived items in the
cache. The interface consists of two flag words. A bit of each represents
a derived item. One flag word stores changes to items caused by changes to
API view model attributes. The other stores unacknowledged changes in the
current coordinate system from which geometry enters. These two words are
used in the fast test so that a primitive can quickly check whether a
pipeline needs to reload derived items. The bits in the first flag word
are updated when the application sets a view model attribute. The second
flag word is updated by a precomputed table: each entry is for a specific
pair of coordinate systems. When a pipeline changes coordinate systems,
say from MC to LC, the precomputed bit pattern is taken from the
precomputed table and combined with the second flag word.
The interface has a pointer for each derived item to an evaluation function
in the cache. For example, two derived items are the MC-to-CC matrix and
the LC-to-CC matrix. If the current coordinate system is MC, the interface
sets the MC-to-CC pointer to the MC-to-CC evaluation function. If a
pipeline changes the current coordinate system to LC, the interface sets
the MC-to-CC pointer to the LC-to-CC evaluation function. This allows a
pipeline to get and reload the correct matrix without the burden of being
aware of the current coordinate system. This is an example of a mapping
for supporting entry of geometry from multiple coordinate systems.
Detail of Implementation
The following is a detail of an example implementation of 2-dimensional
geometr | | |
