Rendering

The ability to transform geometric ancl color infor­ mation into raster information (pixel locations aml pixel values) is embodied in a PEX resource called a renderer, as shown in Figure 2 . Conceptually, ren­ derers contain a structure traverser (discussed in a subsequent section), a state block that defines an instance of a rendering pipeline, the resource iden­ tification of the drawable element (window or pixmap) to which raster data will be directed, and an associated buffer of some sort for doing visible surface computations. Clients may associate various lookup table resources with a renderer. Certain attributes that define the rendering pipeline (e.g. , viewing, depth cuing, light source information) may be obtained indirectly from these lookup tables. Name set resources may a lso be associated with renderers in order to provide control over those output primitives that a re to be highlighted or treated as invisible.

A rendering pipeline can process output com­ mands. Output commands consist of: commands that modify anributes that affect all primitives (e.g., set view index), commands that modify attributes of a certain class of output primitive (e.g. , set line

PEX: A Network-transparent Three-dimensional Graphics System

"R ENDER OUTPUT COMMANDS" REQUEST " R ENDER NETWORK" REQUEST r - - - ,

I

I

I

YES STRUCTURE

I

I

TRAVERSER

I

I

I

I

I

:

r _ _ _

j_

__

L,

�

I I I

I

I

RENDERI N G II STRUCTURES 1,' I PIPELINE 1 _I 1 _I I _I I L - - - J _I L - - - J RASTER DATA

Figure 2 Renderer Resource

color), and commands that contain geometric information that is to be rendered (e. g . , draw poly­ line). Output primitives in P EX _{i nclude the} P H IGS

primitives marker, polyline, text, annotation text, fill area (polygon), fill area set (polygon with holes), cell array, and the PH lGS+ _{extensions to these}

primitives; plus the P H IG S + _{primitives polyhedron}

(indexed polygons), triangle strip, quadrilateral mesh, parametric polynomial curves and surfaces, and trimmed nonuniform B-sp!ine cun'eS and surfaces.

A renderer is made ready for rendering by an explicit "begin rendering" command . This com­ mand provides an opportunity for the renderer to allocate and initialize hidden surface buffers depending on the hidden surface algorithm to be used, to copy initial rendering pipeline attributes from a pipeline context, and to create a procedure vector based on the root and depth of the target drawable for efficient processing of output com­ mands. An "end rendering" request causes any buffered primitives to be rendered . A renderer inunediately processes any output commands it receives. Clients that maintain their own display lists may send output commands to a PEX _renderer for i mmediate execution. Alternatively, clients can build up l ists of output commands in structure resources for later execution by a renderer.

Vertices, control points, and normals that pass through the P EX _{rendering pipeline are transformed} by the stages defined in Figure 3. These stages are identical to the PH IGS _{transformation pipeline.} First, geometry is transformed according to the current composite modeling transformation and clipped according to the modeling clipping volume. Geometry is then further transformed by the view

Digital Technical journal Vol. ₂ No. 3 Summer 1990

orientation (viewing) and v iew mapping (projec­ tion) transformations. Finally, clipping is performed and the resulting geometry is transformed into win­ dow coordinates, and then into physical device coordinates.

PEX _{greatly expands the capabilities of the} P H IGS rendering pipeline by defining a series of color transformations that must also occur. Just as geo­ metry information is ultimately transformed to pi-""<el positions, colors must also be transformed into physically realizable pixel values. A color that is passed to P EX _{as part of a request consists of a color} type/color value pair. There are two fundamental color types in P E X : _{direct and indexed . If the color} type is direct, the color value may be in one of a

OUTPUT PRIMITIVES

X WINDOW

COOR DINATE SYSTEM

PHYSICAL DEVICE COORDINATE SYSTEM

PHYSICAL DEVICE COORDINATES

Figure

3

Geomet1y Transfonnation Stages of the Rendering Pipeline

DECwindows Program

number of supported color formats (e. g . , RGB tloat­ ing point.

I lLS

tloating point, ere .). If the color type is indexed, the color value is a 1 6-bit i nteger value. As shmvn in Figure 4, the first step of the color transformation pipeline is to dereference indexed colors using the color lookup table associated with the renderer. Within the rendering pipeline, all color compu tations (e.g. , illumination, depth cuing, c lipping) are carried out in an implementation­ dependen t true color space, even for devices that have a monochromic display.

After dereferencing, color values and geometry are clipped together during the modeling clipping stage. Light sources, geometry, the object's intrinsic color, and the current rd1ection model are used to compute the color of the illum inated object. The result is further modified according to the current depth-cuing parameters. Colors and geometry are then simultaneous] y cli pped to a three-dimensional Yolume for display purposes. Color approximation, the final color transformation step, converts color

I N P U T COLOR

COLOR

D E R E F E R E N C I N G

I N T R I NSIC COLOR

C L I P P E D I N T R I N S I C COLOR

Figure 4 Color Tra nsforma lion Stages of the Rendering Pipeline

58

values from t he true color, rendering pipel i ne for­ mat into pixel values that the device is capable of displaying. Clients must provide renderers with information on how to perform the quantization through the use of a color approximation table. This table contains information to compensate for the drawable element's v isual type and for the contents of the color map associ:lted with the device. At this step dithering or conversion to monochromic intensity values can be performed to produce out­ put onto drawable elements with lim ited color capabilities.

Except for the addition of color, there were few issues surrounding the dl'sign of the rendering pipeline since it was based on the t ransformation pipeline contained in PHIGS. The major decision, whether the majority of the rendering pipeline was above the network interface or below it, was made early in the project . Our first prototype, X:\lib, partitioned the problem so that all floating point intensive transformation, shading. and three­ dimensional clipping operations were performed by the client CPU , and scan conversion and pixel copy operations were performed by the server CPU . This partitioning was ideal for our development env ironment, which consisted of a VAX 8650 system as our main development machine a nd MicroVAX GPX workstations acting as display servers. Since the GPX workstation has no built-in hardware to supporr structure traversal or floating point intensive three-dimensional graphics opera­ tions, and since we were dealing with fairly simple models, i t made sense to do these things on the faster machine. A proposal calls for partition ing the problem in a fashion very similar to that of the X:)lib project, since such a partitioning also works wel l in an env ironment where the client and server processes are closely coupled using a high band­ width connection, as would be possible on the Titan superworkstation.

PEX supports the ent ire rendering pipeline in the server extension for two major reasons: to reduce the amount of data flowi ng back and forth across the network interface and to a l low server extension implcmenters to take advantage of any built-in rendering hardware support that may exist in the target device. The connection bandwidth assump­ tion is a critical one. The attempt was to design PEX so that it would perform reasonably well in an environment where t he c l ient/server communi­ cation occurs over a (comparatively) s low network connection. Since the network connection can form the performance bottleneck in such an

PEX: A Network-transparent Three-dimensional Graphics System

enviromnent, it is important to reduce the amount of data that must be transmitted. As an illustra­ t ion, transferring the control points of a B-spl ine surface would be faster than transferring the list of polygons generated by tessellating the surface.

In document dtj v02 03 1990 pdf (Page 58-61)