5
a line or triangle—that is scan-con- verted into a frame buffer. An atomic primitive is a very small primitive. In this article, I introduce new approaches in graphics pipeline hardware design that can speed up the rendering of these atomic primitives. Graphics hardware benchmarks and performance competitions often use polygon-fill rates as their efficiency and capability indicators. Improving poly- gon-rendering efficiencies can signifi- cantly advance the whole graphics re- search and application area. In graphics, many 3D graphics models are filled tri- angle meshes, thus, triangle rendering is an important special case of polygon rendering, and a small triangle is a spe- cial-case atomic-primitive. Based on our line statistics research, 1 about 88 per- cent of triangles have all their edges shorter than 17 pixels. Thus, trying to improve the speed it takes to render small triangles makes good sense. Triangle Edge-Length Distribution Statistics In our line statistics research, we ana- lyzed triangles. We collected 600 ap- plication programs in OpenGL. Then, our modified graphics library captured all triangle fillings in these programs and found that 416 of the 600 pro- grams drew 1,414,858 triangles. Tables 1 and 2 list the statistical results. The 1,414,858 triangles have 4,244,574 edges. Table 1 shows their edge-length distributions. The number of pixels includes the two endpoints of each edge. We found that 91 percent of the edges are shorter than or equal to 17 pixels (dx is 16). Additionally, more than 95 percent of the edges are shorter than or equal to 33 pixels (dx is 32). We classified each triangle by the length of its longest edge. For example, the first row (0 < # 17) in Table 2 means that each triangle’s longest edge is shorter than or equal to 17 pixels. The statistics show that about 88.7 percent of the triangles have all three edges shorter than 17 pixels. From this we learned that most trian- gles in computer graphics applications are very small. If we could speed up fill- ing small triangles or polygons, we could significantly improve the efficiency of graphics drawing because many 3D graphics models are tessellated as filled triangle meshes. Thus, most polygons really are rendered as triangles. A New Graphics Pipeline Design Let’s look at a traditional graphics pipeline. I’ll then introduce a new de- sign that has different implementation strategies and algorithms. An OpenGL Graphics Viewing Pipeline In 3D viewing, 2 we must specify a viewing volume, which determines whether parallel or perspective pro- jection methods are used to project 3D models into 2D. All the projection lines are parallel in parallel projection. All the projection lines converge to a point called the center of projection in perspective projection. The center of projection is also called the viewpoint. Think of your eye as being at the viewpoint looking into the viewing volume. In the following example, we use the OpenGL system to demonstrate how 3D viewing is achieved. The OpenGL viewing pipeline includes normaliza- tion, clipping, perspective division, viewport transformation, and scan- conversion with hidden-surface re- moval and shading (see Figure 1). Normalization transformation is achieved by matrix multiplication on the projection matrix stack. In OpenGL, glOrtho() actually specifies a matrix that transforms the specified viewing volume into a normalized viewing vol- ume, which is a cube with six clipping planes (x = 1, x = –1, y = 1, y = –1, z = 1, and z = –1). Therefore, instead of calcu- lating clipping and projection directly, the normalization transformation occurs first to simplify the subsequent clipping and projection. Similarly, glFrustum() specifies a matrix that transforms the perspective viewing volume into a nor- 86 Copublished by the IEEE CS and the AIP 1521-9615/03/$17.00 © 2003 IEEE COMPUTING IN SCIENCE & ENGINEERING NEW GRAPHICS PIPELINE APPROACH SPEEDS UP A TOMIC PRIMITIVES RENDERING By Jim X. Chen M ANY GRAPHICS AND VISUALIZATION APPLICATIONS REQUIRE FAST RENDERING AND ANIMATION OF FINELY DETAILED OBJECTS CONSTRUCTED OF WHAT I CALL ATOMIC PRIMITIVES. A PRIMITIVE IS THE BASIC GRAPHICS SHAPE—SUCH AS Editors: Jim X. Chen, [email protected] R. Bowen Loftin, [email protected] VISUALIZATION V ISUALIZATION C ORNER

New graphics pipeline approach speeds up atomic privitives rendering

  • Upload
    jx

  • View
    215

  • Download
    1

Embed Size (px)

Citation preview

a line or triangle—that is scan-con-verted into a frame buffer. An atomicprimitive is a very small primitive. Inthis article, I introduce new approachesin graphics pipeline hardware designthat can speed up the rendering ofthese atomic primitives.

Graphics hardware benchmarks andperformance competitions often usepolygon-fill rates as their efficiency andcapability indicators. Improving poly-gon-rendering efficiencies can signifi-cantly advance the whole graphics re-search and application area. In graphics,many 3D graphics models are filled tri-angle meshes, thus, triangle renderingis an important special case of polygonrendering, and a small triangle is a spe-cial-case atomic-primitive. Based on ourline statistics research,1 about 88 per-cent of triangles have all their edgesshorter than 17 pixels. Thus, trying toimprove the speed it takes to rendersmall triangles makes good sense.

Triangle Edge-LengthDistribution StatisticsIn our line statistics research, we ana-lyzed triangles. We collected 600 ap-plication programs in OpenGL. Then,our modified graphics library capturedall triangle fillings in these programsand found that 416 of the 600 pro-

grams drew 1,414,858 triangles. Tables1 and 2 list the statistical results.

The 1,414,858 triangles have4,244,574 edges. Table 1 shows theiredge-length distributions. The numberof pixels includes the two endpoints ofeach edge. We found that 91 percent ofthe edges are shorter than or equal to17 pixels (dx is 16). Additionally, morethan 95 percent of the edges are shorterthan or equal to 33 pixels (dx is 32).

We classified each triangle by thelength of its longest edge. For example,the first row (0 < # ≤ 17) in Table 2means that each triangle’s longest edgeis shorter than or equal to 17 pixels.The statistics show that about 88.7percent of the triangles have all threeedges shorter than 17 pixels.

From this we learned that most trian-gles in computer graphics applicationsare very small. If we could speed up fill-ing small triangles or polygons, we couldsignificantly improve the efficiency ofgraphics drawing because many 3Dgraphics models are tessellated as filledtriangle meshes. Thus, most polygonsreally are rendered as triangles.

A New Graphics Pipeline Design Let’s look at a traditional graphicspipeline. I’ll then introduce a new de-

sign that has different implementationstrategies and algorithms.

An OpenGL Graphics Viewing PipelineIn 3D viewing,2 we must specify aviewing volume, which determineswhether parallel or perspective pro-jection methods are used to project3D models into 2D. All the projectionlines are parallel in parallel projection.All the projection lines converge to apoint called the center of projection inperspective projection. The center ofprojection is also called the viewpoint.Think of your eye as being at theviewpoint looking into the viewingvolume.

In the following example, we use theOpenGL system to demonstrate how3D viewing is achieved. The OpenGLviewing pipeline includes normaliza-tion, clipping, perspective division,viewport transformation, and scan-conversion with hidden-surface re-moval and shading (see Figure 1).

Normalization transformation isachieved by matrix multiplication on theprojection matrix stack. In OpenGL,glOrtho() actually specifies a matrixthat transforms the specified viewingvolume into a normalized viewing vol-ume, which is a cube with six clippingplanes (x = 1, x = –1, y = 1, y = –1, z = 1,and z = –1). Therefore, instead of calcu-lating clipping and projection directly,the normalization transformation occursfirst to simplify the subsequent clippingand projection. Similarly, glFrustum()specifies a matrix that transforms theperspective viewing volume into a nor-

86 Copublished by the IEEE CS and the AIP 1521-9615/03/$17.00 © 2003 IEEE COMPUTING IN SCIENCE & ENGINEERING

NEW GRAPHICS PIPELINEAPPROACH SPEEDS UPATOMIC PRIMITIVES RENDERINGBy Jim X. Chen

M ANY GRAPHICS AND VISUALIZATION APPLICATIONS

REQUIRE FAST RENDERING AND ANIMATION OF FINELY

DETAILED OBJECTS CONSTRUCTED OF WHAT I CALL ATOMIC

PRIMITIVES. A PRIMITIVE IS THE BASIC GRAPHICS SHAPE—SUCH AS

Editors: Jim X. Chen, [email protected]

R. Bowen Loftin, [email protected]

VISUALIZATIONV I S U A L I Z A T I O N C O R N E R

MAY/JUNE 2003 87

malized viewing volume. Mathematicaldivisions (x/w, y/w, and z/w) for all themodel’s coordinates are needed to trans-form homogeneous coordinates into 3Dcoordinates.2 Perspective division is car-ried out after clipping in OpenGL.

Clipping calculates the intersectionsbetween the 3D models and the view-port boundaries, and removes the por-tions of the models that are outside theviewport. Thus, all model vertices aretransformed into the normalized view-ing coordinates, clipped against theplanes of the normalized viewing vol-ume (x = –w, x = w, y = –w, y = w, z =–w, z = w), and then transformed intothe viewport device coordinates.

The viewport is a 2D rectangulararea. Transformation into the viewportis achieved by scaling and translationonly. All vertices are maintained in 3Dbecause we need the z values to calcu-late hidden-surface removal. From thenormalized viewing volume after di-viding by w, the viewport transforma-tion calculates each vertex’s x, y, and z(which correspond to the pixels in theviewport), and invokes scan-conver-sion, hidden-surface removal, andshading algorithms to draw the modelin the viewport. Projecting into 2D isnothing more than ignoring the z val-ues when scan-converting the model’spixels into the frame buffer. It is notnecessary, but we might consider thatthe projection plane is at z = 0.

A New Clipping Algorithm for Atomic PrimitivesThe traditional clipping approach hasbeen to calculate the intersections be-tween the primitive models and theviewport boundaries. But because ourstatistics showed that 90 percent of tri-angles are small, we can choose an al-ternative algorithm if the primitive isatomic. For example, for an atomic linesegment, instead of calculating the in-

tersections of the line with the view-port boundaries, we use either of theline’s endpoints to decide whether toaccept or reject it. There is no inter-section calculation. Similarly, we canaccept or reject an atomic trianglebased on one of its vertice’s location(see Figure 2). Thus, our new algo-rithm completely eliminates calculat-ing any intersections.

This new approach is much fasterthan existing methods. However, it hastrade-offs. First, it requires the primi-tives to be atomic; thus, it doesn’t han-dle all cases, and the traditional clippingalgorithm in the hardware remains to

handle the nonatomic primitives. Sec-ond, the atomic models are not cut intopieces by the viewport boundaries—that is, the boundaries straddled byatomic primitives will not appear to becut. Instead, the primitives will appearat the boundaries in their entirety. Be-cause the primitives are atomic, they areconfined in size and, therefore, can beconfined in the viewport as well as longas we use a smaller frame to decide clip-ping boundaries.

I believe that many people won’tlike the jagged edges this new methodproduces, but the jagged appearancecan be removed by overlapping the

Table 1. Statistics on the length of all triangle edges.

Number of pixels Number of edges Percent0 < # ≤ 17 3,879,974 91.410

17 < # ≤ 33 182,028 4.28833 < # ≤ 65 93,756 2.20965 < # ≤ 129 49,709 1.171

129 < # ≤ 257 30,157 0.710257 < # ≤ 385 6,465 0.152385 < # ≤ 513 2,390 0.056513 < # 95 0.002

Total 4,244,574 100

Table 2. The number of triangles classified by their longest edge.

Number of pixels Number of triangles Percent0 < # ≤ 17 1,255,201 88.716

17 < # ≤ 33 80,829 5.71333 < # ≤ 65 39,540 2.79565 < # ≤ 129 20,747 1.466

129 < # ≤ 257 14,183 1.002257 < # ≤ 385 3,221 0.228385 < # ≤ 513 1,074 0.076513 < # ≤ 63 0.004

Total 1,414,858 100

Devicecoordinates

Normalizethe

viewing volume

Clip against thenormalized

viewingvolume

Transforminto the

viewport

Scan-conversionHidden-surface

removal Pixel shading

3D modeling coordinates

Figure 1. OpenGL graphics pipeline: to be displayed, a vertex must go through allthe steps.

88 COMPUTING IN SCIENCE & ENGINEERING

four boundaries with black strips. InFigure 2, I use white strips to high-light the method. An alternativemethod that produces clean-cut clip-ping is just to mark the boundary tri-angles and let scan-conversion algo-rithms deal with clipping. I’ll discussthis option later.

Hidden-Surface RemovalAlong the same line of thought, insteadof comparing all z values of the pixels,we can look at one vertex to decide

whether the atomic primitive is to ap-pear in the viewport. All the z valuescorresponding to the primitive area willbe simplified to one z value (which is thepicked vertex z value). This, again, willnot be a panacea. Nonatomic primitiveswill still need to be handled in the tradi-tional approach. The efficiency andvalue of the new method is based on thelikelihood of drawing more atomicprimitives than “regular” ones. The ac-tual performance is hard to predict be-fore a hardware implementation.

Scan-ConversionMost low-level scan-conversion primi-tives are lines and polygons (triangles).The usual convex polygon-filling algo-rithms include three steps: sorting theedges by the Y values of the endpoints,computing span extrema that lie be-tween left and right edges for each scan-line, and filling all the pixels betweeneach pair of the span extrema. The firstand third steps are straightforward, butthe second step depends on the algo-rithm for calculating the span extrema,which is relatively time-consuming.

Again, due to the overwhelminglyhigh percentages of short lines and smallpolygons, we save the atomic primitivesin a bitmap library, as a font library.Scan-conversion is then a process of in-dexing, retrieving, and filling. The newdata structure and implementation to-tally differ from traditional methods.

I’ll use a triangle as an example. Weuse a 5 × 11 bitmap pixel matrix to storea triangle shape; a triangle library in-cludes all triangles’ bitmap pixel matri-ces (see Figure 3). With my students’help, I have developed a method to gen-erate an index to the pixel matrix in thelibrary. When a program calls to draw asmall triangle within the rectangle area,we can use the index to locate the posi-tion of the triangle’s pixel matrix in thelibrary and scan-convert it directly intothe frame buffer similar to how we’dhandle a font.

During scan-conversion, 0s in thepixel matrix will be ignored, and 1s inthe pixel matrix will be replaced withthe current attributes of the corre-sponding pixel. We’ll ignore the im-plementation details here.

In the clipping algorithm, if theboundary triangles are not trivially re-jected or accepted, they are marked tobe boundary triangles. If a triangle ismarked as a boundary triangle, we canignore all pixels that go beyond the

V I S U A L I Z A T I O N C O R N E R

Figure 2. (a) Atomic triangle clipping: keeping or removing the atomic primitives;(b) rendered; (c) We use rectangles to remove zigzags.

1 2 3 4 5 6 7 8 9 10 11

1 0 0 0 0 0 1 0 0 0 0 0

2 0 0 0 0 1 1 1 1 0 0 0

3 0 0 1 1 1 1 1 1 1 1 1

4 0 1 1 1 1 1 1 0 0 0 0

5 1 1 0 0 0 0 0 0 0 0 0

(a)

0 0 0 0 0 1 0 0 0 0 0

0 0 0 0 1 1 1 1 0 0 0

0 0 1 1 1 1 1 1 1 1 1

0 1 1 1 1 1 1 0 0 0 0

1 1 0 0 0 0 0 0 0 0 0

(b)

Figure 3. Example of the pixel matrix bitmap used to save all different triangleshapes. (a) A triangle and its bitmap image; (b) the pixel matrix of the triangle.

(a) (b) (c)

boundary during the scan-conversionprocess. This method is relativelyslower than rejecting or accepting theatomic primitive as a whole, but it re-sults in a smooth clear-cut boundary.

T his is an interesting topic thatI’ve only been able to present

in an abbreviated form. So far, we haveworked on scan-conversion, clipping,hidden-surface removal, and otherfunctions, such as antialiasing.3 Thegraphics hardware design discussedhere will significantly improve currentgraphics-rendering speeds. The exactimpact and value are hard to assess be-cause no hardware benchmarks arepossible at this time. More work re-mains to be done in lighting, texturemapping, and so on. Our workgroupat GMU has several students activelypursuing this design to obtain morecomprehensive data and results.

References1. J.X. Chen, X. Wang, and J.E. Bresenham,

“The Analysis and Statistics of Line Distribu-tion,” IEEE Computer Graphics & Applica-tions, vol. 22, no. 11, 2002, pp. 100–107.

2. J.X. Chen, Guide to Graphics Software Tools,Springer Verlag, 2003.

3. J.X. Chen and X. Wang, “Approximate LineScan-Conversion and Antialiasing,” ComputerGraphics Forum, vol. 18, no. 1, 1999, pp.69–78.

Jim X. Chen is an associate professor in the

Department of Computer Science at George

Mason University. He is the director of the

Graphics Lab at GMU and program cochair of

IEEE Virtual Reality 2003. His research inter-

ests include graphics, visualization, virtual re-

ality, networking, and simulation. He received

a PhD in computer science form the Univer-

sity of Central Florida. He is a member of the

IEEE Computer Society. Contact him at

George Mason Univ., Fairfax, VA 22030-4444;

[email protected];www.cs.gmuedu/~jchen.

Request a free trial today:

[email protected]

IEEEINFORMATIONTECHNOLOGYLIBRARY (ITeL)

IEEE Journals, Magazines, and Conference Proceedings onComputing, Communications,

Signal Processing, and Circuits and Systems

An ideal online collection forbusinesses and universities!

Submissions: Send two copies, one word-processed file and one PostScript file, of articles and proposals to Francis Sullivan, Editor inChief, CiSE, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720-1314; [email protected]. Submissions should not exceed 6,000 wordsand 10 references. All submissions are subject to editing for clarity, style, and space.

Editorial: Unless otherwise stated, bylined articles and departments, as well as product and service descriptions, reflect the author’sor firm’s opinion. Inclusion in CiSE does not necessarily constitute endorsement by the IEEE, the AIP, or the IEEE Computer Society.

Circulation: Computing in Science & Engineering (ISSN 1521-9615) is published bimonthly by the AIP and the IEEE ComputerSociety. IEEE Headquarters, Three Park Ave., 17th Floor, New York, NY 10016-5997; IEEE Computer Society Publications Office,10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1314, phone +1 714 821 8380; IEEE Computer SocietyHeadquarters, 1730 Massachusetts Ave. NW, Washington, DC 20036-1903; AIP Circulation and Fulfillment Department, 1NO1, 2Huntington Quadrangle, Melville, NY 11747-4502. Annual subscription rates for 2001: $40 for Computer Society members (printonly) and $52 for AIP member society members (print plus online). For more information on other subscription prices, seehttp://computer.org/subscribe or http://ojps.aip.org/cise/subscrib.html. Back issues cost $10 for members, $20 for nonmembers.This magazine is available on microfiche.

Postmaster: Send undelivered copies and address changes to Circulation Dept., Computing in Science & Engineering, PO Box 3014,Los Alamitos, CA 90720-1314. Periodicals postage paid at New York, NY, and at additional mailing offices. Canadian GST#125634188. Canada Post Publications Mail Agreement Number 0605298. Printed in the USA.

Copyright & reprint permission: Abstracting is permitted with credit to the source. Libraries are permitted to photocopybeyond the limits of US copyright law for private use of patrons those articles that carry a code at the bottom of the first page,provided the per-copy fee indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Dr., Danvers, MA01923. For other copying, reprint, or republication permission, write to Copyright and Permissions Dept., IEEE PublicationsAdministration, 445 Hoes Ln., PO Box 1331, Piscataway, NJ 08855-1331. Copyright © 2002 by the Institute of Electrical andElectronics Engineers Inc. All rights reserved.

boundary during the scan-conversionprocess. This method is relativelyslower than rejecting or accepting theatomic primitive as a whole, but it re-sults in a smooth clear-cut boundary.

T his is an interesting topic thatI’ve only been able to present

in an abbreviated form. So far, we haveworked on scan-conversion, clipping,hidden-surface removal, and otherfunctions, such as antialiasing.3 Thegraphics hardware design discussedhere will significantly improve currentgraphics-rendering speeds. The exactimpact and value are hard to assess be-cause no hardware benchmarks arepossible at this time. More work re-mains to be done in lighting, texturemapping, and so on. Our workgroupat GMU has several students activelypursuing this design to obtain morecomprehensive data and results.

References1. J.X. Chen, X. Wang, and J.E. Bresenham,

“The Analysis and Statistics of Line Distribu-tion,” IEEE Computer Graphics & Applica-tions, vol. 22, no. 11, 2002, pp. 100–107.

2. J.X. Chen, Guide to Graphics Software Tools,Springer Verlag, 2003.

3. J.X. Chen and X. Wang, “Approximate LineScan-Conversion and Antialiasing,” ComputerGraphics Forum, vol. 18, no. 1, 1999, pp.69–78.

Jim X. Chen is an associate professor in the

Department of Computer Science at George

Mason University. He is the director of the

Graphics Lab at GMU and program cochair of

IEEE Virtual Reality 2003. His research inter-

ests include graphics, visualization, virtual re-

ality, networking, and simulation. He received

a PhD in computer science form the Univer-

sity of Central Florida. He is a member of the

IEEE Computer Society. Contact him at

George Mason Univ., Fairfax, VA 22030-4444;

[email protected];www.cs.gmuedu/~jchen.

Request a free trial today:

[email protected]

IEEEINFORMATIONTECHNOLOGYLIBRARY (ITeL)

IEEE Journals, Magazines, and Conference Proceedings onComputing, Communications,

Signal Processing, and Circuits and Systems

An ideal online collection forbusinesses and universities!

Submissions: Send two copies, one word-processed file and one PostScript file, of articles and proposals to Francis Sullivan, Editor inChief, CiSE, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720-1314; [email protected]. Submissions should not exceed 6,000 wordsand 10 references. All submissions are subject to editing for clarity, style, and space.

Editorial: Unless otherwise stated, bylined articles and departments, as well as product and service descriptions, reflect the author’sor firm’s opinion. Inclusion in CiSE does not necessarily constitute endorsement by the IEEE, the AIP, or the IEEE Computer Society.

Circulation: Computing in Science & Engineering (ISSN 1521-9615) is published bimonthly by the AIP and the IEEE ComputerSociety. IEEE Headquarters, Three Park Ave., 17th Floor, New York, NY 10016-5997; IEEE Computer Society Publications Office,10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1314, phone +1 714 821 8380; IEEE Computer SocietyHeadquarters, 1730 Massachusetts Ave. NW, Washington, DC 20036-1903; AIP Circulation and Fulfillment Department, 1NO1, 2Huntington Quadrangle, Melville, NY 11747-4502. Annual subscription rates for 2001: $40 for Computer Society members (printonly) and $52 for AIP member society members (print plus online). For more information on other subscription prices, seehttp://computer.org/subscribe or http://ojps.aip.org/cise/subscrib.html. Back issues cost $10 for members, $20 for nonmembers.This magazine is available on microfiche.

Postmaster: Send undelivered copies and address changes to Circulation Dept., Computing in Science & Engineering, PO Box 3014,Los Alamitos, CA 90720-1314. Periodicals postage paid at New York, NY, and at additional mailing offices. Canadian GST#125634188. Canada Post Publications Mail Agreement Number 0605298. Printed in the USA.

Copyright & reprint permission: Abstracting is permitted with credit to the source. Libraries are permitted to photocopybeyond the limits of US copyright law for private use of patrons those articles that carry a code at the bottom of the first page,provided the per-copy fee indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Dr., Danvers, MA01923. For other copying, reprint, or republication permission, write to Copyright and Permissions Dept., IEEE PublicationsAdministration, 445 Hoes Ln., PO Box 1331, Piscataway, NJ 08855-1331. Copyright © 2002 by the Institute of Electrical andElectronics Engineers Inc. All rights reserved.