Animator is a computer animation system which was designed to overcome some of the inherent didadvantages associated with conventional computer animation techniques. The DEC-338 serves as an input terminal for movie making, allowing the trial and error design of picture sequences in a conversational mode. During all stages of the movie specification, a record of the user's actions on the system input elements (lightpen, pushbuttons, and teletype) is maintained. At the user's request, this record is sent to the IBM 360/75 where the S-D 4020 instructions necessary to produce the same sequence of pictures can be generated. It is anticipated that one of the primary contributions of Animator will be the provision of a facility which will allow any professor to produce his own expository film strips.
Research for this paper was supported by the National Science Foundation grant GY-3262.
Although there are certain inherent advantages to current computer animation techniques [1], there are still significant weaknesses which restrict their everyday application This paper reports on a computer animation system that eliminates two of the most serious deficiencies (1) by providing feedback from the system to the human animator and (2) by removing many of the conventional programming language constraints.
In most conventional computer animation systems, the movie maker is faced with a critical lack of feedback during the process of movie specification. The reason for this lack of feedback is that the movie definition must always be translated into an intermediate or final form before any information can be procured as to exactly what has been prescribed. As a result, significant delays can easily be introduced between the time of movie specification and the time when feedback information can be obtained, Not only do these delays slow down the process of film generation, but they decrease the effectiveness of the programmer.
Often the movie maker is not fortunate enough to have complete computer animation facilities (usually a digital computer and a microfilm recorder) available to him. Typically, the microfilm recorder that he must use is located at a site different from that of the digital computer. Where this is true, the movie making process can be slowed down considerably. The magnetic tape containing the machine instructions for the microfilm recorder is generated on location but then must be sent away for processing to the site of the film recorder. Since debugging runs are usually necessary before satisfactory results are achieved, this process has to be repeated several times for each scene, and long delays develop.
To overcome this problem, many installations which do not have a microfilm recorder provide programs which allow the movie maker to produce graphic output on a mechanical plotter or line printer using the same commands which produce microfilm output [1]. Debugging runs are always made using the programs which can produce graphical output on location and, as a result, only the production runs need be sent away for processing.
However, disregarding the unavailability of complete computer animation facilities, other time delays can occur. In many systems, the programs for movie specification are batch processed, and turnaround time can introduce feedback delays which can range from several hours to several days. Even systems which are implemented on time-shared computers and which operate in a conversational mode still must go through the intermediate step of producing magnetic tapes that must then be remounted and processed on a film recorder. It is true that in at least one system the user can choose to have his images directly displayed on a CRT [2]. However, this is not the mode of operation for movie production, as the user is not able to get this feedback and still produce instructions for a microfilm recorder.
What is desired is a system which allows the movie maker to view the results of his work at any time during the process of movie construction.
Another disadvantage is that the movie maker has always been restricted to the use of a one-dimensional, formalized programming language, either as a subset of the FORTRAN programming language or a language specialized in nature such as BEFLIX [3, 4]. As a result, someone unfamiliar with computer programming, or at least some form of formal reasoning, has to go through a period of indoctrination before he can successfully generate movies by means of computer. For although the recent movie specification languages tend to be very specialized, the user must still conform to sometimes undesirable programming constraints. For example, a professional animator would be forced to describe his figures in terms of sets of coordinates, which is an approach quite different from the one to which he is accustomed, that of sketching his figures on a piece of paper.
It would be advantageous to allow the user to construct his pictures in a way analogous to those procedures normally employed by an animator or artist and to completely eliminate the necessity of any familiarity with computers or computer programming techniques.
One means of solving these problems is to develop an on-line, interactive computer animation system capable of sustaining a pictorial display, which could be used in the generation of a broad class of animated films. Using an input device such as a lightpen in conjunction with pushbuttons, toggle switches, teletype, etc., the movie maker could now construct or draw his figures on the face of a CRT. Moreover, now the user could have continuous graphical interaction with the display and could create and modify his images in a trial and error fashion with immediate feedback. One previous system partially fulfilling these requirements, the GENESYS system, has already been developed at the MIT Lincoln Laboratory [5, 6].
We will describe in this paper the Animator system, another computerized film animation system currently being developed at the University of Pennsylvania, which provides a solution to these problems quite different from that offered by GENESYS, in an attempt to further the development of a natural and versatile method for computer animation. It should also be pointed out that the work presented here represents one of the first attempts to catalogue and study methods of motion picture descriptions from both a conceptual and an implementation point of view.
The hardware configuration on which Animator is implemented consists of a DEC-338 with a Type DF32 Disk File, an ASR 33 Teletype, a Type TC01 DECtape Control, and one Type TU55 Dectape Transport interfaced with an IBM 360/75, as shown in Figure 1. This interfacing between the two computers is accomplished through a leased full duplex phone line terminating in Western Electric 201B Data Sets. The data sets are interfaced to the DEC-338 through the DEC DP01A Interface and to the IBM 360/75 through the IBM 2701 Data Adapter Unit. Because no microfilm recorder is available at the University of Pennsylvania, the magnetic tapes that are produced are sent to the Polytechnic Institute of Brooklyn for processing on their Stromberg Datagraphix 4020.
The DEC-338 serves as the input terminal for movie making, allowing the trial and error design of picture sequences in a conversational mode. During all stages of the movie specification, a record of the user's actions on the system input elements, e.g. the lightpen, pushbuttons, and teletype, is maintained so that it can be sent to the IBM 360/75 where the S-D 4020 instructions necessary to produce the same sequence of pictures can be generated.
The actual implementation of Animator consists of three programs. One of these programs permits the use of the DEC-338 as an input terminal for movie specification and is the only program in the system with which the user interacts. Another program transmits the record of the user's actions on the system input elements from the 338 to the IBM 360. A third program, implemented entirely on the 360, takes this record, and using the SCORS package [7], produces the specialized S-D 4020 instructions necessary to generate the movie that the user has prescribed.
The role of the 338 program is (1) to monitor the user's actions on the input elements associated with the 338, (2) to display the user's definitions on the 338 scope, sometimes automatically and sometimes upon request, and finally (3) to maintain a record of the user's input queue. For this latter purpose, a language has been developed, known as the transmission language, into which all of the user's actions are translated immediately upon being recognized by the system. The file of the user's actions is thus compiled in the transmission language and is referred to as the transmission file. The function of the 360 program is then to translate the transmission file into S-D 4020 instructions.
In many cases, the programs implemented on the 338 and the 360 are called upon to perform similar computations. For example, both must have routines which, given a center and a radius, will generate the machine code necessary to display a circle; in one case, the code produced is for the DEC-338 and, in the other, the code produced is for the S-D 4020. Because the DEC-338 is a much smaller and a much less powerful computer than the IBM 360/75, and because the images displayed on the screen of the 338 are used only to give the user feedback of the picture sequences he is defining, the DC-338 routines tend to be less sophisticated and precise than those of the 360 and often yield only approximations to the images that are produced by the S-D 4020. Even though circles are approximated on both the 338 and the 360 by regular polygons, those generated for display on the 338 generally have fewer sides. In addition, scenes are sometimes recreated on the 338 in less than real time (at a rate of less than 24 frames per second).
A motion picture in the Animator system is composed of four classes of constituents: pictures, motions, scenes, and movie segments. The user specifies his movie by constructing appropriate definitions of these elements.
A picture is a relocatable, static, graphical representation which can be composed both of elements from a set of picture primitives which the system provides for the user and of previously defined pictures.
It has been suggested to the authors that the choice of the word picture was an unfortunate one, as it could tend to confuse or mislead the reader, and that a more appropriate choice would have been object or figure.
At any time during the process of movie specification, new pictures may be defined and additions and/or changes made to any already existing picture definitions. During the entire process of picture definition or redefinition, the user gets immediate feedback on the 338 screen of the structures which he is defining.
A motion is an operator which can be applied to any picture and can be defined in terms of a set of motion primitives provided by the system and/or previously defined motions. A motion may be defined as either a parallel or a sequential motion. A parallel motion is one in which more than one motion primitive or defined motion is applied to a picture at a given moment of time. For example, a parallel motion defined in terms of rotate and translate, when applied to a picture, would cause the picture to simultaneously spin and move across the screen. A sequential motion is one which prescribes not only actions but the duration of actions which are to be applied to a picture. A sequential motion describes the motion primitives or defined motions that are to be applied in a sequential fashion to the picture. A sequential motion defined in terms of rotate and translate, when applied to a picture, would cause the picture to spin for a certain number of frames and then move across the screen for a certain number of frames. At any time during the process of movie specification, new motions may be defined and changes made to already existing motion definitions. Feedback of the defined motion to the user can be obtained by observing the motion operating on a standard figure. A scene represents a portion of a movie and consists of one or more pictures and the motions to be associated with them in the given scene. A scene is composed of at least one picture-motion pair and/or at least one previously defined scene. Generally speaking, a scene contains all pictures and actions that are to occur concurrently in the movie during a defined time interval. The user can request that a certain scene be recreated on the screen of the 338 at any time after that scene has been defined and, in this manner, obtain feedback from the semantics of his definition.
A movie segment is composed of at least one scene and/or one previously defined movie segment and describes how the scenes, which the user has defined, are to be put together in sequential order to form a move segment. As with a scene, the user can command that a movie segment be displayed on the 338 screen. Figure 2 illustrates how pictures, motions, scenes, and movie segments are combined to create a movie.
The order in which the movie maker constructs his definitions is restricted only by the requirement that any constituent used in a definition must have been previously defined. Once the user has built up definitions of the picture sequences he desires, he can specify which scenes and/or segments he wishes to produce. At this point, he can request that the record of his finalized input queue be sent to the IBM 360 for production.
The user of Animator operates in six different modes of movie specification: (1) the picture definition mode, (2) the motion definition mode, (3) the scene definition mode, (4) the movie segment definition mode, (5) the production mode, and (6) the transmission mode (see Figure 3). When the system is started, or at any other time of the user's choosing, the main cycle of the program is entered. In this routine, the user is presented with a set of light buttons with which he can select the mode of specification in which he desires to operate. The user can reenter the main cycle to change from one specification mode to another.
Picture definition mode. The picture definition mode is used for the construction of static graphical objects. A picture is a relocatable closed figure whose absolute position on the screen is bound only at the time of its use in a scene definition. A picture definition consists of a name associated with a sequence of picture primitives and/or previously defined pictures. Recursive picture definitions are not allowed.
The syntax of picture definitions can be described formally in Backus Naur form in the following manner:
<picture> ::= <name> <picture description>
<picture description> ::= <picture primitive> | <picture> | <picture description> <picture description>
<picture primitive> ::= CLEAR SCREEN | FIX INTENSIFIED HORIZONTAL OR VERTICAL LINE |
FIX UNINTENSIFIED HORIZONTAL OR VERTICAL LINE | FIX INTENSIFIED LINE |
FIX UNINTENSIFIED LINE | DRAW FOLLOWER LINE | CIRCLE | ENTER COORDINATES | TEXT |
ERASE LINE | ERASE LINES | REMOVE SUBPICTURE | POINT | SPECIFY LENGTH | DUPLICATE LENGTH
<name> ::= <character>6 | <character>5 | <character>4 |
<character>3 | <character>2 | <character>
<character> ::= A|B|C|D|E|F|G|H||J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|y|Z|
0|1|2|3|4|5|6|7|8|9|.|'|/|+|-|*|(|)
The semantics of the picture primitives are explained briefly in Table I.
| Primitive | Semantics |
|---|---|
| CLEAR SCREEN | completely erase the current picture definition |
| FIX INTENSIFIED HORIZONTAL OR VERTICAL LINE | establish an intensified horizontal or vertical line whose length and orientation are determined by the current rubber band vector |
| FIX UNINTENSIFIED HORIZONTAL OR VERTICAL LINE | establish an unintensified horizontal or vertical line whose length and orientation are determined by the current rubber band vector |
| FIX INTENSIFIED LINE | establish an intensified line determined by the current rubber band vector |
| FIX UNINTENSIFIED LINE | establish an unintensified line determined by the current rubber band vector |
| DRAW FOLLOWER LINE | approximate the path of the tracking square with short line segments |
| CIRCLE | add a circle with specified center and radius |
| ENTER COORDINATES | add lines and/or points specified by coordinates entered through the teletype |
| TEXT | add text at specified location (3 size options available) |
| ERASE LINE | erase line drawn at the current level of definition |
| ERASE LINES | erase group of lines which have been consecutively drawn at the current level of definition |
| REMOVE SUBPICTURE | remove an occurrence of a subpicture, circle, or text character |
| POINT | establish a point at the center of the tracking square |
| SPECIFY LENGTH | establish an intensified line of a specified length whose orientation is determined by the current rubber band vector |
| DUPLICATE LENGTH | establish an intensified line of the same length as another line in the definition with an orientation determined by the current rubber band vector |
Motion definition mode. The motion definition mode is used for the construction of the action operators which are applied to pictures. To allow the movie maker the maximum flexibility in constructing more complex motions, motion definitions can be built up in both a parallel and a sequential fashion. In other words, the user can specify that operators be applied either simultaneously or sequentially to an object. The number of frames during which an operator is applied to a picture is bound only at the time of the operator's use in a sequential motion definition. Operators used in parallel motion definitions do not have any prescribed time durations.
A parallel motion definition consists of a name associated with a sequence of motion primitives and/or previously defined parallel motions. A sequential motion definition consists of a name associated with a sequence of motion primitives and/or previously defined parallel motions each associated with a frame count, and/or previously defined sequential motions. Recursive motion definitions are not permitted.
Because parallel motions do not have associated durations, only sequential motions can actually be applied to a picture in a scene definition. Parallel motions, however, can be used in the definitions of other parallel and sequential motions. Since all sequential motions do have associated durations, they cannot be used in the definitions of parallel motions.
The syntax of motion definitions can be described formally in Backus Naur Form in the following manner:
<parallel motion> ::= <name> <parallel motion description> | <motion primitive>
<sequential motion> ::= <name> <sequential motion description>
<parallel motion description> ::= <motion primitive> | <parallel motion> |
<parallel motion description> <parallel motion description>
<sequential motion description> ::= <parallel motion> <frame count> | <sequential motion> |
<sequential motion description> <sequential motion description>
<motion primitive> ::= ERASE DEFINITION | HOLD | TRANSLATE | ROTATE ABSOLUTE |
ROTATE RELATIVE | ZOOM ABSOLUTE | ZOOM RELATIVE | FILL | BLINK
<frame count> ::= a decimal number between 1 and 2000
<(name> ::= <character>6 | <character>5 | <character>4 |
<character>3 | <character>2 | <character>
<character> ::= A|B|C|D|E|F|G|H||J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|y|Z|
0|1|2|3|4|5|6|7|8|9|.|'|/|+|-|*|(|)
The semantics of the motion primitives are presented in Table II.
| Primitive | Semantics |
|---|---|
| ERASE DEFINITION | completely erase the current motion defnition |
| HOLD | identity operator |
| TRANSLATE | move in a linear path prescribed relative to the initial position of the object |
| ROTATE ABSOLUTE | rotate about an absolute point |
| ROTATE RELATIVE | rotate about a point specified relative to the defined center of the object |
| ZOOM ABSOLUTE | scale about an absolute point |
| ZOOM RELATIVE | scale about a point specified relative to the defined center of the object |
| FILL | move in a linear path prescribed relative to the initial position of the object filling in the area through which it passes |
| BLINK | blink at a specified rate |
Scene definition mode. The scene definition mode is used to specify the pictures which occur concurrently during a portion of a movie, the absolute starting positions of these pictures, and the sequential motions to be associated with each. The duration of a scene is governed by the frame count associated with the shortest sequential motion used in the scene definition. A scene definition consists of a name associated with a sequence of basic scene descriptions and/or existing scene definitions. A basic scene description is itself a sequence consisting of a pair of coordinates, a picture and a sequential motion (called a picture-motion pair). Recursive scene definitions are not allowed.
The syntax of scene definitions can be described as follows:
<scene> ::= <name> <scene description>
<scene description> ::= <basic scene description> | <scene> |
| <scene description> <scene description>
<basic scene description> ::= <X> <Y> <picture> <sequential motion>
<X> ::= a decimal number between 0 and 1023
<Y> ::= <X>
<name> ::= <character>6 | <character>5 | <character>4 |
<character>3 | <character>2 | <character>
<character> ::= A|B|C|D|E|F|G|H||J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|y|Z|
0|1|2|3|4|5|6|7|8|9|.|'|/|+|-|*|(|)
Movie segment definition mode. The movie segment definition mode is used to describe a movie or portion of a movie by specifying the temporal relationships among the scenes which the user has defined. A movie segment definition consists of a name associated with a sequence of scenes and/or existing movie segment definitions. Recursive movie segment definitions are not permitted.
The following is a formal description of the syntax of movie segment definitions:
<movie segment> ::= <name> <movie segment description>
<movie segment description> ::= <scene> | <movie segment> |
<movie segment description> <movie segment description>
<name> ::= <character>6 | <character>5 | <character>4 |
<character>3 | <character>2 | <character>
<character> ::= A|B|C|D|E|F|G|H||J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|y|Z|
0|1|2|3|4|5|6|7|8|9|.|'|/|+|-|*|(|)
Production mode. The production mode is used to specify the names of the scenes and/or movie segments that the user desires to have produced by the 360.
Transmission mode. The transmission mode is used to transmit the user's relevant actions on the system input elements (those actions pertaining to the scenes and/or movie segments which the user has requested to be produced) to the IBM 360/75. Although the Animator system was designed primarily for the production of 16 and 35 mm film or hardcopy output on the S-D 4020, for debugging purposes, the user can also produce CalComp 565 plots or obtain simulated graphic output on the line printer.
To illustrate the use of Animator, the following man-machine dialogue is presented which traces the production of the very simple picture sequence shown in Figure 4. For a more detailed description of the specification procedure for the same sequence, the reader is referred to Reference [8].
ROCK1 = TRANSLATE with ΔX/frame = 88 and ΔY/frame = 0 and ROTATE RELATIVE with ΔX = 0 and ΔY = 0 and Δθ/frame = -25°.
ROCK2 = TRANSLATE with ΔX/frame = 128 and ΔY/frame = -64 and ROTATE RELATIVE with ΔX = 0 and ΔY = 0 and Δθ/frame = 50°.
ROCK3 = TRANSLATE with ΔX/frame = 128 and ΔY/frame = 64 and ROTATE RELATIVE with ΔX = 0 and ΔY = 0 and Δθ/frame = -50°.
STILL = HOLD with frame count = 6.
ROCK23 = ROCK2 with frame count = 1 followed by ROCK3 with frame count = 1.
ROCK = ROCK1 with frame count 1 followed by ROCK23 followed by ROCK23 followed by ROCK2 with frame count = 1.
Implications for Computer Graphics. Animator is basically an interactive computer graphics system and as such provides the usual system software requirements: data base, telecommunication routines, man-machine interfacing routines, etc. The division of labor or task sharing is one aspect of interactive computer graphics systems which is handled particularly well by Animator. Although the 338 plays the role of the satellite computer in the system organization, it very nearly functions as a stand alone computer. The 338 handles not only the task of movie specification but also the task of movie monitoring. The 360/75 is utilized only when the user requests production, thus minimizing the overhead on the central computer.
Implications for Computer Animation. Animator was motivated by an attempt to overcome the disadvantages associated with current computer animation techniques. The authors believe this attempt has met with much success. Animator permits the interleaving of movie definition and monitoring, allowing the movie maker to view the results of his work at any time during the process of movie construction. Moreover, the user of Animator is no longer restricted to a conventional onedimensional programming language. Thus even an amateur, with neither the skills of the computer programmer nor the skills of the professional animator, could produce a film using this system.
The one apparent weakness of Animator is its limited applications. The primitives provided by the system allow the description of only two-dimensional data and are by no means universal in scope (additional primitives will be proposed). However, it is believed that this system can easily produce many two-dimensional animated cartoons and educational films. It is anticipated that one principal use of this system will be to allow a professor or teacher to produce a film strip in a relatively short period of time (perhaps an hour or two) to illustrate a concept which he desires to present to his class.
As a result of the experience that has been gained in the study and use of on-line, interactive computer animation systems, there are some desirable additions to Animator that are recommended at this time which would markedly extend the power of this system.
| Primitive (picture) | Semantics |
|---|---|
| GRAPH | add a graph of an analytic expression at a specified location |
| Primitive (motion) | Semantics |
| BLANK | eliminate a picture from a scene for a specified time interval |
| DRAW | incrementally draw a picture on the screen in a specified time interval |
| COMPUTE PATH | move in a path determined by a mathematical equation prescribed by the user |
| SKETCH PATH | move in a path sketched by the user (the user could specify the amount of time that a picture is to take in traversing the designated path by entering a frame count, or alternatively, perhaps the user could specify and even vary the speed of the picture by sketching the path in real time) |
The authors believe that it would be easily possible to implement the above additions to Animator on the hardware that is available at the University of Pennsylvania, and, in the case of (3), such work is now underway.
However, there are two more major problems that the design of the Animator system completely overlooks. The first of these is the extension of the current two-dimensional system to its three-dimensional counterpart. Such a modification would most likely double the necessary storage capacity of the system, and additional processing steps would be required to reduce the threedimensional data to a two-dimensional form suitable for display on the DEC-338. Moreover, a natural way to input three-dimensional data would have to be found.
The second problem which was not included in the design of the Animator system is the mechanization of an interpolation procedure. Interpolation is a technique usually employed in conventional animation in which the principal animator actually draws only certain key frames of a film, while assistant animators later fill in the intermediate frames using the critical frames as guidelines. It would be highly desirable to be able to use computers to introduce the interpolation procedure through computation. Miura, Iwata, and Tsuda suggest the use of hybrid curve generation techniques as an approach to this problem [9].
Animator is an on-line, interactive film animation system which possesses the following features:
Although Animator overcomes some of the disadvantages associated with conventional computer animation techniques, it is not a universal system. It is a two-dimensional system intended primarily for the production of certain types of cartoons and expository films. In particular, it is envisioned that one important use of this system will be the provision of classroom visual aids.
1. Weiner, D, D., and Anderson, S. E. A computer animation movie language for educational motion pictures. Proc. AFIPS 1968 FJCC Vol. 33, Pt 2
2. Nolan, J., and Yarbrough, L. An on-line computer drawing and animation system. Proc. IFIP 1968
3. Knowlton, K. C. A computer technique for producing animated movies. SJCC Vol. 25, 1964
4. Knowlton, K. C. Computer-produced movies. Science 150 (Nov. 1965)
5. Baecker, R. M. Picture driven animation. Proc. AFIPS 1969 SJCC Vol. 34
6. Baecker, R. M. Interactive computer-mediated animation. Ph.D. Diss., Dep. of Electrical Engineering, MIT (Mar. 1969).
7. Programmers' Reference Manual, S-C 4020 Computer Recorder.
8. Talbot, P. A. Animator - system for using the DEC -338 as an input terminal for movie making. Master's Thesis, Moore School of Electrical Engineering, U. of Pennsylvania, Aug. 1969.
9. Miura, T., Iwata, J., and Tsuda, J. An application of hybrid curve generation cartoon animation by electronic computers. 1967 SJCC, Vol. 30
10. Deily, D. New principles for producing computer animated motion pictures. Ph.D. Diss., Moore School of Electrical Engineering, U. of Pennsylvania, Dec. 1968.
11. Cotton, I W, Greatrex Jnr, F S, Data Structures and techniques for remote computer graphics. FJCC 1968