INFORMATION TO USERS
This manuscript has been reproduced from the microfilm master. UMI films the text directly firom the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter fiice, while others may be fi*om any type of computer printer.
The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandard margins, and improper alignment can adversely affect reproduction.
In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion.
Oversize materials (e.g., nuq)s, drawings, charts) are reproduced by sectioning the original, beginning at the upper 1^-hand comer and continuing fi’om left to right in equal sections with small overlaps. Each original is also photographed in one exposure and is included in reduced form at the back of the book.
Photographs included in the original manuscript have been reproduced xerographically in this copy. Higher quality 6” x 9” black and white photographic prints are available for any photographs or illustrations appearing in this copy fi>r an additional charge. Contact UMI directly to order. UMI A Bell & Howell Infimnation Company 300 North Zeeb Road, Ann Arbor MI 48106-1346 USA 313/761-4700 800/521-0600
Encapsulated Models: Procedural Representations for Computer Animation
DISSERTATION
Presented in Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the
Graduate School of The Ohio State University
By
Stephen Forrest May, B.S., M.S.
*****
The Ohio State University
1998
Dissertation Committee: Approved by
Prof. Wayne E. Carlson, Adviser Prof. Richard E. Parent Adviser Prof. Neelam Soundarajan Department of Computer and Prof. Charles A. Csuri Information Science UMI Number: 9822347
UMI Microfonn 9822347 Copyright 1998, by UMI Company. All rights reserved.
This microform edition is protected against unauthorized copying under Title 17, United States Code.
UMI 300 North Zeeb Road Ann Arbor, MI 48103 © Copyright by
Stephen Forrest May
1998 ABSTRACT
This research defines the term “encapsulated model” or “emodel.” An encapsulated model is an animated object containing an integrated set of dynamic attributes — e.g., shape, motion, materials (surface properties), light sources, cameras, user interfaces, sound
— represented by a procedural data format (i.e., a program written in a procedural anima tion language).
A set of properties that characterizes encapsulated models is presented. From these properties, a set of requirements for an appropriate procedural animation language is de rived. Chief among these requirements is the requirement for mechanisms that permit interactive manipulation of the procedural specification of an emodel. To satisfy this re quirement, a new programming language mechanism called “articulation functions” (or
“afuncs”) is proposed.
To demonstrate the practical application of the concepts in this research, a prototype procedural animation language, called AL, was developed. The AL language incorporates the best features of previous animation languages and includes several new features in cluding the articulation function mechanism. The AL software environment includes an
AL language interpreter and graphical user interface tools for interactive manipulation of encapsulated models via articulation functions.
11 The results of this research are given in the form of working examples of encapsulated models that can be manipulated in real-time using current workstation technology. These examples demonstrate that articulation functions are a more powerful and general mech anism for interactive animation and manipulation than previously developed mechanisms.
Further, these examples illustrate the benefits of encapsulated models over existing, static data formats. In particular, emodels are shown as an enabling technology for the (possibly commercial) exchange of models that are parameterized (i.e., reusable), have high-level interactive controls, and have self-contained, integrated components such as animation and modeling. These traits potentially lead to reduced costs in the production of photorealistic computer animation.
m To my loving and devoted wife
Gwen and my supportive and inspiring parents.
Bob and Mary.
IV ACKNOWLEDGMENTS
This dissertation was possible only through the support and inspiration of many family members, friends, and colleagues. I owe a great deal to so many. These acknowledgment cannot fully express my indebtedness.
I would like to thank my adviser Wayne for supporting this research and for being such a great role model — both as a scholar and as a person. I would like to thank Chuck
Csuri. It is because I read an article about Chuck and Ohio State in 1984 that I decided that computer graphics was my calling and that Ohio State was where I had to go. Over the years. Chuck has become a very good friend and mentor and has taught me many things including a deep insight into the relationship between science and art.
I am in debt to Flip Phillips, Tom Linehan, and the others at CGRG who encouraged me to come to Ohio State. Flip named the “AL” language and inspired me to work in this area after his return to Ohio State from Fixar. Without his insights, this work would not have been possible. I am thankful to Don Stredney who, when I was a very poor grad student, offered me a research assistantship to do “medical brain imaging” which not only allowed me to eat but also introduced me to the ACCAD environment.
I would like to thank the other members of my committee — Neelam and Rick. Neelam has been a great adviser and has advised me since I was an undergraduate which makes it at least 10 years. Rick and a number of long since departed graduate students, including Con O’Connell, Hal McMillan, and Mike Fortin, inspired me to continue my graduate work and
become a Ph.D. student and taught me how to conduct scholarly activities while playing
pool.
I would like to thank all of the staff at ACCAD and the CIS department including
Aline, Barb, Bob, Chad, Chris, Deanna, Dennis, Donna, Elaine, Elizabeth, Phil, Marty,
Midori, Ruedy, Tom, Viki, and especially the three amigos, Pete, Steve and Matt. I
would like to thank the graduate students at CIS and ACCAD ^— I learned something
from each one of them and many were my students too — Agata, Alison, Andrew S., An
drew B., Beth, Bill, Brad, Bren, Carol, Cemil, Chitra, Dan, David E., Dave M., Dave R.,
Derek, Ed, Erika, Ferdi, Gigi, Hae-jeon, Heath, Henry, Janet, Jean, Jim, Joe, John, Karan,
Kevin G., Kevin R., Kevin S., Kirk, Lawson, Leslie, Mark, Marla, Meg, Melissa, Miho,
Moon, Moose, Muqueem, Nathan, Nathania, Neal, Pete, Paul, Paolo, Raghu, Reddy, Rina,
Rhonda, Roberta, Saty, Scott K., Scott G., Sara, Terry, Tim, Todd, Tonya, Torsten, Traci,
Yina, and Zil. In particular, I want to thank Lawson Wade for implementing the “alarm
clock” emodel and Melissa Kupper for working with me on the “chandelier” emodel. 1
would also like to recognize my dear friend and colleague, Ferdi Scheepers. Ferdi was
always there for me as a sounding board for new ideas, to help work out math equations, to
implement software, and to coauthor papers.
Finally, 1 would like to thank my wife Gwen, my family, and our friends for their unwavering support. In the end, I did it for them.
VI VITA
February 15, 1968 ...... Bom - Sarasota, Florida
1990 ...... B.S. Computer and Information Science The Ohio State University Columbus, Ohio 1991-1992 ...... Graduate Research Associate, ACCAD The Ohio State University Columbus, Ohio 1992 ...... M.S. Computer and Information Science The Ohio State University Columbus, Ohio 1992-present ...... Graphics Research Specialist, ACCAD The Ohio State University Columbus, Ohio
PUBLICATIONS
Ferdi Scheepers, Richard E. Parent, Wayne E. Carlson, and Stephen F. May. Anatomy- based modeling of the human musculature. In Turner Whitted, editor, SIGGRAPH 97 Conference Proceedings, Annual Conference Series. ACM SIGGRAPH, Addison Wesley Publishing Company, August 1997.
David Y. Y. Yun, Hong-Mei Chen Garcia, Seong K. Mun, James E. Rogers, Walid Thome, Wayne E. Carlson, Stephen F. May, and Roni Yagel. Three dimensional volume visual ization in remote radiation treatment planning. In IS&T/SPIE Symposium on Electronic Imaging Science & Technology Proceedings, volume 2656, January 1996.
vu Alan Paeth, Ferdi Scheepers, and Stephen R May. A survey of extended graphics libraries. In Alan Paeth, editor, Graphics Gems V. AP Professional, 1995.
Wayne E. Carlson, Roni Yagel, Stephen F. May, Stephen Spencer, Donald L. Stredney, and Charles Bender. Remote diagnosis using volume visualization of satellite transmitted medical data. Ohio Journal Of Science, May 1994.
Scott E. Lukas, M. Sholar, Donald L. Stredney, Michael W. Torello, Stephen F. May, and Ferdi Scheepers. Apparent source of EEG sleep spindles and K-Complexes: Correlations with anatomical sites identified using magnetic resonance imaging. In Sleep Research Society, American Sleep Disorders Association APSS 8th Annual Meeting, June 1994.
Scott E. Lukas, M. Sholar, Donald L. Stredney, Michael W. Torello, Stephen F. May, and Ferdi Scheepers. Integration of P300 evoked potentials with magnetic resonance images (MRI) to identify sources in human brain. Society of Neuroscience, November 1993.
Donald L. Stredney, Roni Yagel, Stephen F. May, and Michael W. Torello. Supercomputer assisted brain visualization with an extended ray tracer. In Computer Graphics ( 1992 Workshop on Volume Visualization), pages 33-38, October 1992.
FIELDS OF STUDY
Major Field: Computer and Information Science
Studies in: Computer Graphics Prof. Wayne E. Carlson Programming Languages Prof. Neelam Soundarajan Distributed Systems Prof. Mukesh Singhal
viu TABLE OF CONTENTS
Page
A bstract...... ü
Dedication ...... iv
Acknowledgments ...... v
V ita ...... vii
List of T a b le s ...... xiv
List of Figures ...... xvi
Chapters:
I. Introduction ...... 1
1.1 Background ...... 3 1.1.1 Representation of 3D Graphical Objects ...... 4 1.1.1.1 Raster Representations ...... 4 1.1.1.2 Geometric Representations ...... 7 1.1.1.3 Procedural Representations ...... 12 1.1.2 Historical Development of Computer Animation Systems .... 16 1.1.2.1 Scripting S ystem s ...... 17 1.1.2.2 Interactive S y stem s ...... 19 1.1.2.3 Systems That Combine Scripting and Interaction ...... 20 1.2 Motivation ...... 22 1.3 Thesis...... 25 1.4 Document Overview ...... 26 1.4.1 AL System O verview...... 27
ix 1.4.2 Glossary of Unique Term s ...... 30 1.4.3 Type-face Conventions ...... 31
2. Procedural Languages for Computer Animation ...... 32
2.1 Early Procedural Languages ...... 32 2.1.1 EU L ER -G ...... 32 2.1.2 GRASS...... 33 2.1.3 An Extended Algol-60 ...... 34 2.1.4 D A LI...... 35 2.1.5 PICTUREBALM ...... 35 2.2 AS A S ...... 36 2.2.1 A c to rs ...... 37 2.2.2 N ew tons ...... 38 2.2.3 Message Passing ...... 39 2.3 CINEMIRA...... 39 2.4 E M ...... 40 2.5 M e n v ...... 43 2.5.1 M L ...... 43 2.5.2 Articulated Variables ...... 44 2.6 Other Recent Procedural Animation Languages ...... 45 2.6.1 M M L...... 45 2.6.2 G EN M O D ...... 46 2.6.3 W avesworld ...... 46 2.7 Conclusion ...... 47
3. Articulation Functions ...... 48
3.1 Preliminary Concepts ...... 50 3.1.1 The World M o d e l ...... 50 3.1.2 Global T im e ...... 52 3.1.3 Variable B indings ...... 52 3.2 Basic Syntax and U sa g e ...... 53 3.2.1 Building Models ...... 53 3.2.2 Using Articulation Functions ...... 55 3.2.3 High-level Control ...... 57 3.2.4 Shape M odeling ...... 58 3.3 Properties of Articulation Functions ...... 59 3.3.1 External Binding ...... 60 3.3.1.1 Interactive Manipulation...... 60 3.3.1.2 Instances of Anim ation...... 62 3.3.2 Lexical S c o p e ...... 62 3.3.3 Naming ...... 63 3.3.4 T y p ing ...... 64 3.3.5 Instance Param eters ...... 65 3.4 The Exposure S h e e t...... 65 3.5 Articulation Function C la sse s ...... 67 3.5.1 Channels...... 69 3.5.1.1 Declaration ...... 70 3.5.1.2 U s a g e ...... 71 3.5.1.3 Computation ...... 72 3.5.1.4 Interactive Tool: C h a n t ...... 74 3.5.2 Gcurves ...... 75 3.5.2.1 Declaration ...... 77 3.5.2.2 Usage ...... 77 3.5.2.3 Computation ...... 78 3.5.2.4 Interactive Tool: Forge ...... 79 3.5.3 R asters...... 79 3.5.3.1 Declaration ...... 80 3.5.3.2 Usage ...... 80 3.5.3.3 Computation ...... 81 3.5.3.4 Interactive Tool: R a sp ...... 81 3.6 Implementation ...... 82 3.6.1 A Word About Object-Oriented Scheme Programming ...... 82 3.6.2 Definition and Evaluation of the World M o d e l ...... 83 3.6.3 World Model Definition ...... 84 3.6.3.1 The Retained World M o d e l ...... 85 3.6.3.2 The Exposure Sheet Data Structure...... 87 3.6.3.3 Exposure Sheet Construction ...... 88 3.6.4 World Model Evaluation ...... 90 3.6.4.1 Display...... 90 3.6.4.2 Model M a sk ...... 90 3.6.5 Articulation Function C lasses ...... 91 3.6.5.1 Events — The AL Callback O bject...... 93 3.6.5.2 Articulation Function Abstract Base C la s s ...... 94 3.7 Sum m ary ...... 96
4. Encapsulated M odels ...... 97
4.1 Properties of Encapsulated Models ...... 100 4.1.1 Procedural Specification ...... 100 4.1.2 Parameterization ...... 102 4.1.2.1 Model vs. Animation Parameters ...... 103 4.1.2.2 Simulation ...... 106
x i 4.1.3 Replication ...... 106 4.1.4 Precision ...... 108 4.1.5 Continuous Representation (Anti-aliasing) ...... 110 4.1.6 Compression and Database Amplification ...... 114 4.1.7 Composition and High-level C o n tro l ...... 115 4.1.8 Simulation ...... 117 4.1.9 Self-contained Lighting and Shading E ffects ...... 118 4.1.10 Sound E ffe c ts ...... 119 4.1.11 Summary...... 120 4.2 Examples of Encapsulated Models ...... 120 4.2.1 Cyclorama ...... 121 4.2.2 S un lig h t ...... 124 4.2.3 C am eras...... 127 4.2.3.1 Basic Camera Icon ...... 128 4.2.3.2 Basic Camera Model ...... 129 4.2.4 Vertigo C a m e ra ...... 131 4.2.5 Alarm C lock ...... 135 4.2.6 Chandelier...... 136 4.2.7 Island ...... 139
5. AL: A Prototype Language for Encapsulated M o d e ls ...... 143
5.1 Design G oals ...... 144 5.2 Scheme as a Base Language ...... 145 5.3 Fundamental Concepts ...... 147 5.3.1 Geometric Operations and Geometric Primitives ...... 147 5.3.2 World ...... 148 5.3.3 Graphics Data Types...... 149 5.3.3.1 Graphics Vectors...... 151 5.3.3.2 Transformation Matrices ...... 151 5.3.4 Parameter Lists...... 152 5.4 Geometric Primitives ...... 154 5.4.1 Q uadrics ...... 154 5.4.2 Surface P a tc h e s...... 155 5.4.3 Polygons ...... 157 5.4.4 Rendering Parameters ...... 158 5.5 Geometric O perations ...... 159 5.5.1 Transformations ...... 159 5.5.2 Attributes...... 160 5.5.3 Separators ...... 162 5.5.4 C am eras...... 164 5.5.5 C S G ...... 164
x ii 5.6 Rendering ...... 165 5.7 Implementation ...... 167
6. Conclusion ...... 170
6.1 Summary...... 170 6.2 Future Research ...... 172
Appendices:
A. Encapsulated Model Code Listings ...... 176
A.1 Sunlight Computations ...... 176 A.2 Alarm Clock Model ...... 177 A.3 Chandelier Model ...... 181 A.3.1 Surface of Revolution ...... 183 A.3.2 Sample Exposure Sheet F ile ...... 184
Bibliography ...... 186
X lll LIST OF TABLES
Table Page
2.1 Relation of previous work to this research ...... 47
3.1 Channel parameters...... 70
3.2 Gcurve parameters...... 77
3.3 Raster parameters...... 81
3.4 Model definition vs. model evaluation ...... 84
3.5 World object events ...... 89
4.1 Properties of encapsulated models ...... 121
4.2 Language requirements for encapsulated models ...... 122
4.3 Alarm clock parameters ...... 137
4.4 Chandelier parameters...... 137
5.1 Overloaded math operators ...... 149
5.2 Commonly used math “tools” and constants ...... 150
5.3 Representative procedures for the vec3 type ...... 152
5.4 Representative procedures for the mat4 type ...... 153
5.5 Optional sphere parameters...... 156
x iv 5.6 Sample attributes of the graphics state...... 160
5.7 Transformation gops ...... 161
5.8 Commonly used attribute gops ...... 162
5.9 Perspective and orthographic camera parameters ...... 165
5.10 Available render packages ...... 166
5.11 Standard render package parameters ...... 167
XV LIST OF FIGURES
Figure Page
1.1 Play Among The Stars ( 1994) courtesy of Charles Csuri...... 3
1.2 Horse Play (1996) courtesy of Charles Csuri...... 4
1.3 Anatomical modeling of human muscles of the upper torso [116, 117]. . . . 5
1.4 A frame from Butterflies in the Rain [42]...... 6
1.5 A cell decomposition. From [83] ...... 7
1.6 Voxel representation of a torus. From [20] ...... 8
1.7 An object represented using (a) a regular grid (b) a quadtree. Adapted from [41] ...... 9
1.8 An object built using CSG ...... 10
1.9 Object with edges and vertices labeled. From [83] ...... 11
1.10 A vertex-based boundary model [83] ...... 12
1.11 A edge-based boundary model [83] ...... 13
1.12 A Houdiai network (left) for a fluted cylinder (right) ...... 22
1.13 The AL run-time environment. From left to right, top to bottom: Ogre, Forge, Ogre, Ox, Timetool, Ogre, Chant...... 28
XVI 3.1 LEGO model. The arm lifts up and down and the claws retract using pneu matics. Two switches on the side of the model control the direction of air flow and a compressor (the vertical, black, cylindrical shape in the center with spring) pumps air through the system...... 49
3.2 Ball model where the vertical position (height) of the ball is determined procedurally...... 54
3.3 Graph of (bounce tim e 30) over frames 0 to 150 ...... 55
3.4 Ball model where the vertical position (height) of the ball is determined by a channel afunc...... 56
3.5 Basic “squash and stretch” ball model ...... 59
3.6 Squash and stretch surface of revolution ...... 59
3.7 The relationship between the exposure sheet and other components of the AL run-time environment. The arrows indicate how components modify afunc bindings stored in the exposure sheet ...... 61
3.8 A code fragment for a simple model hierarchy...... 63
3.9 Traditional animator’s exposure sheet. From [10] ...... 66
3.10 Sample AL X-sheet file...... 68
3.11 Conceptual diagram of a channel ...... 69
3.12 Computing the value of a channel at time t. a and d are the keys. 6 and c are the “interior” handles ...... 73
3.13 Chant— editing channels in the spreadsheet mode ...... 75
3.14 Chant— editing channels in the graphical spline mode ...... 75
3.15 Building shapes with gcurves: (a) the defining gcurves; and (b) the result ing shape...... 76
3.16 Gcurve interpolation ...... 79
xvu 3.17 Forge — interactive gcurve editing tool ...... 80
3. IS Relationship between the afunc and the object and class that implement it. . 92
3.19 Articulation function class hierarchy...... 93
4.1 Ball model with animation and model parameters ...... 104
4.2 Three instances of the parameterized ball model ...... 105
4.3 Water droplets, butterfly, and piano keys in a frame from Butterflies in the Rain[Al\...... 107
4.4 Piano keys (a) without shadows; and (b) with procedurally generated shad ows 109
4.5 Diagram of jointed hierarchy (left) and pseudocode (right) ...... 117
4.6 Cyclorama implementation ...... 123
4.7 Cyclorama construction and parameters ...... 124
4.8 (a) Cyclorama with default texture coordinates for gprims; and (b)with re-parameterized texture coordinates ...... 125
4.9 Sunlight source implementation ...... 126
4.10 Implementation for s u n l i g h t - c o l o r function ...... 128
4.11 Sunlight emodel for June I, 1998 at 40° N and 83° W ...... 129
4.12 Camera icon code ...... 130
4.13 Camera icon ...... 131
4.14 “Basic” camera emodel code ...... 132
4.15 Parameters in computation of “vertigo” camera ...... 133
4.16 Vertigo camera model code ...... 135
xvm 4.17 Alarm clock emodel ...... 136
4.18 Chandelier emodel (unlit) ...... 138
4.19 Chandelier emodel ...... 139
4.20 The gcurve defining the shape of candle stem as seen in the Forge editor. . . 140
4.21 An emodel for a tropical island that was interactively painted using the raster shown in Figure 4.22 ...... 141
4.22 The Rasp interactive raster editor. The raster shown here defines the shape of the island shown in Figure 4.21 ...... 142
4.23 Implementation of the “island” emodel ...... 142
5.1 The quadric gprims. From left to right, top to bottom: cone, cylinder, disk, hyperboloid, sphere, paraboloid, and torus. From [107] ...... 155
5.2 Code fragment for a bowl-like shape represented by a 4 x 6, B-spline patch mesh...... 157
5.3 Bowl-like shape created using a patch mesh...... 158
5.4 Code fragment for a cube represented using polygons ...... 159
5.5 Code for a simple object constructed using CSG ...... 166
XIX CHAPTER 1
Introduction
There has been a great deal of research in the field of computer animation since the first computer animated films were produced in the mid-1960’s. A vast array of techniques have been developed in an attempt to simulate the complex shape, motion, and surface ap pearance of “real-world” entities (e.g., characters and environments) in the digital domain.
However, relatively little research has been concerned with how we digitally represent and store these entities. Data formats used to describe and store objects for computer animation are often considered unimportant or uninteresting topics [15]. The data formats employed by computer animation systems are frequently an afterthought, an implementation detail, or a non-issue. As such, the sophistication of data formats has not advanced as other areas in computer animation have. The majority of the data formats in use today are only subtly different from the formats developed twenty years ago.
As the desire for increased complexity of objects modeled in computer animation sys tems continues to grow, insufficient data formats will increasingly pose as obstacles to ob taining those goals. In a seminal paper in the field of computer animation, Craig Reynolds notes “The existence of a formal notation for a field of endeavor leads to a workable pro cedure for the development of an idea [113].” In the context of computer animation, the
1 expressive power of the notation (i.e., the data format) used to describe objects limits both the sophistication of the objects that can be expressed and the sophistication of the anima tion systems that manipulate those objects.
The focus of this research is to investigate advanced and practical methods for describ ing animated objects used to create photorealistic computer animation. The primary benefit of a more expressive representation is the ability to encapsulate many, possibly procedural, attributes — shape, motion, materials (surface properties), light sources, cameras, sound, and others — using a single, self-contained representation. The benefits of encapsulation are numerous and include increased abstraction, efficiency, and potential complexity. An object that contains an integrated set of attributes, like those given above, and is represented by a procedural data format is called an encapsulated model, or emodel.
The concept of encapsulated models and the issues associated with them are illustrated in this document through the use of a procedural animation language and animation system,
AL, developed from 1992 to the present by the author [85, 87]. Charles Csuri, a noted pioneer in computer graphics and computer art [135], was the first user of AL. Since 1993,
Csuri has produced over 100 finished works (still imagery and animation) using the system.
Figures 1.1 and 1.2 show examples of Csuri’s work. In addition to serving as the basis for the research in this dissertation, AL has been used as a framework for research in two masters theses [6, 12], one doctoral dissertation [116] (See Figure 1.3), and ongoing work
[137]. AL has been used to develop numerous computer animated films [7, 13, 23, 29,
42, 69, 88] and innovative image-based and VRML-based web sites [28, 77, 79, 121]. A firame from one of the animated films by this author is shown in Figure 1.4. AL has also been used as the pedagogical platform for advanced courses in geometric modeling [18] and procedural animation [78]. ' * \ v
Figure 1.1: Play Among The Stars (1994) courtesy of Charles Csuri.
1.1 Background
This section introduces background information necessary to understand the context of this research in the field of computer graphics. The section is broken into two parts: the first part contains a discussion of the representations used in computer graphics to describe and store three-dimensional graphical objects; the second part provides an overview of the historical development of computer animation systems, which includes representations used for animation — emphasis is placed on the use of procedural representations. Figure 1.2: Horse Play (1996) courtesy of Charles Csuri.
1.1.1 Representation of 3D Graphical Objects
There are three major representations used for three-dimensional graphical objects in computer graphics: raster, geometric, and procedural. This is a very large topic and to give
full coverage is beyond the scope of this document. A thorough overview of the major representation types is provided in [41].
l.l.l.l Raster Representations
Raster representations are composed of a set of discrete samples in some space. The most common type of raster data is the two-dimensional image [15]. Conceptually, a raster image consists of a two-dimensional grid of samples called pixels. The collection of pixels 1
Figure 1.3; Anatomical modeling of human muscles of the upper torso [116, 117].
represents a picture. The samples can be collected from an actual object using a digital
scanning device or the samples can be produced synthetically using a computer program.
Three-dimensional forms of raster data include cell decomposition, volumetric data, and octrees. In cell decomposition, complex shapes are created from primitive shapes or cells (See Figure 1.5). Cells are often parameterized and can include curved shapes. Cell decompositions are frequently used for computations and activities such as finite element analysis.
The most common form of volumetric data stores samples in three-dimensional regular grids. Each sample is referred to as a voxel. In a regular grid, each voxel is the same size and the voxels are evenly spaced. Irregular grids, where the samples are irregularly spaced. ■ ■IL ■ 1 J
Figure 1.4: A frame from Butterflies in the Rain [42].
are also used. Figure 1.6 shows a volumetric representation of a torus. In this case, a binary decision has been made to determine whether or not a voxel forms a part of the torus. Most volume renderers use a "fuzzy" approach [76] to render surfaces so that the objectional blockiness shown in Figure 1.6 can be avoided.
Octrees store samples of varying size in a hierarchical fashion in an effort to more efficiently represent a regularly spaced, large grid. Quadtrees are the two-dimensional ana logue of octrees. Figure 1.7 compares the use of a regular grid and a quadtree to represent the same shape. Figure 1.5: A cell decomposition. From [83].
The discrete nature of raster representations provides a number of advantages and dis advantages. Because the representation is non-continuous, a large amount of storage is re quired to store the samples and aliasing is a serious obstacle when not enough samples are available. However, discrete samples are easily stored because of the simple grid organiza tion. Researchers have noted that, as opposed to geometric representations of three-dimen sional scenes, the time required to render a volumetric representation of a scene remains constant even as scene complexity increases [67].
11.1.2 Geometric Representations
Geometric representations are continuous. There are two major approaches: construc tive solid geometry (CSG) and boundary representations (B-reps).
In CSG, a hierarchical, tree structure describes how a group of solid shapes are com bined to create a more complex solid model. Leaf nodes in the tree represent primitive shapes (e.g., cubes, cylinders, pyramids). Interior nodes represent either transformations Figure 1.6: Voxel representation of a torus. From [20].
(translation, rotation, etc.) or binary set operations (union, difference, intersection) that op erate on the subtrees of the interior node. Figure 1.8 shows the CSG tree for a simple object built using transformed cube and cylinder primitives.
B-reps represent an object by the surfaces that bound the object. The surface may consist of planar polygons (a polygonal representation) or curved surfaces (a curve or patch representation). In a polygonal representation, the surface is defined by a combination of vertices, edges (vertex pairs), and faces (collections of edges or vertices). For different types of processing and efficiency considerations, a variety of methods can be used to organize this information. Two commoidy used approaches are the vertex-based model (or point-face dictionary) and the edge-based model. Another widely used organization not described here is the winged-edge data structure [8]. m I
Figure 1.7: An object represented using (a) a regular grid (b) a quadtree. Adapted from [41].
The vertex-based model consists of a vertex list and a face list. Figure 1.10 shows a vertex-based model for the object shown in Figure 1.9. The vertex list is numbered and each item in the list specifies the coordinates for one vertex. Each item in the face list represents one polygon by indexing the vertices (by the vertex numbers) that form the polygon. Since most polygonal objects contain polygons that share vertices, referencing the vertices by index can save a considerable amount of storage space.
In the edge-based model, faces are defined by edges instead of vertices. The edges are maintained in a numbered list. Each edge has two indices to vertices in the vertex list.
Figure 1.11 shows an edge-based model for the object shown in Figure 1.9.
Curved surfaces are usually composed of individual surface patches, meshes of patches, or a large number of planar polygons. Individual patches are easily represented. For exam ple, in the case of a bicubic patch, exactly 16 control vertices are needed to define the patch. [ dWéfenc»^
[ union j [ cyllndefj
Figure 1.8: An object built using CSG.
The 16 control vertices along with the patch basis (usually represented using a 4 x 4 ma trix) form an efficient representation [91]. However, if multiple patches are used to create a surface, adjacent patches will have redundant control vertices. In this case, a patch mesh can be defined. A patch mesh consists of arbitrary number of control vertices along each parametric dimension.* A bicubic patch mesh is sampled using a 4 x 4 subset of the control vertices in the same manner that piecewise curves are sampled. Thus patch meshes can be
'Actually there is a tninimuin required number of control vertices dependent upon the order of the curve. For example, at least 4 control vertices are required in each direction for bicubic surfaces.
10 Figure 1.9: Object with edges and vertices labeled. From [83].
represented by an m x n array of control vertices and a basis. More sophisticated curved surface formulations (e.g., NURBS) require additional information in the representation including knot vectors and parametric intervals [37].
The advantages of geometric representations are numerous. The continuous represen tation permits a precise and relatively compact representation (as compared to raster rep resentations). The use of entities, such as vertex-lists, maps directly to simple file formats and data structures. Software and algorithms that manipulate these formats and data struc tures are straightforward to implement. B-reps are the most widely used representation in current animation systems. Several b-rep data formats exist for the exchange of geometric information between systems (e.g., IGES and DXF [15]). In addition, non-geometric in formation, such as color, shading normals, and texture coordinates, can be easily attached to a geometric surface by associating them with the same vertices used to define the shape of the surface [136].
II vertex coordinates Vl Vl zi face vertices V2 X2 V2 Z2 A Vl V2 V3 V4 V3 ^ 3 V3 Z3 A ve V2 Vl Vs t/4 X4 y 4 2 4 h V7 Vs V2 Vs Vs 2^5 V5 Zs h Vs V4 Vs Vt Vs xs Vs Zs h Vs Vl V4 Vs Vr Xt 2/7 27 h Vs Vr Vs Vs Vs xs Vs Zs
Figure 1.10: A vertex-based boundary model [83].
The primary disadvantage of geometric representations (and raster representations) is that the representation is static. That is, the shape and organization of the geometric data is constant. Shapes that change over time, that could benefit from parameterization, or that could be generated procedurally cannot be expressed using the simple, non-procedural representations described thus far.
1.1.1.3 Procedural Representations
In computer graphics, a procedural representation is not a static set of values (like the geometric and raster representations discussed previously), but a definition of a process, which when executed, produces a geometric (or raster) representation of an object. To put it another way, a procedural representation describes “how” an object is built or animated rather than “what” the final appearance of the object will be.
Procedural modeling and animation refers to a diverse range of techniques that use processes (procedures) to generate complex shape and motion. In particular, procedural techniques have been used to model natural phenomena such as mountainous terrain [3,
35, 84, 124], water [45,90, 102, 101], fire [110, 128], smoke [26, 36,44, 128], plants and
12 edge vertices
e i t/l V2
6 2 V2 V3 vertex coordinates
63 Ü3 U4 V l xi yi zi face edges
64 Ü4 V l V2 X 2 V 2 Z2 fi 61 62 63 64 65 V l V5 V z ^3 yz 2 3 A 6g Cs Cl 65 66 V2 V s Va ^A Va ^A h 610 67 62 eg 67 V3 V t Vs xs ys Zs U 611 eg 63 67 68 va Vs Vs X s ye Z s h 612 65 64 eg 69 V5 V s V t XT 2/7 Z t h 612 611 eio eg
610 V s V t V s zg y s Z s
611 V t V s
6 1 2 V s V5
Figure 1. 11:A edge -based boundary model [83].
flowers [109, 124], elastic objects [61, 132], rigid-body collisions [5, 58], cloth [14, 140], the flocking behavior of birds [4, 114], and humans [19,103,116].- In addition, procedural techniques are used for topics as diverse as constraint-based modeling [21, 41, 71] and automatic, virtual camera placement [32, 62].
In general, each of the techniques described above for simulating natural phenomena exhibit a feature known as database amplification [124]. Systems that exploit database amplification produce complex data (i.e., large databases) from a small set of mathematical or logical mles and a small set of parameters that are specified by the user. For example, in the animation of a waterfall, it would be impossible for an animator to specify the motion of each water droplet explicitly. However, a small set of rules can be defined based on known physical properties (e.g., Newtonian mechanics and gravity) and can be applied iteratively
-The work listed here serves as only a small, representative sampling of the research performed in the sim ulation of natural phenomena in computer graphics. Good overviews of procedural modeling and animation techniques are given in [34,41, 139].
13 to each water droplet. Each droplet has slightly different characteristics (e.g., mass or initial
position) that provide variation in the motion of each droplet. The collection of all of the
droplets produces a natural-looking simulation of a waterfall. User parameters can include,
for example, the width, height and shape of the waterfall, the number of water droplets, and
the speed of the river.
Procedural representations are very powerful. In addition to the obvious power of
database amplification (i.e., the ability to replicate objects easily), numerous researchers
have noted the advantages of procedurally defined objects [26,64,94,95, 111,113]. Other
advantages include the ability to define objects with parameters and the ability to encode
mathematical relationships (e.g., constraints) between parts of an object.
Another advantage is related to a relatively new research area called genetic program ming. Genetic programming relies on the fact that a procedural definition encodes informa tion about “how” the object is built. Genetic programming involves permutating procedural definitions of entities to evolve more sophisticated descendents (variations) of the parent
(original) entity. Genetic programming has been used to evolve two-dimensional textures
[122], self-locomoting creatures [123], and animation of articulated objects [51].
The advantages of procedural representations are illustrated in more detail in Chapter 4 of this document.
High-level representations, such as the formal language grammars {L-systems) most fre quently used to describe plants [124, 109] and plant-like processes [59], elegantly describe procedural processes at a structural level. But to actually make a picture, a representation capable of generating geometric representations (e.g., translating a terminal symbol in a grammar into a geometric representation for a plant branch or leaf) is required.
14 Programming languages are the most commonly used representation for creating im agery based on procedural techniques. Unfortunately, the use of programming languages leads to several difficulties. The most basic problem with a programming language rep resentation is that it requires programming. Programming is difficult, especially for users with a non-technical background. Programming is also generally non-interactive. When the goal is to produce preconceived visual imagery, programming and non-interactivity can be significant barriers because the connection between computational processes and im agery is often unclear. The importance of interactivity in today’s animation systems does not really need to be argued.
Another problem is that the syntax and interpretation of a programming language is far more complex than that of a static database such as a vertex-face list. The complexity makes it more difficult to implement programs that read procedural definitions and that convert between data formats. Recently however, Java [38] and other programming languages (e.g.,
JavaScript [39]) have shown that procedural data can be effectively treated as portable, multimedia content (i.e., a data format like those used for two-dimensional images and text) for Internet based applications.
Finally, an argument sometimes levied against procedural representations is that they can be inefficient because the process describing an object has to be executed each time the object needs to be used. Conceptually, this is true and is also the main reason why procedural representations are so powerful. But the argument is flawed, because compu tationally efficient, static data structtmes are a subset of procedural languages. One of the features of most programming languages is the ability to create data structures and define new types. Thus, procedural objects that are essentially static can be converted into more efficient forms.
15 Despite the disadvantages, the potential gains from procedural representations cannot be ignored. Unfortunately, widely used representations for procedural graphics are not yet prevalent. “If there is any gap in the spectrum of data formats it is in the realm of support for ‘algorithmic data streams [15].’ ” In the field of computer graphics, only one procedural language is widely used — the PostScript language [1,15] — and that language is for two- dimensional graphics only. In the three-dimensional domain, one of the best examples of a successful procedural language is the RenderMan Shading Language [107, 136]. The
RenderMan Shading Language is a “C-like” programming language used to implement shaders. Shaders are relatively small programs that implement components involved in the shading of three-dimensional surfaces during the rendering process. Shaders are used to define surface reflectance, variations in surface geometry, light source illumination, and atmospheric attenuation. The success of Pixar’s PbotoRealistic RenderMan as a software tenderer for commercial and feature film work is often attributed to the power and flexibility of the RenderMan Shading Language that is an integral part of that software package.
Chapter 2 presents an overview of procedural languages that have been developed for computer animation. The remaining chapters in this document discuss various aspects of the procedural animation language developed as a part of this research.
1.1.2 Historical Development of Computer Animation Systems
Traditionally, animation systems have neatly filed themselves into one of two distinctly different classifications: scripting and interactive. Modem systems still can be classified in this manner, although increasingly the distinction between the two classifications is being blurred.
16 1.1.2.1 Scripting Systems
The first computer animations were produced by writing programs to generate the an imation using general purpose programming languages (e.g., Fortran). General purpose languages are flexible and inherently allow programmers to take advantage of conventional programming mechanisms (e.g., variables, subroutines, conditional statement execution, it eration) and techniques (e.g., structured programming, object-oriented design, recursion) to produce animation. The main disadvantage of this approach is that many elements needed to generate animations (e.g., specifying geometric shapes, building hierarchies, generating output for renderers, applying transformations to objects) have to be reimplemented for each animation. The amount of work required to provide the underlying framework can easily outweigh the programming needed that is unique to the production of the animation task at hand.
In response to the problems of using general purpose programming languages, re searchers developed specialized programming languages, procedural animation languages, designed for the task of computer animation [30,47, 60, 64, 65, 80, 104, 111, 113]. These animation languages are either new programming languages entirely (often with similari ties to existing languages) or extensions of existing general purpose languages (extension languages). In the case of an extension language, the underlying, general purpose lan guage is called the base language. The base language provides conventional programming functionality; the extensions to the base language provide the functionality needed to pro duce computer animation. Animation languages that are built from scratch (i.e., without an underlying base language) tend to lack the wide range of functionality that extension lan guages have (particularly with regards to the richness of data types and device I/O), but are
17 often easier to learn, use, and implement. A detailed discussion of procedural animation
languages in given in Chapter 2.
As the field of computer animation began to mature, more and more non-technical users
started working with animation systems. Researchers quickly realized that there was a need
for systems that did not require complicated programming in order to specify animation
[27, 30, 54]. The Anima U system [54] was the first animation system to use a high-level script — a list of instructions or commands that specify how the objects in the scene are to be animated. Scripts are specified using a command language. Command languages are simpler than procedural animation languages and thus easier for non-programmers to use. Command languages are typified by a lack of one or more of the features considered essential for general programming languages like variables, function calls, data structures, and control-flow constructs. Most command languages employ a simple syntax where one command is specified per line and each command has a similar syntax. Often a verb-noun syntax was used as shown below.
(verb) (noun) (parameters)
The (verb) specifies the action. The (noun) specifies the object that the action will affect. The (parameters) specify additional values required to fully specify the action. The
Anima H commands shown below are adapted from [54].
SET POSITION ball 0, 0, 0, AT frame 1 CHANGE POSITION ball TO, 1, 0, 0, FROM frame 1 TO frame 100
The conunands in Anima U are executed in parallel so that simultaneous actions can be expressed. In the example above, an object named “ball” is positioned at coordinates
(0,0,0) at firame 1 and simultaneously moved to coordinates (1,0,0) over frames 1 to 100.
18 The use of parallel commands such as these avoids the need for iterative programming constructs.
The disadvantage of command languages is that they are not procedural (i.e., they do not have the features of general programming languages). By eliminating the language constructs that make learning animation languages difhcult, command languages give up the mechanisms that make animation languages powerful. Complex objects that can be rep resented using mathematical constraints, procedural rules, and behavioral processes cannot be effectively represented using command languages. Authors of systems which employ command languages have to resort to a general programming language to procedurally generate complex scripts as is illustrated in [26, 96]. Newell states “Many systems dictate a data format based on their particular primitive form. As these systems are developed, the need for more and more generality in the facilities provided results in escalations in the complexity of the data format until it begins to resemble a programming language. At this point, the arguments for and against special purpose programming languages become relevant [94].”
1.1.2.2 Interactive Systems
In the late 1970’s and early 1980’s, the emphasis in computer animation turned towards the development of interactive animation systems [26, 43, 48, 53, 81, 96, 129]. Interac tive animation systems allow the animator to make continuous modifications to the shape, transformations, and attributes of three-dimensional objects. Modifications are specified using an input device, such as a mouse, and the results are computed and shown (rendered) quickly enough to the user so that the user feels as if he or she is directly manipulating the object on the screen.
19 Interactive systems have become the predominant method for creating computer ani mation today because they provide immediate, visual, user feedback. As such, the features of such systems are well known and are typified by the powerful commercial systems such as Alias PowerAnimator[2], SoftImage\3D [126], and 3D Studio Max [70].
1.1.2.3 Systems That Combine Scripting and Interaction
Over the years, developers and users have debated about what type of animation sys tem, scripting or interactive, was superior. More recently, researchers agree that both types of systems are important [60, 119]. Three types of systems that incorporate both script ing (procedural) and interactive techniques now exist: procedural animation languages that have integrated interactive capabilities, visual programming systems, and interactive sys tems that incorporate procedural capabilities.
The most successful system to date that adds interactive capabilities to a procedural ani mation language is Pixar’s Menv system [111]. The key technology in Menv is a language- level mechanism called the articulated variable that permits the procedural representation of objects to be modified interactively. The articulated variable is an extension of previous work by Hanrahan and Sturman [60] and Reynolds [113]. The Menv system and articulated variables are discussed further in Section 2.5.
Visual programming systems, such as Haeberli’s ConMan [55] and the commercial
Houdini system [120], use a graphical representation of dataflow networks [92, 108]. In a visual programming system, the scene is represented as an acyclic graph (See Figure 1.12).
Nodes in the graph represent functions that produce shapes and functions that apply trans formations to shapes. Each node. Like a function, has a set of inputs and outputs that can be used to pass data between nodes. Outputs of nodes are connected to inputs of other
2 0 nodes by interactively connecting the nodes with edges. In addition to inputs (data) from other nodes, nodes typically have other parameters that can be modified interactively and animated over time using conventional animation channels or tracks. Nodes are usually implemented as independent, modular components. New nodes can be implemented in a general purpose programming language (e.g., C or C++) by the user using an API (applica tion programmer’s interface) specific to the system. Visual programming systems provide facilities for procedural animation and are easier for non-programmers to use because they are interactive and the syntax of a programming language is avoided. However, more com plex types of procedural animation, such as flocking [114], can be difficult to express when communication channels between components are complex or implicit, when centralized data structures are needed, or when an object-oriented design style is preferred.
Interactive animation systems add procedural animation capabilities through three main mechanisms: command languages for scripting (described earlier), expressions, and plug ins. Expressions allow parameters that are usually specified interactively to be specified using simple mathematical expressions that are typed in by the user. Plug-ins are mod ular software units that can be used to extend the functionality of the system. Like the nodes of visual programming systems, plug-ins are implemented using a general purpose programming language and an API specific to the animation system.
The problem with existing systems that use plug-ins and visual programming is porta bility. It is difficult, if not impossible, for a procedural object implemented in either type of system to be transferred intact (i.e., with the same procedural capabilities) to a different an imation system because the representations used to implement plug-ins and store network graphs are system specific.
2 1 io.
Lj -
Figure 1.12: A Houdini network (left) for a fluted cylinder (right).
1.2 Motivation
This chapter began by introducing the term “encapsulated models.” Recall that an en capsulated model is an object that contains an integrated set of dynamic attributes using a procedural data format (i.e., a procedural animation language). The encapsulated attributes may include some or all of the following: geometric shape, time-varying motion, surface materials, light sources, cameras, sound, and even special effects like smoke and fire.
2 2 The concept of encapsulated models is an attempt to improve the representation (i.e.,
data format) used to describe graphical objects for photorealistic computer animation. An
improved representation will yield two major benefits:
1. The complexity and sophistication of objects that can be created will be increased.
2. The cost of producing complex, sophisticated computer animation will be reduced.
Nearly all animate objects exhibit complex, dynamic interactions between motion, form, and other attributes. A procedural representation can model these dynamic inter actions effectively. Consider the work of Scheepers etal. in anatomically-based modeling of human muscles [117]. Using the AL language, visually realistic, procedural models of the anatomy of humans were developed. The procedural models include different types of muscles that vary in shape, size, placement, and behavior. Complex interactions between the different muscle types, tendons, bones, and skin are modeled. Animation of the skele tal structure (represented as an articulated hierarchy) by the animator results in realistic changes in the musculature and skin. The detailed models of skeletal and muscle layers can be manipulated in real-time. The detail and computational efficiency of the complex musculature is achieved because the underlying procedural data format allows for multi ple, highly specialized models of joints, muscles, and tendons to be developed. Models of this complexity (and more) where shape and animation are integrally linked will become increasingly common as artistic demands and computing technology advance.
To argue reduced costs, consider the state of affairs with commercial companies that sell three-dimensional objects for producers of computer animated films. These companies
23 sell data for thousands of objects including all types of cars, planes, people, furniture, archi tecture, appliances, etc. Unfortunately, the objects only contain static geometric informa tion (usually polygonal or NURB-based) and in some cases, surface material descriptions.
Why? Because the data formats used by animation systems for the description of individ ual objects lacks the expressive power needed to describe other components. Even simple objects (e.g., an alarm clock. See Section 4.2.5) would be much easier to use if anima tors could purchase models of objects, “off-the-shelf,” that have predefined movable parts, built-in animation controls, built-in sound effects, and parameters to vary the shape, style, or functionality of the model. In order to provide this type of object, more sophisticated data representations and animation systems that manipulate those representations have to be developed. Currently, the price of three-dimensional data objects is generally based on the number of polygons. Wfith more advanced data representations, the price could be dictated by the sophistication of the self-contained animation, the quality of built-in sound effects, and the range of parameterization.
In order to develop the concept of encapsulated models, the following problems have to be solved:
1. The properties of encapsulated models have to be defined in order to reason about
representations and systems for them.
2. The requirements for procedural animation languages as a representation for encap
sulated models have to be specified. These requirements can be derived directly from
the properties in item 1. The requirements should be independent of any specific pro
gramming language so that they can have general applicability.
24 3. Mechanisms for interactive manipulation of encapsulated models have to be devel
oped. Historically, procedurally based animation systems are difficult to use (even
by technicians) because they lack interactivity and require programming. One ap
proach, to make such systems effective, is to develop programming language mech
anisms and software tools to support interactive manipulation and construction of
procedural representations.
4. Prototype procedural ammation languages and interactive animation systems to sup
port encapsulated models must be developed.
1.3 Thesis
The sophistication of graphical content is limited by the expressive power of the lan guage (i.e., the representation) used to communicate it. Encapsulated models are a pow erful representation for three-dimensional objects used for the production of photorealistic computer animation. Encapsulated models are represented using a procedural data format
— a specialized programming language. In order for the programming language to be a successful vehicle for encapsulated models, it must have certain properties — among the most important of which are mechanisms for interactive manipulation of procedural spec ifications (i.e., programs). Articulation functions are a novel and effective language-level mechanism for incorporating interaction into systems that use procedural specifications.
25 1.4 Document Overview
This chapter provides an introduction to the research topic presented in this dissertation.
Section 1.1.1 provides an overview of the representations used for describing three-dimen sional objects in computer graphics. Section 1.1.2 discusses the development of animation systems — from the first scripting systems to interactive systems to today’s systems that incorporate both scripting and interaction. Section 1.2 provides the motivation for this research and the problems addressed. Section 1.3 gives the thesis of the dissertation. The remaining parts of this chapter provide an overview of the animation system and language used as a framework for this research, a glossary of terminology, and notes on the printing conventions used in this document.
Chapter 2 presents the previous work in computer graphics directly related to this dis sertation. In particular, it highlights the research that provided a foundation for and most directly influenced this research — Reynold’s ASAS system, Hanrahan and Sturman’s EM language, and the Menv system of Ptxar.
Chapter 3 introduces a new language mechanism — articulation functions — that al lows for interactive manipulation and animation of procedural models. Articulation func tions are a generalization of the articulated variables used in the Menv system.
Chapter 4 defines the concept of encapsulated models. The definition is given by a set of properties that characterize the concept, accompanied by a set of language requirements that define the representation needed to describe encapsulated models. The concept is illustrated through several actual examples. These examples also serve to illustrate the prototype procedural animation language, AL, used to implement this research.
Chapter 5 provides an introduction to the syntax and semantics of the Animation Lan guage (AL).
2 6 Chapter 6 summarizes the contributions of this research and discusses future work.
1.4.1 AL System Overview
The AL system consists of a programming language called AL and a set of software tools collectively called the AL run-time environment. The AL run-time environment is distributed freely and runs on a variety of UNIX workstations and PCs running Linux.
The AL language is an extension of the general purpose programming language Scheme
[33]. Scheme is referred to as the “base language” because it provides all of the base programming functionality — basic data types, variables, expressions, and programming statements (e.g., assignment, iteration, procedure calls). The reasons for choosing Scheme are detailed in Section 5.2. The extensions that comprise AL are specifically for the creation of three-dimensional computer animation. An overview of these extensions is given in
Chapter 5.
AL programs (i.e., descriptions of animated objects and scenes) — also known as en capsulated models or emodels— are processed by an interpreter called Ox. AL models can be typed interactively into Ox, but most commonly they are written using a conventional text editor such as Emacs [127]. The interpreter also accepts commands (i.e., messages) from other running processes. In this way, editors like Emacs can send a command to the
Ox interpreter to load the current file being edited using a single keystroke. This allows for relatively interactive programming.
When an AL model is interpreted, the model is immediately displayed in an interactive display tool called Ogre. The AL run-time environment uses the tool-oriented approach advocated in [111] which suggests that many small, modular, interactive tools are better than single monolithic programs. Thus, an arbitrary number of Ogre tools can be running at
27 Figure 1.13; The AL run-time environmenL From left to right, top to bottom: Ogzc, Foige, Ogre, Ox, Timetool, Ogre, Chant
the same time — each providing a different view of the scene (See Figure 1.13). Ogre uses
OpenGL [93] to render using local graphics hardware. Animations of modestly complex
scenes can be interpreted and viewed using Ogre in real-time.
When production quality rendering is needed or the animation is too complex for real time playback, the animation can be rendered to a RenderMan-compliant renderer [107] such as [^otoRealistic RenderMan [105] or BMRT [52]. PhotoRealistic RenderMan has become the predominant renderer for feature film production. Interfaces to specific render
ing devices (such as PhotoRealistic RenderMan and Ogre) are implemented using software modules called render packages. New render packages can be defined for new output de vices. This allows the AL language itself to remain device independent
28 Once an AL model is loaded into the interpreter, the model can be interactively ma nipulated and animated using a language mechanism called articulation functions and a set of interactive tools. When a model is programmed, the parts of a model that are to be in teractively animated are “wired” to individual articulation functions. When an articulation function is modified using an interactive tool, the Ox interpreter automatically re-executes the model which updates the display in tools such as Ogre.
The modify-interpret-display loop can be performed and repeated in real-time for most models. Different types of articulation functions can be used to animate different aspects of a model. The different interactive tools are specialized to operate on a single type of articulation function and thus provide different graphical user interfaces depending on the type. Articulation functions and the associated interactive tools are described at length in
Chapter 3.
An emodel for a chandelier, wired with several articulation functions, is being manip ulated in the workstation display shown in Figure 1.13. Several Ogre processes render the chandelier from different vantage points in orthographic and perspective projections. The shape of one of the parts of the chandelier is specified by an articulation function. The articulation function is manipulated with the interactive tool. Forge (top-middle). The rate that the candles flicker is specified by another articulation function which is interactively specified in an tool called Chant (lower-right). Interactive modifications in either Chant or Forge result in dynamic re-execution and display of the procedural chandelier model.
The animation of the scene is controlled using Timetool (middle) which interactively mod ifies the value of global time (See Section 3.1.2) and allows the animation to be played back over a range of frames at different speeds. The chandelier model is described fully in
Section 4.2.6.
29 1.4.2 Glossary of Unique Terms
A brief glossary of unique terms and symbols used in this document is given below.
#t Scheme symbol representing the "true" boolean state. #f Scheme symbol representing the “false” boolean state.
#
AL A procedural animation language used as the developmental prototype for this re search.
AL run-time environment A set of software tools used to manipulate AL programs. afimc Short for articulation function. articulation function A programming language mechanism used for interactive anima tion of models. base language A general purpose programming language used as the basis for a more specialized language. channel A specific type of afunc. Used to specify time-dependent scalar values. emodel Short for encapsulated model. encapsulated model An encapsulated model is an animated object containing an inte grated set of dynamic attributes — e.g., shape, motion, materials (surface proper ties), light sources, cameras, user interfaces, sound — represented by a procedural data format (i.e., a program written in a procedural animation language). gcurve A specific type of afunc. Used to specify time-dependent, three-dimensional geo metric curves. geometric operation A programming statement that modifies the graphics state thus im plicitly affecting subsequently declared geometric primitives. geometric primitive A programming statement that draws a primitive geometric shape (e.g., a sphere, a bicubic patch, a polygon). gop Short for geometric operation. gprim Short for geometric primitive.
30 graphies state The same as a graphics environment or graphics context. The graphics state is a conceptual database used to maintain a set of attributes which specifies the way shapes are drawn. procedural animation language A programming language for producing computer ani mation. raster A specific type of afunc. Used to specify two-dimensional grids of scalar values.
1.4.3 lype-face Conventions
font used purpose
italicized roman titles, the introduction of a new term, and foreign words
c o u r i e r program code and program variable names in body text
bold courier keywords in a progranuning language
slanted roman names of application programs and systems
31 CHAPTER 2
Procedural Languages for Computer Animation
This chapter describes the development of procedural languages in computer graphics for the specification of three-dimensional shape and motion. It is divided roughly into three major pieces: Section 2.1 describes the languages employed by early animation systems; sections 2.2 through 2.5 describe four languages that direcdy infiuenced the research pre sented in this dissertation; and Section 2.6 describes other recent systems that utilize lan guages with important characteristics regarding the procedural representation of objects.
The systems and languages described are presented in the chronological order of their pub lication.^
2.1 Early Procedural Languages
2.1.1 EÜLER-G
One of the first procedural languages for computer graphics was EULER-G. This lan guage was developed by William Newman to implement display procedures [95].
^There is one exception. The MML language (1988) described in Section 2.6.1 was published before the Menv system (1990) described in Section 2.5.
32 Display procedures are a procedural alternative to conventional display list represen
tations for updating CRT displays. In EULER-G, procedural shapes can be defined using
iteration, mathematical expressions, and a small set of graphical primitives (e.g., lines and
circles). As opposed to conventional display lists, shapes can be transformed when they
are called by an arbitrary number of affine transformations including scale, rotation, and
translation. Transformations are accumulated when pictures are composed hierarchically,
thus large scale transformations on pictures can be achieved by modifying a small number of transformation instructions. Although sophisticated in its use of graphics state, graphics data types (e.g., points and matrices), and understandable syntax, EULER-G only provides support for static, vector-based, line drawings. Nonetheless, many of the techniques de scribed by Newman (e.g., picking and multiple levels of detail) can be found in modem graphics toolkits and display formats such as OpenGL [93] and Postscript [1].
2.1.2 GRASS
The Graphics Symbiosis System(GRASS), by Tom DeFanti [30], was a pioneering animation system in two ways. First, it was one of the first truly interactive animation systems. Second, a fundamental premise in the development of this system was that “inex perienced users such as artists and educators should be able to develop computer graphics interactively without the constant assistance of computer programmers [134].”
The GRASS system has two types of primitives: pictures and commands. Pictures are named lists of 3D vector endpoints. Commands specify picture endpoints and operations on pictures such as translation, scale, and rotation. GRASS commands can be typed in and immediately executed so that the user can quickly view the result. Arguments to commands can contain numbers, expressions, or be attached to hardware devices (e.g., joysticks, dials)
33 so that pictures can be moved and modified interactively. Macros can be developed for more sophisticated programs. The language supports control flow constructs including conditional execution.
GRASS was later extended to ZGRASS [134] which includes additional facilities for manipulating and playing back image sequences.
2.1.3 An Extended Algol-60
Ben Jones describes a procedural graphics language that is an extension to the general programming language Algol-60 [65]. This high-level language serves as an interface to custom graphics hardware developed by Evans and Sutherland. The graphics hardware was a black and white system capable of real-time, vector and shaded display of polygons. The language is used to build a data structure that is processed as a display list for the graphics hardware. The extensions to Algol-60 provide primitive data types for vertices, colors, and transformations; vector arithmetic on vertex and color types; functions to generate affine and perspective transformation matrices; and primitives to specify colored, faceted, or Gouraud shaded polygons. Pictures can be grouped and transformed hierarchically.
Minimal animation capability is achieved by executing sub-pictures within an infinite loop.
The frame rate carmot be explicitly specified and is determined by the speed at which the system can display the scene.
34 2.1.4 DALI
DALI (Display Algorithm Language Interpreter) is a hypothetical/ but progressive pro cedural language system in that “each picture element... describes its own behavior [ 104].”
Analogies to operating system design are employed to define and synchronize independent, modular processes. Each process represents a picture element and contains user-defined, event-driven procedures called “daemons” that define the behavior of the picture element.
Pictures are synchronized via “objects” which are essentially storage locations for the com munication of data between processes (i.e., picture module inputs and outputs). Picture modules can respond to changes in the outputs of other modules. In this way, this system is a precursor not only to actor-based systems (Section 2.2,2.3), but also visual programming systems (Section 1.1.2). Unfortunately, the dynamic, asynchronous behavior of the picture modules and the operating system terminology makes the implementation, through an ex tended PL/1 language, of even very simple pictures far more complex than other systems described in this chapter.
2.1.5 PICTUREBALM
PICTUREBALM is an experimental system intended to explore features that LISP- based languages offer for computer graphics [47]. In particular, the authors note these strengths of LISP-based systems:
• interactive program definition and execution;
■*The author of the paper notes in the conclusion of [104] that “Unfortunately, no usable implementation of DALI exists at this time.” However, a prototype was developed using a LISP-like language also developed by the author.
35 • efficient and natural manipulation of complex, hierarchical, data structures; • run-time type checking; • dynamic storage management; • extensible syntax; and • portable implementation.
This system is characterized by a language that is concise and easy to read. Graphical objects are called “models” and are represented by a special data type. Thus models can be passed as arguments to procedures and assigned to variables. A number of operators are defined to create sequences of 3D points that can represent connected line segments, polygons, or curves. The operators, which include affine ttansformations, return an instance of the model data type. Models are then displayed using the “SHOW” command which takes a model as an argument. The procedure implementing the model is evaluated and displayed. Model procedures can be dependent on variables that change values between the invocation of the model via SHOW. In this way, the user can modify parts of a model without directly changing the procedure implementing the model. Facilities for animation
(other than typing the SHOW command repeatedly) are not described.
2.2 ASAS
One of the most important, and firequently referenced papers, in the domain of pro cedural animation languages is Craig Reynolds’ paper [113] on his system called ASAS
(Actor/Scriptor Animation System). Despite the absence of interactive capabilities, this system had sufficient capabilities and sophistication to be used for production work. At In formation International Inc. (“Triple I”), ASAS was used to generate the computer imagery in Disney’s feature film Tron.
36 2.2.1 Actors
Reynolds is generally given credit for the idea of defining objects that contain their own animation — although the idea has been suggested for computer animation in earlier work [ 6 6, 104]. He calls this type of animated object an actor. His concept of an actor was derived from research in artificial intelligence by )^nograd [142] and Hewitt [63]. An actor is “a ‘chunk’ of code which will be executed once each frame. Usually an actor (or a team of them) is responsible for one visible element in an animation sequence, hence it contains all values and computations which relate to that object [113].” Actors are modular and independent processes, but they can be synchronized using message passing.
ASAS utilizes an extension of the LISP programming language. It provides a num ber of geometric objects including vectors, colors, polygons, solids (closed polyhedrons), groups (collections of geometric objects), coordinate systems, subworlds (objects associ ated with coordinate systems), and light sources. A large set of geometric operations allows geometric objects to be moved, shaped, and oriented. Primitives that operate in the local coordinate system take, as an optional parameter, the name of the object to which the op eration is being applied. If an object is not specified, the transformation is applied to the currently “grasped” object which is specified with the grasp command. For example, the
ASAS code fragment below moves the a ir p l a n e object along the positive z-axis, via the forward operator, and rotates the airplane about the z-axis, using the cw (clockwise) operator.
(grasp airplane) (forward 0.1) (cw 0.02)
The script construct defines a production sequence and performs the necessary ini tialization, finalization, and animate blocks. An animate block is a special type of
37 loop. Each iteration of the loop evaluates the expressions it contains to produce a single
frame of the animation. The example below is from [113] and specifies two actors (green
and blue spinning cubes), the times at which the actors are created, and the time at which
the animate block terminates (by the cut operator).
(script spinrxing-ciibes (local: (runtime 96) (midpoint (half runtime))) (animate (cue (at 0) (start (spin-cube-actor green))) (cue (at midpoint) (start (spin-cube-actor blue) ) ) (cue (at runtime) (cut) ) ) ) )
Once an actor is created, the following happens for each frame of the animation: the local state variables of the actor are restored; the procedure implementing the actor is eval uated; and the local variables are saved.
The “spinning cube actor” is parameterized by a single argument specifying its color.
The current rotation of the cube is maintained in a local variable called a n g le which is incremented each time the actor is evaluated. The code implementing the actor appears below. More details regarding its specification are available in [113].
(defop spin-cube-actor (param: color) (actor (local: (angle 0) (d-angle (quo 3 runtime) ) (my-cube (recolor color cube))) (see (rotate angle y-axis my-cube)) (define angle (plus angle d-angle) ) ) )
2.2.2 Newtons
Newtons (a term introduced by Reynolds) are essentially animation splines that can be used, within the procedure implementing an actor, to modify the numeric parameters of any
38 geometric operation affecting the actor. Newtons are defined by a sequence of piecewise cubic curves. The animator can specify the type of each piece of the curve to control the way in which the number varies over time (constant, linear, smooth). Newtons are automatically sampled at increasing time intervals each time the actor utilizing a newton is evaluated.
2.2.3 Message Passing
Message passing between actors in ASAS is specified using two operations: send and receive. The send operator can send a message of a specific type, with specific data values, to a single actor or broadcast the message to a group of actors. The receive operator is a guarded command that evaluates an expression depending on the type of the message received. Communication between actors can be used for synchronization to im plement complex group behaviors such as flocking [114].
2.3 CINEMIRA
Cinamera is the procedural language component of the script-based animation system
Miranim by Magnenat-Thalmann and Thalmann [80, 81, 82]. Cinemira, an extension of
Pascal, uses the concept of abstract data types (ADTs) and structured programming to implement actors as in the sense of Reynolds (Section 2.2).
Three classes of graphical ADTs are given: figures, actors, and cameras. Figures are used to draw shapes. New, parameterized, graphical data types (objects) are defined using the figure construct. Instances, assigned to variables, of the new data types have four
39 core operations: create, delete, draw, and erase. An object is animated explicitly using these operations for each frame.
Actors, unlike figures, contain their own animation. That is, the motion of the actor is defined in the ADT implementing the actor. Actors (and cameras) may contain animated variables which are an extension of Reynolds’ newton concept (Section 2.2.2). Animated variables include vectors, integers, and reals. Each animated variable explicitly specifies 1) the range of possible values; 2) the time over which the variable is defined; and 3) a “law” that determines how to compute the value of the variable which is often time-dependent.
2.4 EM
A system developed by Hanrahan and Sturman [60] was the first system that allowed in teractive manipulation of proceduraUy defined objects. This system features an interpreter that evaluates procedural definitions of objects and allows the values of arbitrary parameters of the objects to be connected to numeric input devices. By modifying the input device, a procedural model can be continuously modified to provide interactive feedback to the user (via a real-time vector-based display). In addition, the system supports a parameter database that can be used to store the interactively specified parameter values. In addition to saving useful parameter data sets, the parameter database can be combined with other parameter databases to specify key frames for animation.
The language developed by Hanrahan and Sturman is called EM. The language is block structured. Conventional, lexical scoping of variables occurs within blocks. However, blocks have an additional semantic behavior — the beginning of a block pushes the graph ics state and the end of a block pops the graphics state implicitly. Thus, transformations
40 occurring within a block are localized to shapes in the block in which they are declared.
This provides a natural and concise notation for building hierarchical models.
The example below is from [60] and shows an EM program that implements a model for a “tube” that is implemented with a cylinder capped by two spheres. Language blocks are delimited by braces.
; tube parameter scalar a=2, r=l ;; initial values set to 2 and 1 ; ; center rot -90 z rotate -90 degrees about the z axis scale r, 2*a, r scale in x, y, and z cylinder vertical cylinder of length 1, radius 1
; ; left move -a, 0, 0 move in x, y, and z scale r scale X, y, and z by r sphere sphere of radius 1
; ; right move a, 0, 0 scale r sphere
}
Special variables can be denoted as “parameters.” When the interpreter is running, mod ification of parameters automatically results in the re-execution of all program statements dependent upon those parameters. New values for parameters can be specified by enter ing them in the interpreter through the keyboard or by continuously modifying external input devices (e.g., joysticks, dials, light pens). The devices are represented as parame ter variables with specific names in the language. These device variables can be used in expressions like any other variable. When a device is used, the corresponding variable is modified and any expressions dependent upon that variable in the model are re-executed.
41 The tube model can be modified as follows:
{ ; ; tube parameter scalar a=2, r=l ;; initial values set to 2 and 1 parameter scalar dx=0, dy=0, dz=0, spin=0 move dx, dy, dz rot spin y ; ; rotation about y axis { ; ; center
}
}
The position and rotation of the modified tube model can be controlled by assigning
new values to dx, dy, dz, and s p in . In the code firagment below, these variables (with
the exception of dy) are modified by device variables corresponding to number wheels on
a tablet (w heelx, w heely) and a deflection about the z-axis of a joystick.
dx += wheelx dz += wheely spin += joyz
At any time, the values of all the parameter variables in the model can be saved in a pa
rameter database. Thus, the database represents the state of the model at a particular instant
in time. The authors note that there is “no method for accessing previous or subsequent values of a parameter, or its rate of change” which is necessary for certain computations including dynamics.
An implementation detail employed with EM is worth noting. In order to provide the fastest possible execution of the model procedures, only the statements dependent upon the parameter or parameters being modified are re-executed. This is implemented by building a dependency graph that specifies 1) for each line in the program, the parameters dependent
42 on that line; and 2 ) for each parameter, the lines dependent on the value of the parameter.
However, limitations of the dependency graph impose a serious limitation on the types
of models that can be described. Specifically, cyclic dependencies and for-loops cannot
be used. A similar approach is taken in Menv (Section 2.5), but in Menv programs are
“unrolled” — entities such as for-loops are expanded so that for-loops can be permitted in
model procedures (although other limitations still exist and are described in [ 111]).
2.5 Menv
Menv is an animation and modeling system developed at Pixar [III]. This system was
used to develop the Oscar winning short film Tin Toy [ 106] and the first feature length,
computer animated film. Toy Story [115, 138].
The foundation of the system is a sophisticated procedural language called ML (See
Section 2.5.1). A particularly significant feature of the language is the concept of artic
ulated variables which are described in more detail in Section 2.5.2. A distinguishing
characteristic of the animation system is the “tool oriented” approach to its development.
Instead of providing one large program that attempts to encompass all of the desired func
tionality of an interactive animation system, tasks are broken into small, modular tools that
are easier to implement and maintain.
2.5.1 ML
ML has syntactic and semantic similarities to the general purpose programming lan guage C [ 6 8] and the EM language described by Hanrahan and Sturman (Section 2.4). The language supports a wide variety of geometric shapes (including quadrics, bicubic patches,
43 and polygons) and geometric operators. Like EM, blocking (delimited by braces) is used to localize the effect of both local variables and geometric transformations.
The program below, written in ML, specifies a simple model for a “snowman” com posed of several spheres. The argument to the sphere primitive is the radius of the sphere.
The arms are built to swing (rotate) in opposite directions based on the value of an artic ulated variable named arm sw ing. This model code is a variation of the model given in [ 111].
avar armswing; sphere {3 ) ; /* bottom */ translate (0,0,5); sphere (2); /* middle */ { rotate (-armswing, y) translate (2.5,0,0); sphere (.5); /* right arm */ } { rotate (armswing,y); translate (-2.5,0,0) /* left arm */ sphere (.5); } translate (0,0,3); /* head */ sphere (1);
2.5.2 Articulated Variables
Articulated variables, also known as avars, combine the interactive capabilities of the device variables described in EM (Section 2.4) along with the higher functionality of new tons as described by Reynolds (Section 2.2). Also related are the animated variables in
Cinemira (Section 2.3), although articulated variables are more primitive in that avars are
44 only used to represent scalar (real) values and do not specify attributes such as the time range over which the variable is active.
Like newtons, avars are time-dependent and defined by a piecewise cubic curve. The curve is defined by a set of key frames. Each key frame specifies a time, a value, a type
(used to determine the type of interpolation to perform), and possibly other information dependent upon the type (e.g., slope information). The key frames for each articulated variable are stored in a database called the cuesheet which is similar to the database utilized with EM.
Most importantly, avars can be directly and interactively modified using the interactive tools of the Menv system which include spline and spreadsheet type editors.
2.6 Other Recent Procedural Animation Languages
2.6.1 MML
MML is an extension of C for rule-based procedural models [49]. In particular, the au thors were interested in building a system to experiment with concepts and techniques, such as fractals, particle systems, and graftals, for modeling natural phenomena. The system was designed for models that compute the shape and motion of complex objects through incre mental simulation. The language is fairly conventional although it has an interesting feature
— the procedural specification of a model can be used to automatically generate interactive interfaces to allow the user to more easily experiment with the model. The interface gener ated consists primarily of a window in which computed animations can be viewed and an area containing sliders for interactively adjusting the initial parameters of the simulation.
Once the parameters have been set, the user starts the simulation. When the simulation has
45 completed, it can be viewed in the viewing area. Parameters cannot be adjusted during the simulation, thus the interactive capability is quite limited.
2.6.2 GENMOD
Snyder gives a powerful, mathematically robust system and procedural language for geometric modeling in [125]. His system, called GENMOD, operates on a single primi tive type — themanifold. Manifolds primarily represent rectilinear, parametric surfaces although the representation works equally well with entities of other dimensions including curves and geometric solids. All operations are closed with respect to the manifold type.
This allows complex shapes to be defined from simple shapes and complex operators to be built from primitive operators. Symbolic operators include differentiation, integration, re-parameterization, function inversion, vector and matrix operations, constraint solution, constrained minimization, and ODE solution (ordinary differential equation). Only rudi mentary facilities for animation and interactive manipulation are provided.
2.6.3 Wavesworld
Johnson uses an agent-based approach to model characters with autonomous behav ior in a system called Wavesworld [64]. He uses a procedural language called Eve that is a extension of TCL [98]. Eve augments TCL with commands for specifying geometry and surface attributes that directly map to commands provided in the RenderMan Interface
[107]. The language provides data types and mathematical operations useful for computer graphics. Articulated variables (Section 2.5.2) are used to to animate models over time.
46 Sophisticated interface elements can be built using his extensions to TCL which take ad vantage of facilities provided by the NEXTSTEP operating system on which the system was implemented. The interfaces can be customized for each model and allow the user to debug and experiment with model parameters. Perhaps most importantly, Johnson illus trates an approach where a variety of agent types can be used to implement motor planning activities — the lowest level of task-level animation as defined by Zeltzer [143].
2.7 Conclusion
Table 2.1 itemizes the origin of major concepts used in the development of this research related to the work described in this chapter.
concept(s) ______system/source ______Graphics state, graphics data types and EULER-G. operators, multiple levels of detail. Continuous, interactive manipulation of GRASS, EM. the procedural specification of objects. Encapsulation of behavior. DALI, ASAS, Cinemira, Wavesworld. Articulation functions. A generalization of the articulated variables of Menv. Exposure sheet. EM database and cuesheet of Menv. Tool-oriented software system. Menv.
Table 2.1: Relation of previous work to this research.
47 CHAPTERS
Articulation Functions
Articulation functions (or afuncs) are a new programming mechanism for procedural modeling and animation languages. They are called “articulation” functions because they are used to interactively articulate (specify or animate) various parts or aspects of a proce dural model. Articulation functions are a generalization of the avar concept described in
Section 2.5.2.
We can use a simple metaphor to help illustrate the relationship between afuncs and procedural models. We can think of a procedural model as actually being built out of physical materials, like LEGOs or an erector set. The physical model consists of movable and immovable parts. The movable parts, like wheels, gears, hinges, and motors, determine how the model can move. But the range of motions that the model has is dependent on how the model is built and how those parts are used. A person can play with the model by moving certain, reachable parts, turning knobs, or flipping switches. In a procedural model, afuncs are the “reachable” parts that we want to move; the knobs, hinges, or control pads that specify how we want the model to operate at any given point in time. We can manipulate the afuncs to interactively operate a procedural model much as we would use our hands to manipulate an actual model. In software engineering terms, afuncs provide
48 Figure 3.1: LEGO model. The arm lifts up and down and the claws retract using pneumat ics. Two switches on the side of the model control the direction of air-flow and a compres sor (the vertical, black, cylindrical shape in the center with spring) pumps air through the system.
a public interface to aspects of the model that are interactively controlled. And, digital, procedural models have features that “real world" models usually do not have. One of these features is that we can program the afuncs of a model to animate the behavior in specific ways over a period of time.
This chapter discusses the articulation function language mechanism in detail. Sec tion 3.2 discusses the basic syntax and usage of articulation functions. The fundamental properties of afuncs are discussed in Section 3.3. Later sections discuss the exposure sheet database, the different types of afuncs available in AL, and significant implementation de tails. Finally, Section 3.7 summarizes the features of articulation functions and describes the advantages of them over avars.
49 3.1 Preliminary Concepts
Before the discussion of afuncs begins, there are some preliminary concepts that need to be mentioned.
3.1.1 The World Model
The world model refers to the root of the scene hierarchy (i.e., the body of the world model contains all other models in the scene). In AL, the world model is defined using a special syntactic form called world.
(world all o f the models in the scene )
In the program below, for example, the world model contains two objects: a torus that is colored yellow and is rotated about the j/-axis by 45 degrees; and a scaled, translated box with a “marble” surface appearance. Theseparator statement is used to localize the effect of operators (e.g., color) to the geometry defined within the separator.^
(world (separator (color 110) (rotate 45 y-axis) (torus)) (separator (surface "marble") (translate 4 0 0) (scale 0.5) (box) ) )
^See Chapter 5 for a complete discussion of separators, the graphics, state, and the order in which trans formations are applied.
50 When theworld statement is evaluated (i.e., executed), two things happen:
1. The expressions in the body of the world model are explicitly evaluated. This results
in the rendering of the world model to an interactive display device. Models of
modest complexity can be evaluated and displayed in real-time.
2. An unevaluated form of the world model is retained so that it can be implicitly re
evaluated at a later time when necessary.
Why is it necessary to keep a retained world model? Evaluation of models in AL is done in an immediate-mode style [93]. The evaluation of each geometric operation (e.g., color or rotate) and each geometric primitive (e.g., torus) results in the immediate issuance of drawing commands for a specific rendering device. But, unlike database-oriented sys tems, such as Openlnventor [141], there is no explicit creation of a scene database or display list. No additional record (outside the procedural specification of the AL program itself) is kept of the commands executed to render the scene. The database, as it were, is the
AL program for the world model. Therefore, to redraw the scene, we need to be able to re-evaluate the world model in its procedural form.®
Implicit evaluations of the world model are required when output is needed for display in another device (e.g., a photorealistic renderer) or to automatically reflect a change in some external dependency (e.g., modifications to global time or afuncs) that affects the animation of the world model.
^However, individual rendering devices may cache display information in databases so that model eval uation is not necessarily required. For example, the Ogre tool uses OpenGL display lists [93] to efficiently redraw the scene when only viewing parameters (e.g., eye point, field of view, etc.) change or when window system events occur.
51 3.1.2 Global Time
Nearly all models in AL are implicit functions of global time. Global time is stored in a variable called time. In AL. global time is unit-less. However, since animation is often measured in terms of frames, time often stores the current frame number. It is important to note, however, that time is a real number and can therefore denote fractional values. Modifrcations to time result in an implicit evaluation of the world model. External processes can assign new values to time, but within the world model, time is considered
“read-only” (i.e., values cannot be assigned to it).
3.1.3 Variable Bindings
The term “binding” is used to refer to the process of attaching a value (actually a storage location) to a variable in a programming language. We often say that a variable is “bound” to a specific value or expression.
In Scheme, thelet statement establishes a set of variable bindings that are local to the
(body) of the let statement.
(le t (((variable) (value)) ...) (b o d y ))
In Scheme, functions are first class objects which means that they can be manipulated like other primitive data types including being bound to variables.
For example, we can bind the trigonometric cosine function to a variable x and then call X as a function applied to the real value 0. The result of evaluating (x 0 ) is 1.0. The result of evaluating the lot statement is the value of the last expression in the (body) of the let.
52 (let ((x cos)) (X 0 ) ) = > - 1.0
Conceptually, if the variable x was not bound, we would expect an error.
(let ( (xundefined) ) (X 0) ) = > e r r o r
But it turns out that this is exactly the method used for articulation functions. Articu lation functions are dynamic entities. As such, one of the properties of afiincs is that the bindings in a model are left unspecified. The semantics of afiincs are illustrated in greater detail in the next section of this chapter.
3.2 Basic Syntax and Usage
“The standard animation test for all beginning artists was to draw a bouncing ball. It was quickly rendered, easily changed, and surprisingly rewarding in terms of what could be learned.” From The Illusion of Life [133].
3.2.1 Building Models
The central constmct used to build models in AL is a special syntactic form called model. In its simplest form, the model construct defines a new, named, procedural model in the scene hierarchy and specifies the commands that draw that model. The code fragment below creates a model named “ball” that draws a sphere that is translated one unit along the y-axis.
(model "ball" () (translate 0 10) (sphere))
53 Themodel construct preserves the graphics state. In the example above, the translation will not affect any other object in the scene. Further, models may be nested within each other thus providing an efficient and concise means for specifying hierarchical entities.
The “ball” model above is static. When this model is evaluated, the sphere will always be placed one unit along the y-axis with respect to its local coordinate frame. Alternatively, the position of the sphere could be specified procedurally. It might be reasonable to define the position of the ball by some function. For example, we could simulate the bouncing motion of a perfectly elastic object under some pseudo-gravitational force with the function bounce{t, A) = | sin( 7rf(l/A))|, wheret represents the current time or frame number and A specifies the bounce wavelength (i.e., the duration of a single bounce in frames).
In AL, the “bounce” function can be encoded as
(define (bounce t wavelength.) (abs (sin (* PI t (/ wavelength) ) ) ) )
In Figure 3.2, the model b a l l has been rewritten to use the function bounce. We now have a dynamic model that varies (moves) depending on the current value of time
(Section 3.1.2) as shown in Figure 3.3.
(model "ball" () (translate 0 (bounce time 30) 0) (sphere))
Figure 3.2: Ball model where the vertical position (height) of the ball is determined proce durally.
54 Figure 3.3: Graph of (bounce tim e 3 0 ) over frames 0 to 150.
3.2.2 Using Articulation Functions
Procedural specifications of motion can be useful, but it is sometimes more desirable to control the motion “by hand” through the use of interactive tools (either software or hardware).
Articulation functions are a useful mechanism for interactive manipulation of models.
The primary purpose of the model construct is to specify one or more articulation func tions.
The general syntax for model is:
( m o d e l n a m e ((afiincs)) (body)) where name is a string denoting the logical name used to identify the model, (body) is an arbitrary number of expressions, and (afiincs) is a list of afimc declarations. Each afunc declaration has this form:
( (variable) ty p e (optional arguments) )
55 Thetype is a string that specifies the type (or class) of the afunc being declared. Three
pre-defined types (discussed in detail in Section 3.5) are described in this document: “chan
nel,” “gcurve,” and “raster.” New types can be defined using the mechanisms described in
Section 3.6. The optional arguments are specific to each afunc class and allow certain
aspects of the afunc to be controlled.
We can rewrite the ball model (Figure 3.4) to use a particular type of afunc called a
channel (See Section 3.5.1 for a detailed description of channels). Channels are time-
dependent functions that return a scalar value. In this case, a channel is bound to a variable
h e ig h t that is used to position the sphere. Note that h e ig h t is used in the model body
as a function which, syntactically, is denoted by the surrounding parentheses.
(model "ball” ((height "channel”)) (cranslate 0 (height) 0) (sphere))
Figure 3.4: Ball model where the vertical position (height) of the ball is determined by a channel afunc.
The value of a channel is defined by a sequence of keyframes or simply keys. In tra
ditional animation, a master animator draws the key frames of an animation. These are
frames that dictate significant changes in the action of a scene. Then, less experienced ani
mators use the key frames as a reference to draw all the “inbetweens” (the frames between
key frames) required for recording to film.
In a channel, each key specifies the exact value of the channel at a specific point in time.
The value of the channel at times between keys is automatically inbetweened using one of
56 a number of interpolation schemes. When a channel afunc is applied with no arguments,
(as in the second line of Figure 3.4), the value of the channel is determined based on the current value of time. A more detailed discussion of channels follows in Section 3.5.1.
Note that the definition of the height: channel (i.e., the specific channel keys) is not given in the model program. Instead, the definition is stored externally (in a database called the exposure sheet) where it can be modified by external processes such as an interactive channel editor (See Section 3.5.1) or an external hardware device (e.g., motion capture hardware).
3.2.3 High-level Control
Articulation functions are often used for high level control. In Figure 3.4, a channel was used to manipulate a single aspect of the ball model (the vertical translation of the ball).
One of the primary advantages of procedural specification is that individual parameters can control multiple aspects of a model. In this section, we illustrate the use of a single channel to control three parameters of the ball model: the x, y, and z scaling of the sphere.
One of the fundamental principles of animation is called “squash and stretch [72, 133].”
The main idea behind the squash and stretch principle is that objects should preserve vol ume when they are deformed.
We can implement a simple squash and stretch deformation on a sphere by scaling the sphere along the x-axis and the z-axis based on a high-level “squash” control that directly scales the sphere along the y-axis such that the volume of the sphere is preserved.’
^The “squash and stretch sphere” deformation has been suggested elsewhere [40, 111].
57 The sphere gop in AL creates a unit sphere (i.e., the radius is 1). The volume. Vs, of
a unit sphere is simply K = tt. AfSne scaling of the a sphere will result in an ellipsoid.
The volume, %, of an ellipsoid is given as K = Trafic. The scaling along the x and z-axis
of the ellipsoid will be uniform, a = c, and so = Tra^fi. To ensure that the volume of
the sphere is preserved as it is deformed into an ellipsoid, we set thus tt = Korb.
Simplifying this equation, we get
fi > 0 (3.1)
In Figure 3.5 we use Equation 3.1 and a new channel afunc called “squash” to control a squash and stretch deformation on the sphere. The deformation is applied with the scale gop which has three arguments representing the scaling factor along each axis. The y- axis factor is specified as (sq u a sh ) (fi in Equation 3.1) while both the x-axis and z-axis factors are specified as ( / ( s q r t ( sq u a sh ) ) ) (a in Equation 3.1). “Squash” channel values less than 1 will flatten out the sphere, values greater than one will stretch the sphere, and a value of exactly 1 results in no deformation. Channels, by default, evaluate to zero if no channel keys have been specified. The optional arguments shown in the declaration of the “squash” channel, 'd e f a u l t 1 , change the behavior so that division by zero is avoided even if no keys have been specified for the chaimel.
3.2.4 Shape Modeling
There are other types of afuncs in addition to channels. For example, gcurves are used for interactive manipulation and animation of geometric curves. We can use a gcurve, for example, to replace the sphere in Figure 3.5 with a surface of revolution [17, 16, 100].
58 (model “ball" ((height "channel") (squash "channel" 'default 1)) (translate 0 (height) 0) (scale (/ (sqrt (squash))) (squash) (/ (sqrt (squash)))) (sphere))
Figure 3.5: Basic “squash and stretch” ball model.
(model "vase" ((height "channel") (squash "channel" 'default 1) (profile "gcurve")) (translate 0 (height) 0) (scale (/ (sqrt (squash))) (squash) (/ (sqrt (squash)))) (surface-of-revolution (profile)))
Figure 3.6: Squash and stretch surface of revolution.
When a gcurve afunc is evaluated, a set of control vertices defining a geometric curve is returned. In Figure 3.6, the function s u r f a c e - o f - r e v o l u t i o n takes a profile curve and draws a bicubic, B-spline patch mesh that represents the surface created by revolving the profile curve about the y-axis.
3.3 Properties of Articulation Functions
So far, two types of articulation functions have been introduced, channels and gcurves.
The set of types of afuncs is open-ended. There are potentially many more types of afuncs that would be useful for procedural modeling and animation. It is important to that end that we define a number of properties common to all articulation functions.
59 3.3.1 External Binding
The most important property of articulation functions is that the specification for each
afunc is externally defined (or “bound”). The model in Figure 3.6 declares several afuncs.
But note that only the type of each afunc is given. The actual specification is omitted. In
fact, it is illegal for the values of afuncs to be bound anywhere within the world model.
Inside the world model, afuncs are considered “read-only” after they have been declared
— they are treated solely as inputs.
In a procedural modeling and animation language, the results of computations are used
to specify shapes and operations on shapes (e.g., transformations, material properties, etc.).
These computations can be directly or indirectly tied to articulation functions. The pri
mary benefit of externally binding afuncs is that it allows us to separate certain dynamic
properties of a procedural model from the definition of the model itself.
With external binding of afuncs, we can manipulate a procedural model without chang
ing the code that implements the model. The result is that afuncs can serve as a mechanism
for:
• interactive manipulation of procedural models through real-time hardware devices
and interactive software tools; and
• specifying different instances of animation for the same procedmal model or models.
3.3.1.1 Interactive Manipulation
The bindings for all afuncs are maintained in a special object called the exposure sheet.
The bindings in the exposure sheet can be manipulated between evaluations of the world
model. Each time a model is evaluated, the bindings for the model are derived directly firom
6 0 Interactive tool Interactive tool
read/write read/write
exposure sheet (afunc bindings) read-only read/write world model
procedural program wrife-only
hardw are Input device
Figure 3.7: The relationship between the exposure sheet and other components of the AL run-time environment. The arrows indicate how components modify afunc bindings stored in the exposure sheet.
the exposure sheet. Thus, a modification of the bindings will result in a different evaluation
(and display) of the model.
In this way, the exposure sheet acts as sort of a central clearing house for interactive manipulation of the world model (See Figure 3.7). Interactive software tools (e.g., gcurve or channel editors), external hardware devices (e.g., a MIDI keyboard, a 3D digitizer, or a motion capture device), and also non-interactive, procedural programs (e.g., a program that automatically re-times afuncs to fit into a shorter or longer range of frames) can directly modify the articulation functions stored in the exposure sheet and thus implicitly affect the evaluation of the world model. When an afunc binding is modified, event messages are automatically generated and sent to other processes in the AL run-time environment. When these messages are received, the world model is automatically re-evaluated and the display of the new world model is shown.
61 In the current AL run-time environment, the process of modifying afuncs and re-evalua ting the world model can be repeated fast enough, for modestly complex models, to provide interactive feedback.
3.3.1.2 Instances of Animation
Recall the “ball” model shown in Figure 3.4 that translates a sphere vertically over time. In this case, the vertical (y-axis) value of the translation is the value returned by the function h e ig h t. There are a number of ways in which that bouncing ball model can be animated (i.e., the specific ways in which the translation can be applied). The ball could be animated (i.e., the afimc bound to h e ig h t could be defined) so that it bounces like a iron cannon ball or like a ping pong ball. The definition of the model is the same: a sphere is translated vertically. But, we can create more than one instance of animation. That is, we can create multiple animations of the bouncing ball by simply specifying different bindings for the variable h e ig h t. This concept is described further in Chapter 4.
3.3.2 Lexical Scope
Articulation functions are declared using the model construct. Like Scheme’s l e t statement, the model statement in AL provides a block structure where articulation func tions declared in the model statement obey the conventional programming language rules of lexical scoping (also known as “static” scoping). The lexical scoping rules of afuncs are:
• The scope of an articulation function includes the body of the model in which it is
declared, but not any models surrounding it.
62 • The scope of an articulation function includes the body of any models within the
model for which the afimc is declared except any models that declare a new afunc of
the same name.
Figure 3.8 declares a scene containing a room that contains a table. A lamp rests on the table along with a bouncing ball. The intensity of the lamp and the shape of the base of the lamp are controlled by two afuncs, i n t e n s i t y and shap e, that are visible only in the body of the lamp model. The table’s h e ig h t chaimel is accessible within the body of the table model including the body of the lamp model. However, within the body of the ball model, the locally declared h e ig h t has precedence and represents the position of the ball as it bounces.
(world (model "room" () (model "table" ((height "channel")) (model "lamp" ((shape "gcurve") (intensity "channel"))
) (model "ball" ((squash "channel") (height "channel"))
))))
Figure 3.8: A code fragment for a simple model hierarchy.
3.3.3 Naming
The first argument of the model construct is the model name. In addition to making models and model hierarchies more human-readable, model naming is necessary because each articulation function must be associated with a unique identifier. The unique identifier
63 provides an addressing scheme that allows external processes to refer to declared articula tion functions so that the definitions of the articulation fimctions can be modified.
Thescope-name of a model is the name of the model qualified by the concatenation of the names of aU the models containing that model. The scope-name of an afunc is simply the name of the afunc prepended by the scope-name of the model that declares it.
In AL, strings are commonly used to store scope-names in which case we separate the concatenated names by a slash “/.” For example, in Figure 3.8, the ball model’s scope-name is “/room/table/ball.” Sometimes, it is more convenient to store scope-names in Scheme lists. For example, the model just mentioned could also be represented as ( "room"
"table" "ball").
3.3.4 Typing
Although Scheme is a dynamically typed language, the “type” of articulation variables is specified in the model. Typing is necessitated by the property of external binding. Nor mally, the variables in a Scheme program are bound directly to objects. Because Scheme is dynamically typed, each object contains information about its type. But, because afuncs are bound externally, we cannot determine the type by directly examining the object that the variable is bound to. Thus “typing” is necessary for two reasons: 1) to provide the model writer with some knowledge of the semantics of particular types of afuncs (since the functional definition is external); and 2) to allow external processes (e.g., interactive tools) to intelligently reference and modify afunc bindings.
64 3.3.5 Instance Parameters
When an articulation function is declared, an instance of a particular type of articulation function is created. Each instance of an articulation function is defined by two types of pa rameters: fixed parameters and free parameters. The differentiation between the two types of parameters is where the values of the parameters are specified and how the parameters are used. Fixed parameters are specified when the afiinc is declared (as optional arguments in the declaration) and are part of the internal implementation of the model. Free parame ters are specified in the exposure sheet and are manipulated by the user (e.g., an animator) of the model — they represent the aspects of the afunc that are externally controlled.
Consider the “squash and stretch ball” model in Figure 3.5. The keys (frame-value pairs) of the squash channel afunc are firee parameters. Keys are usually specified interac tively and different keys result in different animations of the model. However, regardless of how the ball is animated, an appropriate default value for squash is 1 because it rep resents an undeformed sphere (a natural default state) and it avoids division by zero (See
Equation 3.1). The default value is an example of a fixed parameter. Fixed parameters are inherent to how the model is built and are therefore specified by the programmer of the model, rather than the user.
3.4 The Exposure Sheet
The bindings for all articulation functions (in the current world model) are maintained in a special entity called the exposure sheet or “X sheet.” This terminology is from tra ditional cell animation where a printed, ledger-like sheet of paper (Figure 3.9) is used to document, for every frame of an animation, various aspects of how the animation is to be
65 ^o$r/c/77s/)r /
S^À Z/3S6) ± IL. iSiSST O '.ë^ L3UÉ/& fO ZSL 3 n E /&2 Z&S /MT-df z z // A6Wi S. Î z z z c Figure 3.9: Traditional animator’s exposure sheet. From [10]. filmed [75]. This includes how each frame is to be photographed and descriptions of the actions and sounds occurring each firame. Likewise, the exposure sheet in AL completely specifies the values of all afuncs for every firame in the animation. In AL, the exposure sheet is essentially a hierarchical look-up table. When models are evaluated, afimcs (Scheme procedures) are dynamically retrieved from the exposure sheet 66 and bound to the variables declared using the model statement. The exposure sheet is rebuilt each time a new world model is defined (via the world statement). Programs outside the world model can access afunc bindings stored in the exposure sheet and modify them between evaluations of the world model. Programs that modify the definitions in the exposure sheet may allow both interactive and procedural specification controlled by the user. In some cases, an afimc may be initialized procedurally (e.g., from the results of a physical simulation or mathematical expression) using one program and then “tweaked” interactively using another program to achieve a procedurally-based, but animator-controlled effect. The contents of the exposure sheet can be saved to a file for permanent storage. The model hierarchy and the free parameters (Section 3.3.5) for each articulation function are written to the file in a human-readable format. By storing the free parameters, the afuncs can be reconstructed when the exposure sheet file is loaded. The exposure sheet file shown in Figure 3.10 shows the bindings for the afuncs in the simple model hierarchy declared in Figure 3.8. 3.5 Articulation Function Classes There are 3 articulation function classes discussed in this document: • Channels — time-dependent scalars • Gcurves — time-dependent, three-dimensional geometric curves • Rasters — time-dependent, two-dimensional grids of scalar values 67 AL Exposure Sheet AL version 5.0.2 10/8/97] Written Wed Oct 15 11:05:20 1997 (model "world" (model "room" (model "table" (channel "height" ()) (model "lamp" (gcurve "shape" ( (1 ( #<-1 0 0 1> #<-1 1 0 1> #< 1 1 0 1 > #<1 0 0 1>)))) (channel "intensity" (1 0 L) (70 1.5 L)))) (model "ball" (channel "squash" ( (1 0 L) (15 1.5 -4 0 4 0 Z) (30 1 L))) (channel "height" ( (1 0.5 L) (15 4.72 L) (30 2.1 L))))))) Figure 3.10: Sample AL X-sheet file. 68 bezier keys handles bezier key linear key a value time Figure 3.11: Conceptual diagram of a channel. 3.5.1 Channels Channel afuncs are similar to the animation channels or tracks found in many animation systems [43,48], but are most closely related to the avar mechanism in Menv (Section 2.5). A channel provides a time-varying, one-dimensional, scalar (real) value. Recall from Section 3.2.2, that channels are defined by a sequence of keys (See Fig ure 3.11). Each key represents the value of the channel at a particular point in time. An interpolating spline is used to compute values for times between keys. The interpolating spline is a piecewise cubic spline that allows the type of each control point to be varied so that different types of interpolation can be performed per key. Currently two types of interpolation are used: linear and Bezier. Bézier keys have slope (ease-in/ease-out) control in the form of “handles.” Handles are specified by a time and value relative to their associated key time and value. Each Bézier key has two handles, although conceptually, the first and last keys only use one handle. Thus, linear keys are defined simply by a time-value pair, (time, value). Bézier 69 keys, however, are a 6-tuple: {time, value, lefi time A, value A, right time A, right value A). 3,5.1.! Declaration Channels are declared using the model statement (Section 3.2.2). Various aspects of a channel’s behavior can be controlled by specifying one or more fixed parameters (Table 3.1) in the parameter list of the declaration. name default class description d e f a u l t 0 fixed The value of the channel when no keys are specified. map f{x) —X fixed A procedure that maps the output of a channel to some new range, k ey s empty list free A list containing the keys defining the channel over time. Table 3.1: Channel parameters. Channels with no keys evaluate to zero. Zero is sometimes an inappropriate default value. For example, in an articulated figure for a human, the model builder might want to give a default pose that has non-zero joint angles. The value of a channel with no keys is defined by the d e f a u l t parameter. So, if we want to set the default angle for the elbow joint in a human model to be 180 degrees, we might use the following declaration: (model "human" (...) (model "forearm" ((elbow-rotation "channel" 'default 180)) (elbow-joint-transform (elbow-rotation)) forearm-geometry ) ) 70 It is often convenient to clamp the output of a channel to some range, normalize the output to some new range, or perform some other mathematical mapping on the value computed from the channel keys. A mapping can be specified using the map parameter which allows an arbitrary procedure (function) to be specified. The only requirement for the procedure is that it must take a single, scalar input value (the value of the channel) and it must return a new scalar value. In Figure 3.5, any zero or negative value for sq u a sh creates havoc. The model builder might decide, for example, that it is reasonable to limit the range of values returned by the s q u a s h channel to 0.01 to 2. This can be declared as follows: (define clamp-squash (lambda (x) (clamp x 0.01 2))) (model "ball" (... (squash "channel" 'map clamp-squash))) Such mappings could be specified in the body of the model rather than in the afunc dec larations. The primary advantage of specifying mappings in the declaration of the afuncs is that interactive tools (which access afuncs externally) will then also have access to that mapping and can then provide more intuitive display and manipulation of the afimc. 3.5.1.2 Usage Channel afuncs have three primary usages: • (name) — Evaluates name using the current value of the global variable time. • (name t) — Evaluates name at time t. • (name ' d e r iv t) — Evaluates the derivative of name at time t. The second form allows a channel to be sampled at an arbitrary point in time. Animals and people tend to look ahead in anticipation of where they want to move. This “look 71 ahead” characteristic can be built into a model by sampling the channels that specify the motion path at some time value sufficiently far in the future. A vector that specifies the direction that the creature is looking (in anticipation of going there) can be computed by subtracting the current position from the future position. The third form computes the first derivative of the channel with respect to time at the specified point, t, in time. The derivative can be used for a variety of purposes such as aligning a figure tangent to a motion path or computing a deformation based on the velocity of an object. 3.5.1.3 Computation This section discusses the computation of the value of a channel assuming we have a set of key points. In the trivial case, where no key points are defined, the value of a channel corresponds to the d e f a u l t parameter shown in Table 3.1. Computation of the non-trivial case is below. In both cases, the value of the channel is then filtered through the map function also shown in Table 3.1. Computing the value of the channel at a given time, f{t), is fairly straightforward. Let us assume that all the keys are Bézier.* Recall that channels are piecewise bicubic. Figure 3.12 shows a hypothetical channel and the time t at which we want to sample it. Note that the keys labeled a and d surround t. Let aume and a„aiue be the time (temporal value) and value (spatial) respectively at which keya is defined. Then the surrounding keys a and d are the two keys such thataume < t < dume- The interior handles are labeled 6 and c in Figure 3.12; h is the right handle of a and c is the left handle of d. *Linear keys can be easily transformed into Bézier keys. The Bézier equivalent key is the same as the linear key (i.e., same time-value coordinates) with degenerate handles (i.e., handles that are in the same position as the key). 72 key interior handles value key time t Figure 3.12: Computing the value of a channel at time t. a and d are the keys, b and c are the “interior” handles. We are actually dealing with two splines: one that is based on the times at which the keys are defined (the temporal spline) and one that is based on the values at which the keys are defined (the spatial spline). Let T{u) and S{u) be the polynomials representing the temporal and spatial Bézier splines® respectively; in both cases, u is defined over 0 to 1. T{u) is composed of these four control points: atime, bume, Cjtme. and dume- And likewise, iS('u) is composed of c^aiue^ and We are sampling the channel given time t, so we solve for u such thatT(u) = f.*® Any numerical technique for solving non-linear equations will suffice (e.g., bisection or Newton’s Method [46]). Given u, the value of the channel att is f{t) = S{u). ^See [37] for a description of the formulation of polynomials for Bézier curves. ‘°There is exactly one solution for u because channels, by definition, are one-to-one and onto functions of t. To maintain that property, however, we must maintain the invariant that T(u) is monotonically increasing for u E [0,1] for all operations on a channel. If the derivative of T(u) contains no roots (no solutions for T'{u) = 0), we know that T{u) is strictly monotonie. Then if dume > oume. T{u) is monotonically increasing. 73 3.5.1.4 Interactive Tool: Chant In the AL run-time environment. Chant is a tool for interactive manipulation of chan nels. Chant supports two modes of interaction: a spreadsheet mode and a graphical spline mode. Chant offers similar functionality to tools found in non-procedural animation sys tems. Figure 3.13 shows the spreadsheet mode of Chant. On the left side of the tool is a hierarchical display of the world model. Charmels to be manipulated are selected from that display. In the spreadsheet mode, each row of the spreadsheet corresponds to one channel. Each colunm corresponds a frame (time) where a key has been defined for any of the channels currently displayed in the tool. New keys can be inserted and existing keys can be deleted or modified by entering the values using the keyboard. In addition, an existing key can be modified interactively by clicking and dragging the mouse in the cell in the spreadsheet corresponding to the key. The values can be dragged at several different speeds for both gross adjustments and fine tuning of values. The spreadsheet mode is particularly useful for seeing how actions line up temporally and for precise setting of values. In the graphical spline mode (Figure 3.14), each channel is displayed as a curve. Time mns horizontally on the display while the value of the channel is shown vertically. Keys and handles can be interactively manipulated. The graphical spline mode is particularly useful for controlling the timing (ease-in and ease-out) of and the transitions between the keys. 74 Figure 3.13: Chant— editing channels in the spreadsheet mode. Figure 3.14: Chant— editing channels in the graphical spline mode. 3.5.2 Gcurves Channels are versatile articulation functions, but they are not good for interactively specifying curves in 3-space. Gcurves arc time-dependent, three-dimensional, geometric (“G”) curves. Like chan nels, gcurves arc composed of keys. Each key in a channel specifies a time-value pair where the value, a scalar, denotes the value of the channel at the specified point in time. 75 I profile g-curve path g-curve I dme.l (a) (b) Figure 3.15: Building shapes with gcurves: (a) the defining gcurves; and (b) the resulting shape. Each gcurve key also specifies a time-value pair, but the value is an ordered sequence of 3D control vertices (or CVs). Thus each key specifies the entire shape of the geometric curve at the specified point in time. Hence, the result of evaluating a gcurve at any point in time is a 3D curve composed of an arbitrary number of CVs. Figure 3.15 shows a vase shape that has been modeled using two gcurves. The vase is constructed as a surface of revolution. One gcurve is circular and specifies the “path” that the other “profile” gcurve is rotated about. These gcurves can be interactively modified which dynamically constructs a new surface of revolution. The shape of the vase can be animated over time by specifying additional keys, at different points in time, for the path or profile curve or both. The current implementation of gcurves uses piecewise cubic splines of arbitrary basis. Each CV is actually a 4D, homogeneous point — the first three components specify the position of the point in 3D space; the fourth component specifies a “weight” that can be 76 used to affect the interpolation behavior of the curve about the 3D point. Other curve formulations, such as NURBs, could be used to implement gcurves and would provide more flexibility at the cost of increased complexity of use. Gcurves can be specified as periodic (open) or non-periodic (closed). 3.5.2.1 Declaration Gcurves are declared using the model statement (Section 3.2.2). Various aspects of a gcurve’s behavior can be controlled by specifying one or more fixed parameters (Table 3.2) in the parameter list of the declaration. name default class description periodic? #f fixed A boolean that specifies whether or not the gcurve is periodic (i.e., closed). basis B-spline fixed The bicubic spline basis. step 3 fixed The spline basis “stepping” factor. keys empty list free A list containing the keys defining the gcurve. Table 3.2: Gcurve parameters. S.5.2.2 Usage Gcurve afuncs have these primary syntactic usages: {name) — Evaluates name using the current value of the global variable time. • {name t) — Evaluates name at time t. 77 Like channels, these two forms sample the gcurve as a function of time. In the former case, the gcinve is implicitly sampled using the value of the global variable time. In the latter case, the time is specified explicitly. The evaluation of a gcurve is a list containing zero or more control vertices. In the current implementation of gcurves and cubic splines, the CVs (4D, homogeneous points) are actually converted to lists of 3D points when the gcurve is evaluated. The homogeneous coordinate (the “weight”) introduces points of multiplicity (sequential points in the same position in 3-space). If the gcurve is periodic (i.e., closed), addition points required to explicitly close the curve are automatically included. This conversion work simplifies the task of the model writer that uses the gcurves because knowledge of weights or periodicity is not required. 3.S.2.3 Computation The computation for gcurve evaluation uses a simple interpolation scheme. We assume that the number of CVs for each key is uniform." Figure 3.16 shows two gcurve keys labeled A and B that represent the shape of the gcurve at two different points in time. To compute the interpolated value of the gcurve labeled C, we perform cubic interpolation (/(%) = Zu^ — 2u^) on the 3D points of the (time-wise) neighboring curves A and B. Note that this type of interpolation is smooth and differentiable, but provides no control over the timing (ease-in and ease-out) between keys. It is a straightforward matter to use Bézier or some other form of cubic interpolation that would provide timing control. In that case we then need a minimum of 4 keys. ' ' A number of approaches can be taken if the number of CVs is not uniform including the insertion of one or more new CVs. 78 CV (control vertex) CV Figure 3.16: Gcurve interpolation. 3.5 2.4 Interactive Tool: Forge Figure 3.17 shows a labeled screen shot of an interactive tool for editing gcurves called Forge. It has basic spline editing capabilities (creating new gcurves, inserting, modifying and deleting CVs, and so on). Forge is different from most conventional spline editors in that it is time-based and thus allows the user to specify key frames for gcurves and then preview the animation of the gcurves over time. 3.5.3 Rasters Raster afuncs are used to interactively modify and animate two-dimensional grids of scalar values. Rasters can be used to manipulate terrain models, control vertices of patch meshes, and apply hand-drawn texture and details to geometric objects. Like channels and 79 name ol current cuive control hull ______ gcurve adive (adKatNe) gcurve Ume-1 Figure 3.17: Forge — interactive gcurve editing tool. gcurves, a raster consists of a set of key frames. But in rasters, each key consists of an n X m grid of discrete scalar values. 3.5.3.1 Declaration Rasters are declared using the nodal statement (Section 3.2.2). Various aspects of a raster’s behavior can be controlled by specifying one or more fixed parameters (Table 3.3) in the parameter list of the declaration. 3S.3.2 Usage Raster afuncs have these syntactic usages: • (name) — Evaluates name using the current value of the global variable tinn. 8 0 name default class description x s i z e 10 fixed The a: dimension of the raster grid, y s i z e 10 fixed The y dimension of the raster grid, d e fa u lt: 0 fixed The default value of elements in the grid, k ey s empty list free A list containing the keys defining the raster over time. Table 3.3: Raster parameters. • {name t) — Evaluates name at time t. Like channels and gcurves, these two forms sample the raster as a function of time. In the first case, the gcurve is implicitly sampled using the value of the global variable time. In the second case, the time is specified explicitly. 3.5.33 Computation When a raster is sampled, a Scheme vector containing the contents of the scalar grid in row-major order is returned. Interpolation for times between key frames is computed by interpolating corresponding grid points using a cubic spline. 3.5 3.4 Interactive Tool: Rasp Rasp (“raster paint”) has been developed for interactive modification of raster afuncs. Essentially, this tool is a low-resolution paint program. The mouse is used to directly paint pixels (i.e., grid values) using a semi-transparent bmsh. Pixels can be painted repeatedly to gradually increase their opacity. The variations in opacity (i.e., intensity) are directly translated to the normalized scalar values ([0,1]) in the two-dimensional grid. As with channels and gcurves, modification of the raster immediately results in dynamic changes 81 to parts of the world model that utilize the affected raster. In this way, various aspects of emodels can be interactively “painted.” For example, in an emodel for terrain, a raster can be used to interactively paint the altitude of hills, mountains and lakes. Another raster can be used to place shrubs, trees, and buildings on the terrain. An example emodel and a figure showing Rasp is given in Section 4.2.7, page 139. 3.6 Implementation In the implementation of a system that supports articulation functions, a number of issues must be addressed. Emphasis in this section is placed on implementing articulation functions and evaluation of the world model in a manner that is as efficient (time-wise) as possible. After all, the main purpose of afuncs is to provide a mechanism for interactive manipulation, so the speed at which the objects in the world model can be displayed is paramount. This section describes how the primary implementation issues, with regards to articu lation functions, are solved in the current version of the AL run-time environment. 3.6.1 A Word About Object-Oriented Scheme Programming In many cases, primary components of the AL run-time environment are implemented using object-oriented programming techniques. Although standard Scheme does not di rectly provide any mechanisms for object-oriented programming, object-oriented tech niques can be employed. In some cases. Scheme systems provide special language mech anisms for object-oriented programming by using standard Scheme methods for extending the language syntax. 82 AL uses the mechanisms described in [73] for object-oriented programming. To help understand the examples in this section that use object-oriented techniques, an overview of the main concepts used is given here. Classes are defined using define-class. In the definition, data members (“instance variables”) and super-classes (existing classes used to derive the class) can be specified. (define-class class-name . options) Member functions (methods) are specified using def ine -method which has a syntax similar to define. (de fine-method class {name arguments) . body) An instance of a class is created u sin g m ak e-in stan ce. For example, the code below creates an instance of a class named “foo” and assigns it to a variable called “bar.” (set! bar (make-instance foo)) To invoke a method of a class, the send command is used, send returns the value returned by the member function. (send instance message . args) 3.6.2 Definition and Evaluation of the World Model Evaluation of the expressions contained in the world model has two primary purposes: • to define the model hierarchy and articulation functions therein; and • to evaluate the geometric primitives and operations for display (to an arbitrary dis play device). 83 The model hierarchy is defined by constructing a special database called the exposure sheet. All of the articulation functions used in the world model are maintained in this database. Construction of the database is costly, so we separate it firom the task of evalu ation (i.e., display of the world model). Evaluation occurs frequently. Several evaluations per second are required to provide user-feedback when interactive tools are used to ma nipulate objects in the world model (via articulation functions). Table 3.4 compares the cost-frequency tradeoffs between model definition (which includes construction of the ex posure sheet) and model evaluation (display). computational cost frequency definition high low evaluation low high Table 3.4: Model definition vs. model evaluation. 3.6.3 World Model Definition Model definition occurs when the world model is explicitly evaluated using the world statement. This may seem obvious, but recall that the world model can also be evaluated implicitly in a response to a request to render the scene or in reaction to changes in global time or modifications to the exposure sheet. Model definition implies these actions: • The retained world model is saved. The code specified in the body of the world statement is stored in unevaluated form — we call this unevaluated code the retained 84 world model. Whenever we say that the “world model is evaluated ” we mean that the expressions (stored in unevaluated form) of the retained world model are evaluated. • The exposure sheet is constructed. The exposure sheet is constructed only during model definition. During model evaluation (evaluation of the retained world model), the exposure sheet structure is invariant (i.e., the model hierarchy is fixed). However, modification of the definitions of the afuncs in the exposure sheet is allowed between evaluations. • Any free parameters of pre-existing afuncs should be retained. If a new world model is defined, we do not want to lose the values for any afuncs that existed in the previous model definition. 3.6.3.1 The Retained World Model The retained world model is managed by an object-oriented class called the w o rld - c la s s . A single instance of this class is created and bound to a variable called _w orld- ob j . (In the AL implementation, system variables are generally preceded by an underscore to separate them from keywords and other global variables.) (define-class world-class (instance-variables the-world ) ) (define _world-obj (make-instance world-class)) 85 The world statement is a special form.'- The body of the world statement is not immediately evaluated. Instead, the expressions in the body are saved, in unevaluated form, by constructing a new procedure that has, as its body, the expressions in world statement — this new procedure is the retained world model. Special forms are declared using define-macro.'^ The unusual syntax and characters shown in the implementation of world below are specific to defining macros. (define-macro (world . body) ' (begin (send world-obj 'retain-world (lambda () ,@body)) (send world-obj 'define-world))) The simplified implementations of r e t a in - w o r l d , d e f in e -w o rld , and e v a l - w o rld are given below. Note that both d e f in e - w o r ld and e v a l- w o r ld evaluate the retained world model. The difference is that the model statement is temporarily redefined (via fluid-1er). In world definition, the model statement is used to help construct the exposure sheet. (define-method world-class (retain-world proc) (setI the-world proc)) (define-method world-class (define-world proc) ( fluid-let ( (model definition form of the model statement) ) (the-world) ) (define-method world-class (eval-world proc) ( fluid-let ( (model evaluation form of model statement) ) (the-world) ) *-A special form in Scheme is a statement that does not follow the normal rules of evaluation. Normal evaluation rules state that, in the case of functions, each argument of a function is evaluated and then the arguments are applied to the function. '^Other Scheme implementations use different commands for defining new Scheme syntax [33]. 86 3.63.2 The Exposure Sheet Data Structure The exposure sheet is implemented using a tree data structure. The exposure sheet is separate from the world model, but the tree structure directly mimics the scene model hierarchy. There are two types of nodes in the tree: model nodes and afimc nodes. The tree always contains a root model node that corresponds to the root of the world model. There exists a model node for each model declaration in the scene hierarchy. Model nodes contain 3 items: • model name — the name of the model as specified by the second argument of the model statement. The name is represented by a Scheme string. • afuncs — an ordered list of afimc nodes. Each afunc node in this list corresponds to one afimc declaration in the model statement. This list is sorted in the order in which the afuncs are declared. • sub-models — an ordered list of model nodes. Each model node in this list corre sponds to exactly one model declared in the body of the model statement. This list is sorted in the order in which the sub-models are declared. Afimc nodes are leaf nodes and contain 2 items: • afunc name — the name of the afimc which is a string representation of the name of the variable to which the afimc is bound. • afunc — the articulation function. 87 3.6.3 3 Exposure Sheet Construction The exposure sheet is constructed as the world model is evaluated during “world model definition.” Evaluation of the model statement is used to help build the hierarchical database. The model statement utilizes a stack data structure called the model stack. The top-most item on the model stack is the model node corresponding the the evaluation of the current model statement. Initially, the model stack contains a single model node cor responding to the root of the world model hierarchy. Recall the syntax for themodel statement: (m o d e l name ((afuncs)) (body)) When themodel statement is evaluated, the following actions occur: 1. Let w be a new model node corresponding to the model being declared. (A new model node contains no afuncs or sub-models.) 2. Add m to the list of sub-models for the top-most node on the model stack. 3. Pushm onto the model stack, (m is now the top-most item on the model-stack.) 4. For each afunc declared in the model statement: (a) Let a be a new new articulation function using the afunc make-(classname) member function. (b) If this afunc exists in the exposure sheet, inherit the values of the free param eters from the afunc in the exposure sheet using the afimc inherit member function. (c) Add a new afimc node containing a to the list of afuncs for the top-most model node on the model stack. 88 (d) Bind a to the corresponding variable in the afunc bindings of the model decla ration. 5. Evaluate the expressions in the body of the model. For each model statement en countered during evaluation of the body, the process is repeated recursively starting back at step number 1. 6. Pop the model stack. When the world model evaluation is completed, only the root node will remain on the model stack. At this point, the root node is recorded as the current exposure sheet. When the process is complete, a w o r ld - d e f in e d event is generated (Table 3.5) so that other processes can respond to changes in the world model hierarchy. event name description w o r ld - d e f in e d Generated whenever the world model has been redefined via theworld statement. p r e - w o r ld Generated immediately before evaluation of the world model. p o s t -w o rld Generated immediately after evaluation of the world model. Table 3.5: World object events. It is important to not build the exposure sheet destructively (i.e., in place of the existing exposure sheet) because it is possible that the world model will not terminate normally. A programming error, an infinite loop, etc. can cause evaluation of the world model to abort which would then corrupt the exposure sheet. Any free variables in the cormpted exposure sheet might be umecoverable which would mean that work spent creating afunc 89 keys would be lost. This is the primary motivation for creating a new exposure sheet each time the world model is defined. 3.6.4 World Model Evaluation Model evaluation occurs when the retained world model is executed. Often, this evalu ation is implicit — a part of the response to a change in the world model via global time or the definitions of one or more afuncs in the exposure sheet. The primary purpose of the model evaluation phase is to display the world model to an interactive display device. The exposure sheet has been constructed prior to evaluation. For each afimc declaration, the model statement retrieves the afimc definition from the exposure sheet and binds it to the declared local variable. 3.6.4.1 Display The AL language and AL run-time environment provide a flexible rendering archi tecture that permits both high-quality and interactive rendering to an arbitrary number of rendering devices. New rendering devices can be added easily by providing new render packages. Render packages are object-oriented mechanisms that bind primitives in the AL language to device-dependent rendering commands. 3 6.4.2 Model Mask Display of certain parts of the world model can be explicitly controlled using the model mask. The model mask specifies a list of model names that will not be displayed when the world model is evaluated. 90 The purpose of the model mask is to allow for more efficient evaluation of the world model, without requiring the AL programmer to explicitly comment out parts of the model program. The problem that commonly arises is that it is impossible to determine if a model has been deleted from the AL program, never again to be used, or if it has just been com mented out temporarily to make the world model simpler. Any models and their afuncs will be lost when the model is defined if they no longer exist in the program. The model mask feature requires that initially the entire model be evaluated. But after wards, individual portions of the model can be disabled without losing the afuncs that have been defined for those models. 3.6.5 Articulation Function Classes The heart of each articulation function declared in an AL model is actually an instance of an object-oriented style class definition. We call this instance the articulation function object. We call the class definition the articulation function class. Each type of articulation function (e.g., channel, gcurve, etc.) is implemented by its own articulation function class. Therefore, each articulation function is actually composed of two parts: • An instance of an object-oriented class that implements a specific type of articulation function object. • A Scheme procedure that serves as an interface (or “wrapper”) to the articulation function object. When we speak of the articulation function, we are referring to this Scheme procedure and not the object used to implement it. 91 (model "ball" ((squash "channel")) (scale ... (squash) ... ) afunc "squash* (Scheme procedure) afunc object: - state - member functions instances afunc class: ’c h a n n e l * Figure 3.18: Relationship between the afimc and the object and class that implement it. Within an AL model, all access to the instance of the class that implements the artic ulation function is through the wrapper function. However, applications (e.g., interactive tools) and low-level subsystems generally manipulate the afimc objects directly. One could argue that we actually have “articulation objects” rather than articulation functions since afiincs are implemented as objects in the object-oriented sense. However, functions are used as the interface in this research since standard Scheme does not pro vide object-oriented programming mechanisms. Currently, the fact that afimcs are imple mented as objects is an implementation detail that most users of AL are not concerned with. Further, a functional interface provides a simple syntax that can be provided in any base language. Each articulation function is derived from an abstract base class (or “ABC”) that de fines member functions required for all articulation function classes. The afimc ABC is 92 AL Callback Object Afunc Abstract Base Class Channel G-curve Raster Figure 3.19: Articulation function class hierarchy. derived from a more primitive class that provides low-level mechanisms for generating and processing events. 3.6^. 1 Events — The AL Callback Object Event management is an important part of the implementation of articulation functions. Recall that the world model is a function of global time and the exposure sheet. Modifica tion of any afuncs in the exposure sheet then directly affects the world model definition. There are two primary, expected results when an afunc is modified: • The world model should be re-evaluated to reflect any changes in the state or values returned by afuncs declared in the model. • Interactive tools that display the output of the world model (e.g.. Ogre) or display the afuncs themselves (e.g.. Chant, Forge, Rasp) should update their display. 93 Since all articulation functions will need event management capabilities, these capabil ities are implemented in a separate class, the “AL Callback Object,” that is used to derive all afunc classes. (See Figure 3.19.) The AL Callback Object class provides two main facilities: 1. Event Generation. Individual afunc member functions generate events that implicitly notify registered clients when changes to an afunc have occurred. 2. Event Response. Clients (e.g., interactive tools) register their “interest” in specific events with individual afuncs. Each client provides one or more functions (“call backs”) that will be invoked by the afunc when an event of that type occurs. The event management facilities provided by the AL Callback Object Class are very flexible. The event types and message protocols are determined by the derived classes. In fact, the AL Callback Object is not only used by afuncs, but by most other objects in the AL runtime system that require event management (e.g., global time, the world object, etc.). 3 6.5.2 Articulation Function Abstract Base Class All articulation function classes have a uniform baseline functionality. This simplifies the implementation of entities, like the exposure sheet, that deal with afuncs and eases the process of defining new types of afuncs. The minimum, required functionality of all afuncs is defined, through member function prototypes, in a class called the Articulation Function ABC (abstract base class). Each afunc class is required to implement the following member functions: (make- (classname) (args) ) Creates and retiuns the afunc wrapper function that acts as the interface to a particular 94 instance of the afimc class, (classname) must correspond to value returned by the classname member function described below. (classname) Returns the name of the class (e.g., "gcurve"). (free-assign (args) notify) Assigns values to each of the free parameters. The number of arguments in (args) corresponds to the number of free parameters. The ordering of the arguments de pends on the class implementation. If notify is # t, events wUl be generated notifying registered clients that the value of the afimc has changed. This member function is used primarily to assign the values of the free parameters when the values are read from an exposure sheet file. The return value is undefined. (free-write indent) Writes the values of the free parameters to the current output port. This member function is used to store the free parameters when the exposure sheet file is written. The return value is undefined. ( i n h e r i t parent) Assigns the free parameters to the values of the same corresponding parameters of another afimc {parent). This member function is used when a new afimc is created to replace a parent (existing) afimc and we wish to retain the behavior of the parent. The return value is undefined. 95 3.7 Summary Articulation functions are a generalization of the articulated variables (avars) used in Pixar’s Menvsystem [111]. Avars and afuncs share the most fundamental property: ex ternal binding. In both cases, external binding separates the specific animation of a model from the definition of the model itself. This separation permits multiple animations of the same model (or entire scene) to be specified by only providing variations of the database (the exposure sheet in AL, the cuesheet in Menv) used to store the bindings (values). In ad dition, the separation permits modification of the database (and thus implicit modification of the models in the scene) by external processes such as interactive tools. Avars manifest themselves as scalar variables in the Menv language ML. Operations such as computing the derivative of an avar or sampling an avar at other points in time (other than global time) have not been described in the literature. Using avars to specify other types of entities, e.g., geometric curves, is clumsy or impossible. Articulation functions manifest themselves in AL as functions that take optional argu ments and return values of a variety of types. Three specific types of afuncs have been investigated in this research: channels, gcurves, and rasters. Channels are very much like avars and return a scalar value. However, through optional arguments, additional operations can be performed including computing the channel derivative and sampling the channel at arbitrary points in time. Gcurves provide animated, geometric curves as a modeling prim itive. Via gcurves, a variety of modeling operations can be animated and interactively controlled. Rasters provide animated, two-dimensional grids of scalar values that can be used in procedural models based on grids, e.g., terrain models and patch data. 96 CHAPTER 4 Encapsulated Models An encapsulated model (or emodel) is an animated object containing an integrated set of dynamic attributes — e.g., shape, motion, materials (siuface properties), light sources, cameras, user interfaces, sound — represented by a procedural data format (i.e., a program written in a procedural animation language). In many ways, encapsulated models are closely related to the actor introduced by Reynolds (Section 2.2). Actors and emodels both consist of relatively small, independent, modular programs that represent a single visual element in a computer animation. When ever the visual element is needed (e.g., once per animation frame), the program is executed, resulting in the production of information — geometry, color, transformations — used to render the object in a three-dimensional environment. The program that represents an actor or an emodel contains all of the values and computations that relate to the visual element. For example, an actor contains not only the processes needed to produce geometry that represents its shape, but also the processes needed to transform the geometry to animate it over time. Because of this, actors have been said to “possess their own animation.” As we will see in this chapter, emodels extend the actor concept by expanding the types and quality of attributes that are self-contained in the model. 97 Encapsulated models distinguish themselves from actors in the following ways: 1. Encapsulated models are specifically about advanced data representations (data for mats) for the production of photorealistic computer animation. The emphasis of this research is to develop a portable data format that can enable the exchange of a wide range of objects with procedural specifications between different animation systems (including conventional interactive systems) and between vendors that provide geo metric models and consumers that purchase these models. 2. Encapsulated models readily permit arbitrary aspects of a model to be manipulated interactively. In particular, this is enabled by decoupling the definition of the emodel from the values used in the emodel that are specified interactively. This decoupling a) permits external, interactive manipulation of the procedural representation; b) allows the interactively specified values to be modified at a later date; and c) allows multiple versions of interactively specified values for the same emodel to be retained (e.g., different animations of the same character in a scene). This research presents the concept of articulation functions as a language-level mechanism used in conjuction with a database, called the exposure sheet, to implement this decoupling. Articulation functions and the exposure sheet are described in Chapter 3. 3. Encapsulated models expand the range of objects, for the production of computer an imation, that are represented procedurally. One problem with the term “actor” is that it implies that it is only used to represent a principal character or group of characters that behave semi-autonomously. In cinema, a director instructs an actor on the part ‘■*The use of procedural data formats to exchange information between systems requires that systems can execute the procedures via some type of virtual machine. 98 to play and the actor responds in (possibly) the way that the actor had intended. As computer animated films have increased in complexity and sophistication, a much broader range of objects can benefit from procedural representations. For example, emodels can be built not only for lead characters, but also simple objects and props, cameras, lighting rigs, and special effects. The last item above suggests that emodels can be built to represent a broad range of entities — everything from a fully-clothed character with complex behaviors to a simple, inanimate prop. As a result, the definition of what is and what is not an encapsulated model is somewhat vague. For example, emodels may or may not have geometry. Most do have geometry, but an emodel for a camera, for example, might only contain viewing transformations. Most emodels are time-dependent, but some may represent inanimate objects. Some emodels may contain light sources and sound effects, whereas others may not. In an effort to present the issues related to encapsulated models in more definitive terms, the next section of this chapter presents a set of “properties” that encapsulated models have. These properties describe specific features, advantages, and challenges that emodels present. Further, each property is used to derive specific requirements for a procedural ani mation language used to implement emodels. The requirements are applicable as criteria to any base language, not just the base language chosen to implement the prototype language given in this document. The hope is that these language requirements will lead to languages and animation systems that allow encapsulated models to be used as a portable data format for the exchange of animated objects. 99 Section 4.2 illustrates the properties of encapsulated models through actual, working examples. These examples also illustrate the use of a prototype language called AL for encapsulated models that is described in more detail in Chapter 5. 4.1 Properties of Encapsulated Models Many of the properties described in this section pertain to procedural models in general. While the properties are presented in the context of encapsulated models, the discussion here may be applicable to other aspects of procedural computer graphics. For example, the properties of parameterization, replication, and precision have been noted in previous work in this domain [94, 111]. Further, please note that these properties characterize the class of encapsulated models as a whole. Individual emodels may only contain a subset of the properties given. Only by considering the entire class of encapsulated models can a complete set of language requirements be derived. 4.1.1 Procedural Specification Property: Encapsulated models have a procedural specification. The most fundamental property of encapsulated models is that they are specified pro cedurally. That is, a program or procedure describes the representation of the model. Ex ecuting the instructions of the procedure produces a visual, and possibly aural (See Sec tion 4.1.10), rendering of the model. The procedure for a model is described using a pro gramming language. 100 Language Requirement: A language for encapsulated models must provide general pro- granuning language features such as variables, procedures, and control flow constructs. The details of the programming language are significant. Newell pointed out, in early work [94] on procedural objects, that the expressiveness of the representation used to de scribe objects will dictate the complexity of the objects that can be described. To provide a strong foundation, languages used to describe encapsulated models should be extensions to or implementations in a programming language with general purpose features such as variables, procedures, and control flow constructs. The need for these features will become evident as more properties are discussed and examples of encapsulated models are given. The property of procedural specification is an enabling property. That is, it makes many of the other properties (e.g., parameterization and high-level control) discussed in this section inherent to encapsulated models. In fact, it could be argued that procedural specification is actually a requirement due to the other desired properties. But, it would be misleading to not present procedural specification as a property since it is certainly the most important characteristic. It dictates not only how encapsulated models are described, but also presents the most significant challenges to the use of encapsulated models in practice. These challenges were introduced in Chapter 1, Section 1.1.1. The most important challenges relate to the embedding of complex procedural mod els in an interactive environment. Two challenges relate directly to the requirements for languages of encapsulated models. Language Requirement: A language and system for encapsulated models must provide mechanisms to allow efficient execution under interactive conditions. 101 First, in order to generate a representation or rendering of a procedural model, the pro cedural specification must be executed. Changes in the model (e.g., modification of model parameters) require re-execution of the procedural specification. The need to repeatedly execute the procedural specification under interactive conditions can incur a significant computational cost for even modestly complex models. Faster hardware does not necessar ily solve the problem because the desire for visual complexity tends to increase in lock step with advances in hardware technology. Therefore, languages and systems for encapsulated models must provide mechanisms so that models can be executed fast enough to provide real-time visual feedback. Language Requirement: A language for encapsulated models must provide language mechanisms for interactive manipulation of models. Secondly, mechanisms are needed, at the language level, so that model parameters can be directly connected to interactive tools. These tools can be used to build, test, and use (animate) existing models. The effectiveness of a procedural animation system is directly tied to the integration of interactive tools with the procedural specification of the models in the scene. 4.1.2 Parameterization Property: Encapsulated models are parameterized. One of the most important properties of encapsulated models (and procedural models in general) is that they can be parameterized. Parameters in a model are variables that do 102 not have fixed values. Certain aspects of a model (e.g., size, color, shape) can be tied to (made dependent upon) parameter values. When a model procedure is executed with a set of specific values for each parameter, we say that an instance of the model has been created. Parameterization allows multiple instances (variations) of a model to be created from a single definition. Through parameterization, encapsulated models can be made to be reusable (i.e., the same model can be used in different contexts). This section identifies three distinct ways that models can be parameterized: by model parameters, by animation parameters, and through simulation. Each form can be used to create model instances in different ways. Often, a single model will utilize more than one type of parameterization. 4.1.2.1 Model vs. Animation Parameters Model parameters are simply parameters specified as arguments to conventional func tions or procedures. The values of the parameters are not specified in the model definition, but they are specified in the model for the scene (in AL, the model for the scene is called the “world model”). Model parameters are generally used to control static or procedurally defined aspects of a object. On the other hand, the values for animation parameters are neither specified in the model definition nor in the definition of the model for the scene — the values are stored ex ternally. In AL, animation parameters are manifested as articulation functions. Articulation functions were discussed in detail in Chapter 3. Consider Figure 4.1 which shows a variation of the ball model given in Figure 3.5. The function b a ll- m o d e l creates instances of a ball shape that can be positioned and 103 deformed. The b a ll- m o d e l function has two arguments: name and b a llc o lo r.* ^ These are model parameters. (define (ball-model name ballcolor) (model name ((height "channel") (squash "channel" 'default 1)} (translate 0 (height) 0) (scale (/ (sqrt (squash))) (squash) (/ (sqrt (squash)))) (color ballcolor) (sphere))) (world (ball-model "balll" #<1 0 0>) ; ; red ball (translate 3 0 0) (ball-model "ball2" #<0 1 0>) ;; green ball (translate 3 0 0) (ball-model "ball3" #<0 0 1>) ;; blue ball ) Figure 4.1: Ball model with animation and model parameters. The b a ll-m o d e l uses the model construct to declare two articulation functions: sq u a sh and h e ig h t. These afuncs are animation parameters. Figure 4.2 shows a partic ular instance of animation for the scene represented by the code in Figure 4.1. The difference between animation and model parameters is more than syntactic. To illustrate, consider the case where an animator wishes to create a scene containing three bouncing balls of different colors. The animator knows in advance the number of balls and the color for each ball. These are fixed properties for the scene no matter how the scene is animated. We use model parameters for this purpose: to create different instances of ‘^The b a l l c o l o r parameter is specified using the vec3 data type (Section 5.3.3, page 149). The x, y, and z elements represent the red, green, and blue components respectively. For example, #<1 0 0> represents the color red. 104 Figure 4.2: Three instances of the parameterized ball model. the ball model which we will then animate in this example. But the balls can be animated in many different ways. In fact, we could use the same scene with the same colored ball models to produce multiple unique animations. The world model is the same, but each animation is stored in a unique exposure sheet These different animations might simply represent progressively improved versions of the animation that the animator can review or they might represent entirely different animations — for example, one animation of the balls as ping pong balls and another animation of the balls as if they were made of lead. Each animation is in fact an “instance” of the entire scene. Language Requirement: Languages for encapsulated models require mechanisms for specifying both model parameters and animation parameters. 105 To summarize, model parameters are used to provide different instances of individual models in a scene; animation parameters are used to provide different instances of the animation for a scene. In general, values of model parameters are static or procedurally defined, while values of animation parameters are specified interactively. 4.1.2.2 Simulation Another, more complex form of parameterization occurs in models that use some form of simulation. Simulations involve one or more bodies or actors which converge iteratively to a solution over time. The solution is derived by evaluating predefined rules given a set of initial conditions. Classic examples of simulations for computer graphics include parti cle systems [110] (Figure 4.3), fiocking behaviors [114, 4], and physical simulation [61]. Encapsulated models that contain simulation are parameterized by the initial conditions of the simulation, the rules defining the behavior of the actors, and scripted or interactive intervention by the animator. (In AL, animators can intervene using articulation functions.) Simulation is discussed further in Section 4.1.8. That discussion includes an associated property and derived language requirement. 4.1.3 Replication Property: Encapsulated models can be replicated. The steps in a staircase, the pages in a book, the spokes in bicycle wheel, the figures in a crowd scene, and the peaks in a mountain range are all examples of complex objects composed of simpler forms that have been repeated. Individual parts or models are repli cated and positioned, rotated, and scaled. Parameterized parts can be replicated and varied 106 Figure 4.3: Water droplets, butterfly, and piano keys in a frame ftom Butterflies in the Rain [42]. to produce even more interesting forms. Transformations and parameters can be varied regularly or pseudo-randomiy. Language Requirement: Languages for encapsulated models have control constructs, it eration, recursion, and primitives for pseudo-randomness. Piano keys were replicated to create the full, 88-key, upright piano shown in Figure 4.3. Two models, one for white keys and one for black keys, were used. The “white key” model was parameterized by musical note (e.g., “A” or “C ’ note) to provide the appropriate piano key shape. Both key models were also parameterized by a depression angle used to animate the keys as they were “played." 107 4.1.4 Precision Property: Encapsulated models have parts that relate in mathematically precise ways. The piano (Figure 4.3) is a particularly good example of the efficiency and complexity that can be obtained by integrating modeling, animation, and rendering into a single model. In the production of the animation, it was found that the lighting of the white keys looked incorrect. It turns out that to reduce the firame rendering time, a short-cut had been taken and it was decided that shadows would not be computed for the piano keys. The result was that the piano keys did not cast shadows on each other and thus the sides of the keys facing the primary light source were unduly bright. Further, it wasn’t satisfactory to simply make the sides of the keys darker, because as keys were played (depressed), they exposed the sides of neighboring keys to the light source and thus the neighboring key would be directly lit and logically brighter. The frames of the animation were rendered using PbotoRealistic RenderMan which uses “depth maps” (a form of texture mapping) for shadow generation [II2]. The quality of the shadows is limited by the resolution of the depth map and it was found that the resolution required to provide self shadowing of the keys was far too costly due to the small dimensions of the keys and, in particular, the very small space between keys. So, the solution was to enhance the key model so that it could use information about neighboring keys and the primary light source to procedurally produce shadows without using shadow maps (See Figure 4.4). An “ivory” surface shader was used to define the material reflectance properties of the white keys. This surface shader was modified to use information about the depression angle of neighboring keys (from the model of the piano) and the angle of incident light to procedurally generate shadows on the sides of 108 (a) Figure 4.4: Piano keys (a) without shadows; and (b) with procedurally generated shadows. keys oriented towards the light source. The procedural shadows added little cost to the shading of the keys and provided sharp, dynamic shadows dependent upon the geometry and animation of the keys. In addition to demonstrating the use of models that integrate modeling, rendering, and animation, the piano model is a representative example of the property of precision in procedural models. Frequently, there are relationships between objects that can be com puted mathematically to provide precision that is difficult to specify interactively. Examples throughout this document rely on mathematical constraints (See Figure 3.5, Section 4.2.1, Section 4.2.4, Section 4.2.2, and others.) Language Requirement: A language for encapsulated models should provide extensive “graphics math” operations and data types. In order to implement precise mathematical constraints and relationships, languages for encapsulated models should provide data types for commonly used mathematical entities 109 including scalars, points, vectors, and transformation matrices. In addition to the common mathematical and trigonometric functions (e.g., sine, tangent, floor, ceiling, log, etc.), func tions useful in the domain of computer graphics should be provided [99]. This includes vector and matrix math, vector operations (e.g., dot product, cross product, distance and normalization functions), matrix operations (e.g., matrix inverse, transpose, determinant), conversion between coordinate systems (including spatial, temporal, and color coordinate systems), and functions for evaluating curves and surfaces. 4.1.5 Continuous Representation (Anti-aliasing) Property: Encapsulated models use approximations to geometric surfaces only when nec essary; otherwise, exact specifications are used. Property: Encapsulated models are implicit functions of time. Aliasing and the techniques used to alleviate aliasing artifacts (known as anti-aliasing) are fundamental to all aspects of computer graphics [25, 41, 139]. Aliasing refers to arti facts (errors) created during the discretization of continuous entities. Aliasing in rendering (spatial aliasing) has received the most attention. This may be due to the emphasis in ren dering research over the years or it may be the saliency of the artifacts themselves. Aliasing in rendering manifests itself in many ways including “jaggies” or “staircasing” along lines and shape boundaries, “crawling ants” that occur on shape boundaries as an object moves across the view plane, and surface textures that appear “pixelized” or noisy. 110 Aliasing also occurs in animation. Strobing and the “wagon wheel effect” (where the spokes on a moving wagon wheel appear to be stationary or moving backwards) are com mon examples of temporal aliasing. Finally, aliasing also exists in modeling. Polygonal representations of surfaces still re main the most commonly used representation because of the mathematical simplicity of planar polygons. But, the polygonalization of curved surfaces presents the opportunity for aliasing and also inefficiency. Consider a polygonal representation of a sphere. While a sphere can be represented by the equation af 4- 4- = r^, hundreds and possibly thousands of polygons are needed for a reasonable approximation of the same shape. Fur ther, with an insufficient number of polygons, aliasing will occur in the form of faceted silhouette edges. With too many polygons, space and computation time are wasted. Also consider modeling operations such as computing the volume of an object. If the representation is polygonal, the volume must be computed using the enclosed polyhedron formed by all of the faces. If the polyhedron in fact represents a sphere, the error in the computation of the volume of the sphere as a polyhedron from the actual volume of a sphere is a form of aliasing. Represented in continuous form as a sphere, the volume can be quickly and accurately computed using the equation for the volume of a sphere, V = rrr^. Encapsulated models are a method for representing objects, so it is important that prop erties related to aliasing be presented. The underlying characteristic of each property is, that if at all possible, explicit sampling of the model is avoided in the definition of the model itself. One of the goals of encapsulated models is reusability. That is, certain en capsulated models may be constructed so that they can be reused in the same animation or even reused for completely different projects. Of course, the generality of a model is determined by the designer or engineer of the model. But, an underlying design goal is to 111 provide models that can be sampled under varying conditions without introducing aliasing artifacts since the sampling rate will not always be known apriori. Language Requirement: Languages for encapsulated models must provide an extensive set of geometric primitives including high-order and implicit surfaces. Geometrically, encapsulated models use representations of surfaces that most accu rately mimic the surface being modeled. This means, for example, that polygons are used for flat surfaces; that quadrics (spheres, cones, etc.), bicubic surface patches, and NURBS, are used for curved surfaces; and that implicit functions (e.g., “metaballs” [11]) are used for volumes. The approximation of the surface into polygons or a simpler form as required is dictated by the tenderer because it has the necessary information to properly sample the surface for viewing to suit both quality and efficiency needs. With regards to level of detail, the same philosophy applies. An encapsulated model will specify all levels of detail for tenderers that are capable of determining the appropriate representation to use (based on the size of the object in screen space or the screen refresh rate). In some cases however (e.g., to reduce the visual complexity of the screen display), it may be desirable to allow the user to explicitly dictate the level of detail used. Language Requirement: Languages for encapsulated models should manipulate models as implicit functions of time. Temporally, sampling of encapsulated models is deferred to the animation system by the requirement that models be specified as implicit functions o f time. That is, for any given value of time, t, the procedure that implements the model must answer the question “What does the object look like at time tT 112 m{t) — y representation of model m at time t In an explicit model, the temporal values and the temporal sampling rate are included in the definition of the model. For example, the pseudo-code below gives a model that translates a sphere over time (expressed by the variable t) and explicitly specifies the times at which the model is sampled. explicit ball model: for t = 0 to 10 by 1 translate 0.5 * t draw sphere Let’s assume that the time units are seconds. Thus the ball will travel 5 units in 10 seconds. But what if sampling the model one time per second is insufficient? Clearly this would be the case if we were generating frames for film or video that require 24 or 30 frames per second respectively. An implicit specification does not include how the model will be sampled temporally, thus the model can be sampled at a rate as demanded by the output medium. For example, motion blur techniques [24,56] require multiple samples per frame of the scene to simulate the exposure of camera film to light over the period of time that the camera shutter is open. Thus motion blur requires very high sampling rates. In the case of real-time display, the temporal sampling rate may be dynamically lowered to maintain an interactive display rate that is dependent upon the complexity of the scene. The pseudo-code below gives an implicit form of the ball model: 113 implicit ball model(t): translate 0.5 * t draw sphere In addition to supporting models as implicit functions of time, languages for encap sulated models should be flexible enough to allow models to be specified using a variety of time spaces (e.g., frames, seconds) and provide routines for converting between spaces. Further, languages should make the temporal sampling rate available to models so that models can “filter themselves” if the sampling rate is too low compared with the frequency of the motion. 4.1.6 Compression and Database Amplification Property: Encapsulated models exhibit high levels of compression (and database amplifi cation conversely). By virtue of many of the properties discussed thus far — procedural specification, pa rameterization, replication, and continuous representation — encapsulated models can be a space-efficient representation. For example, a procedural representation of a surface of revolution, that consists of a profile curve (consisting of n vertices) swept along a path curve (consisting of m vertices), requires n-f m control vertices because the operation is represented as a process — “revolve profile about path.” An explicit representation, on the other hand, that represents the surface as the result of a surface of revolution operation, requires n x m control vertices, because the entire resulting vertex mesh must be stored. 114 In the case of a recursively based representation, e.g., a fractal model of terrain, an arbitrary level of complexity can be achieved using a fixed sized description (e.g., the re cursive rules that state how the surface is to be subdivided). The depth of the recursion is arbitrary, thus the complexity that can be generated is arbitrary. Generation of complex shape and motion firom small databases is called database amplification and was discussed in Section 1.1.1. Further, when continuous representations of geometry and motion are used, encapsu lated models can exhibit lossless’® compression. Johnson states that procedural represen tations of scenes “can be treated as continuous media. With appropriate sampling, the representation is not lossy. For a large class of scenes, this allows orders of magnitude of compression of the amount of data which need be stored or transmitted [64].” 4.1.7 Composition and High-level Control Property: Encapsulated models are composable. If models are composable, complex models can built and manipulated using techniques directly analogous to the concept of functional decomposition. In functional decompo sition, complex programs are broken into simpler subroutines. This process is applied recursively to the subroutines until the lowest level subroutines are trivial to implement. The same process can be applied to the construction of complex models. Simple, pa rameterized models can be built and tested and then incorporated into larger, more complex models. Parameters of high-level models can control multiple parameters of lower-level '^Lossless (or non-Iossy) compression results in no loss of data or information. 115 models thus yielding high-level control. Through composability, complex models can be constructed from simpler models aiding in both the construction of the model and in ±e ease of use through high-level controls. In the simplest case, composability allows models to be placed within the transforma tion hierarchies of other models. Consider the case where we have an encapsulated model of a spinning toy top. It should be possible to use this top in scenes where it rests on the floor or on a table or in the hand of a character in the scene. Language Requirement: A language for encapsulated models should allow models to be nested and composed hierarchically. This should be implemented using a graphics state. The ability to construct hierarchies efficiently and easily can be implemented using the concept of a graphics state that is common to many modem graphics languages and toolk its including PostScript [1], OpenGL [93], Open Inventor [130, 141] and the RenderMan Interface [107]. When transformations and attributes (e.g., surface color) are specified, they become a part of the graphics state. When geometric shapes are specified, they are drawn using the transformations and relevant attributes of the current graphics state rather than explicitly carrying attribute and transformation information along with the primitive itself. Specification of an attribute generally replaces the current value of the attribute in the graphics state with the new value being specified. However, transformations are accumu lated. At any point, the graphics state can be saved or “pushed” and restored or “popped” to the previous state.Used in conjunction with the accumulative nature of transforma tions, hierarchically organized objects can be efficiently and easily constmcted. Figure 4.5 stack data structure is typically used to implement a graphics state system, hence the terminology of “pushing” and “popping” the graphics state. 116 joint 3 draw base ^ _ rotate about joint 1 segment C ^^0 % ^segm ent B ^raw segment A . translate to end of segment A rotate about joint 2 draw segment B claw seg m en t A translate to end of segment B rotate about joint 3 draw segment C joint 1 translate to end of segment C draw claw Figure 4.5: Diagram of jointed hierarchy (left) and pseudo-code (right). depicts a robot arm and pseudo-code used to implement it. Rotation of “joint 1” will move the entire arm while rotation of “joint 3” only moves the last segment and claw. 4.1.8 Simulation Property: Encapsulated models contain components derived using simulation techniques. Simulation, in computer graphics, includes numerous techniques that are used to model a wide range of complex phenomena including water, smoke, fire, the flocking of birds, elastic objects, and collisions between objects. Names for the techniques include particle systems [110] and behavioral simulation [4,61, 114]. Language Requirement: Languages for encapsulated models must support general simu lation mechanisms including message passing between models. Models of objects, like a toy rocket for example, should include components that pro vide special effects. The toy rocket model could include a fuse that ignites and bums, 117 leaving a carbon trail on the ground. When the spark reaches the rocket engine and the rocket takes off, the rocket model should include a smoke trail that follows the flight path of the rocket. Often, the simulated special effects are closely associated with the direct animation of the object (e.g., the smoke trail). Shading and lighting are also involved with most effects. The spark that moves along the rocket fuse should include at least one light source for example. By integrating simulation techniques with the explicitly animated model, a more complete model can be provided to the animator. New animations of the model can automatically include new special effects. Many types of simulation (e.g., flocking) require conununication between the individ ual elements of the group behavior (e.g., individual birds in the flock). Thus, languages for encapsulated models need to provide mechanisms for communication between models located at different positions in the scene hierarchy. 4.1.9 Self-contained Lighting and Shading Effects Property: Encapsulated models contain light sources, surface materials, and atmospheric effects. Surface material definitions are currently provided in many commercially available data sets. However in most cases, the materials, like the geometry, are static in commercial models. Changes in the shape of the model often lead to undesirable artifacts in the surface properties (See Section 4.2.1). Procedural models can automatically adjust texture coordi nates and shader parameters to relate to changes in shape or other conditions. Earlier in this chapter (Section 4.1.4), an example was described where the shading of piano keys varied 118 based on the animation of the piano. As another example, high quality models can have an “age” parameter that directly affects surface appearance. New models are rendered as smooth, clean, and shiny, while old models are dented, dirty and even weathered [31]. Light sources are rarely specified in current commercial data sets. Yet light sources are often integral parts of real objects. A model for a lighthouse should contain a rotating light source. Car models should contain headlights, turn signals, parking lights, and glows from the dashboard. A candle should have a flickering, glowing flame. Clearly, the light sources are directly affected by the state and animation of the models that they are a logical part of. Language Requirement: Languages for encapsulated models must allow for the specifica tion of light sources, surface materials, and atmospheric effects as integrated components of models. Shading, modeling, and animation are often coupled logically and models that integrate them can benefit from enhanced usability and efficiency. 4.1.10 Sound Effects Property: Encapsulated models contain sound effects. Recently, research has begun on integrating sound effects with the motion of animated objects [57, 131]. This has been termed sound rendering. The advantages of integrating sound with motion are twofold. First, sound effects can be produced that more accurately reflect the objects generating the sounds and more accurately reflect the modulation of sounds by the environment (e.g., attenuation, reflection) as the sound travels to the listener. 119 Second, by integrating sound with motion, sound tracks can be automatically generated whenever the animation is modified instead of reapplying sound effects each time in post production. Language Requirement: Languages for encapsulated models support sound rendering. In addition, synchronized sound effects played concurrently with real-time animation previews may aid the animator in motion specification. When an animation is rendered, sound tracks will be produced concurrently with images for each frame. Then, the animator can review the animation with both aural and visual cues. It seems reasonable to speculate that models wül contain sound effects as commonly as they currently include information about surface color. 4.1.11 Summary This section has described the properties of encapsulated models and, from those, de rived a set of language requirements. These properties and language requirements are sum marized in Table 4.1 and Table 4.2 respectively. Section 4.2 characterizes the concept of encapsulated models through working examples implemented in the AL language. 4.2 Examples of Encapsulated Models The purpose of this section is to provide simple examples of actual models to reinforce the concept of encapsulated models, illustrate the properties described in the previous sec tion, and show the use of articulation functions (Chapter 3). In addition, these examples should prove useful in understanding the prototype language, AL, used in this research. 120 section encapsulated models... 4.1.1 have a procedural specification. 4.1.2 are parameterized. 4.1.3 can be replicated. 4.1.4 have components that can be related (constrained) in mathematically precise ways. 4.1.5 use continuous geometric representations whenever possible. 4.1.5 are implicit functions of time. 4.1.6 exhibit high levels of compression. 4.1.7 are composable. 4.1.8 contain components computed using simulation techniques. 4.1.9 contain light sources, surface materials, and atmospheric effects as integrated components. 4.1.10 contain integrated sound effects. Table 4.1 : Properties of encapsulated models. 4.2.1 Cyclorama A cyclorama or eye (pronounced “sike”) is a commonly used element in studio sets. It is basically a curved drop or wall used as a background. When properly lit, the curve joining the wall and floor provides a smooth transition that gives the impression of a large or infinite space. Cycs are frequently painted a very clean white which further enhances the feeling of space. An encapsulated model for a cyclorama is shown in Figure 4.6. The eye is built out of two bilinear patches (one for the wall and one for the floor) and a partial cylinder for the curved portion (See Figure 4.7). The width, height, and depth of the eye can be specified with the model parameters of the same name. The wall doesn’t have to be perpendicular to the floor. It can be tilted back using the b en d parameter. If b e n d is 0, the wall is perpendicular to the floor. If b end is 1, the wall will lay flat and be parallel to the floor. 121 section languages for encapsulated models.. 4.1.1 have general programming language features (i.e., variables, procedures, and control flow constructs, etc.). 4.1.1 contain mechanisms to improve model execution performance under interactive conditions. 4.1.1 contain mechanisms for interactive manipulation of models. 4.1.2 contain mechanisms for specifying both model and animation parameters. 4.1.3 support control flow, iteration, recursion, and have primitives for pseudo-randonmess. 4.1.4 have extensive “graphics math” operators and data types. 4.1.5 contain an extensive set of geometric primitives including high-order and implicit surfaces. 4.1.5 manipulate models as implicit functions of time. 4.1.7 allow models to be hierarchically composed. 4.1.8 provide support for simulation techniques including message passing between models. 4.1.9 allow for the specification of light sources, surface materials, and atmospheric effects as integrated components. 4.1.10 provide support for sound rendering. Table 4.2: Language requirements for encapsulated models. The ro u n d ed n e ss parameter specifies the radius of the cylinder and can be used to make the curved portion of the eye more or less rounded. A value of 0 for the ro u n d e d n e ss parameter will make a sharp crease between the wall and floor. There is no upper limit on the value for roundedness. At all times, the wall and floor remain in contact with and tangent to the cylindrical por tion of the eye. In addition, the texture coordinates of each gprim are dynamically computed to provide seamless texture coordinates across the entire eye regardless of the dimensions or “roundedness” of the cyc.‘* Evenly parameterized texture coordinates greatly simplifies ‘*The s t parameter of the patch gprim specifies the two-dimensional texture coordinates corresponding to each comer of the bilinear patch. 122 (define (eye width height depth roundedness bend) (let* ( (tmax (lerp 90 0 bend)) (eire (* (/ tmax 360) 2 PI roundedness)) (tlen (+ depth height eire)) (tl (/ height tlen)) (t2 (+ tl (/ eire tlen))) ) (xfm-separator (translate 0 roundedness 0) ; ; wall (xfm-separator (rotate (- tmax 90) x-axis) (translate 0 0 (- roundedness)) (seale width height 1) (pateh “bilinear" 'P '(#<-1 1 0> #<1 1 0> #<-1 0 0> #<1 0 0>) ' S t (list #<0 0> #<1 0> (vee2 0 tl) (vee2 1 tl))) ) ; ; floor (xfm-separator (translate 0 (- roundedness) 0) (seale width 1 depth) (pateh "bilinear" 'P '(#<-1 0 0> #<1 0 0> #<-1 0 1> #<1 0 1>) ' S t (list (vee2 0 t2) (vee2 1 t2) #<0 1> #<1 1>))) ; ; eurve (xfm-separator (rotate -90 x-axis) (rotate 90 y-axis) (eylinder 'thetamax tmax 'radius roundedness ' zmin (- width) ' zmax width ' S t (list (vee2 0 t2) (vee2 0 tl) (vee2 1 t2) (vee2 1 tl)))) )) ) Figure 4.6: Cyclorama implementation. 123 b e n d = 0 b e n d = 0 . 2 partial cylinder b e n d = 1 Figure 4.7: Cyclorama construction and parameters. the task of developing surface shaders that “paint” the cyclorama to give the background different appearances. The horizontal texture coordinates are static and are in the range 0 to 1 across the entire eye. The vertical texture coordinates for each gprim are computed so that the texture coordinates are proportional to the cross-sectional length of each gprim with respect to the total cross-sectional length of the entire eye (tle n ). 4.2.2 Sunlight The “sunlight” encapsulated model is a procedural light that automatically creates a light source that mimics the actual position and behavior of the Sun. The position of the Sun in the sky is dependent upon: 124 (a) (b) Figure 4.8: (a) Cyclorama with default texture coordinates for gprims; and (b) with re parameterized texture coordinates. 1. The movement the Earth takes as it orbits about the Sun. This is non-constant due to the “eccentricity” of the Earth’s orbit 2. The tilt of the Earth’s axis. 3. The position of the observer on the Earth. The observer’s position on Earth is assumed to be known and is given in terms of degrees of longitude (west) and latitude (north). Items 1 and 2 above can be approximated given a specific date [89]. The date is specified by calendar year, month, day and time. The time is specified as a fractional 24-hour value and assumed to be Eastern Standard Time (EST). For example, 1:30 p.m. EST is specified as 13.5. In spherical (or observational) astronomy [50, 9], the position of the Sun is specified by two angles relative to the position of the observer the altitude and the azimuth. The 125 (define (sunlight year month day hour long lat intensity) (let* ( (sun-info (sun-position year month day hour long lat) ) (altitude (degrees (car (car sun-info)))) (azimuth (degrees (cdr (car sun-info)))) (sunrise (car (cdr sun-info))) (sunset (cdr (cdr sun-info))) (lightcolor (sunlight-color sunrise sunset hour)) ) (xfm-separator (rotate (- azimuth) y-axis) (rotate (- altitude) x-axis) (light "distantlight" 'from #<0 0 3> 'to #<0 0 0> 'lightcolor lightcolor 'intensity intensity)))) Figure 4.9: Sunlight source implementation. altitude specifies the height of the celestial body above the horizon. For the Sun, an altitude of zero indicates that the sun is rising or setting; positive values indicate that it is daytime and the Sun is overhead. The azimuth specifies the angle along the horizon between the observer and the celestial body as the observer faces south. Positive angles indicate that the body lies to the west; negative angles indicate that the body lies to the east. Figure 4.9 shows the implementation for the s u n l i g h t model. The model consists of a "distant” light source shader*® that is rotated a l t i t u d e degrees about the x-axis and a z im u th degrees about the y-axis. In this model, east is represented by the positive x-axis and south by the positive z-axis. '®The "distant” light source shader simulates light sources that are located at a sufficiently great distance such that all the light rays emanating from the source are parallel (as the Sun’s rays essentially are). The from and to parameters specify a vector indicating the direction of the parallel rays. 126 AU of the work is done in the s u n - p o s it i o n function which computes the posi tion of the Sun and also the time at which the Sun wiU rise and set for that day. (The implementation of s u n - p o s itio n is given in Appendix A, page 176.) The s u n - p o s itio n function returns a Scheme pair.-® The first element in the pair contains the altitude and azimuth (stored in another pair). The second element in the pair contains the time that the sun wiU rise and set (stored in yet another pair). These values are extracted in the l e t * statement. As an added feature, the sunlight model varies the color of the light source using an ad hoc approach. Based on the current time relative to the sunrise and sunset, the color is varied from a Ught blue at sunrise, to a yeUowish-white that dominates throughout the day, to a reddish color at sunset. A possible implementation of s u n l i g h t - c o l o r is given in Figure 4.10. Figure 4.11 shows the sunlight model used to render three different images of the same scene. The approximate latitude and longitude of Columbus, Ohio were used. The invoca tion of the model for the third image (7:15 p.m.) is: (sunlight 1998 6 1 19.25 83 40) 4.2.3 Cameras In most animation systems, cameras (viewpoints) have only low-level controls for spec ifying the position and secondary parameters of the camera. Encapsulated models provide the opportunity to build cameras with higher-level and more intuitive controls. Specialized -^Scheme “pairs” are data items containing two members. The members of the pair are retrieved using the Scheme functions c a r and c d r for the first and second data members respectively. 127 (define (sunlight-color sunrise sunset t) (let ( (sunrisecolor #<.56 .87 1>) (sunsetcolor #<1 .2 .2>) (nooncolor #<1 1 0.75>) (delta 2) ) (cond ( (and (> t sunrise) (< t (+ sunrise delta))) (lerp sunrisecolor nooncolor (smoothstep sunrise (+ sunrise delta) t))) ((and (< t sunset) (> t (- sunset delta))) (lerp nconcolor sunsetcolor (smoothstep (- sunset delta) sunset t))) (else nooncolor)))) Figure 4.10: Implementation for s u n l i g h t - c o l o r function. camera models can be easily built and customized for individual scenes and shots. There has been recent interest in procedural camera specification [32, 62]. This section describes a simple camera model that still has relatively low-level controls, but is useful in demonstrating how an encapsulated model for a camera can be built. Sec tion 4.2.4 provides a more interesting camera model that automates a task that is generally performed manually in traditional and digital cinematography. 4.2.3.1 Basic Camera Icon Frequently, it is useful to a have a graphic representation (icon) of the camera in the scene. The representation can be helpful in specifying the position and determining the effect of other parameters such as the camera field of view and focal distance. Figure 4.12 provides the implementation of a simple icon (shown in Figure 4.13) used for the camera models described in this document. Its shape indicates the position and 128 6 a.m. 12 noon 7:15 p.m. Figure 4.11: Sunlight emodel for June 1, 1998 at 40® N and 83® W. orientation of the camera model. It is included here because it concisely demonstrates the use of several different types of gops and gprims and is therefore helpful in understanding how shapes can be specified in the AL language. 4.2.3^ Basic Camera Model The “basic” camera model implementation in shown in Figure 4.14. This model has both model and animation (articulation function) parameterization. Multiple copies of the model can be created in the same scene by instancing b a s ic - c a m e r a with different names via the name model parameter. It provides animation controls through the use of seven channel articulation functions that specify the position, orientation, and field of view of the camera. Each channel can be independently and interactively modified to transform and animate the camera. Note that transformations on the camera also implicitly transform the camera icon. It is desirable that the camera icon be displayed in interactive views, but not rendered in final images. The rendered gop (Figure 4.14, line 21) can be used to implement this feature. It has a single boolean argument; if false (if), subsequent primitives will be displayed, but not rendered. 129 (define (basic-camera-icon) (define (one-spool) (xfm-separator (rotate 90 y-axis) (scale 0.6 0.6 0.15) (disk 'height 1) (disk 'height -1) (cylinder 'zmin -1 'zmax 1))) (xfm-separator ; ; scale to fit roughly in -1 to 1 box (uscale 0.65) (translate 0 0 -1.5) (xfm-separator (translate 0 -0.2 0.3) (scale 0.2 .55 0.7) (box)) (xfm-separator (translate 0 0.95 0) (xfm-separator (translate 0 0 .6) (one-spool)) (xfm-separator (translate 0 0 -.6) (one-spool))) (xfm-separator (translate 0 0 1.5) (scale 1 1 .6) (scale .4) (disk 'height -1 'radius 0.5) (hyperboloid 'pointl '#<1 0 1> 'point2 '#<0.5 0 -1>)))) Figure 4.12: Camera icon code. 130 Figure 4.13: Camera icon. 4.2.4 Vertigo Camera The vertigo shot is an interesting cinematic technique. It’s name is derived from the film Vertigo in which Alfred Hitchcock made the technique famous. The vertigo shot in volves dollying the camera (moving the camera forward or back) while simultaneously adjusting the field of view so that the subject of the shot remains the same size on the image plane. The effect is dramatic and disconcerting in that the environment around the subject expands or contracts while the subject appears unaffected. The effect is often used to imply instability and that the subject has little or no control over his or her surrounding environment. Manual dollying and simultaneous modification of the field of view can be difficult. Fortunately, the relationship between these two parameters can be expressed mathemati cally and thus can be automated through a procedural, “vertigo,” camera model. 131 1 (define (basic-camera name) (model name ( (pos.X "channel") 4 (pos.y "channel”) (pos.z "channel") (zoom "channel" 'default 0.5) (pan “channel") 8 (tilt "channel") (roll "channel") ) (separator 12 ; ; transform the camera (translate (pos.x) (pos.y) (pos.z)) (rotate (tilt) x-axis) (rotate (+ 180 (pan)) y-axis) 16 (rotate (roll) z-axis) (camera name "perspective” 'from '#<0 0 0> 'to '#<0 0 1> 'fov (lerp 0 90 (zoom)) 'tilt (roll)) 20 ; ; draw the icon (rendered #f) (basic-camera-icon) ) ) ) Figure 4.14: “Basic” camera emodel code. 132 Figure 4.15: Parameters in computation of “vertigo” camera. The relationship between the camera field of view, (f>, the height,h, of an object that fills the screen, and the distance, d, of the object from the camera is shown in Figure 4.15 and expressed in Equation 4.1. (4.1) Throughout the vertigo shot, the relationship between d and 0 must remain constant as one of the quantities is varied so that the subject remains the same size on the screen. We can either allow the animator to control the position of the camera or the field of view and compute the other component mathematically. In this example, the field of view is automatically adjusted as the animator dollies the camera. 133 Let 00 and rfo be the “base” values. In other words, the size of the subject on the screen given 00 and do will be maintained. Let d\ and 0i be the new distance and field of view respectively. Thus, and 01 _ h The heighth of the object doesn’t change. So, 00 , 01 do tan —— = di tan —- 2 2 Then reordering terms to solve for 0i, we derive 01 = 2 tan ^ tan ^ j (4.2) An implementation of the vertigo camera using Equation 4.2 is shown in Figure 4.16. Only one animation parameter is provided: d o lly . The d o l l y channel moves the camera back and forth along the direction defined by the model parameters from (the tail of the vector) and to (the head of the vector). The “base” distance is specified by the implied length between from and to . The “base” field of view is specified by f ov. 134 (define (vertigo-camera name from to fov) (model name ((dolly "channel")) (let* ( (dir (- to from) ) (do (norm dir)) (dl (+ dO (dolly))) (phiO (radians fov)) (phil (* 2 (atan (* (/ dl d2) (tan (/ phiO 2)))))) ) (separator (translate from) (translate (* (dolly) (- (normalize dir)))) (concat-transform (from-z-xfm dir)) (camera name "perspective" 'from '#<0 0 0> 'to '#<0 0 1> 'fov (degrees phil)) (rendered #f) (basic-camera-icon) )))) Figure 4.16: Vertigo camera model code. 4.2.5 Alarm Clock An emodel for an alarm clock is shown in Figure 4.17. This model has model param eters and high-level animation controls (Table 4.3). The position of the hands are set by model parameters h o u r and m in u te. These parameters can be specified as constants or attached to time for animation. The color of the casing of the clock can also be set. Two channels control the ringing of the alarm clock. The r i n g in g channel is used as a switch to turn the ringing on or off and the e x a g g e ra tio n channel is used to exaggerate the ringing effect. High values of exaggeration cause the bells to move more dramatically and cause the entire clock to shake in response to the vibrations. The hammer (the part that strikes the metal bells) is animated back and forth using a sine wave. The motion of the bells and vibrations of the clock are animated using time-dependent noise. The amplitude 135 1 Figure 4.17; Alarm clock emodel. of noise is scaled by the e x a g g e ra tio n channel. The implementation of the alarm clock is given in Appendix A, page 177. 4.2.6 Chandelier Figures 4.18 and 4.19 show an emodel for a chandelier. This model is both a visible object in the scene and a light source. For each candle, a flame is visible and each flame acts as a point light source. The intensity of the flames is controlled by the i n t e n s i t y parameter (Table 4.4). The flames also flicker which results in a visible change in the appearance of the candles and a change in the intensity and position of the point light sources. The amount of flickering can be controlled by the animator using a channel called 136 nam e type description h o u r number The position of the hour hand (1-12). m in u te number The position of the minute hand (1-60). clockcolor vec3 The color of the clock casing. r i n g in g chatmel If greater than 0, the alarm clock is ringing. exaggeration chaimel Controls the exaggeration of the ringing. From 0 (no exaggeration) to oo (very exaggerated). Table 4.3: Alarm clock parameters. f 1 ic k e r . In this way, the animator can cause the candles to flicker when a door or window opens in the scene, but turn the flickering down or off the rest of the time. If i n t e n s i t y is zero, the candles are unlit. nam e type description name string The model name. num candles number The number of candles. i n t e n s i t y number The intensity of the candles (0 => unlit). glow number The intensity of the candle glow. g lo w sp re a d number The size of the candle glow. f l i c k e r channel The rate of flickering. tr u n k gcurve The shape of the trunk (center piece). c a n d le - h o ld e r gcurve The shape of the candle holder. c a n d le -s te rn gcurve The shape of the candle stems. c a n d le - e n d gcurve A detail piece on the end of the stems. hook gcurve The shape of the chandelier hook. Table 4.4: Chandelier parameters. The shape of various parts of the chandelier are controlled (and can even be animated) using a number of gcurves that can be interactively modified by the user. For example, the stems (arms) that extend out firom the center of the chandelier to each candle holder 137 Figure 4.18: Chandelier emodel (unlit). are defined by a gcurve shown in Figure 4.20. As that one gcurve is modified, all of the candle stems update in the interactive display. (The number of candles and candle stems is controlled by the n u m candles parameter.) In addition, the model automatically places the candles at the end of the stems regardless of the defining shape of the stem. So, when the candle stem gcurve is modified, not only is the shape of candle stems updated, but the candles and candle holders dynamically update their position to remain attached to the stem. The implementation of the chandelier is given in Appendix A, page 181. 138 Figure 4.19: Chandelier emodel. 4.2.7 Island The island shown in Figure 4.21 is an emodel that utilizes a raster afunc. The shape and altitude of the beaches, hills and mountains of the island were interactively painted using the Rasp tool described in Section 3.5.3. The corresponding raster used to gener ate the island is shown in Figure 4.22. The implementation of this model is provided in Figure 4.23. The terrain of the island is specified as a height field composed of a mesh of B-spline patches. The mesh is specified using thepatch-mesh gprim. (patch-mesh "bicubic" size "nonperiodic" size "nonperiodic" 'Pz (height)) 139 Vk* Eût Ume.1 Figure 4.20: The gcurve defining the shape of candle stem as seen in the Forge editor. The dimensions of the raster afunc h e ig h t and the number of control vertices in the patch mesh are specified by the s i z e variable. The(x,y) coordinates of each control vertex are implied by their (u, v) parametric position, while the z coordinate is determined from the vector of intensity values returned by h e ig h t that is passed using the Pz parameter. (The island is rotated so that the z-axis points up.) Note that higher intensity pixels in Figure 4.22 correspond to higher altitude land formations on the island in Figure 4.21. Based on the height of the surface at any given point, a special purpose surface shader adds rockiness and provides color variations that indicate beaches, hills, and snow-capped peaks. 140 Figure 4.21: An emodel for a tropical island that was interactively painted using the raster shown in Figure 4.22. 141 Figure 4.22; The Rasp interactive raster editor. The raster shown here defines the shape of the island shown in Figure 4.21. (define (island size) (model "island" ((height "raster" 'xsize size 'ysize size)) (scale 3 13) (rotate -90 x-axis) (translate -.5 -.5 0) (divisions 2) (surface "island" 'Km 0.1) (basis "bspline") (patch-mesh "bicubic" size "nonperiodic" size "nonperiodic" 'Pz (height)))) Figure 4.23: Implementation of the “island” emodel. 142 CHAPTERS AL: A Prototype Language for Encapsulated Models The purpose of this chapter is to provide an overview of the AL programming language. AL is a language for creating photorealistic, three-dimensional, computer animation. By virtue of its programmability, the range of potential applications is quite broad. However, it was specifically designed as a prototype language to develop and test the primarv concepts of this research: articulation functions (Chapter 3) and encapsulated models (Chapter 4). Discussions in this chapter include design goals, the use of Scheme as a base language, a description of the AL language, and implementation details. Omitted from this chapter is a discussion of language featiures related to animation, as they are illustrated in chapters 3 and 4. A complete reference for the language and software tools is found in [85]. Some of the material in this section can also be found in [87]. A brief overview of the AL software system and operational model is provided in Section 1.4.1. The development of the AL language and associated software tools continues. This discussion is limited to the current implementation. 143 5.1 Design Goals There are three main goals in the development of AL. The first goal is to incorporate the best features of previous procedural animation languages (See Chapter 2) and add new features to reflect recent advances in technology. Specifically, the AL language is based pri marily on Reynold’s AS AS system and Pixar’s Men v system (both described in Chapter 2) which includes the language ML. AL follows Reynold’s lead of using a base language from the Lisp family (specifically Scheme), but the programming statements of AL are much more like those in ML. Unfortunately, very little information has been documented publicly on ML (only [111]) so a thorough comparison is difficult. However, both AL and ML utilize the same, primary rendering interface for the production of photorealistic im agery — the RenderMan Interface [107, 136] — which heavily influences both languages and naturally leads to many similarities in the language syntax. Many geometric primi tives and operations in both languages are directly derived from the thoughtfully designed RenderMan Interface specification. The most significant feature of ML is the articulated variable described in some detail in Section 2.5.2. Earlier versions of AL directly adopted and used articulated variables. But this research led to the development of a more gen eral mechanism called articulation functions (Chapter 3) that have now replaced articulated variables in early versions of the AL language. The AL language is also influenced by programming toolkits such as OpenGL [93] and Open Inventor [130, 141]. The second goal is to make a language and software system that is as easy to use and as interactive as possible. The system is programming language-based, so the system in inher ently difficult for users with non-technical backgrounds. However, it is wrong to coarsely categorize users of animation systems as strictly “programmer” or “animator.” First of all, there are animators that are proficient programmers and vice-versa. Secondly, there are 144 also middle range professions (e.g., the somewhat vague title of “technical director” from the production industry) in which technical users, that are not necessarily computer scien tists or computer progranuners, develop technical content (small software programs) for animators and artists. Simple syntax and interactive components make the language easier to use for both technicians and technically proficient artists. A third goal is to maintain a primitive design philosophy. The idea is to follow the prin ciple used in the development of operating systems: “provide mechanism, but not policy.” The advantage of providing mechanisms is flexibility. Changing needs can be dictated by the user. The entire system is inherently programmable, thus higher-level features can be implemented by the user when necessary or convenient. 5.2 Scheme as a Base Language AL is an'extension of the general purpose, programming language Scheme [22, 33], which in turn is a lexically scoped, tail-recursive descendent of Lisp. There are two primary advantages to using a pre-existing, general purpose, programming language as a basis for a “new” language. 1. Pre-existing languages have pre-existing specifications, books, compilers, interpre ters, and support libraries. 2. A general purpose language will be flexible enough to solve a wide range of computer graphics problems. Although AL has been designed primarily for building and ani mating encapsulated models, the foundation provided by a general purpose language 145 permits AL to also be used for frame rendering management, image post process ing, input and output to and from MIDI and other devices, and creating interactive, graphical user interface tools. Previous modeling and animation languages have been based on a number of program ming languages including Algol-60 [65], PL/1 [104], Lisp [113], Fortran [96], C [49], TCL [64], and others. Theoretically speaking, all non-trivial programming languages are equiv alent; but in practice, each language has various strengths and weaknesses. We have found Scheme to be an excellent choice as the base language for AL for the following reasons: Ease of use. Scheme has a simple syntax and a small core of semantic concepts. (Scheme is frequently used as the language for introductory programming courses.) Scheme is generally interpreted rather than compiled. This reduces tum-around time and encourages experimentation. Scheme supports a rich set of high-level data types commonly used in computer graphics including strings, lists and vectors. Dynamic memory allocation and deallocation is handled automatically in Scheme. Functions are treated as first-class objects. Extensible syntax. Scheme has an informally standardized method for specifying new syntax. This allows new syntactic forms to be defined which aids in the readability of the language. In AL, for example, the structure of hierarchical objects is visible in the corresponding program because of the syntax of separators and the m odel statement. Program vs. Data. In Scheme, programs and data share a common printed form. Keywords and variables correspond to symbols. Program constructs (syntactic forms) cor respond to lists. In Scheme, functions and programs can be manipulated in the way that other systems manipulate object databases. This type of representational manipulation can be useful in computer graphics (e.g., genetic progranuning, described in Section 1.1.1). 146 Performance. Performance is an important issue in interactive computer graphies. Scheme has a reputation for being slow, but Scheme compilers now exist that compare favorably with optimized C and Fortran compilers. The AL interpreter allows functions to be implemented in native object code [33]. Formal Specification. Scheme has both formally specified syntax and formally spec ified semantics [22]. Therefore a complete formal specification of AL would only require formal specification of the extensions. 5.3 Fundamental Concepts The AL language is based on a few fundamental concepts. Those concepts are intro duced in this section and are illustrated in more detail in later sections of this chapter. 5.3.1 Geometric Operations and Geometric Primitives AL provides several efficient, high-level procedures and special forms for the construc tion of hierarchical geometric models. These procedures and special forms can be classified into two distinct categories: geometric primitives and geometric operations. Both types op erate within a global context defined by a structure called the graphics state. The graphics state in AL is similar to that used in other graphics systems including PostScript [1], OpenGL [93], Open Inventor [130,141] and the RenderMan Interface [107]. The graphics state maintains information used to determine, among other things, how ge ometry is rendered. As the execution of an AL model proceeds, the graphics state is mod ified. At any specific point in time, the current graphics state specifies both a cumulative 147 transformation (the result of an arbitrary number of scales, translations, rotations, etc.) and a table of attributes. Geometric primitives, or gprims, specify simple, geometric shapes or forms including quadrics, polygons, and surface patches. When a gprim is rendered, it is transformed by the cumulative transformation contained in the current graphics state. In addition, any relevant attributes of the current graphics state (e.g., surface color, opacity, and shaders) are also applied to the gprim. Geometric operations, or gops, are operations that modify the current graphics state and thus implicitly modify gprims that are declared afterwards. An overview of the geometric primitives follows in Section 5.4. Geometric operations are discussed in Section 5.5. 5.3.2 World The world model was introduced in Section 3.1.1. To reiterate, the world statement is used to declare the current scene. The world model is analogous to the m ain ( ) procedure in the C programming language. All of the code that generates the scene must be specified in the (body) of the world syntactic form. Conceptually, each time the world statement is evaluated, the old world model is discarded and is replaced by the contents of the new declaration. The syntax is: (world (body)) 148 5.3.3 Graphics Data Types Scheme provides numerous data types including lists, vectors (heterogeneous arrays), symbols, strings, characters and numbers (natural, real, rational, and complex). AL extends that set by adding types for representing points and transformation matrices. Standard mathematical operators are overloaded,"* providing natural and concise operations such as vector-scalar multiplication (See Table 5.1). prototype ___ description + v e c ...) Vector addition. + m a t ... ) Matrix addition. - v e c ...) Vector subtraction. - m a t ... ) Matrix subtraction. * m a t ...) Matrix multiplication. •k v e c r e a l ... ) Vector scalar multiplication. * m a t r e a l ... ) Matrix scalar multiplication. * v e c m a t ... ) Row matrix multiplication. * m a t v e c ... } Matrix column multiplication. / v e c r e a l ... ) Vector scalar division. / m a t r e a l ... Table 5.1 : Overloaded math operators. Additional functions that are convenient for “graphics math” that can be found in li braries for other languages [99] are supplied. These functions include conversion between various spatial and color coordinate systems, interpolation functions including splines and surface patches, and the complete set of noise functions described by Peachey in [35]. A summary of commonly used functions is given in Table 5.2. Most functions transparently ^‘Overloaded functions serve multiple purposes depending on the data types of the arguments when the function is called. 149 operate on all math types. For example, the same interpolation function can be used to interpolate points or scalar values. prototype description (ata n 2 y x ) Computes tan“^ Range: [—tt, tt]. (basis-deriv mat4) Computes the derivative basis matrix of mat4. (bezier-basis) Returns a bicubic Bézier basis matrix. bezier-sfcep Cubic Bézier stepping constant. (bspline-basis) Returns a bicubic B-spline basis matrix. bspline-step Cubic B-spline stepping constant. (clam p X a b ) Clamps jc to the range [a, 6]. (d e g re e s x ) Converts x to degrees. (hsv->rgb veci) Converts a color in HSV space to a color in RGB space. (rg b -> h sv vec3) Converts a color in RGB space to a color in HSV space. ( le r p a b x ) Linear interpolation: a (l — ar) + bx. (mod X y ) Floating point remainder of x /y . (n o is e s) Pseudo random noise function. The seed s may be ID, 2D, or 3D. Range: [—1,1]- PI The constant n. ( ra d ia n s x ) Converts x to radians. (sample-pcs cvs m step u) Samples a piecewise cubic spline at u. The spline is defined by basis m, stepping constant step, and control vertices cvs (a list of reals or vecSs). ( s le r p a b x ) Smooth (Hermite) interpolation between a and b given 2 in [0,1]. (smoothstep a b x ) Returns 0 if x < a, 1 if x > 6, smooth interpolation between 0 and 1 otherwise. (s te p a x ) Returns 0 if x < a, 1 otherwise. Table 5.2: Commonly used math “tools” and constants. ISO 533.1 Graphics Vectors Scheme vectors are heterogeneous arrays of arbitrary length. In computer graphics, we frequently deal with a more restricted form for representing points in three-dimensional space, surface normals, and colors (e.g., red-green-blue representation). The vec2, vecS, and vec4 “graphics vectors” data types provide an efficient and convenient representation for points in R^,R^, and R^ respectively. Graphics vectors have a printed (literal) form that consists of the elements of the vectors (2,3, or 4 real numbers) preceded by the prefix #< and followed by >. For example, a vec3 containing the elements 1,0, and -2.5 is written #<1 0 -2 . 5>. Table 5.3 shows many of the procedures that operate on the vec3 type including a con structor, a predicate for testing whether or not an arbitrary Scheme object is a vec3, pro cedures for retrieving and setting components, and mathematical operations. Many of the procedures shown are overloaded for use with the vec2 and vec4 types. Three commonly used constants x-axxs, y-axis, and z-axis are defined in the global environment and evaluate to #<1 0 0>, #<0 1 0>, and #<0 0 1> respectively. S.3.3.2 Transformation Matrices Themat3 and mat4 data types are provided in AL as an efficient and convenient repre sentation for 3 X 3 and 4 x 4 homogeneous transformation matrices. Transformation matrices have the same printed (literal) form as the graphics vector types (vec2, vec3, vec4) except that either 9 or 16 elements of the 3 x 3 or 4 x 4 matrix respectively are specified in row-major order between the prefix #< and the suffix >. Table 5.4 shows a representative set of the procedures that operate on the mat4 type. Several of these are overloaded for the mat3 type as well. 151 prototype______description (vec3 X y z) Creates a new vec3 containing elements .r, y, z. (v e c 3 ? obj) Returns # t if obj is a vec3, # f otherwise. (xcomp vec) Returns the z component of vec. (ycomp vec) Returnsthe y component of vec. (zcomp vec3) Returns the 2 component of vccJ. (se t-x c o m p i vec-r) Sets the x component of vec. ( vec3 -c o p y veci) Returns a copy of vecJ. ( d o t veci vec 2 ) Returns the dot product of veci and vecg. (c r o s s vecix vecia ) Returns the cross product of vecii and vecJg- ( d is ta n c e veci vec 2 ) Returns the Euclidean distance between the points veci and vec 2 . ( norm vec) Returns the vector length of vec, || vec||. (n o rm a liz e vec) Returns vec normalized to unit length. Table 5.3: Representative procedures for the vec3 type. 5.3.4 Parameter Lists Parameter lists are a commonly used syntactic convention in AL. Parameter lists are used to specify an arbitrary number of parameter values for numerous functions in the AL language. The list is specified as an arbitrary number of name-value pairs. (namci) (valuei) . . . (name„) (value„) The names are Scheme symbols that represent the name of the parameter being set. The parameter determines the type of the value. Parameters may be specified in any order and parameters that are not specified assume a default value. The use of parameter lists and default values greatly simplifies the chore of remembering the syntax of commands. For example, the camera gop has the following prototype. (camera name type (parameterlist)) 152 prototype description (m at4 «0,0 Oo,i •••^*3,3 ) Creates a new mat4 with real elements «0,0 through «3 ,3 - (m at4? obj) Returns # t if obj is a mat4, # f otherwise. ( m a t4 -r e f mat4 i j) Returns the element in row i and column j of mat4. (mat4-setî mat4 i j a) Sets element mat4ij = a. ( transform -point vec mat) Returns vec (a point) transformed by mat. ( in v e r s e mat) Returns the inverse of mat. (transpose mat) Returns the transpose of mat. (determinant mat) Returns the determinant of mat. (m at4-identity) Returns the 4 x 4 identity matrix. (mat4-rotate angle vec3) Returns the transformation matrix corresponding to a rotation of angle degrees about the specified axis vec3. (m at4-translate vec3) Returns the corresponding translation transformation matrix. (mat4-scale vec3) Returns the corresponding scale transformation matrix. Table 5.4: Representative procedures for the mat4 type. The camera gop requires two parameters, the name of the camera and the camera type. Depending on the type of camera, the optional parameters vary. The “perspective” type camera has several options including the camera position (from), the point that the camera is looking at (to), and the field of view (f ov). Because the parameter names are Scheme symbols, each will be preceded by a single quote in the parameter list which denotes it as a literal symbol value. Each statement below shows a valid usage of the “perspective” camera gop: (camera "main" "perspective") (camera "main" "perspective" 'from #<1 1 3> 'to #<0 .5 0>) (camera "cam2" "perspective" 'from #<1 1 3> 'fov 45) 153 5.4 Geometric Primitives The three major types of geometric primitives in AL are quadrics, surface patches, and polygons. Other primitives (e.g., ciuves, points, text) also exist. With a few exceptions, the gprims in AL are based directly on the primitives specified in the RenderMan Interface [107]. In general, gops (Section 5.5) are used to modify gprims; however, each gprim has a set of parameters for controlling specific aspects of the primitive including specification of texture coordinates, shading normals, etc. 5.4.1 Quadrics Seven different quadric gprims are available: cylinder, cone, disk, hyperbo loid, paraboloid, sphere and torus. Each shape has several parameters for con trolling size, sweep angles, and clipping (See Figure 5.1). Further, these shapes can be combined to create more complex shapes using CSG operations which are described in Section 5.5.5. Good examples of the flexibility of the quadric primitives are shown in the encapsulated models in Section 4.2.3 and Section 4.2.5. The syntax for the each quadric gprim is the same: {quadric-name (parameter List) ). All parameters are optional. The parameters and corresponding default values for the sphere gprim are given in Table 5.5. The sphere is a semi-circle swept th e ta m a x degrees about the z-axis. The code below creates a scene containing a single hemisphere. (world (sphere 't:hetamax 180)) 154 » k k ,V v . KzrH 0 _ A _ Figure 5.1: The quadric gprims. From left to right, top to bottom: cone, cylinder, disk, hyperboloid, sphere, paraboloid, and torus. From [107]. 5.4.2 Surface Patches A number of gprims exit for the creation of curved surfaces. The simplest gprim is the patch gprim which is used to specify single bicubic and bilinear patches. The type is specified as a string argument; either “bilinear” or “bicubic.” A list containing four or sixteen control vertices is required for bilinear or bicubic patches respectively. The vertices are specified in row-major order (where the parametric variable u varies along each row). (p atch type 'P (vertex list)) Note that in the prototype above, the control vertices are specified using the P (“points”) parameter. The type of control vertices used can be varied. Control vertices (including polygon vertices) can be specified using three-dimensional points (P parameter), homoge neous points (Pw parameter), or height values (P z parameter). 155 name default description r a d iu s I Radius. zm in -1 Minimum clipping plane along z-axis. zmax 1 Maximum clipping plane along z-axis. th e ta m a x 360 Sweep angle (in degrees). Table 5.5: Optional sphere parameters. A square can be represented by a bilinear patch with the following statement. (patch "bilinear" 'P '(#<-1 I 0> #<1 1 0> #<-I 0 0> #<1 0 0>) ) Piecewise, bicubic patch meshes are specified using the patch-mesh gprim. (patch-meshtype nu itwrap nv vwrap' P (vertex list) ) In a patch mesh, the number of vertices along each parametric dimension {nii and nv) must be specified. In addition, the patch mesh can be specified as “periodic” or “non periodic” about either dimension {itwrap and vwrap) which allows the patch to be wrapped without repeating control points. The interpolation basis used for bicubic patches and patch meshes is a part of the graph ics state (Table 5.6). By default, a Bézier basis is used. The basis can be changed using the basis gop. For convenience, a number of built-in bases are provided including Bézier, B-spline, CatmuU-Rom, and Hermite; however, arbitrary bases can be specified using a 4 x 4 matrix. A synopsis of the different spline bases and a more detailed discussion of patch-based primitives is given in [136]. Figure 5.2 shows the use of the patch-mesh gprim to create the bowl-like shape shown in Figure 5.3. The bowl is defined by a B-spline mesh consisting of a grid of 4 x 6 control vertices. The mesh is periodic along the u dimension. 156 (basis "bspline") (patch-mesh "bicubic" 6 "periodic" 4 "nonperiodic" 'P '(#<1.435 -2.48549 l.I8> #<-1.435 -2.48549 1.18> #<-2.87 0 1.18> #<-1.435 2.48549 1.18> #<1.435 2.48549 1.18> #<2.87 0 1.18> #<0.28 -0.484974 0.47> #<-0.28 -0.484974 0.47> #<-0.55 0 0.47> #<-0.28 0.484974 0.47> #<0.28 0.484974 0.47> #<0.56 0 0.47> #<0.64 -1.10851 -0.66> #<-0.64 -1.10851 -0.66> #<-1.28 0 -0.66> #<-0.64 1.10851 -0.66> #<0.64 1.10851 -0.66> #<1.28 0 -0.66> #<-0.635 1.09985 -1.02> #<0.635 1.09985 -1.02> #<1.27 0 -1.02> #<0.635 -1.09985 -1.02> #<-0.635 -1.09985 -1.02> #<-1.27 0 -1.02>)) Figure 5.2: Code fragment for a bowl-like shape represented by a 4 x 6, B-spline patch mesh. Non-uniform rational B-splines (NURBs) and trim curves can also be specified. See [85] for a description of the corresponding primitives. 5.4.3 Polygons The most commonly used primitive for polygonal surfaces is points -polygons. This primitive uses a vertex-based organization (Section 1.1.1) and has the following pro totype: (points-polygons (face list) 'P (vertex list)) The face list contains a list of polygon definitions. Each polygon is defined by a list of indices that reference points in the vertex list (indexing begins at zero). Figure 5.4 shows the use of thepoint s -polygons primitive to create a cube using the organization given in Figure 1.10 on page 12. 157 Figure 5.3: Bowl-like shape created using a patch mesh. Geometric primitives for creating single polygons (polygon) and polygons with holes (general-polygon and general-points-polygons) are described in [85]. The box gprim, (e.g.. Figure 4.12), creates a cube equivalent to that shown in Figure 5.4. 5.4.4 Rendering Parameters Additional parameters, often needed for rendering (e.g., smooth shading normals, tex ture coordinates, etc.), can be specified in the parameter lists for most gprims. In general, the values of these parameters are associated with the vertices used to define the shape. For example, the cyclorama model (Section 4.2.1) dynamically modifies the texture coor dinates of the cylinder and the two bilinear patches used to build the model. The parameter S t is used to specify the texture coordinates for each primitive (Figure 4.6). The texture coordinates consist of a pair (s, t) for each vertex of the geometric primitive.— ^Quadrics are specified as parametric surfaces of u and v. Conceptually, the parametric “vertices” of a sphere then are for (u, v) = (0,0), (1,0), (0,1), (1,1) with u corresponding to longitude and v corresponding to latitude. 158 (points-polygons '((0 1 2 3) (5 1 0 4) (6 2 1 5) (7 3 2 6) (4 0 3 7) (7 6 5 4) ) 'P '(#<-]. -1 1> #<1 -1 1> #<1 -1 -1> #<-1 -1 -1> #<-1 1 1> #<1 1 I> #<1 1 -1> #<-] 1 -1>) ) Figure 5.4: Code fragment for a cube represented using polygons. 5.5 Geometric Operations Geometric operations (gops) modify the graphics state. The graphics state consists of two independent stack data structures. One stack maintains the current transformation ma trix (the matrix stack). The other stack maintains an attribute table (the attribute stack). Some of the attributes are shown in Table 5.6. Accordingly, most gops divide into those that modify the transformation matrix (transformation gops) and those that modify the at tribute table (attribute gops). In addition, there are operators used to localize the effect of gops called separators, specify viewpoints (cameras), and build solid models using com putational solid geometry (CSG). 5.5.1 TYansformations The complete set of transformation gops is shown in Table 5.7. With the exception of the transform gop, all gops premultiply the current transformation matrix (the CTM) 159 attribute default value description color #<1 1 1> surface color (RGB) opacity #<1 1 1> surface opacity (RGB) surfaces — surface shader lights — light source shaders list motion-blur # t true primitives are motion blurred rendered # t true gprims are rendered (off-line rendering) displayed # t true gprims are displayed (real-time rendering) divisions (10,10) display quality of gprims basis Bezier bicubic basis matrix light-shadows # f true lights cast shadows casts-shadows # t true objects cast shadows hierarchy "/world " full name of the current model Table 5.6: Sample attributes of the graphics state. with a new transformation matrix. In other words, the first transformation specified lexi cally is actually the last one applied. To rotate and then translate a box, the translate gop is specified first followed by therotate gop. ; ; rotate then translate a torus (translate 1 0 0) (rotate 45 y-axis) (torus) Points are transformed by matrices as column vectors. Thus, p' = Mp, wherep is the original point, M is the transformation matrix, and p' is the result of p transformed by M. 5.5.2 Attributes Unlike transformation gops that modify the current transformation matrix, attribute gops (with the exception of light sources) replace the corresponding value in the current attribute table (See Table 5.6). In general, attribute gops affect the way gprims are drawn. This 160 prototype description {brans form mat4 ) Replaces the CTM withmat4. (concat-brans form mat4) Concatenates onto the CTM. ( s c a l e xyz) Concatenates a scale transformation onto the CTM. ( s c a le 5 ) Concatenates a uniform scale transformation onto the CTM. ( ro b a b e angle vec3 ) Concatenates a rotation transformation of angle degrees about the axis vec3 onto the CTM. ( brans labe xyz) Concatenates a translation transformation onto the CTM. {slfi&fi angle vec3i vecJg ) Concatenates a skew transformation of ang/e degrees between vectors vec3i and vec32 onto the CTM. ( c tm ) Returns the CTM. Table 5.7: Transformation gops. includes material properties (color, opacity, shading), basis functions for bicubic surface patches, trim curves, light sources, and other rendering controls. Table 5.8 summarizes many of the available attribute gops. Shaders (e.g., light sources, surface shaders, etc.) have unique properties when com pared to those of other attribute gops. First, they are transformed by the current transfor mation matrix. Thus, the scale (i.e., frequency) of a solid texture, for example, can be modified using the conventional scale gop. Further, shaders can be incorporated into hi erarchical models. For example, a light source carried by a figure can automatically move with the figure if the light is incorporated into the same articulated hierarchy. Second, light source shaders are accumulated (other gops including surface shaders replace the previous attribute) so that objects can be illuminated by more than one light. Light sources cannot be explicitly removed, but the application of light sources can be localized using separators and the illuminate gop. 161 prototype description ( c o lo r rgb) Set the current surface color. ( o p a c ity rgb) Set the current surface opacity. ( s u r f a c e name (paramlist)) Set the current surface shader. ( l i g h t name (paramlist)) Add a light source to the current set and return the light source identifier. (illum inate id bool) Turn the specified light {id) on or off. (displacement name (paramlist)) Set the current displacement shader. (atmosphere name (paramlist)) Set the current atmosphere shader. (re n d e re d bool) Turns the rendering (off-line) of gprims on or off. (displayed bool) Turns the display (real-time) of gprims on or off. (motion-blur bool) Turns motion blur for primitives on or off. ( b a s is type) Specifies the current bicubic basis by type (e.g., “bezier,” “bspline,” “catmullrom,” “hermite”). ( b a s is matdstep) Specifies the current bicubic basis as mat4 with stepping factor step. (light-shadows bool) Specifies that light sources will or will not cast shadows. (casts-shadows bool) Specifies that gprims will or will not cast shadows. Table 5.8: Commonly used attribute gops. 5.5.3 Separators Two gops, separator and x£m-separator, are used to group gprims and gops into logical components. Both types of separators may be nested to an arbitrary depth to create hierarchically organized components. These special syntactic forms localize the effect of other gops to a particular body of expressions by pushing and popping one or both of the stacks in the graphics state. When a stack is “pushed,” a copy of the top-most item of the stack is placed on top of the stack. 162 When the stack is “popped,” the top-most item is discarded which leaves the stack in the state before the previous push. The separator pushes both the attribute and transformation stacks. The x£m-sep arator only pushes the transformation stack. (separator (body)) (xfm-separator (body) ) Thexfm-separator has two main purposes. First, because only the transformation stack is pushed/popped, the xfm- separator is more efScient than the separator when only transformations need to be preserved. Second, the xfm- separator is needed in order to transform shaders independently of geometry. For example, assume we have a “marble” shader, which produces a marble-like pattern using solid texture [102], applied to a sphere. (surface "marble") (sphere) The surface gop must appear before the gprim in order to be applied to the gprim. Placing a scale before the surface call will not work because it will scale both the shader and the sphere (we only want to scale the shader). Placing a separator around the scale and shader is also incorrect because the separator will prevent the shader from being applied to the sphere. The xfm-separator, on the other hand, localizes the transformation to the shader but does not modify the attributes of the graphics state, thus the scaled marble shader will be applied to the sphere. ; ; increase marbling frequency (xfm-separator (scale 0.5) (surface "marble")) (sphere) 163 The graphics state in AL is programmable. New attributes of arbitrary type can be added by the user and automatically maintained by the standard separator gops. For ex ample, in a dynamics simulation, it might be desirable for each geometric object have a “rigidity” attribute that defines how flexible or rigid a shape is under the application of ex ternal forces. By adding “rigidity” as an attribute of the graphics state, the attribute can be easily applied and isolated to entire sub-hierarchies of the scene using a new gop and the existing functionality of separators. 5.5.4 Cameras Cameras specify view transformations for the scene. An arbitrary number of cameras can be specified in the world model. The scene can be viewed from any camera in the world model using the Ogre tool. Multiple Ogre tools can be used to view the scene firom a variety of different cameras angles simultaneously. Cameras are affected by the current transformation matrix and thus can be easily incorporated into object hierarchies. AL pro vides two types of cameras — “perspective” and “orthographic.” New types can be defined by the user. The syntax is: (camera type (paramlist)) The optional parameters for perspective and orthographic cameras are shown in Ta ble 5.9. 5.5.5 CSG Closed primitive shapes can be combined to create more complex shapes using com putational solid geometry (CSG) techniques (Section 1.1.1). The solid gop is used to 164 name default description from #<0 0 1> Camera position. to #<0 0 0> Point at which the camera is directed. r o l l 0 Rotation about view vector (degrees). f ov 90 Field of view (degrees) — “perspective” camera only. Table 5.9: Perspective and orthographic camera parameters. specify primitive shapes and perform boolean operations (union, intersection, difference) on shapes. (solid operation (body)) The operation is either “primitive” (to specify a new, closed primitive shape), “union,” “intersection,” or “difference.” The (body) of the solid statement contains primitive shapes or solid statements along with transformations and surface attributes. Figure 5.5 provides the AL code used to generate the boolean object shown in Figure 1.8 on page 10. Note that thecylinder gprim has to be capped using two disk gprims before it can be defined as a primitive (i.e., solid) shape. 5.6 Rendering Rendering of the world model is universally performed by the render conunand. This command is called explicitly, outside the world model, by the user when high-quality rendering of firames is required. It is also called implicitly to update interactive displays in response to interactive modifications. Rendering requires evaluation of the world model. As the world model is evaluated, individual gops and gprims are dynamically translated to instructions for specific output 165 (solid "difference" (solid "union" (solid "primitive" (scale .25 1 1) (box)) (solid "primitive" (translate 1 -0.75 0) (scale 1 0.25 1) (box)) ) (solid "primitive" (translate 1.1 0 0) (rotate 90 x-axis) (disk 'radius 0.5 'height -.5) (disk 'radius 0.5 'height 1.5) (cylinder 'radius 0.5 'zmin -.5 'zmax 1.5))) Figure 5.5: Code for a simple object constructed using CSG. devices via software modules called render packages. Render packages are used to im plement interfaces to both interactive and high-quality tenderers. A summary of render packages is given in Table 5.10. New render packages can be defined by the user. name description ogre OpenGL-based, interactive display tool, rib Generic RIB (RenderMan Interface Bytestream). prman Pixar’s PhotoRealistic RenderMan. bmrt Gritz’ Blue Moon Rendering Tools. null Evaluates the world model, but does not produce rendering output. Table 5.10: Available render packages. 166 Therender command has the following syntax: (ren d er (paramlist)) The parameter list is used to control various aspects of the rendering process. Some parameters are standard (i.e., they apply to all render packages); others are render package (device) specific. A sununary of standard parameters is given in Table 5.11. In some cases, the tasks performed by render packages can be sophisticated. For example, the “prman” render package automatically generates statements for motion blur and pre computes tex ture files (shadow maps and environment maps) needed for global illumination. name ______type______description ______p a c k a g e string The render package to use (e.g., "prm an" ). fram e varies The frame number(s) to render. A single frame or range can be given. p re fra m e procedure A function to call before each frame is rendered, p o s t fram e procedure A function to call after each frame is rendered, tim e c o n v e r te r procedure A function that converts the current frame number to global time. Table 5.11: Standard render package parameters. 5.7 Implementation The current version (Version 5) of the AL software system consists of roughly 35,0(X) lines of C++ and Scheme code. This does not include the base Scheme interpreter or system libraries (e.g., OpenGL). The AL run-time environment is available in the public domain for SGI and HP UNIX workstations and also IBM PCs running the Linux operating system. The AL software can be downloaded firom: ftp://cgrg.ohio-state.edu/pub/AL. 167 The AL interpreter. Ox, is an extension of an R4RS-standard [22] Scheme language interpreter called Elk by Oliver Laumann [74]. In addition to providing standard Scheme functionality, EUc provides a number of extensions to Scheme including interfaces to UNIX, X Windows [118], and Motif [97]. An extremely important feature of Elk is that the in terpreter can be extended by dynamically loading compiled modules written in C or C++. This allows performance critical features to be implemented in native object code (as op posed to being interpreted in Scheme) and allows libraries implemented in C or C++ to be easily incorporated. This author has added several, independent extensions to Eüc including Scheme interfaces to the RenderMan Interface [107] and OpenGL [93], and a high-level toolkit for building user interfaces. While these extensions were not required to imple ment the AL language, they are used to implement the interactive tools included in the AL run-time environment. To the user, the AL run-time environment consists of a text-based interpreter and a set of interactive tools. Each tool is relatively small in that it is designed for one specific purpose (e.g., modifying a particular type of afunc). The tools are independent units and thus can be easily implemented and maintained. The user environment is easily customized by starting up tools of the appropriate type and quantity. This tool-oriented approach is advocated in the Menv system [111]. As is done in Menv, older versions of the AL run time environment used independent UNIX processes that used shared memory for IPC (inter-process communication). A C++ class hierarchy was constructed that encapsulated the details of synchronization and shared memory allocation [86]. Unfortunately, there are serious limitations with regards to C++ classes in shared memory — e.g., no virtual functions, no static data members. Even with the IPC library, distributed programming 168 is difficult; thus, it was difficult for anyone without in depth knowledge of the system to implement new tools. In the current version of the AL run-time environment, shared memory communica tion has been eliminated and all interactive tools are implemented as AL/Scheme programs that run directly from the Ox interpreter. Ox was modified to be event-based which al lows multiple programs to execute concurrently. Because all of the tools are implemented in Scheme, communication is through Scheme data structures (e.g., the exposure sheet) which greatly simplifies the implementation of the tools and the bookkeeping associated with the evaluation of AL models. Most synchronization problems are avoided because there is only one UNIX process. The obvious disadvantage is that only one processor on a multiprocessor platform is utilized, but the advantages of dramatically simpler implemen tation and absence from deadlock situations currently outweigh that shortcoming. 169 CHAPTER 6 Conclusion 6.1 Summary This research began with the observation that while computer animation and modeling techniques have advanced (and continue to advance), representations (i.e., data formats) for animated objects, relatively speaking, have not. Data formats for objects that integrate dy namic components including, but not restricted to, animation, modeling, shading, lighting, user interfaces, and sound do not exist. As a result, the concept of an “object” in computer animation has been limited to what can be described by the existing, relatively primitive, data formats that are currently available. In order to expand the concept of an “object” and improve the sophistication of computer animation systems that manipulate objects, a foundation consisting of more expressive representations for objects must be developed. It is reasonable to suggest that the most complex requirement of new data formats is the capability to represent procedurally defined and interrelated components. Procedural com ponents are defined by processes, not static databases. Therefore, the representation must be capable of describing processes. The most ubiquitous representation for processes in 170 computer science is the programming language. However, a general purpose programming language (e.g., C++ or Java) is an inefficient mechanism for describing animated objects. This is because programming them requires a significant underlying framework including the ability to easily specify geometric shapes, geometric and photometric transformations, and controls that can be interactively manipulated. A better alternative is to use a program ming language specialized for the production of photorealistic computer animation — a procedural animation language. This research defines the term “encapsulated model” or “emodel.” An encapsulated model is an animated object containing an integrated set of dynamic attributes — e.g., shape, motion, materials (surface properties), light sources, cameras, user interfaces, sound — represented by a procedural data format (i.e., a program written in a procedmral anima tion language). A set of properties that characterizes encapsulated models is presented. From these properties, a set of requirements for an appropriate procedural animation language is de rived. Chief among these requirements is the requirement for mechanisms that permit interactive manipulation of the procedural specification of an emodel. To satisfy this re quirement, a new programming language mechanism called “articulation functions” (or “afimcs”) is proposed. To demonstrate the practical application of the concepts in this research, a prototype procedural animation language, called AL, was developed. The AL language incorporates the best features of previous animation languages and includes several new features in cluding the articulation function mechanism. The AL software environment includes an AL language interpreter and graphical user interface tools for interactive manipulation of encapsulated models via articulation functions. 171 The results of this research are given in the form of working examples of encapsulated models that can be manipulated in real-time using current workstation technology. These examples demonstrate that articulation functions are a more powerful and general mech anism for interactive animation and manipulation than previously developed mechanisms. Further, these examples illustrate the benefits of encapsulated models over existing, static data formats. In particular, emodels are shown as an enabling technology for the (possibly commercial) exchange of models that are parameterized (i.e., reusable), have high-level interactive controls, and have self-contained, integrated components such as animation and modeling. These traits potentially lead to reduced costs in the production of photorealistic computer animation. 6.2 Future Research This dissertation presents initial efforts to address the issues concerned with procedural representations of data for computer animation. There are many points of departure for future research. The development of the AL language is not complete. In particular, one of the language requirements for encapsulated models that has not been implemented in AL is support for sound rendering. Effective and flexible primitives for sound rendering, specifically rendering of MIDI files, need to be developed. Another area for future development in AL is enhanced support for simulation. The functional nature of the world model is clumsy for specifying the distributed processes needed for physical and behavioral simulation. New language primitives should be devised to aid the user in constmcting models that utilize 172 simulation. An important consideration, with regards to such primitives, is the need for animator control of the simulation through articulation functions. In order to use AL as a portable data format, the integration of AL into existing in teractive animation systems must be investigated. For example, an AL plug-in could be developed for a commercial interactive animation system. The plug-in would be used to import emodels written in AL into the existing scene hierarchy. Articulation functions would attach directly to the interactive tools of the commercial system. AL could also be integrated with visual programming systems. Existing visual programming systems could produce AL programs. Alternatively, a new type of afunc could be developed to provide a visual programming interface for building parts of an AL model within the AL mn-time environment. The development of articulation functions is incomplete. Extended functionality and applications for the proposed types — channels, rasters, gcurves — should be developed. For example, functionality to sample gcurves and gcurve derivatives parametrically should be provided. As an example of extended applications, the author feels that gcurves could be an effective means for specifying animated feature points for facial animation. Further, new types of articulation functions could be developed. Some possible types include vector flow fields, skeletal armatures, and specialized user interfaces. A number of aspects related to interaction have yet to be pursued. Articulation functions have been shown to be a powerful mechanism for interactive modifications of programs. However, simpler forms of interaction through specialized interactive software programs may be possible. Most models contain numerical constants used as parameters to gops and gprims. Articulation functions are sometimes used in place of these constants so that, for example, shapes can be interactively positioned even though the shape will ultimately 173 remain at a fixed location. In this case, once the shape is in position, the afunc is sometimes removed and replaced by the constant numerical value that was represented by the afunc (because the model builder does not intend for the value to be animated). An alternative solution, for interactive manipulation of constant values, is to build a text editor that allows values to be modified by selecting the number (in the text of the program) and dragging the mouse. Dragging the mouse would increment or decrement the number and immediately re-evaluate the model for interactive visual feedback. Performance issues are an important consideration. “Unrolling” models (as described in [60, 111]) and other techniques that produce an intermediate, but more efficient, rep resentation lead to restrictions in the usage of the language, of which the developer must be aware. In the current version of AL, the evaluation of sub-hierarchies can be selectively turned on or off by the user. In addition, the OpenGL display lists [93] generated for interac tive display in Ogre can be cached for sub-hierarchies so that evaluation is only needed for models dependent on the current afimcs being edited. Another problem is related to mul tiple evaluations of the world model. Multiple evaluations of the world model are avoided due to cost, but are required when different temporal samples are need (e.g., motion blur). Implementation of context sensitive language semantics (e.g., when one model references the current coordinate system of another model in the hierarchy) requires special strategies to avoid unnecessary evaluations. Finally, this research is centered about representations of data. The concepts explored may have applicability in other related areas in computer science and engineering. For example, a topic receiving considerable attention recently is “virtual prototyping.” Virtual prototyping is an area in CAD/CAM research where models are developed to not only sim ulate the geometry of physical objects, but also the mechanical and physical processes that 174 act on those objects. These types of models incorporate traditional solids modeling with simulation and scientific visualization. Effective procedural representations and interactive manipulation of procedural representations would likely be valuable in that field as well. 175 APPENDIX A Encapsulated Model Code Listings A .l Sunlight Computations This listing provides the implementation for the s u n - p o s it i o n function used to implement the sunlight encapsulated model (Section 4.2.2). Compute the altitude and azimuth given altitude of observer, hour-angle, and declination. (define (altitude-azimuth phi ha delta) (let ( ; as s azimuth (az (atan2 (sin ha) (- (* (cos ha) (sin phi) ) (* (tan delta) (cos phi))))) : ; h « altitude (h (asin I* (* (sin phi) (sin delta) ) {* (cos phi) (cos delta) (cos ha)}))) ) (cons h as))) Compute the day-number from date and universal time. (define(♦ (day-number year month day ut) (• 367 year) (- ( truncate (/ (• 7 {♦ year (truncate (/ (♦ awnth 9) 12) ) ) ) 4) ) ) (truncate (* 275 (/ month 9))) day -730530 (/ ut 24)}) Compute "sidereal" time given day number, universal time, and longitude of observer. (define (sidereal d ut long) (♦ 98.9818 (• 0.985647352 d) (" ut 15) long)) ; ; Compute the position of the sun as altitude and azimuth and 176 also stmrise and sunset. These values are returned in a list as follows: ( (alt . azimuth) sunrise . sunset) . Cosfnication is Cor EST time zone, northern hemisphere, and observer position is expressed as west longitude, north latitude. (define (sun-position year laonth day hour long lat) (let* ( (tz S) ;; tz « timezone differential. S»BST (t (» tz hour) ) ;; t » universal time (hrs. 24hr system) ; ; d s day number (d (day-number year month day t) ) ;; theta * "sidereal" time (degrees) (theta (radians (sidereal d t (- long)11) ;; confutation of Sun's true longitude (slon) (epsilon (radians (- 23.4393 (" 3.S63e-7 d)))) (w (radians (♦ 282.9494 (" 4.7093Se-5 d ) ))) (K (radians (-» 356.C470 (" 0.9856002585 d) ) ) ) (e (- 0.016709 C 1.151e-9 d ) )) (E (»M('e (Sin K) (*l('e (cos M) ) ) ) ) ) (A. (- (cos E) e) ) (B (• (sqrt {- 1 (sqr e ) )) (sin E) )) (slon (» (atan2 BA) w)) ; ; alpha - right ascension of Sun (alpha (atan2 (* (sin slon) (cos epsilon)) (cos slon))) ; ; delta » declination of Sun (delta (asin (* (sin epsilon) (sin slon)))) (K (- theta alpha) ) ;; H > hour angle (trr) ; ; HT * meridian time (HO) ; ; HO > hour angle at rise/set (rise) (set) ) ;; if alpha is < 0, add 360 degrees (if (negative? alpha) (set! alpha (* alpha PI PI))) (set! MT (- alpha (radians (sidereal d 5 (- long) ) ) ) ) : ; HO « hour angle at sunrise/sunset ;; (computation for upper limb of Sun) (set! HO (acos (/ (- (sin (radians (/ -50 60))) (* (sin (radians lat)) (sin delta))} (* (cos (radians lac)) (cos delta))))) ; compute sunrise and sunset (set! rise (- M T HO)) (set! set (* M T H O ) ) : ; convert to liours (set! rise (/ (mod (degrees rise) 360) 15)) (set! set (/ (mod (degrees set) 360) 15)) : ; return values in a list of 2 pairs (altitude-azimuth (radians lat) H delta) (cons rise set)) ) ) A.2 Alarm Clock Model The implementation of the alarm clock model (Section 4.2.5) is given below. ;; A single bell (define (bell cloclcradius thic)cness bellangle bellrocle) (let ( (bellradius (* 0.5 thic)cness) ) ) (xfm-separator 177 (rocaee bellangle r> : A support post for a bell (define (bellpost clocicradius thickness bellangle) (let ( (bellradius (* 0.5 thickness)) (postradius (* 0.05 thicloiess) ) ) (xfa-separator (rotate bellangle :-axis) (rotate -90 x-axis) (translate 0 0 (* clockradiua (* 0.2 (oellradius) ) ) ; the support post (cylinder * radius postradius 'aoin ( * -0.3 bellradius) 'zmax ( * 0.88 bellradius)) (disk 'radius postradius 'height ( * 0.88 bellradius) ) I)) ; ; The hammer between the bells (define (hairmer clocicradius thickness hasnerrock) (let* ( (slit (* 0.1 thickness)) (halfslit (* 0.5 slit)) (fourthslit (* 0.25 slit)) )(halfhamaer (* 0.25 thickness) ) (xfm-separator (translate 0 ( * 0.7 clocicradius) 0) (rotate ( * hammerrock -12) z-axis) ; ; the support for the hasner (box " m i n c o m e r (vec3 (- halfslit) 0 (- fourthslit)) ' m a x e o m e r (vec3 halfslit (* 0.5 clocicradius) fourthslit) ) (translate 0 (* 0.5 clocicradius) 0) (rotate 90 y-axis) ; the hassner (cylinder radius slit 'zmin (- halfhammer) zmax halfhammer) (disk 'radius slit height half hammer) (rotate 180 y-axis) (disk ' radius slit 'height halfhansner) ) ) ) : : A single leg (define (leg clockradius legangle leglength legradius footradius) ( xfm-separator (rotate legangle z-axis) (rotate 90 x-axis> (translate 0 0 clockradius) ; the leg (cylinder 'radius legradius 'zmax leglength) (translate 0 0 leglength) ; ; the round foot (sphere 'radius footradius zmin (- footradius) 'zmax footradius) ) ) ; ; The four legs (define (legs clocicradius thic)cness lift) (let* ( (legangle 30) ( legradius ( / cloc)cradius 20 ) ) {footradius (/ clockradius 10)) (leglength (- (/ (- lift footradius) (cos (radians legangle) ) ) clocicradius) ) (legoffset (- (* 0.5 thic)oiess) (* 0.8 legradius))) ) (begin : back legs (xfm-separator (translate 0 0 (- legoffset) ) (leg clocicradius legangle leglength legradius footradius) (leg clocicradius (- legangle) leglength legradius footradius)) 178 ; (rone legs (xfm-sepAracor (eranslace 0 0 legoCfsec) (leg cloetaradius legangle leglength legradius footradius) (leg clockradius (- legangle) leglength legradius footradius) ) ))) ; The face of the clock (define (clockfaee faceradius thickness protrusion) (separator (divisions 20 5) (if ( ;; The back panel of the clock (define (baekpanel faceradius thicicness protrusion) (separator (divisions 20 5) (if ( ;; The clock case (with a slit in the top for the hammer) (define (clockcase faceradius rimradius thickness) (let ( (halfthickness (* 0.5 thickness)) (halfslit (* 0.05 thickness)) (halfslicangle 8) ) (separator (divisions 20 3) ; clock case with slit on top (rotate (* 90 halfslicangle) z-axis) (crylinder radius (» faceradius rimradius) 'zmin (- halfthickness) 'zmax (- halfslit) ) (cylinder 'radius (* faceradius rimradius) 'zmin (- halfslit) 'zmax halfslit 'thetamax (* 360 (* 2 halfslicangle))) (cylinder 'radius (* faceradius rimradius) 'zmin halfthic)cness 'zmax halfslit) (divisions 20 6) ; ; back lip of case (translate 0 0 {- halfthickness)) (torus 'phimin -180 'phimax 0 'minorrad rimradius 'majorrad faceradius) ; ; front lip of case (translate 0 0 thic)cness) (torus 'phimax 180 'minorrad rimradius 'majorrad faceradius) ))) ;; The liands of the clock (define (hands faceradius chic)oiess protrusion hour minute) (let ( 179 (twuutradius (/ faceradius 28)) (knobradius (/ faceradius 14 ) ) ; ; the minute hand is updated once every SO seconds (minuteangle {* (/ (floor minute) SO) 360) ) : ; the hour hand is updated once every five minutes »(hourangie (* (/ (♦ (floor hour) (/ (floor (/ minute 5)) 12)) 12) 360) ) {xfm-separator (translate 0 0 (* (* 0.5 thickness) protrusion)) ; ; knob connecting hands to face (sphere 'radius knobradius 'rmin (- )cnobradius) 'zmax knobradius) (translate 0 0 (» (* 0.1 )mobradius) ) ) ; ; hour hand (xfm-separator (rotate (- 180 hourangle) s-axis) (rotate 90 x-axis) (cylinder 'zmax (* 0.5 faceradius) 'thetamax 180 'radius handradius) (disk 'height (* 0.5 faceradius) 'thetamax 180 ' radius handradius) ) ; minute hand (xfm-separator (rotate (- 180 minuteangle) z-axis) (rotate 90 x-axis) (cylinder 'zmax (* 0.8 faceradius) ' thetamax 180 'radius handr adius) (disk 'height (* 0.8 faceradius) 'thetamax 180 'radius handradius) ) ) ) ) ; ; The clock (define (alanaclock hour minute cloc)ccolor) (model "alarmclock" ( (ringing "channel* 'map (lamlxia (x) (step Ox))) (exaggeration "channel") ) (let" ( ( cloc)cradius 1.5) (tbic)cness 1.0) (lift ( " (/ 4 3) clocicradius} ) ( rimradius ( / cloc)cradius 15 ) ) (faceradius (- clocicradius rimradius) ) (protrusion (* 0.25 thicicness) ) (bellangle 30) (laellrocicl 0) (l3ellroc)c2 0) (haxmerrock 0) I (separator (translate 0 lift 0) (if (positive? (ringing)) (let* ( (ampx ("0.5 (exaggeration) )) (amps (" 0.2 (exaggeration) )) (ampt (" 30 (exaggeration) )) (clockroclcx (* ampx (noise (* 0.237 PI time)))) (cloc)croclcs (" amps (noise (" 1.439 PI time)))) ) (clccktwist (" ampt (noise (" 3 PI time)))) (translate cloclcroclcx 0 clockrocks) (rotate clocktvist y-axis) ) ) : movement of the laells and liammer (if (positive? (ringing)) (begin (set! hammerrock (sin (* 1.23 PI time))) (set! bellroclcl (noise (* 1.237 time))) (set! bellroc)c2 (noise (* 1.192 time))) )) : the casing, legs, bell-posts. and hammer (separator (surface "plastic" 'Ka 0.05 )Cd 0.65 *Ks 0.3) (color clockcolor) (cloclccase faceradius rimradius thicicness) (baclcpanel faceradius thicicness protrusion) (legs clocicradius thickness lift) (bellpost clocicradius thickness bellangle) (bellpost clockradius thickness (- bellangle)) (hammer clockradius thicicness hasmerrock) ) ;; the bells (separator (surface "metallic* 'texeuremap "office.env" 'roughness 0.151 (color 0.6 0.6 0.6) (bell clockradius thickness bellangle bellrockl) (bell clockradius thickness (- bellangle) t>ellroc)c2) ) ; the clock face (separator (surface "texturedplastic" 'Ka 0.1 'Kd 0.5 'tCs 0.4 'texturename "clockface.tex") (color 111) 180 (clockfaee faceradius chicJcness procrusion) ) ; che hands (separacoc (surface ‘plastic* 'Ka 0.05 'Kd 0.5 Ks 0.5) (color 0 0 0) Oiands faceradius thickness protrusion hour minute) ) ) ) ) ) A 3 Chandelier Model The implementation of the chandelier model (Section 4.2.6) is given below. The imple mentation of one of the geometric modeling routines and the exposure sheet file used for Figure 4.18 are also provided. ;; The chandelier model. (define (chandelier name numcandles intensity glow glowspread) (model name ( (flicker ‘channel*) (hook ‘gcurve*) (crunk ‘gcurve*) (candle-holder ‘gcurve*) (candle-stern ‘gcurve* ) (candle-end ‘gcurve") ) (let ( (candle-position (last-point (candle-stern))) (candle-id) (light-ids (make-vector numcandles) ) ) ; chandelier is created about r-axis, rotate to make it upright (rotate -90 x-axis) make candle light sources first, since lights must all be declared before the geom for lights to illuminate the chandelier. che light ids are stored in a vector ( light-ids) which is returned by che model so that che lighcs can be cumed on/off wich che 'illuminate* gop. (for i 1 numcandles 1 (xfm-separator (rotate (* i (/ ISO numcandles) ) s-axis) ;; move candle and holder to end of che stem (rotate 90 x-axis) (translate candle-position) (rotate -90 x-axis) ; ; make candle light source (set! candle-id (candle intensity glow glowspread (flicker) i ' light)') (vector-set! light-ids (- i 1) candle-id))) : now make the geometry (for i 1 numcandles I (xfm-separator (rotate ( * i (/ 3S0 numcandles) ) z-axis) ; move candle and holder to end of the stem (xfm-separator (rotate 90 x-axis) (translate (last-point (candle-stern))) (rotate -90 x-axis) (candle intensity glow glowspread (flicker) i 'geom) 181 ; ; candle holder ( x£m-separacor (color .458 .215 .105) (surface "wood" Ks .05 'swirl .5) ; ; Ks was 0.2 (uscale .7} (revolve (candle-holder) 0.8))) ; ; candle stem ( xfm-separacor (rocace 90 x-axis) (excrude-cube (candle-scen) 0.04)) ; ; derail on end of candle seem away from candle holder ( xfm-separacor (rocace 90 x-axis) (cranslace (firsc-poinc (candle-scem))) (rocace -90 y-axis) (rocace -70 x-axis) (scale .6 .4 .4) (revolve (candle-end) 0.4) ) ) ) ; ; crunk of chandelier (color .458 .215 .105) (surface "wood" Ks .05 'swirl .18) (revolve (crunk) 1) : ; chandelier hook (xfm-separacor (color .614 .386 .205) (surface "plascic") (rocace 90 x-axis) (cranslace (firsc-poinc (crunk))} (excrude-cube (hook) 0.025) ) ; ; re cu m Che lighc ids in a lise (veccor->lisc lighc-ids) ))) The model for a single candle. The 'mode' paramecer specifies whecher or noc co creace che lighc source or che geomecry. Thus mode « g e o m or 'lighc. (define (candle incensicy glow glowspread flicker offsec mode) d e c " ( (candle-prof ;; che profile shape of che candle '(#<0.079 0.738 0> #<-0.01 0.61 0> #<-0.05 0.72 0> ♦<-0.06 0.31 0> #<-0.07 0.06 0> #<-0.06 0.01 0>)) ( flame-prof ; che profile shape of che candle flame ‘(#<0.009 0.408 0> *<-0.017 0.207 0> #<0.063 0.0340> #<-0.01 -0.009 0> #<0 0.063 0>)) (lighc-id #f) (noi (noise cime offsec 0.5))) (pnoi (• (• noi 1) 0.5)) (accen (- 1 (* fliclcer pnoi 0.5))) (lighccolor #<1 .85 .5>) ) (xfm-separacor ; candle geomecry (if (eq? mode ’geom) (separacor (surface "macce" K a .1 'Kd .5) (color 1 .783 .651) (revolve candle-prof 0.8))) ; posicion of origin of candle flame (cranslace 0 0 0.69) (cranslace (" 0.05 flicker noi) (* 0.05 flicker noi) 0) ;; lighc source, chis is a modified poinclighc which ; generaces che sofc glowing effecc on che camera lens. (if (and (posicive? incensicy) (eq? mode 'lighc) ) ( xfm-separacor (cranslace 0 0 0.063) (see! lighc-id (lighc "glowpoinc" 'lighccolor lighccolor 'incensicy (" accen incensicy) 'glowColor lighccolor 'glowlncensicy glow ' glowSpread glowspread 'glowFalloff 3 'fallon 1.75)))) ; flame geomecry 182 (1C (and (posicive? incensicy) (eq? mode 'geom) ) (separacor (eascs-shadows •£) ;; don'C wane flame geom co blocic lighc (surface *conscanc*} (color (* lighccolor accen)) (scale 1 1 (-1 (* flicker pnoi))) (revolve flame-prof 0.8))) ) end of separacor ; ; recum che id of che poinc lighc source lighc-id) ) Funccions co gee che fisse and lasc poinc ouc of a lise. If che lise is empcy. #<0 0 0> is recumed. (define (lasc-poinc 1) (if (null? 1) #<0 0 0> (lisc-ref I (- (length I) 1)))) (define (firsc-poinc f ) (if (null? f) $<0 0 0> (car f ) ) ) A.3.1 Surface of Révolution Many of the shapes in the chandelier model are created as surfaces of revolution. The r e v o lv e routine (given below) generates a B-spiine patch mesh surface which is the result of a planar profile curve swept along a closed, circular path. The r e v o lv e rou tine calls on two subordinate functions: p r o f il e - p r o d u c t and m a k e -c ir c le . The p r o f il e - p r o d u c t function sweeps an arbitrary profile about an arbitrary path. It takes advantage of the standard Scheme function map^ to iterate over the path and profile ver tices and construct lists containing the vertices for the surface of revolution. The re v o lv e routine uses m a k e - c irc le to construct a path which approximates a circle and passes this curve as the path to p r o f il e - p r o d u c t . The m a k e - c ir c le function takes two arguments: the radius of the circle and the number of control vertices desired. revolve a profile about che :-axis co conscrucc a B-spline pacch mesh. (define (revolve prof) dec ((pach (make-circle 16))) (if (>« (length prof) 4) (begin (basis "bspline") (pacch-mesh ‘bicubic* (length prof) "nonperiodic* (length path) "periodic* 'P (profile-product path prof) ) ) ) ) ) ^S ee [22] or [33] for a description of map. 183 : sweep a profile curve abouc a path curve. (define (profile-product path prof) (flatten-lisc (map (lambda (a) (map (lambda (b) (vec3 (* (xcomp a) (xcomp b) ) (* (ycomp a) (xcoop b)) (ycomp b) ) ) p r o f ) ) path) ) ) generate a list of control vertices for a B-spline curve which approximate a circle. (define (make-circle r npoints) (let ((dtheta (/ (radians 360) npoints))) (do ((pts '()) (theta 0 (* theta dtheta) ) ) ( (>» theta (radians 359) ) pts) (set! pts (cons (vec3 (* r (cos theta) ) (* r (sin theta) ) 0) pts))))) "flatten" a Scheme list. e.g. ((I 2 3) (4 5 6)) becomes ( 1 2 3 4 5 6). (define (flatten-list 1) (cond ((null? 1) 1) ( (list? (car 1)) (append (flatten-list (car 1)) (flatten-Iist (cdr I)))) (else (cons (car 1) (flatten-list (cdr 1)))))) A.3.2 Sample Exposure Sheet File Below is the exposure sheet file for the chandelier shown in Figure 4.18. AL Exposure Sheet AL version 5.0.8 1/7/981 written Mon Feb 9 16:21:56 1998 (model "world" (model "chandelier" (channel "flicker* ( (4 0 -4.85873 0.00495741 15.0327 -0.0139001 Z) (18 0.450282 -6.20055 0.151 9.62216 -0.238523 Z) (29 0.842381 -4.31634 -0.1517 1.89972 0.071797 Z) (42 1 -7.48366 0.00199682 12.6338 0.00199682 Z) (74 0 -35.2947 0.00478922 4.03601 0 Z ) )) (gcurve "hook" ( (1 (#<-0.265 -0.11 0 1> #<-0.105 -0.04 0 1> #<-0.055 -0.02 0 1> #<-0.175 0.11 0 1> #<0.115 0.11 0 1> «<0.005 -0.02 0 I> *<0.065 -0.05 0 1> #<0.195 -0.09 0 1>)))) (gcurve "trunk" ( (1 (*<0.025 2.39 0 2> #<-0.25 2.275 0 1> #<-0.02 2.285 0 l> #<-0.25 2.155 0 l> #<-0.04 2.215 0 l> #<-0.11 1.505 0 1> #<-0.3 1.285 0 1> #<-0.23 1.025 0 1> #<0.02 0.865 0 I> #<-0.46 0.815 0 I> #<-0.24 0.745 0 1> #<-0.24 0.665 0 1> #<-0.34 0.605 0 1> «<0.06 0.515 0 1> 184 ♦<-0.72 0.335 0 1> ♦<-0.58 -0.135 0 L> ♦<0.03 -0.285 0 l> ♦<-0.16 -0.325 0 l> ♦<0.01 -0.375 0 1> ♦<-0.11 -0.445 0 1> ♦<-0.02 -0.585 0 1> ♦<0.14 -0.885 0 !>)))) (gcurve "candle-holder" ( (I (♦<0.01 0.225 0 1> ♦<0.03 0.065 0 1> ♦<-0.245 0.28 0 1> ♦<-0.115 0.13 0 1> ♦<-0.125 0.08 0 1> ♦<-0.335 0.15 0 1> ♦<-0.495 0.15 0 1> ♦<-0.135 0.04 0 1> ♦<-0.415 0 0 I> ♦<0.1 -0.085 0 I> ♦<0.03 -0.335 0 1»))) (gcurve "candle-scem" ( (1 (^<0.45 0.62 0 2> ♦<0.49 0.51 0 1> ♦<0.245 0.475 0 1> ♦<0.235 0.805 0 1> ♦<0.645 0.825 0 1> ♦<0.765 0.475 0 1> ♦<1.025 0.395 0 1> ♦<1.245 0.495 0 1> ♦<1.305 0.755 0 2>)J n (gcurve "candle-end" ( (I (4<0.22 0.29 0 l> ♦<-0.01 0.18 0 1> ♦<-0.22 0.05 0 1> ♦<-0.22 -0.06 0 1> ♦<-0.01 -0.09 0 1>)|)M) 185 BIBLIOGRAPHY [1] Adobe Systems Incorporated. PostScript Language Reference Manual, second edi tion, 1994. [2] Alias I Wavefront, a division of Silicon Graphics Limited, Toronto, Ontario. Alias Studio, V8, 1997. [3] Phil Ambum, Eric Grant, and Turner Whitted. Managing geometric complexity with enhanced procedural models. In David C. Evans and Russell J. Athay, editors. Computer Graphics (SIGGRAPH 86 Conference Proceedings), volume 20, pages 189-195. ACM SIGGRAPH, August 1986. [4] Susan Amkraut and Michael Girard. Eurhythmy: Concept and process. Journal of Visualization and Computer Animation, 1(1):15—17, August 1990. [5] David Baraff. Coping with friction for non-penetrating rigid body simulation. In Thomas W. Sederberg, editor. Computer Graphics (SIGGRAPH 91 Proceedings), volume 25, pages 31-40, July 1991. [6] Bren Bataclan. Documentation of a pilipino folk song animation utilizing computer graphics technology and visual communication principles. Master’s thesis. The Ohio State University, June 1995. [7] Bren Bataclan, Steve May, and Ferdi Scheepers. Bahay kubo: A pilipino folk song. The Ohio State University, August 1995. [8] Bruce G. Baumgart. Geometric modeling for computer vision. AIM-249, STA CS- 74-463, CS Dept, Stanford University, October 1974. [9] D. Scott Bimey. Observational Astronomy. Cambridge University Press, 1991. [10] Preston Blair. Cartoon Animation. Walter Foster Publishing, Inc., Tustin, California, 1994. [11] James F. Blinn. A generalization of algebraic surface drawing. ACM Transactions on Graphics, l(3):235-256, July 1982. 186 [12] Beth Blostein. Procedural generation of alternative formal and spatial configurations for use in architecture and design. Master’s thesis. The Ohio State University, 1995. [13] Beth Blostein and Terry Monnett. Tectonic evolution. The Ohio State University, August 1995. [ 14] David E. Breen, Donald H. House, and Michael J. Wbzny. Predicting the drape of woven cloth using interacting particles. In Andrew Glassner, editor, SIGGRAPH 94 Conference Proceedings, Annual Conference Series, pages 365—372. ACM SIG GRAPH, Addison Wesley, July 1994. [15] C. Wayne Brown and Barry J. Shepherd. Graphics File Formats. Manning Publica tions Co., 1995. [16] Wayne E. Carlson. An advanced data generation system for use in complex object synthesis for computer display. In Proceedings of Graphics Interface ’82, pages 197-204, 1982. [17] Wayne E. Carlson. Techniques for the generation of three dimensional data for use in complex image synthesis. PhD thesis. The Ohio State University, 1982. [18] Wayne E. Carlson. Computer and Information Science 783: Geometric modeling. The Ohio State University, 1996. [19] John E. Chadwick, David R. Haumann, and Richard E. Parent. Layered construction for deformable animated characters. In Jeffrey Lane, editor. Computer Graphics (SIGGRAPH 89 Conference Proceedings), volume 23, pages 243-252, July 1989. [20] A.H.J. Christensen, “blocked puzzle,” approximation to a dougnut. In James J. Thomas, editor. Computer Graphics (SIGGRAPH 80 Conference Proceedings), vol ume 16. ACM SIGGRAPH, July 1980. [21] Sharon Rose Clay and Jane Wilhelms. Put: Language-based interactive manipula tion of objects. IEEE Computer Graphics and Applications, 16(2):31—39, March 1996. [22] William Clinger, Jonathan Rees, et al. The revised^ report on the algorithmic lan guage Scheme. USP Pointers, 4(3), 1991. [23] Alison Colman. Deadly mister misty. The Ohio State University, August 1996. [24] Robert L. Cook. Stochastic sampling in computer graphics. ACM Transactions on Graphics, 5(l):51-72, January 1986. [25] Franklin C. Crow. The aliasing problem in computer-generated shaded images. Communications o f the ACM, 20(11):799-805, November 1977. 187 [26] C. Csuri, R. Hackathora, R. Parent, W. Carlson, and M. Howard. Towards an interac tive high visual complexity animation system. In Bary W. Pollack, editor. Computer Graphics (SIGGRAPH 79 Conference Proceedings), volume 13, pages 289-299. ACM SIGGRAPH, August 1979. [27] Charles Csuri. Computer graphics and art. Proceedings of the IEEE, pages 558—570, April 1974. [28] Charles Csuri and Stephen F. May. Playground. http://www.horizonsmedia.com/csuri/Playground.html, October 1995. [29] Charles Csuri, Stephen F. May, Peter G. Carswell, and Lawson Wade. Queenly gestures. ACM SIGGRAPH 97 Conference, August 1997. [30] Tom DeFanti. The digital component of the circle graphics habitat. In AFIPS Con ference Proceedings (National Computer Conference), volume 45, pages 195—203, 1976. [31] Julie Dorsey and Pat Hanrahan. Modeling and rendering of metallic patinas. In Holly Rushmeier, editor, SIGGRAPH 96 Conference Proceedings, Annual Confer ence Series, pages 387—396. ACM SIGGRAPH, Addison Wesley, August 1996. [32] Steven M. Dmcker, Tinsley A. Galyean, and David Zeltzer. CINEMA: A system for procedural camera movements. In David Zeltzer, editor. Computer Graphics ( 1992 Symposium on Interactive 3D Graphics), volume 25, pages 67—70, March 1992. [33] R. Kent Dybvig. The Scheme Programming Language. Prentice Hall, second edition, 1996. [34] David S. Ebert. Advanced geometric modeling. In Jr. Allen Tucker, editor. The Computer Science and Engineering Handbook, chapter 56. CRC Press, 1997. [35] David S. Ebert, F. Kenton Musgrave, Darwyn Peachey, Ken Perlin, and Steven Wor ley. Textiiring and Modeling: A Procedural Approach. Academic Press, October 1994. ISBN 0-12-228760-6. [36] David S. Ebert and Richard E. Parent. Rendering and animation of gaseous phenom ena by combining fast volume and scanline A-buffer techniques. In Forest Baskett, editor. Computer Graphics (SIGGRAPH 90 Conference Proceedings), volume 24, pages 357-366, August 1990. [37] Gerald Farin. Curves and Surfaces fo r Computer Aided Geometric Design: A Prac tical Guide. Academic Press, Inc., San Diego, CA, 1988. [38] David Flanagan. Java in a Nutshell: A Desktop Quick Reference for Java Program mers. O’Reilly & Associates, Inc., 1996. 188 [39] David Flanagan. JavaScript: The Definitive Guide. O’Reilly & Associates, Inc., second edition, 1997. [40] Kurt Fleischer and Andrew Witkin. A modeling testbed. In Proceedings o f Graphics Interface ’88, volume 21, pages 127-137. Canadian Inf. Process. Society, 1988. [41] James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. Computer Graphics, Principles and Practice. Second Edition. Addison Wesley, Reading, Mas sachusetts, 1990. [42] Mark Fontana, Kirk Bowers, and Steve May. Butterflies in the rain. The Ohio State University, 1997. [43] D. Fortin, J. F. Lamy, and Daniel Thalmann. A multiple track animator sys tem for motion synchronization. In Proceedings ACM SIGGRAPH/SIGART Inter disciplinary Workshop: Motion: Representation and Perception, pages 180-186, Toronto, April 1983. [44] Nick Foster and Dimitris Metaxas. Modeling the motion of a hot, tiu’bulent gas. In Turner Whitted, editor, SIGGRAPH 97 Conference Proceedings, Annual Conference Series, pages 181-188. ACM SIGGRAPH, Addison Wesley, August 1997. [45] Alain Fournier and William T. Reeves. A simple model of ocean waves. In David C. Evans and Russell J. Athay, editors. Computer Graphics (SIGGRAPH 86 Proceed ings), volume 20, pages 75-84, August 1986. [46] Curtis F. Gerald and Patrick O. Wheatley. Applied Numerical Analysis. Addison Wesley, Reading, MA, 1985. [47] G. B. Goates, M. L. Griss, and G. J. Herron. PICTUREBALM: A LISP-based graph ies language system with flexible syntax and hierarchical data structure. In James J. Thomas, editor. Computer Graphics (SIGGRAPH 80 Conference Proceedings), vol ume 14, pages 93-99. ACM SIGGRAPH, July 1980. [48] Julian E. Gomez. TWIXT: A 3D animation system. In K. Bo and H. A. Tucker, editors, Eurographics ’84, pages 121—133. North-Holland, 1984. [49] Mark Green and Hanqin Sun. A language and system for procedural modeling and motion. IEEE Computer Graphics and Applications, 8:52-64, November 1988. [50] Robin M. Green. Spherical Astronomy. Cambridge University Press, 1985. [51] L. Gritz and J. K. Hahn. Genetic programming for articulated figure motion. Journal of Visualization and Computer Animation, 6(3): 129-142, July 1995. 189 [52] Larry Gritz and James K. Hahn. BMRT: A global illumination implementation of the RenderMan standard. Journal o f Graphics Tools, 1(3), 1996. [53] R. Hackathom, R. Parent, B. Marshall, and M. Howard. An interactive microcom puter based 3-D animation system. In Proa, of the 7th Canadian Man-Computer Communications Conf, pages 181—191, 1981. [54] Ronald J. Hackathom. Anima H: a 3-D color animation system. In James George, editor. Computer Graphics (SIGGRAPH 77 Conference Proceedings), volume 11, pages 54-64. ACM SIGGRAPH, July 1977. [55] Paul E. Haeberli. ConMan: A visual programming language for interactive graphics. In John Dill, editor. Computer Graphics (SIGGRAPH 88 Conference Proceedings), volume 22, pages 103—111. ACM SIGGRAPH, Addison Wesley, August 1988. [56] Paul E. Haeberli and Kurt Akeley. The accumulation buffer: Hardware support for high-quality rendering. In Forest Baskett, editor. Computer Graphics (SIGGRAPH 90 Conference Proceedings), volume 24, pages 309-318, August 1990. [57] J. K. Hahn, J. Geigel, J. W. Lee, L. Gritz, T. Takala, and S. Mishra. An integrated approach to motion and sound. Journal of Visualization and Computer Animation, 6(2): 109-124, AprU 1995. [58] James K. Hahn. Realistic animation of rigid bodies. In John Dill, editor. Computer Graphics (SIGGRAPH 88 Proceedings), volume 22, pages 299—308, August 1988. [59] Mark Hammel and Przemyslaw Pmsinkiewicz. Visualization of developmental pro cesses by extmsion in space-time. In Wayne A. Davis and Richard Bartels, editors, Graphics Interface '96, pages 246-258. Canadian Information Processing Society, Canadian Human-Computer Communications Society, May 1996. [60] Pat Hanrahan and David Sturman. Interactive animation of parametric models. The Visual Computer, l(4):260-266, December 1985. [61] David R. Haumann and Richard E. Parent. The behavioral test-bed: obtaining com plex behavior from simple rules. The Visual Computer, 4(6):332-347, December 1988. [62] Li-wei He, Michael F. Cohen, and David H. Salesin. The virtual cinematographer: A paradigm for automatic real-time camera control and directing. In Holly Rushmeier, editor, SIGGRAPH 96 Conference Proceedings, Annual Conference Series, pages 217-224. ACM SIGGRAPH, Addison Wesley, August 1996. [63] C. Hewitt and R. Atkinson. Parallelism and synchronization in actor systems. In ACM Symposium on Principles of Programming Languages 4, January 1977. 190 [64] Michael B. Johnson. Wavesworld: A testbed for constructing three-dimensional semi-autonomous animated characters. PhD thesis, Massachusetts Institute of Tech nology, 1995. [65] Ben Jones. An extended Algol-60 for shaded computer graphics. In Toby Berk, editor. Computer Graphics (Proceedings ACM Symposium on Graphic Languages), volume 10, pages 18-23. ACM SIGGRAPH/SIGPLAN, April 1976. [66] K. Kahn. An actor-based computer animation language. In Proceedings of the ACM- SIGGRAPH Workshop on User-Oriented Design o f Computer Graphics Systems, October 1976. [67] Arie Kaufinan, Daniel Cohen, and Roni Yagel. Volume graphics. IEEE Computer, 26(7):51-64, July 1993. [68] Brian W. Kemighan and Dennis M. Ritchie. The C Programming Language. Prentice Hall, second edition, 1988. [69] Muqeem Khan. The platonic problem. The Ohio State University, June 1996. [70] Kinetix, a division of Autodesk, Inc., San Francisco, CA. 3D Studio Max, April 1996. [71] J. U. Korein and N. I. Badler. Techniques for generating the goal-directed animation of articulated structures. IEEE Computer Graphics and Applications, 2(9):71-81, November 1982. [72] John Lasseter. Principles of traditional animation applied to 3D computer anima tion. In Maureen C. Stone, editor. Computer Graphics (SIGGRAPH 87 Conference Proceedings), volume 21, pages 35-44, July 1987. [73] Oliver Laumann. The OOPS Package for Elk Scheme. 1994. [74] Oliver Laumann and Carsten Bormann. Elk: The extension language kit. USENIX Computing Systems, 7(4), 1994. [75] Eli L. Levitan. Handbook of Animation Techniques. Van Nostrand Reinhold Com pany, New York, 1979. [76] Marc Levoy. SIGGRAPH 96 Conference Course Notes: Introduction to Volume Visualization. 1991. [77] Matthew Lewis. Abulafia gallery. The Ohio State University, http://www.cgrg.ohio- state.edu/"mlewis/Gailery/gailery.html, June 1995. [78] Matthew Lewis. Art 894: Procedural animation. The Ohio State University, 1997. 191 [79] Matthew Lewis. Conversations. The Ohio State University, http://www.cgrg.ohio- state.edu/"mlewis/Converse/converse.html, July 1997. [80] N. Magnenat-Thalmann and D. Thalmann. The use of high-level 3-D graphical types in the Mira animation system. IEEE Computer Graphics and Applications, 3:9—16, December 1983. [81] N. Magnenat-Thalmann, D. Thalmann, and M. Fortin. MIRANIM: An extensi ble director-oriented system for the animation of realistic images. IEEE Computer Graphics and Applications, 5(3):61-73, March 1985. [82] Nadia Magnenat-Thalmann and Daniel Thalmann. Computer Animation: Theory and Practice. Springer-Verlag, New York, 1985. [83] Martti Mantyia. An Introduction to Solid Modeling. Computer Science Press, Rockville, MD, 1988. [84] Robert Marshall, Roger Wilson, and Wayne Carlson. Procedure models for gen erating three-dimensional terrain. In James J. Thomas, editor. Computer Graphics (SIGGRAPH 80 Conference Proceedings), volume 14, pages 154—162. ACM SIG GRAPH, July 1980. [85] Stephen F. May. AL: Animation language reference manual. Technical Report OSU-ACCAD-11/94-TR3, ACCAD, The Ohio State University, November 1994. http://www.cgrg.ohio-state.edu/"smay/AL. [86] Stephen F. May. LibDm: A Library for Shared Memory IPC Using C++ Objects. The Ohio State University, August 1995. [87] Stephen F. May, Wayne Carlson, Flip Phillips, and Ferdi Scheepers. AL: A language for procedural modeling and animation. Technical Report OSU-ACCAD-12/96- TR5, ACCAD, The Ohio State University, December 1996. [88] Neal McDonald and Tonya Ramsey. Context. The Ohio State University, August 1995. [89] Jean Meeus. Astronomical Formulae for Calculators. Willmann-Bell, 1988. [90] Gavin Miller and Andrew Pearce. Globular dynamics: A connected particle system for animating viscous fluids. Computers and Graphics, 13(3):305-309, 1989. [91] Michael E. Mortenson. Geometric Modeling. John Wiley and Sons, 1985. [92] Tom Nadas and Alain Fournier. GRAPE: An environment to build display processes. In Maureen C. Stone, editor. Computer Graphics (SIGGRAPH 87 Conference Pro ceedings), volume 21, pages 75-84, July 1987. 192 [93] Jackie Neider, Tom Davis, and Mason Woo. OpenGL Programming Guide: The Official Guide to Learning OpenGL, Release I. Addison Wesley, Reading, Mas sachusetts, 1993. [94] Martin E. Newell. The Utilization of Procedure Models in Digital Image Synthesis. PhD thesis. University of Utah, 1975. [95] William M. Newman. Display procedures. Communications o f the ACM, pages 651-660, October 1971. [96] T. J. O’Donnell and Arthur J. Olson. GRAMPS - A graphics language interpreter for real-time, interactive, three-dimensional picture editing and animation. In Henry Fuchs, editor. Computer Graphics (SIGGRAPH 81 Conference Proceedings), vol ume 15, pages 133-142. ACM SIGGRAPH, August 1981. [97] Open Software Foundation, Cambridge, MA. OSF/Motif Programmer’s Guide, 1990. [98] John K. Ousterhout. Tel and the Tk Toolkit. Addison Wesley, 1994. [99] Alan Paeth, Ferdi Scheepers, and Stephen F. May. A survey of extended graphics libraries. In Alan Paeth, editor, Graphics Gems V. AP Professional, 1995. [100] Richard E. Parent. A system for generating three-dimensional data for computer graphics. PhD thesis, Ohio State University, 1977. [101] Darwyn R. Peachey. Modeling waves and surf. In David C. Evans and Russell J. Athay, editors. Computer Graphics (SIGGRAPH 86 Proceedings), volume 20, pages 65-74, August 1986. [102] Ken Perlin. An image synthesizer. In B. A. Barsky, editor. Computer Graphics (SIGGRAPH 85 Proceedings), volume 19, pages 287—296, July 1985. [103] Ken Perlin and Athomas Goldberg. IMPROV: A system for scripting interactive actors in virtual worlds. In Holly Rushmeier, editor, SIGGRAPH 96 Conference Proceedings, Annual Conference Series, pages 205-216. ACM SIGGRAPH, Addi son Wesley, August 1996. [104] Gregory F. Pfister. A high level language extension for creating and control ling dynamic pictures. In Toby Berk, editor. Computer Graphics (Proceedings ACM Symposium on Graphic Languages), volume 10, pages 1-9. ACM SIG GRAPH/SIGPLAN, AprU 1976. [105] Pixar. PhotoRealistic Renderman. Richmond, CA, 1987-1997. [106] Pixar. Tin toy. By John Lasseter and Eben Ostby and WiUiam Reeves, August 1988. 193 [107] Pixar. The RenderMan Interface, Vferjio/i J./, September 1989. [108] Michael Potmesil and Eric M. Hoffert. FRAMES: Software tools for modeling, rendering and animation of 3D scenes. In Maureen C. Stone, editor. Computer Graphics (SIGGRAPH 87 Conference Proceedings), volume 21, pages 85—93. ACM SIGGRAPH, July 1987. [ 109] Przemyslaw Pmsinkiewicz and Aristid Lindenmayer. The Algorithmic Beauty of Plants. Springer-Verlag, 1990. [110] William T. Reeves. Particle systems - a technique for modeling a class of fuzzy objects. ACM Transactions On Graphics, 2:91-108, April 1983. [111] William T. Reeves, Eben F. Ostby, and Samuel J. LefQer. The Menv modelling and animation environment. Journal of Visualization and Computer Animation, 1(1):33— 40, August 1990. [112] William T. Reeves, David H. Salesin, and Robert L. Cook. Rendering antialiased shadows with depth maps. In Maureen C. Stone, editor. Computer Graphics (SIG GRAPH 87 Conference Proceedings), volume 21, pages 283—291, July 1987. [113] Craig W. Reynolds. Computer animation with scripts and actors. In R. Daniel Bergeron, editor. Computer Graphics (SIGGRAPH 82 Conference Proceedings), volume 16, pages 289-296. ACM SIGGRAPH, July 1982. [114] Craig W. Reynolds. Flocks, herds, and schools: A distributed behavioral model. In Maureen C. Stone, editor. Computer Graphics (SIGGRAPH 87 Conference Pro ceedings), volume 21, pages 25—34. ACM SIGGRAPH, July 1987. [115] Barbara Robertson. Toy story: A triumph of animation. Computer Graphics World, pages 28-38, August 1995. [116] Ferdi Scheepers. Anatomy-Based Surface Generation for Articulated Models of Hu man Figures. PhD thesis. The Ohio State University, June 1996. [117] Ferdi Scheepers, Richard E. Parent, Wayne E. Carlson, and Stephen F. May. Anatomy-based modeling of the human musculature. In Turner Whitted, editor, SIG GRAPH 97 Conference Proceedings, Aimual Conference Series. ACM SIGGRAPH, Addison Wesley, August 1997. [118] Robert Scheifler and James Gettys. The X window system. ACM Transactions On Graphics, 5:79-109, 1986. [119] John F. Schlag. Eliminating the dichotomy between scripting and interaction. In M. Green, editor. Proceedings o f Graphics Interface ’86, pages 202-206, May 1986. 194 [120] Side Effects Software Inc., Toronto, Ontario. Houdinil.O: User Guide, September 1997. [121] David Siegel. Creating Killer Web Sites: The Art o/Third-Generation Site Design. Hayden Books, 1996. [122] Kârl Sims. Artificial evolution for computer graphics. In Thomas W. Sederberg, editor. Computer Graphics (SIGGRAPH 91 Proceedings), volume 25, pages 319— 328, July 1991. [123] Karl Sims. Evolving virtual creatures. In Andrew Glassner, editor, 5/GG/ÎAP//94 Conference Proceedings, pages 15—22. ACM SIGGRAPH, Addison Wesley, July 1994. [124] Alvy Ray Smith. Plants, fractals, and formal languages. In Hank Christiansen, editor. Computer Graphics (SIGGRAPH 84 Conference Proceedings), volume 18, pages 1-10. ACM SIGGRAPH, July 1984. [125] John M. Snyder. Generative Modeling for Computer Graphics and CAD: Symbolic Shape Design Using Interval Analysis. Academic Press, Inc., 1992. [126] Softimage, a subsidiary of Microsoft Corp. Softimage\3D, 1997. [127] Richard Stallman. GNU Emacs Manual. Free Software Foundation, 11th edition, 1994. [128] Jos Stam and Eugene Fiume. Depicting fire and other gaseous phenomena using diffusion processes. In Robert Cook, editor, SIGGRAPH 95 Conference Proceed ings, Annual Conference Series, pages 129—136. ACM SIGGRAPH, Addison Wes ley, August 1995. [129] Garland Stem. Bbop - a program for 3-dimensional animation. laNicograph ’83, pages 403-404. December 1983. [130] Paul S. Strauss and Rikk Carey. An object-oriented 3D graphics toolkit. In Edwin E. Catmull, editor. Computer Graphics (SIGGRAPH 92 Conference Proceedings), vol ume 26, pages 341-349. ACM SIGGRAPH, Addison Wesley, July 1992. [131] Tapio Takala and James Hahn. Sound rendering. In Edwin E. Catmull, editor. Computer Graphics (SIGGRAPH 92 Conference Proceedings), volume 26, pages 211-220, July 1992. [132] Demetri Terzopoulos, John Platt, Alan Barr, and Kurt Fleischer. Elastically de formable models. In Maureen C. Stone, editor. Computer Graphics (SIGGRAPH 87 Proceedings), volume 21, pages 205-214, July 1987. 195 [133] Frank Thomas and Ollie Johnston. Disney Animation: The Illusion of Life. Abbeville Press, New York, fifth edition, 1981. [134] T. Towle and T. DeFanti. GAIN: An interactive program for teaching interactive computer graphies programming. In Richard L. Phillips, editor. Computer Graph ics (SIGGRAPH 78 Conference Proceedings), volume 12, pages 54—59. ACM SIG GRAPH, August 1978. [135] Paul Trachtman. Charles Csuri is an ‘Old Master’ in a new medium. Smithsonian, 25(11):56-65, February 1995. [136] Steve Upstill. The RenderMan Companion: A Programmer’s Guide to Realistic Computer Graphics. Addison Wesley, 1990. [137] Lawson Wade and Richard E. Parent. Automatic generation of control skeletons for animation of polyhedral models. Technical Report OSU-ACCAD-3/98-TRl, ACCAD, The Ohio State University, January 1998. [138] Graham Walters. SIGGRAPH 96 Conference Course Notes: The Making o f Toy Story. 1996. [139] Alan Watt and Mark Watt. Advanced Animation and Rendering Techniques: Theory and Practice. Addison Wesley, 1992. [140] Jerry Weil. The synthesis of cloth objects. In David C. Evans and Russell J. Athay, editors. Computer Graphics (SIGGRAPH 86 Proceedings), volume 20, pages 49-54, August 1986. [141] Josie Wemecke. The Inventor Mentor: Programming Object-Oriented 3D Graphics with Open Inventor, Release 2. Addison Wesley, Reading, Massachusetts, 1994. [142] Terry Winograd. Understanding Natural Language. Academic Press, 1974. [143] David Zeltzer. Task-level graphical simulation: Abstraction, representation, and control. In Norm Badler, Brian Barsky, and David Zeltzer, editors. Making them move: mechanics, control, and animation of articulated figures, chapter 1, pages 3-33. Morgan Kaufmann, 1991. 196 IMAGE EVALUATION TEST TARGET (QA-3) ff m % 1.0 l.l 1.25 1.4 1.6 150mm /A PPL IE D A IM4GE . Inc 1653 East Main Street Rochester. NY 14609 USA Phone: 716/482-0300 ------Fax: 716/288-5989 0 1993, Applied Image, Inc., AU RlgMs Reserved