SAN FRANCISCO JULY 22-26 Volume 19, Number 3, 1985 An Image Synthesizer Ken Perlin Courant Institute of Mathematical Sciences New York University Abstract We introduce the concept of a Pixel Stream Editor. This forms the basis for an interactive synthesizer for designing highly realistic Computer Generated Imagery. The designer works in an interactive Very High Level programming environment which provides a very fast concept/implement/view iteration cycle. Naturalistic visual complexity is built up by composition of non- linear functions, as opposed to the more conventional texture mapping or growth model algorithms. Powerful primitives are included for creating controlled stochastic effects. We introduce the concept of "solid texture" to the field of CGI. We have used this system to create very convincing representations of clouds, fire, water, stars, marble, wood, rock, soap films and crystal. The algorithms created with this paradigm are generally extremely fast, highly realistic, and asynchronously parailelizable at the pixel level. CR CATEGORIES AND SUBJECT DESCRIPTORS: 1.3.5 [Computer Graphics]: Three-Dimensional Graphics and Realism ADDITIONAL KEYWORDS AND PHRASES: pixel stream editor, interactive, algorithm development, functional composition, space function, stochastic modelling, solid texture, fire, waves, turbulence Intreduetion This work arose out of some experiments into developing efficient namraiistlc looking textures. Several years ago we developed a simple way of creating well behaved stochastic functions. We found that combinations of such functions yielded a remarkably rich set of visual textures. We soon found it oambersome to continually rewrite, re.compile, and rerun programs in order to try out different function combinations. This motivated the development of a Pixel Stream Editing language (PSE). Cook [1] has proposed an expression parser for this purpose. We have taken the same idea somewhat farther by providing an entire high level programming language available at the pixel level. Unlike [1], The PSE contains, general flow of control structures, allowing arbitrarily asynchronous operations at different pixels. With the PSE we may interactively compose functions defined over modelling space. By starting with the right choice of Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copyiag is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. © 1985 ACM 0-89791-166-0/85/007/0287 $00.75 primitive functions we can build up some rather convincing naturalistic detail with surprisingly simple and efficient algorithms. We will first describe the PSE language and environment. Then we will introduce the concept of solid texture, together with our well behaved stochastic functions. Finally we will give some examples of how these concepts work together in actual practice. A Plxel Stream Editing Language Consider any list of variable names. We will call any list of corresponding values for these variables a "pixer'. For example, one possible pixel for the variable list [red green blue] is [0.5 0.3 0.7]. We will call any list of names together with a two dimensional array of pixels an "image". A Pixel Stream Editor (PSE) is simply a filter which converts input images to output images by running the same program at every pixel. We always read and write image pixels in some canonical order. At any one pixel, all that the program "knows" about each image are its variable names and their current values. The PSE we have designed has a rather high level language. All of the familiar programming constructs are supported, including conditional and looping control structures, function procedure definitions, and a full compliment of arithmetic and logical operators and mathematical functions. Assignment and the equality operator are denoted by "=" and "ffi •", respectively, as in the C programming language [2]. For any infix operator op, a op = b denotes a = a op b. Variables may be scalars, or else vectors of scalars and/or vectors (recursively). Typing is implicit, determined by assignment. Program blocks are indicated by indenting. All operators will work on scalars or vectors. For example a+b is a scalar sum if a and b are scalars, and a vector sum if a and b are vectors. The following simple example will illustrate. Suppose the input image contains the variable list [surface point normal], where surface is a surface identifier, point is the location in space of the surface visible at this pixel, and normal is the surface normal direction at point. This image in particular would generally be the output of some visible surface finding algorithm. Let the output image consist of [color]. If we interpret color as a [red green blue] vector, then the procedure : if surface = = 1 color = [1 00] * max(O.l, dot(normal, [1 0 01)) else color = [0 0 0.1] will produce an image of a diffusely shaded red object lit from the positive x direction against a dark blue background. The function "'dot()" is simply a built in function returning the dot product of two v~tors. 287S I G G R A P H '85 Spotted Donut Bumpy Donut Stucco Donut Disgusting Donut Bozo's Dollut Wrinkled Donut 288SAN FRANCISCO JULY 22-26 Volume 19, Number 3, 1985 Note that in the above example, "[1 0 0]" is used in one place to denote the color red, and in another to denote a direction in space. Such looseness and ambiguity was a deliberate design decision in creating the language. In using the system we obtained some of the most striking visual effects only by stepping over (real or imagined) semantic distinctions. We find that the PSE is most useful as a design tool when used as interactively as possible. For this reason we have placed it in an interactive design cycle : 1.Edit PSE program 2. Run it on a low resolution