Computer Graphics and Geometric Modeling

GOSPR 5/5/2005 5:47 PM Page i

Max K. Agoston

Computer Graphics andGeometric ModelingImplementation and Algorithms

GOSPR 5/5/2005 5:47 PM Page iii

Max K. Agoston, MA, MS, PhDCupertino, CA 95014, USA

British Library Cataloguing in Publication DataAgoston, Max K.

Computer graphics and geometric modeling:implementation & algorithms1. Computer graphics 2. Geometry—Data processing 3. Computer-aided design4. Computer graphics—Mathematics I. Title006.6

ISBN 1852338180

Library of Congress Cataloging-in-Publication Data

Agoston, Max K.Computer graphics & geometric modeling/Max K. Agoston.

p. cm.Includes bibliographical references and index.Contents: Implementation & algorithmsISBN 1-85233-818-0 (v. 1 : alk. paper)1. Computer graphics. 2. Geometry—Data processing. 3. Mathematical models. 4. CAD/CAM

systems. I. Title.

T385.A395 2004006.6—dc22 2004049155

Apart from any fair dealing for the purposes of research or private study, or criticism or review, as per-mitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, storedor transmitted, in any form or by any means, with the prior permission in writing of the publishers, or inthe case of reprographic reproduction in accordance with the terms of licences issued by the CopyrightLicensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers.

ISBN 1-85233-818-0 Springer is part of Springer Science+Business Mediaspringeronline.com

© Springer-Verlag London Limited 2005Printed in the United States of America

The use of registered names, trademarks, etc. in this publication does not imply, even in the absence of aspecific statement, that such names are exempt from the relevant laws and regulations and therefore freefor general use.

The publisher makes no representation, express or implied, with regard to the accuracy of the informationcontained in this book and cannot accept any legal responsibility or liability for any errors or omissionsthat may be made.

Typesetting: SNP Best-set Typesetter Ltd., Hong Kong34/3830-543210 Printed on acid-free paper SPIN 10971451

GOSPR 5/5/2005 5:47 PM Page iv

This book and [AgoM05] grew out of notes used to teach various types of computergraphics courses over a period of about 20 years. Having retired after a lifetime ofteaching and research in mathematics and computer science, I finally had the time tofinish these books. The two books together present a comprehensive overview of com-puter graphics as seen in the context of geometric modeling and the mathematics thatis required to understand the material. Computer graphics itself is a multifacetedsubject, but it has grown up. It is no longer necessary that a book on graphics demon-strate the diversity of the subject with a long list of “fun” projects at the expense ofthe mathematics. From movies, television, and other areas of everyday life, readershave already seen what graphics is about and what it can do. It follows that one shouldbe able to present the geometric modeling aspect of the subject in a systematicfashion. Unfortunately, the sheer amount of material that I wanted to cover meantthat it had to be divided into two parts. This book contains the practical stuff anddescribes the various algorithms and implementation issues that one runs into whenwriting a geometric modeling program. The book [AgoM05] provides the mathemat-ical background for the underlying theory. Although each book can be read by itselfwithout reading the other, one will get the most benefit from them if they are read inparallel.

The intended audience of this book (and the combined two volumes especially) isquite broad. It can be used in a variety of computer graphics courses or by those whoare trying to learn about graphics and geometric modeling on their own. In particu-lar, it is for those who are getting involved in what is referred to as computer-aideddesign (CAD) or computer-aided geometric design (CAGD), but it is also for mathe-maticians who might want to use computers to study geometry and topology. Bothmodeling and rendering issues are covered, but the emphasis is on the former. Thebasic prerequisites are that the reader has had an upper division data structure course,minimally three semesters of calculus, and a course on linear algebra. An additionalcourse on advanced calculus and modern algebra would be ideal for some of the moreadvanced topics. On the companion CD there is a geometric modeling program (GM)that implements many of the algorithms discussed in the text and is intended toprovide a programming environment both for further experimentation and applica-tion development. Another program (SPACE) on the CD is an application that usessome of the more advanced geometric modeling concepts to display the intrinsic

Preface

GOSPR 5/5/2005 5:47 PM Page v

geometry of two- and three-dimensional manifolds. Both programs were written usingthe Microsoft Visual C++ compiler (and OpenGL) and run under Microsoft Windows98 or later. Their source code and documentation are included on the CD. The ReadMefile on the CD lists what all is on the CD and also contains instructions for how to usewhat is there.

As I began to develop this book on geometric modeling, one concern obviouslywas to do a good job in presenting a thorough overview of the practical side of thesubject, that is, the algorithms and their implementation details. However, there weretwo other goals that were important from the very beginning. One was to thoroughlyexplain the mathematics and the other, to make the material as self-contained as pos-sible. In other words, pretty much every technical term or concept that is used shouldbe defined and explained. The reason for putting all the computer graphics–relatedmaterial into one book and all the mathematics into the other rather than inter-weaving the material was to keep the structure of the implementation of a modelingprogram as clear as possible. Furthermore, by separating out the mathematics it iseasier for readers to skip those mathematical topics that they are already familiar withand concentrate on those with which they are not. In general, though, and in partic-ular as far as instructors using this book are concerned, the intent is that the mate-rial in the two books be covered in parallel. This is certainly how I always taught mycourses. An added motivation for the given division was that the applied part of geo-metric modeling was often a moving target because, largely due to improvements inhardware (faster CPUs, more memory, more hard disk space, better display devices),the way that one deals with it is changing and will continue to change in the future.This is in contrast to the supporting mathematics. There may be new mathematicsrelevant to computer graphics in the future but it will be a long time before the math-ematics I do discuss will lose its relevance. A lot of it, in fact, is only now starting to be used as hardware becomes capable of dealing with computationally expensivealgorithms.

One property that sets this book apart from others on geometric modeling is its breadth of coverage, but there is another. The combined books, this one and[AgoM05], differ from other books on computer graphics or geometric modeling inan important way. Some books concentrate on implementation and basically add therelevant mathematics by tossing in appropriate formulas or mathematical algorithms.Others concentrate on some of the mathematical aspects. I attempt to be as compre-hensive on both the implementation and theory side. In [AgoM05] I provide a com-plete reference for all the relevant mathematics, but not in a cookbook fashion. Afundamental guiding principle was to present the mathematics in such a way that thereader will see the motivation for it and understand it. I was aiming at those indi-viduals who will want to take the subject further in the future and this is not possi-ble without such understanding. Just learning a few formulas is not good enough. Ihave always been frustrated by books that throw the reader some formulas withoutexplaining them. Furthermore, the more mathematics that one knows, the less likelyit is that one will end up reinventing something. There are instances (such as in thecase of the term “geometric continuity”) where unfamiliarity with what was knowncaused the introduction of confusing or redundant terminology. The success or failureof the two books should be judged on how much understanding of the mathematicsand algorithms the reader gets. In the case of this book by itself, it is a question ofwhether or not the major topics were covered adequately. In any case, because I

vi Preface

GOSPR 5/5/2005 5:47 PM Page vi

emphasize understanding what is going on, there is a natural emphasis on theory andnot on tricks of the trade. The reader will also not find any beautiful glossy pictures.

Clearly, no one book can cover all that falls under the general heading of geo-metric modeling. As usual, the topics that are in fact covered and the degree to whichthey are covered reflect my own bias. In a large field, there are many special topicsand it should not be surprising that some are not discussed at all and others onlybriefly in an overview. On the other hand, one would expect to see a discussion ofprinciples and issues that are basic to the field as a whole. In that regard, I would liketo alert the reader to one topic, namely, the issue of robustness of algorithms and com-putations, that really is a central issue in geometric modeling, but is not dealt withas thoroughly as it should be, given its importance. The only excuse for this is that todo this topic justice would have entailed a much larger book. It is important thatreaders who want to do serious work in geometric modeling realize that they will haveto get more information elsewhere on this. The discussion in Section 5.10 is inade-quate (although I do devote the brief Chapter 18 to interval analysis). When it comesto the bibliography, as large as it is, it is also a victim of space constraints. In somecases I have tried to compensate for the lack of completeness by giving references tobooks or papers where additional references could be found.

Most of this book covers material that is not new, but a few algorithms have notappeared in print before. One is the approach to trimmed surfaces based on the Vatticlipping algorithm described in Section 14.4. Another is the result in Section 17.5about convex set intersections, which motivated the algorithm described in Section13.2. Another aspect of the book that should be noted is Chapter 16 and the SPACEprogram. Although the material on intrinsic geometry in Sections 16.3 and 16.4 didnot get developed as much as I would have liked, it is a start. The extensive materialon topology in [AgoM05], in particular algebraic and differential topology, has hereto-fore not been found in books on geometric modeling. Although this subject is slowlyentering the field, its coming has been slow. Probably the two main reasons for thisare that computers are only now getting to be powerful enough to be able to handlethe complicated computations and the material involves exceptionally advancedmathematics that even mathematics majors would normally not see until graduateschool.

Here is how the material in this book has been used successfully in teaching threedifferent types of semester courses on computer graphics in the Department of Math-ematics and Computer Science at San Jose State University. The courses were

(1) Introduction to Computer Graphics,(2) Computer Graphics Algorithms, and(3) Geometric Modeling.

The first two were upper-division undergraduate courses and the third was a gradu-ate course. The prerequisites for the introductory course were three semesters of calculus, linear algebra, and an upper division course in data structures. The only prerequisite to both the algorithm and geometric modeling course was the introduc-tory computer graphics course. Some of the material in the introductory course wasbriefly reviewed in the other two courses. The courses used material from the fol-lowing parts of this book and [AgoM05] (but the material was not necessarily dis-

Preface vii

GOSPR 5/5/2005 5:47 PM Page vii

cussed in the order listed, and listing a chapter or section in no way means that allof it was covered):

Introduction to Computer Graphics: Chapters 1–4, a quick overview of Chapters 5, 6, 11, 12, and a brief discussion of visible surface algorithms and shading from Chapters 7 and 10.

From [AgoM05]: Chapters 1–3.Computer Graphics Algorithms: Chapters 2–10, just enough of Chapter 12 to

have surfaces to render, Sections 21.6–21.8, and Chapter 22.

From [AgoM05]: Chapter 1 and Sections 4.5, 4.7, 8.1–8.5.

Geometric Modeling: Chapters 3–6, 11, 12, a sampling of topics from Chapters 13–15, and Sections 17.4–17.5.

From [AgoM05]: Review of parts of Chapters 1 and 2, Sections 4.2, 4.5, 4.7, Chapter 6, and Sections 8.1–8.5, 9.2–9.4, 9.9.

The numbering of items in this book uses the following format: x.y.z refers to itemnumber z in section y of chapter x. For example, Theorem 12.7.1 refers to the firstitem of type theorem, proposition, lemma, or example in Section 7 of Chapter 12.Algorithm 14.3.1 refers to the first algorithm in Section 3 of Chapter 14. Tables arenumbered like algorithms. Figures are numbered by chapter, so that Figure 14.7 refersto the seventh figure in Chapter 14. Exercises and programming projects at the endof chapters are numbered by section.

Finally, some comments on the language used in this book to describe algorithms.Even though the C/C++ language is the language of choice for most people writingcomputer graphics programs, with the exception of some initialization code found inSection 1.6, we have opted to use “the” more universal “standard” algorithmic lan-guage. The reason is that this book is mostly about concepts that are independent ofany particular programming language and low-level optimization issues that hinge onthe language being used do not play any role. Every reader with some general com-puter experience will understand the language used here (a detailed description of itssyntax can be found in Appendix B) and so there seemed to be little point to restrictthe audience to those familiar with C. Consider the following points:

(1) There is little difference between the code that is presented and what the corresponding C code would look like, so that any translation would be straightforward.

(2) The emphasis in the code and algorithms in this book is on clarity and thefact is that even in simple constructs like a for-loop or a case statement, C has morecomplicated syntax and uses more obscure terminology which would make it harderfor the non-C reader to understand. A certain universality would be lost with no realcorresponding gain. The efficiency advantage of C that is usually cited is only really

viii Preface

GOSPR 5/5/2005 5:47 PM Page viii

significant in a relatively small number of places. It would be relevant, for example,if one wanted to implement low level drawing primitives, but that is not what thisbook is about.

(3) C programmers who want to see C code can look at the GM and SPACE pro-grams, which are written in C++.

Cupertino, California Max K. Agoston

Preface ix

GOSPR 5/5/2005 5:47 PM Page ix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

I Basic Computer Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 The Basic Graphics Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Hardware Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Graphics Standards and Primitives . . . . . . . . . . . . . . . . . . . . . . . . . 101.5 From Window to Viewport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.6 Programming Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.7 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.8 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Raster Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Discrete Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 Border Following Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4 Fill Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5 Generating Discrete Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5.1 Digital Differential Analyzers . . . . . . . . . . . . . . . . . . . . . . . 362.5.2 The Bresenham Line-Drawing Algorithm . . . . . . . . . . . . . . 382.5.3 The Midpoint Line-Drawing Algorithm . . . . . . . . . . . . . . . . 40

2.6 The Aliasing Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.7 Halftoning, Thresholding, and Dithering . . . . . . . . . . . . . . . . . . . . . 482.8 Choosing the Coordinates of a Pixel . . . . . . . . . . . . . . . . . . . . . . . . 492.9 More Drawing Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.9.1 Scan Converting Polygons . . . . . . . . . . . . . . . . . . . . . . . . . 492.9.2 Drawing Circles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.9.3 Drawing Ellipses and Other Conics . . . . . . . . . . . . . . . . . . 57

2.10 Bit Map Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.11 2D Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Contents

GOSPR 5/5/2005 5:47 PM Page xi

2.12 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662.13 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3 Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.2 Line Clipping Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.2.1 Cohen-Sutherland Line Clipping . . . . . . . . . . . . . . . . . . . . . 713.2.2 Cyrus-Beck Line Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . 733.2.3 Liang-Barsky Line Clipping . . . . . . . . . . . . . . . . . . . . . . . . 773.2.4 Nicholl-Lee-Nicholl Line Clipping . . . . . . . . . . . . . . . . . . . . 81

3.3 Polygon Clipping Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.3.1 Sutherland-Hodgman Polygon Clipping . . . . . . . . . . . . . . . 843.3.2 Weiler Polygon Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.3.3 Liang-Barsky Polygon Clipping . . . . . . . . . . . . . . . . . . . . . . 863.3.4 Maillot Polygon Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . 893.3.5 Vatti Polygon Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983.3.6 Greiner-Hormann Polygon Clipping . . . . . . . . . . . . . . . . . . 106

3.4 Text Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103.6 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4 Transformations and the Graphics Pipeline . . . . . . . . . . . . . . . . . . . . . 1114.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114.2 From Shape to Camera Coordinates . . . . . . . . . . . . . . . . . . . . . . . . 1124.3 Vanishing Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174.4 Windows and Viewports Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.5 The Clip Coordinate System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224.6 Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254.7 Putting It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304.8 Stereo Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314.9 Parallel Projections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324.10 Homogeneous Coordinates: Pro and Con . . . . . . . . . . . . . . . . . . . . 1344.11 The Projections in OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.12 Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394.13 Robotics and Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.14 Quaternions and In-betweening . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464.15 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1494.16 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514.17 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5 Approaches to Geometric Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565.2 R-sets and Regularized Set Operators . . . . . . . . . . . . . . . . . . . . . . . 1585.3 Representation Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.3.1 Early Representation Schemes . . . . . . . . . . . . . . . . . . . . . . 164

xii Contents

GOSPR 5/5/2005 5:47 PM Page xii

Contents xiii

5.3.2 Boundary Representations . . . . . . . . . . . . . . . . . . . . . . . . . 1665.3.3 The CSG Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 1675.3.4 Euler Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715.3.5 Sweep Representations and Generative Modeling . . . . . . . . 1745.3.6 Parametric Representations . . . . . . . . . . . . . . . . . . . . . . . . 1785.3.7 Decomposition Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1785.3.8 Volume Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805.3.9 The Medial Axis Representation . . . . . . . . . . . . . . . . . . . . . 182

5.4 Modeling Natural Phenomena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1885.5 Physically Based Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1905.6 Parametric and Feature Based Modeling . . . . . . . . . . . . . . . . . . . . . 1925.7 Functions and Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1985.8 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

5.8.1 Data Structures for Boundary Representations . . . . . . . . . . 1995.8.2 Data Structures for Volume Modeling . . . . . . . . . . . . . . . . . 203

5.9 Converting Between Representations . . . . . . . . . . . . . . . . . . . . . . . 2055.10 Round-off Error and Robustness Issues . . . . . . . . . . . . . . . . . . . . . 2115.11 Algorithmic Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2155.12 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2205.13 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

6 Basic Geometric Modeling Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2276.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2276.2 Bounding Objects and Minimax Tests . . . . . . . . . . . . . . . . . . . . . . . 2276.3 Surrounding Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2326.4 Orientation Related Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2386.5 Simple Intersection Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2406.6 Distance Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2456.7 Area and Volume Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2496.8 Circle Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2526.9 Parametric or Implicit: Which Is Better? . . . . . . . . . . . . . . . . . . . . . 2586.10 Transforming Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2596.11 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2616.12 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

7 Visible Surface Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2647.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2647.2 Back Face Elimination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2677.3 The Schumacker List Priority Algorithm . . . . . . . . . . . . . . . . . . . . . 2687.4 Newell-Newell-Sancha Depth Sorting . . . . . . . . . . . . . . . . . . . . . . . 2697.5 The BSP Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2707.6 Warnock and Weiler-Atherton Area Subdivision . . . . . . . . . . . . . . . 2737.7 Z-buffer Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2757.8 The Watkins Scan Line Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 2787.9 Octree Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

GOSPR 5/5/2005 5:47 PM Page xiii

xiv Contents

7.10 Curved Surface Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2847.11 Adding Antialiasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2907.12 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2917.13 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

8 Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2948.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2948.2 What Is Color? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2948.3 Perceived Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2958.4 Colorimetry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2978.5 Color Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2998.6 Transforming Between Color Models . . . . . . . . . . . . . . . . . . . . . . . . 3038.7 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

9 Illumination and Shading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3089.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3089.2 Local Reflectance Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3109.3 Simple Approaches to Shading . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3169.4 Global Illumination Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

9.4.1 Shadows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3189.4.2 Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3209.4.3 Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3229.4.4 Radiosity Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

9.5 The Rendering Equation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3239.6 Texture and Texture Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3249.7 Environment Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3279.8 Bump Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3289.9 The Rendering Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3309.10 Selecting a Color Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3329.11 Programming Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3339.12 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

10 Rendering Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33710.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33710.2 Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

10.2.1 A Ray-Tracing Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 33810.2.2 Ray Intersection Formulas . . . . . . . . . . . . . . . . . . . . . . . . . 34410.2.3 Ray Tracing CSG objects . . . . . . . . . . . . . . . . . . . . . . . . . . 348

10.3 The Radiosity Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35010.3.1 Form Factors: The Hemicube Method . . . . . . . . . . . . . . . . 355

10.4 Volume Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35810.4.1 Discrete Three-Dimensional Lines . . . . . . . . . . . . . . . . . . . 36210.4.2 The Marching Cubes Algorithm . . . . . . . . . . . . . . . . . . . . . 365

10.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36910.6 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

GOSPR 5/5/2005 5:47 PM Page xiv

II Geometric Modeling Topics . . . . . . . . . . . . . . . . . . . . . . . . 371

11 Curves in Computer Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37311.1 Introduction to Curves and Surfaces . . . . . . . . . . . . . . . . . . . . . . . . 37411.2 Early Historical Developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

11.2.1 Lagrange Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37811.2.2 Hermite Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38111.2.3 Spline Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

11.3 Cubic Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39011.4 Bézier Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39611.5 B-Spline Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

11.5.1 The Standard B-Spline Curve Formulas . . . . . . . . . . . . . . . 40411.5.2 The Multiaffine Approach to B-Splines . . . . . . . . . . . . . . . . 41811.5.3 Rational B-spline Curves . . . . . . . . . . . . . . . . . . . . . . . . . . 43011.5.4 Efficient B-spline and NURBS Curve Algorithms . . . . . . . . 43611.5.5 B-Spline Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

11.6 Nonlinear Splines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44511.7 Superellipses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44811.8 Subdivision of Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44911.9 Composition of Curves and Geometric Continuity . . . . . . . . . . . . . . 45211.10 The Shape of a Curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45611.11 Hodographs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45911.12 Fairing Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46011.13 Parallel Transport Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46111.14 Recursive Subdivision Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46511.15 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46611.16 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46811.17 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

12 Surfaces in Computer Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47212.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47212.2 Surfaces of Revolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47412.3 Quadric Surfaces and Other Implicit Surfaces . . . . . . . . . . . . . . . . 48012.4 Ruled Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48212.5 Sweep Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48412.6 Bilinear Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48612.7 Coons Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48712.8 Tensor Product Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49512.9 The Bicubic Patch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49612.10 Bézier Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50012.11 Gregory Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50212.12 B-spline Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

12.12.1 The Basic B-spline Surface . . . . . . . . . . . . . . . . . . . . . . . . . 50412.12.2 Polynomial Surfaces and Multiaffine Maps . . . . . . . . . . . . . 50512.12.3 Triangular Bézier Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . 50912.12.4 Rational B-spline Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . 512

Contents xv

GOSPR 5/5/2005 5:47 PM Page xv

12.12.5 Efficient B-spline and NURBS Surface Algorithms . . . . . . . 51412.12.6 B-spline Interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

12.13 Cyclide Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51712.14 Subdivision of Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52112.15 Composite Surfaces and Geometric Continuity . . . . . . . . . . . . . . . . 52212.16 Fairing Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52512.17 Recursive Subdivision Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52612.18 Summary for Curves and Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . 53012.19 A Little Bit of History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53212.20 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53412.21 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536

13 Intersection Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53713.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53713.2 Convex Set Intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54013.3 Curve Intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

13.3.1 Ray-Curve Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54313.3.2 Curve-Curve Intersections . . . . . . . . . . . . . . . . . . . . . . . . . . 54513.3.3 A Curve Newton-Raphson Method . . . . . . . . . . . . . . . . . . . 54613.3.4 Curve Recursive Subdivision Methods . . . . . . . . . . . . . . . . 54713.3.5 Curve Algebraic Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 551

13.4 Special Surface Intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55213.4.1 Ray-Surface Intersections . . . . . . . . . . . . . . . . . . . . . . . . . . 55213.4.2 Curve-Surface Intersections . . . . . . . . . . . . . . . . . . . . . . . . 55213.4.3 Surface Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553

13.5 Surface-Surface Intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55713.5.1 Surface Lattice Evaluation Methods . . . . . . . . . . . . . . . . . . 55813.5.2 Surface Marching Methods . . . . . . . . . . . . . . . . . . . . . . . . . 55813.5.3 Surface Homotopy Method . . . . . . . . . . . . . . . . . . . . . . . . . 57013.5.4 Surface Recursive Subdivision Methods . . . . . . . . . . . . . . . 57213.5.5 Surface Algebraic Methods . . . . . . . . . . . . . . . . . . . . . . . . . 574

13.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57813.7 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

14 Global Geometric Modeling Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58214.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58214.2 Distance Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58214.3 Polygonizing Curves and Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 58714.4 Trimmed Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59814.5 Implicit Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614

14.5.1 Implicit Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61414.5.2 Implicit Surfaces and Quadrics . . . . . . . . . . . . . . . . . . . . . 622

14.6 Finding Contours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62414.7 Skinning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63014.8 Computing Arc Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63314.9 Offset Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638

14.9.1 Offset Curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63814.9.2 Offset Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

xvi Contents

GOSPR 5/5/2005 5:47 PM Page xvi

14.10 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64614.11 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64714.12 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

15 Local Geometric Modeling Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64915.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64915.2 Curvature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64915.3 Geodesics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652

15.3.1 Generating Smooth Geodesics . . . . . . . . . . . . . . . . . . . . . . 65215.3.2 Generating Discrete Geodesics . . . . . . . . . . . . . . . . . . . . . . 657

15.4 Filament Winding and Tape Laying . . . . . . . . . . . . . . . . . . . . . . . . . 66715.5 Dropping Curves on Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67015.6 Blending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67215.7 Programming Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

16 Intrinsic Geometric Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68416.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68416.2 Virtual Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68516.3 Geometrically Intelligent Modeling Systems . . . . . . . . . . . . . . . . . . 68716.4 Exploring Manifolds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68916.5 Where To From Here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

III More on Special Computer Graphics Topics . . . . . . . . . . . . 695

17 Computational Geometry Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69717.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69717.2 Range Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69717.3 Interval and Segment Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70317.4 Box Intersections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70917.5 Convex Set Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71117.6 Triangulating Polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71417.7 Voronoi Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72017.8 Delaunay Triangulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722

18 Interval Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72618.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72618.2 Basic Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72718.3 Inclusion Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73118.4 Constraint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73518.5 An Application: Implicit Curve Approximations . . . . . . . . . . . . . . . . 73818.6 Constrained Minimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74218.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74418.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744

19 The Finite Element Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74519.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74519.2 What Is It All About? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745

Contents xvii

GOSPR 5/5/2005 5:47 PM Page xvii

19.3 The Mathematics Behind FEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74719.4 An Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74919.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753

20 Quaternions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75520.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75520.2 Basic Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75520.3 Quaternions as Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . 76020.4 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

21 Digital Image Processing Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76721.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76721.2 The Ubiquitous Laplace Equation . . . . . . . . . . . . . . . . . . . . . . . . . . 76821.3 From Laplace to Fourier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77221.4 The Lp Function Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77321.5 Fourier Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77521.6 The Fourier Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78121.7 Convolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78621.8 Signal Processing Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78821.9 Wavelets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79221.10 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796

22 Chaos and Fractals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79722.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79722.2 Dynamical Systems and Chaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79722.3 Dimension Theory and Fractals . . . . . . . . . . . . . . . . . . . . . . . . . . . 80222.4 Iterated Function Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806

Appendix A: Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815

Appendix B: Abstract Program Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819

Appendix C: IGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822C.1 What Is IGES? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822C.2 A Sample IGES File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822C.3 The IGES Geometric Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827C.4 The IGES Nongeometric Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835Advanced Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835Algebraic Curves and Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835Algebraic Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836Algebraic Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836Analytic Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836Antialiasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836Blending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837

xviii Contents

GOSPR 5/5/2005 5:47 PM Page xviii

Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837Computational Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838Conics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839Constructive Solid Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839Contours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839Convex Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840Curvature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840Curve Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840Cyclides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841Differential Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841Digital Image Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841Engineering Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841Finite Element Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842Fourier Series and Transforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842Fractals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842General Computer Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Geodesics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Geometric Modeling Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843Geometric Modeling Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845Graphical User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848Graphics Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848Graphics Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848Hodographs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849Implicit Curves and Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849Intersection Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850Interval Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852Mathematics for Geometric Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852Medial Axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854Numerical Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854Offset Curves and Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855PC Oriented Computer Graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855Physically Based Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855Polygonization Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856Projective Geometry and Transformations . . . . . . . . . . . . . . . . . . . . . . . . . 856Quadrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856Quaternions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856Radiosity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857Raster Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858Real Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859Robotics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859Shading and Illumination (Early Work) . . . . . . . . . . . . . . . . . . . . . . . . . . 859Spatial Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860Splines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860Subdivision Curves and Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862Surfaces and Manifolds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862

Contents xix

GOSPR 5/5/2005 5:47 PM Page xix

Texture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863Trimmed Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863Virtual Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864Visible Surface Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865Volume Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867

Bibliographic Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896

Index of Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906

xx Contents

GOSPR 5/5/2005 5:47 PM Page xx

BASIC COMPUTERGRAPHICS

C H A P T E R 1

P A R T I

GOS01 5/5/2005 5:48 PM Page 1

C H A P T E R 1

Introduction

1.1 Overview

This book is about constructive geometry. Our object is to study geometry, all sorts ofgeometry, and also to present a setting in which to carry out this investigation on acomputer. The adjective “constructive” is intended to imply that we will not be satis-fied with an answer to a geometric problem unless we also are given a well-definedalgorithm for computing it. We need this if we are going to use a computer. However,even though our goal is a computational one, our journey will take us through somebeautiful areas of pure mathematics that will provide us with elegant solutions toproblems and give us new insights into the geometry of the world around us. A readerwho joins us in this journey and stays with us to the end will either have implementeda sophisticated geometric modeling program in the process or at least will know howto implement one.

Figure 1.1 shows the task before us at a very top level. We have a number of rep-resentation problems. Our starting point is the “real” world and its geometry, but theonly way to get our hands on that is to build a mathematical model. The standardapproach is to represent “real” objects as subsets of Euclidean space. Since higherdimensional objects are also interesting, we shall not restrict ourselves to subsets of3-space. On the other hand, we are not interested in studying all possible subsets. Inthis book, we concentrate on the class of objects called finite polyhedra. More exoticspaces such as fractals (the spaces one encounters when one is dealing with certainnatural phenomena) will only be covered briefly. They certainly are part of what weare calling geometric modeling, but including them would involve a large amount ofmathematics of a quite different flavor from that on which we wish to concentratehere. Next, after representing the world mathematically, we need to turn the (contin-uous) mathematical representations into finite or discrete representations to makethem accessible to computers. In fact, one usually also wants to display objects on amonitor or printer, so there are further steps that involve some other implementationand computation issues before we are done.

GOS01 5/5/2005 5:48 PM Page 3

As we look at the various representation problems shown in Figure 1.1, note that,although we have only mentioned objects so far, representations also need to repre-sent the maps (operations, etc.) between them because a good and complete modelof something needs to mimic everything in the original. In any case, objects and mapsgo hand in hand in mathematics. With every new class of objects it is fruitful to definethe naturally associated maps (take vector spaces and linear transformations, forexample).

To summarize, the emphasis of this book is on showing how to model finite poly-hedra and the invariants associated to them on a computer and we shall show howto set up a programming environment to facilitate this investigation. One has a fairlygood grip on the mathematics part of the representation pipeline, but less so on therest, at least in terms of having a well-defined theoretical approach. The fact is that,although computer graphics is an exciting, rapidly developing field that has come along way from the early days when people first tried to use computers for this, thingsare still being done in rather ad hoc ways. There is really no overall systematicapproach, only a lot of isolated, special results that, neat as some of the ideas andalgorithms may be, do not fit into any unifying picture. To put it another way, com-puter graphics today is an “art” and not a “science.” There have been a few attemptsto formalize the digital geometry aspect. See [Fium89] or [Herm98], for example. Onthe other hand, since the nonmathematical part of computer graphics depends on thecurrent technology used for the display medium (raster devices at present) and, ofcourse, the computer, and since this will continually evolve (with holographic displaysthe next dominant medium perhaps), the hardcore part of “computer” graphics maystay an art and never become a science.

All that we shall do in this chapter is get a few preliminaries out of the way. Weshall introduce some basic terminology and indicate some of the mathematics we shallneed. What little we have to say about hardware topics will be found in this chapter.The chapter ends with a bit of mathematics so that we can get started with somesimple two-dimensional (2d) graphics.

1.2 The Basic Graphics Pipeline

Any meaningful use of a computer to study geometry implies that we ultimately wantto display objects on a graphics device. Figure 1.2 shows some standard terminologyfor the first step of the three-dimensional (3d) graphics pipeline that takes us fromthe mathematical representation of an object in R3 to its image on the device. Objectsin the world are described by the user with respect to a world coordinate system. Theworld is then projected onto a view plane from some viewpoint that we shall think ofas the location of a camera or the eye. We have an associated view plane and camera

4 1 Introduction

real world objects and queries

Æmathematical objects and maps

Æ abstract

finiterepresentations

Æ actual implementations

Figure 1.1. The geometric modeling representation pipeline.

GOS01 5/5/2005 5:48 PM Page 4

coordinate system. Looking from the viewpoint along the positive z-axis of the cameracoordinate system specifies the view direction. A window in the view plane specifiesthe area of interest. The view volume or view pyramid is the infinite volume swept outby the rays starting at the viewpoint and passing through points of the window. Tolimit the output of objects one often uses a near (or front or hither) and far (or backor yon) clipping plane. The volume inside the view volume between these two planesis called the truncated view volume or truncated view pyramid. Only those parts ofobjects that lie in this volume and project into the window will be displayed. Findingthose parts of an object is referred to as clipping. In principle, the three coordinatesystems – the world, the camera, and the view plane coordinate system – could be dis-tinct. In practice, however, one assumes that the coordinate axes of the camera andview plane coordinate system are parallel and the z-axes are perpendicular to the viewplane. One also assumes that their x- and y-axes are parallel to the sides of the window.

The final step in mapping an object to a graphics device involves a map that trans-forms view plane coordinates to physical device coordinates. This is usually thoughtof as a two-stage process. First, an initial map transforms the window to a viewportthat is a subrectangle of a fixed rectangle called the logical screen, and a second mapthen transforms logical screen coordinates to physical device coordinates. See Figure1.3. Sometimes the logical screen is already defined in terms of these coordinates, sothat the second map is not needed. Other times, it is set equal to a standard fixed rec-tangle such as the unit square [0,1] ¥ [0,1], in which case we say that the viewport isspecified in normalized device coordinates (NDC). The basic 3d graphics pipeline cannow be summarized as shown in Figure 1.4. Chapter 4 will discuss it in great lengthand also fill in some missing details.

1.2 The Basic Graphics Pipeline 5

Figure 1.2. 3d graphics coordinate systems and terminology.

GOS01 5/5/2005 5:48 PM Page 5

The two-dimensional graphics pipeline is similar but much simpler. The window-to-device pipeline shown in Figure 1.3 stays the same, but Figures 1.2 and 1.4 getreplaced by Figures 1.5 and 1.6, respectively. We have a two-dimensional world coor-dinate system and a window whose edges are parallel to the coordinate axes. In thecase of the three-dimensional graphics pipeline, one usually assumes that the windowis of a fixed size centered on the z-axis of the camera coordinate system. This is ade-quate to achieve most views of the world. To move the viewpoint and change the viewdirection we simply change the camera coordinate system. Zooming in and out isaccomplished by moving the view plane further from or closer to the viewpoint. Inthe two-dimensional graphics case, on the other hand, one must allow the window tomove and change in size. We have to be able to move the window to see different partsof the two-dimensional world and we must be able to shrink or expand the size of thewindow to zoom.

One word of caution is in order. The distinction between “window” and “view-port” is often blurred and, sometimes, what should be called a viewport is called awindow. The terms used are not as important as the conceptual difference. One spec-ifies what one sees in user coordinates and the other specifies where one sees it. Thewindow, as defined above, refers to the former and the viewport, to the latter.

6 1 Introduction

Figure 1.3. The window-to-devicepipeline.

ÆÆ Æ Æ

Æ Æ Æ

transform into camera coordinates

clip against view volume

project toview plane

transform to viewport

Transform tophysical device coordinates

representation of 3d world objects

Figure 1.4. The basic 3d graphics pipeline.

GOS01 5/5/2005 5:48 PM Page 6

1.3 Hardware Basics

Although the goal of this book is to emphasize the abstract ideas in graphics, one doesneed to understand a few hardware basics because that is what drives the search forefficient algorithms for the implementation of low-level graphics primitives. The mostcommon display devices have been cathode ray tube (CRT) devices. Here an electronbeam traces out an image on a phosphor-coated screen. There have been differenttypes of CRTs, but since the early 1970s raster scan CRTs have been the most preva-lent graphics display devices. They are refresh CRTs because the electron beam is con-tinually rescanning the entire screen. The screen itself should be thought of as arectangular array of dots. The image that one sees depends on how those dots are lit.The beam starts at the top of the screen and proceeds down the screen from one scanline to the next until it gets to the bottom. It then jumps back to the top. See Figure1.7. The term “horizontal retrace” refers to the time the beam jumps from the end ofa line to the beginning of the next line and “vertical retrace” refers to the time it jumpsfrom the right bottom corner of the screen to the top left corner. These times, espe-cially the latter, were often used to write to the screen to avoid flicker and knowingthem was important to game developers who wanted to produce smooth animationeffects.

Another display technology that has been becoming more and more popular inrecent years is the liquid crystal display (LCD). Although there are different variants,LCDs are also raster scan devices because, for all practical purposes, they consist ofa rectangular array of dots that is refreshed one row at a time. The dots themselvesare the “liquid crystals,” which are usually organic compounds that consist of mole-cules that allow light to pass through them if they are aligned properly by means ofan applied voltage. The bottom line is that the liquid crystals can be individuallyswitched on or off. LCDs have a number of advantages over the raster scan CRTs. In

1.3 Hardware Basics 7

Figure 1.5. 2d graphics coordinate system andwindow.

ÆÆ Æ Æ clip against

windowtransform to viewport

transform tophysical device coordinates

representation of 2d world objects

Figure 1.6. The basic 2d graphics pipeline.

GOS01 5/5/2005 5:48 PM Page 7

particular, one does not have to worry about refresh rates or flicker and they are notas bulky.

The hardware assumption made in this book, one that should apply to two-dimen-sional displays in the foreseeable future, is that the reader is working on a raster scandevice. This assumption has an important consequence. Raster scan devices use arefresh buffer to specify which dots on the screen are to be lit and how. To get thepicture we want, we only have to set the values in that buffer correctly. Therefore, ourabstract representation problem specializes to representing subsets of Euclideanspace as (discrete) subsets of a rectangle in Z2. Less formally, we shall talk about rep-resenting objects in a “raster.” A raster refers to a two-dimensional rectangular arrayof pixels, where a pixel is an abbreviation for “picture element,” which could, in theory,be any value. In practice, a pixel is represented in computer memory by one or morebits that specify a color. A monochrome picture is where each pixel is represented byonly one bit. A row in a raster is called a scan line. If the raster has m columns andn rows, then we say that the resolution of the picture is m ¥ n.

The hardware graphics standards for computers have evolved over time. The stan-dards for the IBM personal computer (PC) are listed in chronological order below:

8 1 Introduction

Figure 1.7. The raster scan CRT.

Type Resolution Number of colors

CGA 640 ¥ 200 2 (black plus one other)Hercules 720 ¥ 348 2 (black and white)EGA 640 ¥ 350 16VGA 640 ¥ 480 16super VGA ≥800 ¥ 600 ≥256

For more details about these standards see [Wilt87] or [Ferr94].The refresh buffer of a raster scan device is usually called a frame buffer. In

general, the term “frame buffer” refers to an array of memory (separate from mainmemory) thought of as a two-dimensional array of pixels (a raster). Frame buffersserve two functions:

(1) as a place where the image is stored as it is computed(2) as a refresh buffer from which the image is displayed on a raster device

GOS01 5/5/2005 5:48 PM Page 8

A frame buffer is an interface between what are usually relatively slow graphics compu-tations and the high data rate video image display. In the typical personal computer theframe buffer is located on the graphics card that manages the video subsystem of thecomputer. It basically used to be not much more than some extra memory. For example,the table below describes the frame buffers used by the IBM PC family of computers:

1.3 Hardware Basics 9

Type Size of frame buffer Starting memory address (in hexadecimal)

CGA 16 K B800:0000Hercules 64 K B000:0000EGA,VGA 256 K for 16 colors accessed via a 64 K window starting at A000:0000super VGA 1 M or more accessed via a 64 K window starting at A000:0000

Over time the graphics subsystems of personal computers have become more power-ful, and the hardware is supporting more and more of the operations that one needsto perform in graphics, such as antialiasing (Section 2.6) and the bit map operationsdiscussed below and in Section 2.10. They also have additional buffers, such as a z-buffer (Chapter 7), texture buffers (Chapter 9), or stencil buffers (for masking opera-tions). This support only used to be found on high-end graphics workstations.

As indicated above, displaying objects on the computer screen involves writing tothe frame buffer. This amounts to storing values in memory. Ordinarily, a store opera-tion replaces the value that was there. In the case of frame buffers one has moreoptions. If A is a location in memory, then let [A] denote the content of A. Frame bufferstypically support store operations of the form (V op [A]) Æ [A], where V is a new valueand op is a binary logical operator that operates on a bit-by-bit basis. Typical binarylogical operations on bits are or, and, xor, and replace. The statement (V replace [A])Æ [A] corresponds to the standard store operation where the new value replaces theold one. When a frame buffer uses a store operation corresponding to an operator op,we shall say that it is in op mode. For example, we may talk about being in xor mode.

As a simple example of how having various modes for a frame buffer can be useful,consider how the standard quick and dirty method used to move a cursor around onthe screen without destroying the background uses the xor mode. The method relieson xor’s well-known property that

What this means is that if one xor’s the same value to a memory location twice in arow, then that memory location will hold its original value at the end. Now, a straight-forward way to move a cursor on the screen without erasing what is there would beto save the area first before writing the cursor to it and then restoring the old valueafter the cursor has moved. This would be very time consuming. There is a muchbetter way of using the xor mode. Assume that the cursor starts out at some initialposition defined by a variable oldA. Now switch into xor mode and repeat the fol-lowing three steps as often as desired:

Draw cursor at oldA (this will erase the cursor)Draw cursor at new position newAReplace the value in oldA with that in newA

b b a axor xor( ) = .

GOS01 5/5/2005 5:48 PM Page 9

Note that replace mode would cause this loop to erase everything in the cursor’s path and leave behind a trail of the cursor. There is one disadvantage with the xor operation, however, which may not make it a viable option in certain situa-tions. Although one can use it to move objects around on the screen without destroy-ing the background, the objects may change color. If, for example, one wants to movea red cursor and have it stay red, then this is not possible with xor mode because the cursor will assume different colors as it moves over differently colored areas of the screen. Therefore, if it is important that the cursor stay red, then there is no simple alternative to first saving the area to which one is writing and restoring itafterwards.

Because the availability of logical operators in store operations simplifies and speeds up many useful graphics operations, current graphics systems have built-in hardware support for them. We will have more to say about this in Section2.10.

We finish this section with two more terms one sees frequently in graphics. Scanconversion is the act of converting points, lines, other geometric figures, functions,etc., into the raster data structure used in frame buffers one scan line at a time. Aftera scene is modeled, it needs to be “rendered.” To render a scene means to constructan image on a display device that is visually satisfactory. What is “satisfactory”depends firstly on the device and its constraints and secondly on what one is tryingto do. To emphasize the position that rendering occupies in graphics, keep in mindthat the modeling or mathematical representation comes first and then the rendering.Any given model can have many different renderings. For example, a sphere can berendered in different colors. In trying to render scenes one runs into a number ofimportant problems: visible line or surface determination, illumination, texturing,transparency, etc. These will all be addressed in coming chapters.

1.4 Graphics Standards and Primitives

A person who wants to develop a graphics program has to learn how to access thegraphics capabilities of the system that he/she is working on. Unfortunately, there aremany graphics devices out there in the world. If one wanted a program to work withall those devices and if one had to program the hardware directly, then one couldeasily spend all of one’s time on very low-level code and never get to that in whichone is really interested. Therefore, let somebody else, say the manufacturer of thesystem or the compiler vendor, worry about the low-level stuff so that one can con-centrate on higher-level ideas. This is where software graphics standards come in.They are the interface between a high-level language and the low-level code that talksto the actual hardware. The interface is basically a specification of high-level graph-ics primitives. As long as one’s code calls only these primitives, a program will run onany system that is supported by that particular interface. In other words, standardsmake code portable by making it device independent.

Lots of different standards exist with some more sophisticated than others. Theearly DOS operating system standards, such as the Borland Graphics Interface (BGI),were fairly primitive. Any program in Borland PASCAL or C/C++ that used the BorlandPASCAL or C/C++ graphics primitives was guaranteed to run under DOS on most of

10 1 Introduction

GOS01 5/5/2005 5:48 PM Page 10

the IBM PC–compatible computers. The same was true of the corresponding inter-face found in the Microsoft compilers. A number of much more sophisticated stan-dards were developed over the years such as

Core (The 3d Core Graphics System): specified by ACM SIGGRAPH committeesin 1977 and 1979 ([GSPC77] and [GSPC79])

GKS (Graphics Kernel System): specified by various national and internationalcommittees in the 1980’s with a 3d version becoming a standard in 1988([ANSI85], [ISO 88], [EnKP84], [BDDH95])

PHIGS (Programmer’s Hierarchical Interactive Graphics System): a more complexstandard than GKS, which was specified by ANSI (the American NationalStandards Institute) in 1988 ([ANSI88] and [VanD88])

See [Cars98] for a brief history. Two more recent standards are

OpenGL: see [WNDS99], [KemF97], [WriS00]DirectX: see [Glid97], [BarD98], [Timm96]

The rise in the popularity of the Microsoft Windows operating system meant thatits application programming interface (API) became a driving force for standards forthat system. At first there was only the basic Windows graphics device interface (GDI).This made writing graphics programs hardware independent, but at the expense ofspeed. The result was that developers, especially those involved in writing games,stayed with DOS, which allowed programmer to go directly to the hardware andsqueeze out the last ounce of speed essential for games. To attract developers toWindows, Microsoft next came out with WinG, which provided a few low-level bitmapfunctions that did speed up basic graphics operations substantially, but it was notenough. Microsoft’s graphics standard successors to WinG were DirectDraw andDirect3D, which were part of the DirectX API that was intended for multimedia appli-cations. DirectDraw provided two-dimensional graphics primitives. Direct3D was the three-dimensional counterpart. Although these allowed for high-performance graphics under Windows, DirectDraw and Direct3D were low level. A competing and higher-level graphics API is OpenGL, a graphics standard originally developed by Silicon Graphics, Inc., for its graphics workstations. Good implementations ofOpenGL for Windows are built on DirectX drivers. Although native DirectX code iscurrently faster, the advantage of OpenGL is that it is available on many other com-puter and operating system platforms, a plus for Internet applications. The companionprograms for this book, GM and SPACE, use OpenGL.

Having just praised standards, we also need to point out what has traditionallybeen their downside. If one uses a standard, then one must be willing to put up withextra overhead in the code. Furthermore, because standards are device independent,they, by definition, usually do not take advantage of any special features that a par-ticular piece of hardware may have. What this means is that programs that use themare sometimes much slower on a particular machine than a program that accesses itshardware features directly. Software developers have often been forced to choosebetween device independence and speed in those cases where speed is critical. For-tunately, with DirectX and OpenGL the situation has much improved and this is nolonger a serious problem.

1.4 Graphics Standards and Primitives 11

GOS01 5/5/2005 5:48 PM Page 11

1.5 From Window to Viewport

One of the first bits of mathematics one runs into in a graphics program is the trans-formation from the window to the viewport. Both the window and viewport are rep-resentable as rectangles in the plane whose sides are parallel to the coordinate axes.What we are looking for is a simple map from one of these rectangles to another. Intuitively, all this amounts to is a change of scale.

The standard representation for our rectangles is as products of intervals in theform [a,b] ¥ [c,d]. Normally, the implied assumption in the representation of an inter-val like [a,b] is that a £ b; however, in our current context where we will be interestedin maps from one interval to another, we do not require that. It will be useful to allowa > b. Returning to our discussion of windows and viewport, if one uses normalizeddevice coordinates, the viewport is a subrectangle of [0,1] ¥ [0,1]. If one considers theviewport as a rectangle in the raster, then it has the form [m1,m2] ¥ [n1,n2], where miand ni are integers. There is one caveat, however. The (0,0) position in the raster hastraditionally been associated to the top left-hand corner on the screen. That means thatthe y-axis has to be inverted because users always think of that axis as going up, notdown. In other words, if, say, the resolution is 800 ¥ 600 and the viewport is the entirescreen, then the viewport should be represented by the rectangle [0,799] ¥ [599,0].

Mathematically then, the search for the window-to-viewport transformation boilsdown to the following: If W = [wa,wb] ¥ [wc,wd] and V = [va,vb] ¥ [vc,vd] are the rec-tangles that represent the window W and viewport V, respectively, then we want amap T: W Æ V of the form

where each Ti is linear. In other words, we have two one-dimensional problems of theform:

Given intervals [a,b] and [c,d], find the linear map S: [a,b] Æ [c,d] with S(a) = c and S(b) = d.

If S(x) = ax + b, then the stated boundary conditions for S lead to two equations intwo unknowns a and b, which are easily solved. We get that

The second form of the answer says that we send x to that point in [c,d], which is thesame percentage of the way from c to d as x is from a to b. If one remembers thatintuitive fact then one has no need to solve equations because the answer is obvious.At any rate, we now have the following solution for T:

T x yw w

v v x w v w vw w

v v y w v w vb a

b a b a a bd c

d c d c c d, , .( ) = --( ) + -( )( )ÊË -

-( ) + -( )( )̂̄1 1

S xd cb a

xbc adb a

cx ab a

d c

( ) = --

+--

= +--

-( ).

T x y T x T y, , ,( ) = ( ) ( )( )1 2

12 1 Introduction

GOS01 5/5/2005 5:48 PM Page 12

Later on in Chapter 4 we shall derive a more general window-to-viewport transfor-mation, but what we have now is good enough to do some simple two-dimensionalgraphics programming.

1.6 Programming Notes

In the early years of the IBM PC and DOS and after there were some programminglanguages such as PASCAL or C that had some basic graphics primitives built into thelanguage, it was fairly easy to describe what had to be done to write a graphicsprogram. It was a three-stage process. First, every such program had to enter “graph-ics mode” when it started, then it could do all the graphics that it wanted, and finallyit had to leave graphics mode at the end and restore whatever mode the system wasin before the program started. Life has gotten much more complicated now that weare in an age of graphical user interfaces (GUIs) and the Microsoft Windows operat-ing system. Describing how one programs the graphics API for Microsoft Windowswould entail writing another book. However, we do want to give the reader a flavorof what is involved. To that end we present and discuss our only piece of low-levelgraphics code in this book. It shows how one would have used BGI code for the DOSoperating system.

As we just mentioned, the first thing that needed to be done in any graphicsprogram was to initialize both the hardware and certain global variables describingthis hardware to the program. Program 1.6.1 shows a very basic sample BGI C pro-cedure, “InitializeGraphics,” which did this. The BGI procedure “initgraph” did theinitialization and returned the information about the hardware in use in its parame-ters “graphDriver” and “graphMode.” The third parameter to the procedure was a DOSpath name to a directory where the BGI drivers were located. An empty string meantthat they were in the current directory. The function “graphresult” returned any errorthat might have occurred and prevented the graphics system from being initialized.A typical error was caused by the fact that the BGI driver was not located in thecurrent directory. The BGI drivers were files that came with the Borland program-ming languages. Each contained hardware-specific code for the basic graphics prim-itives and the one that matched one’s hardware got linked into one’s program.

After the graphics mode was initialized correctly, we then stored some useful constants in global variables. The functions “getmaxx” and “getmaxy” returned themaximum resolution of the screen in pixels in the horizontal and vertical direction,respectively. The “textheight” and “textwidth” functions returned the height and widthof characters which one needs to determine the space required for text.

The “atexit” procedure passed the name of a procedure to call when the programwas done and was about to return to DOS. We have passed the name of the “MyEx-itProc” procedure that calls the “closegraph” procedure. The latter switches fromgraphics mode back to the standard 25 line and 80 column text mode (or whatevermode the system was in before the program was called). Without the call to the “close-graph” procedure the system would have been left in graphics mode with a messed-up screen and would probably have had to be rebooted.

Assuming that the “InitializeGraphics” procedure executed without problems, onewould be in graphics mode and be presented with a blank screen. As indicated earlier,

1.6 Programming Notes 13

GOS01 5/5/2005 5:48 PM Page 13

doing a similar initialization for Microsoft Windows is much more complicated. Thereason is that the user’s program is now initializing one of potentially many windowson the screen. Under DOS basically only one window was initialized, namely, thewhole screen. If a program wanted to deal with multiple windows, it would have todo that completely by itself. In other words, with Microsoft Windows we have a morecomplicated initialization procedure but we gain functionality. If one is using OpenGLor DirectX, then actually two initializations are required. After initializing the nativeWindows GDI, so that one can run the program in a standard window on the screen

14 1 Introduction

/* Global variables */int graphDriver, graphMode, /* After call to InitGraph these variables specify the

current hardware */numColors, /* maximum number of colors */scrnXmax, scrnYmax /* screen resolution */txtHeight, txtWidth; /* the height and width in pixels of a character in the

current font */

void MyExitProc (void){ closegraph (); /* Shut down the graphics system */ }

void InitializeGraphics (void){ int errorCode;

graphDriver = DETECT; /* DETECT is a BGI constant */ initgraph (&graphDriver,&graphMode,""); errorCode = graphresult ();

if ( errorCode != grOk ) /* grOk is a BGI constant */ { /* Error occurred during initialization */ printf (" Graphics system error: %s\n",grapherrormsg (errorCode)); exit (1); }

atexit (MyExitProc); /* so that we do closegraph when exiting */

numColors = getmaxcolor () + 1; scrnXmax = getmaxx (); scrnYmax = getmaxy (); txtHeight = textheight ("A"); txtWidth = textwidth ("A");

}

Program 1.6.1. Code for initializing DOS graphics mode.

GOS01 5/5/2005 5:48 PM Page 14

and use basic windowing operations, one has to initialize OpenGL and DirectX in aseparate step.

After a program has initialized the graphics hardware, the next step is to decidehow to lay out the screen. Where should graphics output go? Where to put the menus?What about an area for getting feedback from the user and printing system–relatedmessages? Books have been written on what makes for a good graphical user inter-face. See [Pedd92] for example. Microsoft has its own recommendations for programsthat run in its Windows environment. See [Micr94].

One thing is clear though about today’s GUIs. They take an awful lot of code andtime to develop. Even if one does not start from scratch and one uses the typical APIsone gets when developing for an environment like Windows, it still requires quite abit of understanding about the underlying architecture to use them effectively. Forthat reason, when this author has taught graphics classes he always, since the daysof DOS, provided the students with a program similar to the current GM programthat can be found on the accompanying CD. Its interface, described in the documentGmGUI which is also on the CD, allowed both mouse and keyboard input and madeit easy for students to add menus. In this way the students did not have to spend anytime developing this interface and could concentrate on implementing the variousalgorithms described in the book. The current Windows version of GM is also suchthat students do not need to have any prior knowledge of Windows or C++. (They obvi-ously do have to know how to program in C.) A couple of lectures at the beginningof the semester and another one or two later on to describe some additional featureswas all that was necessary. Of course, if one wants to make use of OpenGL, then thistakes extra time.

The GM program already comes with quite a bit of functionality built into it. Thismeans that some of the programming projects at the end of the chapters in this book,in particular some of the basic ones in the early chapters such as this one, have alreadybeen implemented either implicitly or explicitly. Read