.\"##
.\" $Xorg: trans_rend.pg,v 1.3 2000/08/17 19:42:17 cpqbld Exp $
.\"##
.\"##
.\"## Copyright (c) 1990, 1991 by Sun Microsystems, Inc.
.\"##
.\"## All Rights Reserved
.\"##
.\"## Permission to use, copy, modify, and distribute this software and its
.\"## documentation for any purpose and without fee is hereby granted,
.\"## provided that the above copyright notice appear in all copies and that
.\"## both that copyright notice and this permission notice appear in
.\"## supporting documentation, and that the name of Sun Microsystems,
.\"## not be used in advertising or publicity
.\"## pertaining to distribution of the software without specific, written
.\"## prior permission.
.\"##
.\"## SUN MICROSYSTEMS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
.\"## INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
.\"## EVENT SHALL SUN MICROSYSTEMS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
.\"## CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
.\"## USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
.\"## OThER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
.\"## PERFORMANCE OF THIS SOFTWARE.
.\"##
.\"## Copyright (c) 1990, 1991 X Consortium
.\"##
.\"## Permission is hereby granted, free of charge, to any person obtaining
.\"## a copy of this software and associated documentation files (the
.\"## "Software"), to deal in the Software without restriction, including
.\"## without limitation the rights to use, copy, modify, merge, publish,
.\"## distribute, sublicense, and/or sell copies of the Software, and to
.\"## permit persons to whom the Software is furnished to do so, subject to
.\"## the following conditions:
.\"##
.\"## The above copyright notice and this permission notice shall be
.\"## included in all copies or substantial portions of the Software.
.\"##
.\"## THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
.\"## EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
.\"## MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
.\"## IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
.\"## OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
.\"## ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
.\"## OTHER DEALINGS IN THE SOFTWARE.
.\"##
.\"## Except as contained in this notice, the name of the X Consortium shall
.\"## not be used in advertising or otherwise to promote the sale, use or
.\"## other dealings in this Software without prior written authorization
.\"## from the X Consortium.
.H C "Porting the Transformation Module" transformation
The Transformation Module and the next module, the 3D Rendering
Module form the output command processing section of the server.
Output command processing takes two forms, translation of \s-1PEX\s+1
protocol command blocks to internal format and back again, or
execution of the specified command for rendering, picking or
incremental spatial search.
Functionally, The Transformation Module is divided into two principal
subsets, \s-1OC\s+1 parsing and \s-1OC\s+1 execution.
.H 2 "Important Data Structures and Procedures Most Likely to Be Changed"
.LP
The Transformation Module is designed around two important sets of data structures.
The first of these sets is the set of data structures for
internal storing and processing of \s-1PEX\s+1 output commands.
These data structures are defined in \fL\s-1mit/extensions/server/PEX/ddpex/mi/include/ddpex2.h\fR\s+1.
Note that many of the \s-1PEX\s+1 output commands are not reformatted for internal use.
For example, the majority of the output commands used to modify rendering
attributes are stored in \s-1PEX\s+1 format.
However, reformatting certain of the output commands (principally the rendering primitives)
greatly eases the implementation of the rendering pipeline.
It is likely that these data structures will require modification when porting
to a different graphics library or accelerator; although the rendering
primitives supported by the various libraries on the market are similar,
the details of the interface and the data formats used to describe
the geometries often differ.
.LP
Note that data structures defined in \fL\s-1mit/extensions/server/PEX/ddpex/mi/include/ddpex2.h\fR\s+1
use the same data structure for storing all geometric data
(miListHeader, defined in \fL\s-1mit/extensions/server/PEXinclude/miRender.h\fR\s+1).
This approach has helped increase the resemblance between the routines
used to render the various rendering primitives, simplifying the implementation
and helping to reduce bugs.
.LP
The second important set of data structures are those used to defined
the ddContext \(em the device-dependent part of the renderer resource (defined
in \fL\s-1mit/extensions/server/PEX/ddpex/mi/include/miRender.h\fR\s+1).
The ddContext is used to store the state of the rendering pipeline
during rendering, picking and incremental spatial search.
.LP
The ddContext is divided into two sections, a dynamic section and a static section.
The dynamic section of the ddContext is pushed on or popped off
the stack during structure traversal, while the static structure is not.
The dynamic section of the ddContext contains a copy of the pipeline context resource.
The static structure contains a similar attribute list, although all bundle
indices are resolved in this list, and the attributes in the static ddContext
are used directly for setting the state of the rendering device
(ddx for the \s-1PEX-ME\s+1).
The ddContext also stores a number of miscellaneous
intermediate values used by the rendering pipeline.
.LP
The fields in the ddContext have generally been designed to minimize
data reformatting during rendering.
The contents and format of the ddContext will probably require changes
to accommodate the destination device.
The general design philosophy for both the data structures and code
in the Transformation Module has been to perform as much
data reformatting as possible up front.
This approach yields significant performance benefits,
particularly in server-side structure store
.H 2 "Procedures Used by diPEX"
.LP
None of the Transformation Module procedures are called by di\s-1PEX\s+1.
.H 2 "Procedures Used by Other Parts of ddPEX"
.IX "Transformation Module" "output commands"
.IX "output commands, the Transformation Module"
.LP
The Transformation Module contains two sets of routines that are accessed
by other dd\s-1PEX\s+1 modules, the ddContext management functions and
the \s-1PEX\s+1 output command processing functions.
.H 3 "ddContext Functions"
.LP
The ddContext is used to store the state during rendering, picking
or incremental spatial search.
A ddContext is created for each renderer resource in InitRenderer.
The routines that follow are defined in \fL\s-1mit/extensions/server/PEX/ddpex/mi/level2/ddContext.c\fR\s+1
.LP
.KS
The following procedure creates the device-dependent part of the renderer.
.LP
.IX "Renderer Functions" "CreateDDContext"
.IX "Functions" "CreateDDContext"
(ddpex3rtn)CreateDDContext(pRend)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddRendererPtr pRend; /* renderer handle */
.fi
.RE
.KE
.LP
.KS
The following procedure deletes the device-dependent part of the renderer.
.LP
.IX "Renderer Functions" "DeleteDDContext"
.IX "Functions" "DeleteDDContext"
(ddpex3rtn)DeleteDDContext(pDDContext)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddPointer pDDContext; /* ddPEX attribute structure */
.fi
.RE
.KE
.LP
.KS
The following procedure pushes a copy of the device-dependent part of
the renderer on the stack when decending a level in the \s-1CSS\s+1.
.LP
.IX "Renderer Functions" "PushddContext"
.IX "Functions" "PushddContext"
(ddpex3rtn)PushddContext(pRend)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddRendererPtr pRend; /* renderer handle */
.fi
.RE
.KE
.LP
.KS
The following procedure pops the last saved copy of the device-dependent
part of the renderer off the stack when rising a level in the \s-1CSS\s+1.
.LP
.IX "Renderer Functions" "PopddContext"
.IX "Functions" "PopddContext"
(ddpex3rtn)PopddContext(pDDContext)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddRendererPtr pRend; /* renderer handle */
.fi
.RE
.KE
.LP
.KS
The following procedure ensures that the attributes saved in the
device-dependent part of the renderer match the attributes associated
with the current pipeline context.
.LP
.IX "Renderer Functions" "ValidateDDContextAttrs"
.IX "Functions" "ValidateDDContextAttrs"
(ddpex3rtn)ValidateDDContextAttrs(pRend, pDDContext, tables, namesets, attrs)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddRendererPtr pRend; /* renderer handle */
ddPointer pDDContext; /* ddPEX attribute structure */
ddBitmask tables, namesets, attrs; /* change masks */
.fi
.RE
.KE
.H 3 "Output Command Processing"
.LP
The majority of the routines in the Transformation Module are accessed
through one of eight function tables.
The tables support parsing, inquiring, copying, replacing, destroying, and
rendering, picking or incremental spatial search of output commands.
Each function table has one entry for every output command.
Each entry is a pointer to a procedure that supports the operation
on that particular output command.
The function tables are defined in the
file \fL\s-1mit/extensions/server/PEX/ddpex/mi/level2/Lvl2Tab.c\fR\s+1.
.H 3 "The ParseOC Table"
.LP
Functions in the ParseOC table reformat a \s-1PEX\s+1 output command into the
implementation-dependent internal formats used by the code that executes
the output command.
Each output command may have its own internal format, may use
the same format as other output commands, or may use the \s-2PEX\s+2 format.
.LP
The functions in the ParseOC table take a \s-2PEX\s+2
output command and return a pointer to the reformatted data.
.LP
The functions in the ParseOC table expect that the second argument contains a 0.
The calling code in the \s-1PHIGS\s+1 Workstation Module and
the Rendering Control Module ensure this when they create new output commands.
This feature allows the \s-1PEX-ME\s+1 to reuse many of the functions in the
ParseOC table for entries in the ReplaceOC table.
.LP
The functions have the binding shown below.
Generic pointer types are used in this definition.
These are replaced with the \s-2PEX\s+2 and internal data structures
for each output command in an implementation.
There is one global ParseOC table in a server.
.LP
.KS
.IX "Output Functions" "parseOC"
.IX "Functions" "parseOC"
(ddpex2rtn)parseOC( pPEXOC, ppExecuteOC )
.RS
.nf
.ta 0.5i 2.0i 4.0i
ddElementInfo *pPEXOC; /* OC in PEX format */
ddGenericOCPtr *ppExecuteOC; /* OC in internal format */
.fi
.RE
.KE
.LP
The functions in the ParseOC table are in the file \fL\s-1pexOCParse.c\fR\s+1.
.H 3 "The DestroyOC Table"
.LP
The functions in the DestroyOC table free all memory allocated
for the reformatted output commands created by the ParseOC functions.
These functions must free all the memory that was allocated for their
respective output commands.
There is one global DestroyOC table in a server.
The functions have the following binding.
.LP
.KS
.IX "Output Functions" "destroyOC"
.IX "Functions" "destroyOC"
(void)destroyOC( pExecuteOC )
.RS
.nf
.ta 0.5i 2.0i 4.0i
ddGenericOCPtr pExecuteOC;
.fi
.RE
.KE
.LP
The functions in the DestroyOC table are in the file \fL\s-1miDestroy.c\fR\s+1.
.H 3 "The CopyOC Table"
.LP
Functions in the CopyOC table copy one output command into another.
They take as input a pointer to a previously stored and parsed
output command, allocate memory for the destination output command,
and copy the data from the old output command into the newly allocated one.
Server porters must be careful to ensure that
the memory allocated in a CopyOC routine for the new output command
is allocated in the same chunks that memory is allocated in the
corresponding ParseOC routine \(em otherwise unexpected behavior may
result during the corresponding DestroyOC routine.
The functions in the CopyOC table have the following binding.
.KS
.LP
.IX "OC Function" "copyOC"
.IX "Functions" "copyOC"
(ddpex2rtn) copyOC (pSrc, ppDst)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
miGenericElementStr *pSrc;
/* out */
miGenericElementStr **ppDst;
.fi
.RE
.KE
.LP
The functions in the CopyOC table are in the file \fL\s-1miCopy.c\fR\s+1.
.H 3 "The ReplaceOC Table"
.LP
Functions in the ReplaceOC Table replace the data in the given parsed
output command with the data specified in the to-be-parsed (\s-1PEX\s+1 format)
output command.
These routines are provided as an aid to enhancing
the performance of the server when one element is
replacing an element of the same type.
Routines in the ReplaceOC table must allocate no new memory
(or else this efficiency is gone).
.LP
Porters must take care to ensure that the new output command will not
use up any more memory than the existing output command \(em if it will use
up more, an error must be returned.
Otherwise, the stored data may overrun the allocated space for it,
which may cause corruption of your server structure element store
or other server internal data structures.
.LP
To reduce the number of functions required to parse the incoming
\s-1PEX\s+1 data, the above-mentioned feature was added to
the routines in the ParseOC table.
If the destination pointer is 0, then the parse routine allocates memory
for the storage of the formatted output command.
Since the destination pointer has already been allocated for the replace,
the ReplaceOC table entry can usually be the same as the corresponding
ParseOC table entry for that output command type.
The file \fL\s-1miReplace.c\fR\s+1 contains a few exceptions to this
rule \(em cases where additional verification must be performed in order
to ensure that the new output command will fit into the memory already allocated.
Depending on the how you define your implementation's output command
data structures, you may be able to use this scheme.
The functions in the ReplaceOC table have the following binding.
.KS
.LP
.IX "OC Function" "replaceOC"
.IX "Functions" "replaceOC"
(ddpex2rtn) replaceOC (pPEXOC, ppExecuteOC)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddElementInfo *pPEXOC; /* PEX format */
miGenericElementPtr *ppExecuteOC; /* internal format */
.fi
.RE
.KE
.LP
The functions in the ReplaceOC table are in the file \fL\s-1miReplace.c\fR\s+1.
.H 3 "The InquireOC Table"
.LP
Functions in the InquireOC table translate the stored, formatted output
command back into the original \s-1PEX\s+1 format.
Inquiring is the inverse of parsing.
The de-parsed (\s-1PEX\s+1) format is written into the ddBuffer,
which was passed in by the calling code and allocated previously.
Inquiries of output commands are only expected to be done in response
to the PEXFetchElements request.
Functions in the InquireOC table have the following binding.
.KS
.LP
.IX "OC Function" "inquireOC"
.IX "Functions" "inquireOC"
(ddpex2rtn) inquireOC (pExecuteOC, pBuf, ppPEXOC)
.RS
.nf
.ta 0.5i 2.0i 4.0i
miGenericElementStr *pExecuteOC; /* internal format */
ddBuffer *pBuf;
pexElementInfo **ppPEXOC; /* PEX format */
.fi
.RE
.KE
.LP
The functions in the InquireOC table are in the file \fL\s-1miInquire.c\fR\s+1.
.H 3 "The InitExecuteOC Table"
.LP
The InitExecuteOC table is the output command table in the renderer.
There is one instance of this table for every renderer.
The functions in the table perform the rendering for the output commands.
The appropriate procedures are loaded into the table by the InitRenderer procedure.
The functions have the following binding.
.KS
.LP
.IX "OC Function" "InitExecuteOC"
.IX "Functions" "InitExecuteOC"
(ddpex2rtn)InitExecuteOC(pRend, pExecuteOC)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddRendererPtr pRend; /* renderer */
ddGenericOCPtr pExecuteOC;
.fi
.RE
.KE
.H 3 "The PickExecuteOC Table"
.LP
The PickExecuteOC table is the output command table in the renderer.
There is one instance of this table for every renderer.
The functions in the table perform the picking for the output commands.
The appropriate procedures are loaded into the table by the BeginPicking procedure.
The functions have the following binding.
.KS
.LP
.IX "OC Function" "PickExecuteOC"
.IX "Functions" "PickExecuteOC"
(ddpex2rtn)PickExecuteOC(pRend, pExecuteOC)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddRendererPtr pRend; /* renderer */
ddGenericOCPtr pExecuteOC;
.fi
.RE
.KE
.H 3 "The SearchExecuteOC Table"
.LP
The SearchExecuteOC table is the output command table in the renderer.
There is one instance of this table for every renderer.
The functions in the table performs incremental spatial search for the output commands.
The appropriate procedures are loaded into the table by the BeginSearching procedure.
The functions have the following binding.
.KS
.LP
.IX "OC Function" "SearchExecuteOC"
.IX "Functions" "SearchExecuteOC"
(ddpex2rtn)SearchExecuteOC(pRend, pExecuteOC)
.RS
.nf
.ta 0.5i 2.0i 4.0i
/* in */
ddRendererPtr pRend; /* renderer */
ddGenericOCPtr pExecuteOC;
.fi
.RE
.KE
.H 2 "Output Command Internal Data Format"
.LP
All internal formats for output commands in \s-1PEX-ME\s+1 have
the output command number and the length of the command in
\s-2PEX\s+2 format as the first two fields in the data structure.
The definition of the rest of the structure varies with each output command.
The following generic element structure is defined to specify
a non-specific output command in the internal data format.
Specific data structures are defined for each output command below.
.LP
typedef struct _miGenericOC {
.nf
.ta 0.5i 2.0i 4.0i
ddUSHORT ocNumber;
ddUSHORT pexOCLength;
/* implementation-dependent OC data concatenated here */
} ddGenericOCStr, *ddGenericOCPtr;
.fi
.LP
The internal data format for the output commands listed in the following
table is the \s-2PEX\s+2 protocol format for the output commands.
It conforms to the specification that the first two fields in the
data structure are the output command number and the length of the
command in \s-2PEX\s+2 format.
For definitions of the encoding for these output commands,
see the \fIPEX Protocol Specification\fR.
.TN "PEX Format Output Commands"
.TS H
tab(@) box center;
c s s
l l l .
Output Commands
_
.TH
Marker type@Marker scale@Marker color index
Marker color@Marker bundle index@Text font index
Text precision@Character expansion@Character spacing
Text color index@Text color@Character height
Character up vector@Text path@Text alignment
Annotation text height@Annotation text up vector@Annotation text path
Annotation text alignment@Annotation text style@Text bundle index
Line type@Line width@Line color index
Line color@Curve approximation@Polyline interpolation method
Line bundle index@Surface interior style@Surface interior style index
Surface color index@Surface color@Surface reflection attributes
Surface reflection model@Surface interpolation method@Backface surface interior style
Backface surface interior style index@Backface surface color index@Backface surface color
Backface surface reflection attributes@Backface surface reflection model@Backface surface interpolation method
Surface approximation@Facet culling mode@Facet distinguish flag
Pattern size@Pattern reference point@Pattern reference point and vectors
Interior bundle index@Surface edge flag@Surface edge type
Surface edge width@Surface edge color index@Surface edge color
Edge bundle index@Set individual ASF@Local transform 3D
Local transform 2D@Global transform 3D@Global transform 2D
Model Clip@Set model clip volume 3D@Set model clip volume 2D
Restore model clip volume@View index@Depth cue index
Pick ID@HLHSR identifier@Color approximation index
Execute structure@Label@Rendering color model
Parametric surface characteristics@@
.TE
The remaining output commands are re-formatted into a server specific format.
The actual structure definitions
can be found in \fL\s-1mit/extensions/server/PEX/ddpex/mi/include/ddpex2.h\fR\s+1
.TN "Reformatted Output Commands"
.TS H
tab(@) box center;
c s s
l l l .
Output Commands
_
.TH
Light source state@Add names to name set@Remove names from name set
Application data@GSE@Marker 3D
Marker 2D@Text 3D@Text 2D
Annotation text 3D@Annotation text 2D@Polyline 3D
Polyline 2D@Polyline set 3D with data@Non-uniform B-spline curve
Fill area 3D@Fill area 2D@Fill area set 3D
Fill area set 2D@Fill area 3D with data@Fill area set 3D with data
Set of fill area sets@Triangle strip@Quadrilateral mesh
Non-uniform B-spline surface@Cell array 3D@Cell array 2D
Extended cell array 3D@GDP 3D@GDP 2D
.TE
.H 2 "The Rendering Pipeline"
.IX "Transformation Module" "rendering pipeline"
.LP
The second major function of the transformation pipeline is executing
the output commands for rendering, picking or incremental spatial search.
\s-1PEX\s+1 output commands fall into two general categories,
output commands that modify rendering attributes, and rendering primitives.
.LP
The attribute modifying output commands are all handled in generally the same fashion:\ \
a routine is selected through one of InitExecuteOC, PickExecuteOC, or SearchExecuteOC
function tables according to whether the current operation
is a rendering, picking or spatial search operation; the
appropriate dynamic ddContext attribute is modified; and finally,
if the attribute source flag corresponding to the attribute
specifies that the attribute is not bundled, the corresponding
entry in the static ddContext is updated.
In the \s-1PEX-ME\s+1 there is no difference between the routines
selected by the various ExecuteOC function tables for these output commands.
The attribute output command functions are all located
in \fL\s-1mit/extensions/server/PEX/ddpex/mi/level2/miOCs.c\fR\s+1
.LP
Most of the code in the Transformation Module is dedicated
to processing the various rendering primitives.
\s-1PEX\s+1 supports ten principal rendering primitives:
.BP
Polylines
.BP
Stroke Text
.BP
Annotation Text
.BP
Polymarkers
.BP
Fill Areas
.BP
Triangle Strips
.BP
Quadrilateral Meshes
.BP
\s-1NURBS\s+1 Curves
.BP
\s-1NURBS\s+1 Surfaces
.BP
Cell Arrays
.LP
Each of these rendering primitive types has multiple
calls, each typically differentiated by the input data type.
However, by storing the data type in the type field of the
\s-1miListHeader\s+1 structure used to store coordinate data in
each of the \s-1PEX-ME\s+1 primitive formats, the multiple calls
are collapsed into a single function call.
To further simplify the implementation, \s-1PEX-ME\s+1
implements some of these primitives in terms of other primitives,
for example, curves are subdivided into polylines. Figure
.XR @NumberOf(trans_diag)
illustrates the calling sequence of the rendering primitives.
.LP
.KS
.PS
scale = 1
line from 2.550,7.825 to 2.862,7.700 to 3.612,7.450
line from 3.510,7.458 to 3.612,7.450 to 3.526,7.505
line from 2.550,7.450 to 3.050,7.263 to 3.612,7.075
line from 3.510,7.083 to 3.612,7.075 to 3.526,7.130
line from 6.175,8.325 to 7.175,8.325 to 7.175,7.325 to 6.175,7.325 to 6.175,8.325
line from 3.737,9.387 to 3.737,10.200 to 1.988,10.200 to 1.988,9.387 to 3.737,9.387
line from 0.675,8.700 to 2.550,8.700 to 2.550,8.463 to 0.675,8.463 to 0.675,8.700
line from 0.675,8.325 to 2.550,8.325 to 2.550,8.088 to 0.675,8.088 to 0.675,8.325
line from 0.675,7.950 to 2.550,7.950 to 2.550,7.713 to 0.675,7.713 to 0.675,7.950
line from 0.675,7.575 to 2.550,7.575 to 2.550,7.338 to 0.675,7.338 to 0.675,7.575
line from 0.675,7.200 to 2.550,7.200 to 2.550,6.963 to 0.675,6.963 to 0.675,7.200
line from 3.612,8.700 to 5.487,8.700 to 5.487,8.463 to 3.612,8.463 to 3.612,8.700
line from 3.612,8.325 to 5.487,8.325 to 5.487,8.088 to 3.612,8.088 to 3.612,8.325
line from 3.612,7.950 to 5.487,7.950 to 5.487,7.713 to 3.612,7.713 to 3.612,7.950
line from 3.612,7.575 to 5.487,7.575 to 5.487,7.338 to 3.612,7.338 to 3.612,7.575
line from 3.612,7.200 to 5.487,7.200 to 5.487,6.963 to 3.612,6.963 to 3.612,7.200
line from 2.862,9.387 to 0.237,8.950 to 0.237,7.200 to 0.675,7.075
line from 0.572,7.078 to 0.675,7.075 to 0.586,7.127
line from 2.800,9.387 to 0.300,8.887 to 0.300,7.575 to 0.675,7.450
line from 0.572,7.458 to 0.675,7.450 to 0.588,7.505
line from 2.800,9.387 to 0.425,8.825 to 0.425,7.950 to 0.675,7.825
line from 0.574,7.847 to 0.675,7.825 to 0.597,7.892
line from 2.800,9.387 to 0.487,8.762 to 0.487,8.325 to 0.675,8.200
line from 0.578,8.235 to 0.675,8.200 to 0.606,8.276
line from 2.800,9.387 to 0.550,8.700 to 0.675,8.575
line from 0.587,8.628 to 0.675,8.575 to 0.622,8.663
line from 2.550,8.575 to 3.612,8.575
line from 3.512,8.550 to 3.612,8.575 to 3.512,8.600
line from 2.550,8.200 to 3.112,8.387 to 3.612,8.575
line from 3.528,8.516 to 3.612,8.575 to 3.510,8.563
line from 2.800,9.387 to 2.987,7.450 to 3.612,7.075
line from 3.514,7.105 to 3.612,7.075 to 3.540,7.148
line from 2.800,9.387 to 3.112,7.700 to 3.612,7.450
line from 3.512,7.472 to 3.612,7.450 to 3.534,7.517
line from 2.800,9.387 to 3.175,8.012 to 3.612,7.825
line from 3.511,7.841 to 3.612,7.825 to 3.530,7.887
line from 2.800,9.387 to 3.300,8.200 to 3.612,8.200
line from 3.512,8.175 to 3.612,8.200 to 3.512,8.225
line from 2.800,9.387 to 3.612,8.575
line from 3.524,8.628 to 3.612,8.575 to 3.559,8.663
line from 5.487,7.825 to 6.175,7.825
line from 6.075,7.800 to 6.175,7.825 to 6.075,7.850
line from 5.487,8.575 to 6.175,7.825
line from 6.089,7.882 to 6.175,7.825 to 6.126,7.916
line from 5.487,8.200 to 6.175,7.825
line from 6.075,7.851 to 6.175,7.825 to 6.099,7.895
line from 5.487,7.450 to 6.175,7.825
line from 6.099,7.755 to 6.175,7.825 to 6.075,7.799
line from 5.487,7.075 to 6.175,7.825
line from 6.126,7.734 to 6.175,7.825 to 6.089,7.768
line from 2.550,7.013 to 2.612,7.013 to 2.550,6.825 to 0.550,6.825 to 0.550,7.325 to 0.675,7.450
line from 0.622,7.362 to 0.675,7.450 to 0.587,7.397
line from 2.550,7.138 to 2.737,7.138 to 2.612,6.763 to 0.487,6.763 to 0.487,7.700 to 0.675,7.825
line from 0.606,7.749 to 0.675,7.825 to 0.578,7.790
.ps 11
"3D" at 6.550,8.168 ljust
"Rendering" at 6.237,7.918 ljust
"Function" at 6.300,7.656 ljust
"Table" at 6.425,7.431 ljust
"InitExecuteOC" at 2.188,10.043 ljust
"PickExecuteOC" at 2.188,9.856 ljust
"SearchExecuteOC" at 2.100,9.681 ljust
"Tables" at 2.500,9.481 ljust
"miCellArray" at 1.012,8.531 ljust
"miQuadMesh" at 1.050,7.443 ljust
"miNurbsSurface" at 0.912,7.043 ljust
"miNurbsCurve" at 0.950,8.168 ljust
"miSOFAS" at 1.200,7.793 ljust
"miTriangleStrip" at 3.812,7.056 ljust
"miFillArea" at 4.037,7.406 ljust
"miText" at 4.162,7.818 ljust
"miMarker" at 4.100,8.206 ljust
"miPolyLines" at 3.925,8.581 ljust
.PE
.FN "Rendering Primitives and Calling Sequence" trans_diag
.KE
.LP
Picking and incremental structure store use the same
Transformation Module primitive rendering routines
as those used during rendering operations.
However, these routines are not called directly through the
Transformation Module function tables.
Instead, an intermediate routine (common for each of the rendering primitives
except for text and annotation text), is called to
initialize the transformations for the pipeline.
The various rendering routines are then called from this
central picking or search routine.
In the case of text and annotation text, picking and search
routines perform the transformation and clipping stages.
.LP
The bottom level rendering routines (in other words, the
routines that do not call other primitive rendering routines
to perform their rendering) each contain code to transform,
light, clip, and depth cue the primitive.
They all share the same transformation routines (miTransform
and miFacetTransform in \fL\s-1ddContext.c\fR\s+1) and lighting
routine (Apply_Lighting in \fL\s-1miLight.c\fR\s+1), but otherwise
contain routines to perform each of the above operations on the specified primitive.
As a general rule, these routines are not designed to be particularly portable.
Though the algorithms are general ones for the primitive type,
a significant proportion of the code in each of these routines is
typically dedicated to the book keeping operations associated with
the data structures used to store coordinate and facet data, rather than
to implementing the algorithm.
.LP
Pointers to miListHeader, listofddPoint, and listofddFacet data types, along
with a pointer to the current renderer, comprise the interface between
all stages of the rendering pipeline.
.LP
In order to reduce reallocation of memory at run time, a cache of
miListHeaders, listofddPoints, and listofddFacets is maintained by
the ddContext.
.LP
When a Transformation Module rendering routine is called, it will
generate intermediate data, with associated
list headers and lists, as it proceeds down the rendering pipeline.
When the Transformation Module rendering routine returns control
to the traverser, the cache is made available for use
by the next rendering routine, and the intermediate data is lost.
.LP
Because of the constraints imposed by clipping, color is handled
in floating-point format throughout the pipeline, and
therefore, clipping and geometric coordinate transformation
routines only support vertices and facets
with \s-1RGBFLOAT\s+1, \s-1HLS\s+1, \s-1HSV\s+1,
and \s-1CIE\s+1 color models.
It should be noted, however, that because each axis of a particular
color model is handled independently, interpolation during clipping
is identical for these color models.
.LP
The use of pointer unions for the vertex and facet data facilitates the
manipulation of varying data types.
Not all compilers will allow assignment
of unions to register variables, however.
.LP
An internal format for edge flags in Triangle Strips
has been adopted to facilitate removal of clipping artifacts.
Because QuadMesh structures are decomposed into triangle strips for
rendering, edge flags are used to suppress rendering of the diagonals.
.H 2 "Picking"
.LP
Picking is achieved by determining the \s-1FIRST\s+1 output command that
intersects the pick aperture. In picking, \s-1OC\s+1s are essentially
``clipped'' to the pick aperture and the first non-degenerate remainder
is picked. All of the view clipping code is used to perform this
intersection calculation. The only difference between view clipping and
picking is that the \s-1OC\s+1 is clipped against the pick aperture,
instead of the \s-1NPC\s+1 sub-volume.
.LP
The pick operation initiates its own traversal of the display list.
Instead of calling the rendering routines via the InitExecuteOC table,
the traverser calls picking routines by using the PickExecuteOC table.
.LP
Annotation text is a special case in picking because only picking the
annotation text origin constitutes a valid ``pick''.
.H 2 "Searching"
.LP
Searching is performed in the same way as picking in \s-1PEX-ME\s+1,
with the following exceptions:
.BP
Searching is performed in world coordinates, while picking is performed in
\s-1NPC\s+1 coordinates.
.BP
Searching is specified by a search reference point and a search distance, while
picking is specified by a pick measure resource.
.LP
The search operation also initiates its own traversal of the display list.
Instead of calling the rendering routines via the InitExecuteOC table,
the traverser calls picking routines by using the SearchExecuteOC table.
.KS
.H 2 "Curve and Surface Architecture"
.LP
The \s-1NURBS\s+1 curve code is an ordinary forward differencing implementation:
.BS
.LS 1
if (order == 1) put_point_at_control_points();
else {
foreach knot interval {
compute_nurb_polynomial_coefficients_for_span()
multiply_basis_function_and_control_points();
compute_forward_difference_matrix();
forward_difference_span_and_add_polylines_to_polyline_set();
}
render_polyline_set();
}
.LE
.BE
.FN "NURBS Curve Inner Loop Pseudo-Code"
.KE
.LP
The first step in the loop, \fL\s-1compute_nurb_polynomial_coefficients_for_span\fR\s+1,
uses a recurrence solution to solve for the curve polynomial coefficients.
Note that there is no particular optimization for simpler common cases.
.LP
The \s-1NURBS\s+1 surface implementation is somewhat more complicated
than the curve code.
The general approach is to build a list of rectangular ``grids,''
with one grid for each u,v span.
The grids are subdivided as necessary to meet the current
surface approximation criteria.
Thus each grid consists of a list of (u,v) coordinates and their
corresponding (x,y,z,w) coordinates.
The code uses recurrence from the surface polynomials to solve for
the (x,y,z,w) coordinates of the corners of each of the rectangles in each of the grids.
Note that, just as in curve code, no effort is
made to optimize for simpler problems such as uniform or fourth order curves.
.LP
The grids are trimmed along each trim curve, if necessary,
by computing the (x,y,z,w) point on the grid corresponding to each
new (u,v) coordinate generated by the trim curve. The curves are first
tessellated then sorted to speed the process of selecting appropriate
grids.
.LP
The (x,y,z,w) points are derived by interpolating the values from each
of the nearest grid corners, (instead of being derived from the surface polynomials).
This assures that the trim curve does not depart from the tessellated surface,
and speeds the computation significantly.
Polyline sets for iso-parametric curves are generated using a similar scheme.
.LP
The surface routines independantly compute and render solid filled
or hollows patches, their edges, and iso-parametric curves for the surface.
Filled or hollow patches are rendered using quadrilateral meshes if
no trimming curves are specified, otherwise the routine generates \s-1SOFAS\s+1.
Polyline sets are used to render surface edges and iso-parametric curves.
.H C "Porting The 3D Rendering Module" three_d
.IX "3D Rendering Module" "" "" "" PAGE MAJOR
.IX "3D Rendering Module" "special primitives"
.IX "primitives, 3D Rendering Module"
.LP
The 3D Rendering Module walks through data lists, and resolves colors
into \s-1X\s+1 windows that are passed to \s-1GC\s+1's, and calls 2D ddx
routines for access to the actual frame buffer device.
.LP
The 3D Rendering Module is the ``lowest'' level of the \s-1PEX\s+1
rendering pipeline, calling into standard \s-1X\s+1 window drawing routines
such as polygon and polyline, as well as determining if primitives are
``rendered" into a pick aperature projected into screen space around
the cursor location.
The 3D Rendering routines are called through the
RenderPrimitiveTable and the PickPrimitiveTable, located in the
the file \fL\s-1mit/extensions/server/PEX/ddpex/mi/level1/miLvl1Tab.c\fR\s+1.
.H 2 "Procedures Used by diPEX"
.LP
None.
.LP
.H 2 "Procedures Used by Other Parts of ddPEX"
.LP
All Transformation Module \s-1OC\s+1s are eventually decomposed into
the core set of rendering routines in this module:\ \
polylines, fill areas, triangle strips, polymarkers, and text.
In turn, these routines call only polygon and polyline ddx rendering
routines, with the appropriate \s-1GC\s+1.
Because these are the only ddx primitives usable by
the \s-1PEX-ME\s+1, key functions, such as Z-buffering, color interpolation,
and transparency functionality are intentionally ommitted.
All rendering styles are treated as flat shaded objects,
although separate case statements for this functionality are provided in
each of the rendering routines.
This is because the module has been fashioned as a ``staging'' area
for initializing vendor-specific hardware that may have capabilities
such as Gouraud shaded triangle generators, hardware clipping, and Z-buffering.
.LP
All surface primitives that require color interpolation are averaged.
Lists of vertices representing ``chained'' polyline vectors associate
a single color per segment; thus, segment \fIN\fR is associated with
vertex \fIN\fR's color, segment \fIN+1\fR with vertex \fIN+1\fR's color,
and so on.
.LP
The pick routines in this module determine if the remainder of the
clipping operation falls within the pick aperture, in \s-1DC\s+1 space.