Animated cartoon design with a CRT

Marya Goldman Repko

Land Use and Built Form Studies, School of Architecture, Cambridge

1972

Computer Journal, Vol 15, No 4

The background section of this paper reviews some of the activity of other workers in this field. In the succeeding sections of the paper the author's approach to computerised cartoon animation design is discussed and a program developed by the author is described from a user viewpoint. Detail is given of the internal organisation of the program.

Background

Reports of efforts to produce animated films with computers date from as long ago as 1964 (Knowlton, 1964). The attendance at the recent symposium at the Atlas Computer Laboratory in Chilton, Berkshire, on computer animation demonstrates that interest in this technique is prevalent among a wide spectrum of professionals: educationalists, animators of films for entertainment, scientists, and computer graphics programmers. The papers and discussions at the symposium showed that progress towards practical computer-aided animation has not advanced considerably since its inception.

Most activity has been in filming mathematical functions for teaching mathematics or science. The best known example of this is the Bell Telephone Laboratories film Space, Time and Motion, demonstrating the inverse power law over two moving bodies. More recently, in England, the Open University has been sponsoring the development of films for helping to teach the concepts of interpolation and the Nuffield Foundation Science Teaching Project has been involved with computer produced films for demonstrating statistical mechanics at atomic level.

In the area of less specialised graphics, only a few of the many plotting packages have been designed for the film animator. One of these is CAMP (Computer Animated Motion Pictures), with its three-dimensional partner CAMPER (Hopgood and Ralphs, 1971). The program uses fixed-format data on cards to draw pictures, perform transformations on them, and output them. There is no hidden line suppression in CAMPER. Instructions for drawing geometrical shapes as well as electrical symbols are provided. One unique feature is the clock, or meter, drawing facility.

In the UK at the Atlas Computer Laboratory in Chilton, GROATS (Graphic Output Package for Atlas using The SC 4020) (Hopgood, 1969) has been written for the Atlas 1 and a Stromberg-Carlson microfilm recorder. The package is an extension of ALGOL and provides procedures for drawing curves and alphanumeric characters, for transforming them, for windowing or blanking-out parts of a frame, for shading, and for preparing a magnetic tape for input to the SC 4020. A film available from the Atlas Laboratory demonstrates that the package is quite powerful.

Although these systems have useful graphics capabilities, they are not conducive to the free designing techniques that the artist is accustomed to with pencil and paper. Graphic data is meaningless to human eyes in digital form. A sneak preview of a film showing some development work at IBM in New York indicates that a system using a 360 computer with a 2250 graphical CRT display and Rand-type tablet is being designed for drawing and animating pictures. ACIANS (Artist Computer Interactive Animation System) allows the user to draw pictures, store them, call them up, define movements and combine foreground and background pictures.

An interactive system using a PDP/15 with graphic CRT display and tablet is being developed at the Atlas Computer Laboratory. It is intended that sequences of animation can be previewed and edited before being filmed on the SC 4020 ind will be a useful extension of the work already done there in animation.

Anderson (1971) has adapted CAMP and CAMPER for interactive use on a CRT. Using a function keyboard, the user can step through frames of animation. The editing procedure involves changing the card images that define the pictures. A digitiser off-line relieves the tedium of coding the original cards.

Introducing 'the little man'

The work reported in the remainder of this paper was done when the author was employed by the Land Use and Built Forms Study Group (LUBFS) in the School of Architecture at the University of Cambridge. Some of the author's colleagues wished to make a film demonstrating the operation of an interactive time-table scheduling system on a CRT display aid mentioned that they could not afford the cartoons that would enhance their film into a memorable occasion for its viewers.

Necessity being the mother of invention, a special purpose program was written to make a stick figure (affectionately known as the little man among friends) walk and sit on the CRT screen. The choice of his several limited actions was controlled in real-time by manipulating the switches on the computer control panel. He was immortalised on the header and trailer of a film made by LUBFS.

The little man was programmed explicitly. A display file defining his parts was coded and routines to change the vectors in the display file were written. He appeared to walk because the angles and lengths of the vectors defining his legs were changed dynamically in the display file by a routine. Figure 1 illustrates the following explanation. In Fig. l(b) his leg is bent from the hip and his knee is raised causing his foot to come off the floor. In Fig. l(c) he extends his lower leg and in Fig. l(d) his front leg is swung behind to simulate his back leg and at the same time his whole body is moved as his origin is changed. Finally, in Fig. 1(e), his back leg is returned to standing position.

General approach

Experience in programming the little man showed that a general purpose drawing and animating system was needed for future generations. The concept that evolved was that a picture is drawn and edited, series of motions are defined for elements of the picture, and the series of motions are performed in some order and filmed. The system should not be hierarchical because humans, unlike computers, do not think strictly logically, especially when being creative. Thus, it is imperative for effective interactive designing that the user have the ability to try out animations at any time and to be able to revert to another phase of the system in order to change the picture or the definitions of the motions or the sequence of series of motions at any time in the design process.

A prime requirement of the system was that input and output be easy. All graphical data should be described by the hand and the eye rather than in digits. All timing parameters should be determined by the computer from signals in real-time. Textual data and commands should be minimal, although for meaningful retrieval of pictures and series of motions these items must be named. Finally, after animations are designed there should be a method to output them for re-input.

Implementation

These requirements were achieved with some exceptions in a program called CARTOON DESIGN. It was implemented at the University Computing Laboratory, Cambridge, on a PDP/7 with a model 340 graphical CRT display with light pen and joystick. The computer has 8K of 18 bit words with paper tape input and output. There was no backing store. A cine camera was interfaced to the computer as a peripheral during the development of CARTOON DESIGN.

CARTOON DESIGN is organised in three modes:

1. Draw pictures.
2. Define operations.
3. Script.

Each mode contains commands which have control over different sections of the computer store: picture file, operations file, and script file, respectively. The picture file contains vectors and subroutine calls and is constructed with the picture drawing commands. The operations file contains series of actions, or operations. An action operates on a part of the picture file. The operation definition commands build up the operations file. The script file contains a list of the operation names and is built-up with the script commands. The relationship between the files can be seen in Fig. 2.

The space for each file is allocated dynamically in store as the user builds up the file with the appropriate commands. Pointers linking the script to the operations and the actions to parts of the picture are independent of the files. Thus, in the fixed amount of core in the PDP/7 the user can control the relative size of each file. For example, a complicated picture would leave room for less operations and script than a simple one.

Drawing pictures

The picture file is made up of pictures. Each picture is assigned a name and an origin. A picture contains elements which are its origin points, vectors, and subroutine calls. Each element can be identified with the light pen and edited during the drawing process. The elements are the items which are operated upon by actions in the second phase of the program.

The user draws on the display screen by moving a joystick which moves a small spot of light on the screen in the corresponding direction. After naming a picture, which assigns the position of the spot as the origin, he can add elements to the; picture file in several ways (the commands are summarised in the Appendix). One command causes a visible line to follow the path of the spot. Each straight line section that is drawn will be an element in the picture. Other commands connect the previous position of the spot to its present position with a visible or invisible straight line. Another command puts a subroutine at the position of the spot by adding a subroutine call to the picture file.

Two types of subroutines are available. A library of subroutines consists of upper and lower case letters, numbers andg punctuation marks. The user calls the subroutine by typing the appropriate commands and the desired character on the on-line teletype. Shift case is indicated by typing a non-printingg character.

User defined subroutines are built-up like pictures except that there is no permanent origin. The user names the subroutine, draws elements in it, and types a command to end it. A subroutine can have other subroutine calls in it including library subroutines but cannot call itself. The elements in a user-defined subroutine can be edited as if they were main picture elements. The user defines the subroutine the first time he wants to call it. For subsequent calls he uses a command with the subroutine name. The definition of the subroutine can beg embedded within another subroutine or picture but still beg called independently.

To edit a picture the spot is moved onto a previously drawng element with the light pen and that element is erased or other; elements are added after it.

Defining operations

After a picture has been built-up in the picture file, the user can define actions to be performed on elements in the file. One or more actions form sub-operations which are saved in the operations file.

There are two types of commands available in this mode: those which add actions to the operations file and those which perform the actions in the file or move the spot. These are summarised in the Appendix

The first command the user must use is that which names an operation. By typing the command and a name the user creates the beginning of a new operation in the file. If the name has already been used for an operation that operation is made available to him for editing or performing. The named operation is referred to as the current operation.

To define an action the user moves the spot to an element in the current picture with the light pen or with the two commands that step the spot forward or backward through the picture. To change the length and direction of a vector element he moves the spot to a position on the screen that will be the new end-point of the vector and types the appropriate command. The vector immediately changes dimensions on the display and the action is added to the operations file. Alternatively, the user can define an action to add a new visible or invisible vector element to the picture file at that place rather than change an existing vector. In this case, each time the action is performed another vector element is added to the picture file.

Similarly, a subroutine call in the picture file can be replaced with another subroutine call by pointing to the subroutine with the spot and typing the desired subroutine name and the command. The subroutine call will replace the old one in the picture file and the action will be added to the operation file and performed on the screen. The subroutine must have been defined previously by the user in the drawing mode or be in the library. An action to add a subroutine call after any element referenced by the spot can be defined by typing the subroutine name and a command. In this case, a call to the subroutine is added to the picture each time the action is performed.

The absolute co-ordinates of the origin of a picture can be changed by moving the spot to the new origin and typing a command. The action which is added to the operations file will move the origin an amount equal to the difference between the old and new origin at the time of the definition of the action.

An action can be defined to make a whole picture visible or invisible. The name identifies the picture in the command.

Actions are performed so fast on the display that they are indiscernible to the human eye. Thus, provision has been made for a pause to be inserted after an action so the eye can take in the new form of the picture before the next action is performed. Several actions operating on different elements can appear to be performed simultaneously if there is a pause after the last one. For example, the little man moves his leg and origin in the same step in Fig. l(d).

A sub-operation is one or more actions terminated by a pause. The sub-operation is defined by typing the pause command after the last action in the sub-operation is defined. An empty sub-operation contains only a pause. A sub-operation is the smallest unit of an operation that can be edited or performed selectively. A command is available to erase the current sub-operation.

The length of a pause is determined by the setting of the switches on the computer panel. The user can flip the switches to specify pauses in multiples of 1/16th second.

When a sub-operation is performed an interpretive routine@ reads that part of the operation file and decodes the actions An action is represented in the file by several words (see Fig. 3). The first word contains an instruction code and the address of a pointer to the picture file. The following worgs contain the arguments of the instruction, such as increments for vectors or references to subroutine names.

There are several commands in this mode which allow the user to initiate the interpretive routine so he can see the operations he has defined be performed. One of these commands causes all of the current operation to be performed. Another allows only one sub-operation in the current operation to be performed. After a single sub-operation is performed a pointer is incremented so the user can step through the operation performing one sub-operation at a time with this command. He can add other sub-operations after any sub-operation in th~ current operation or erase a sub-operation.

Script

The script is an ordered list of sets of operation names and numbers. The numbers specify the repetitions to be performed of each operation. A routine which is callable through a command in this mode drives the interpretive routine to perform the operations in the script.

Other commands allow the user to build up and edit the script, to input and output the script, and to control the performance of the script (see the Appendix).

The script is built-up as the user types a command followed by an operation name and a decimal number specifying how many times the operation is to be performed. If the number is empty the operation will be repeated until the user flips a switch on the computer panel. This switch is independent of the timing switches for inter-sub-operation pauses, which also can be manipulated during the performance of the script. As an operation is added to the script, it is performed on the screen.

The script can be punched on paper tape. If the command has set the formfeed flag before the punch command, a formfeed will be punched at the end of the script. The formfeed signals the end of the script to the input routine.

The script can be read from paper tape in two ways. The read command causes the script to be built-up in the store by reading it from paper tape. The reader stops when it encounters a formfeed or 6.3 in of runout code. Alternatively, the script can be read in and performed simultaneously.

The script is performed if the user types the demand performance command. He can look at the script already in the store or he can set a flag to co-ordinate reading from paper tape and performing. If the flying read flag has been set a buffer full of script is read and performed continuously until a formfeed is encountered on the tape. In this way a very long script can be performed without the user having to save a large section of store, and it can be constructed, tested and punched out in short sections.

A flag to activate the cine camera during a performance can be set with a command. When the film is projected at 16 frames per second, it will have the same timing as the script does when viewed with the naked eye on the screen. The camera shutter and film drive can be controlled by the computer. To avoid flicker due to the refresh rate of the cathode ray in the tube each frame of the film is exposed individually by the program.

Comments and conclusions

The program and alphanumeric subroutines occupy a little less than half the PDP store. Several improvements have been suggested which can be added without enlarging the program too greatly. The method of drawing with a joystick has been found to be awkward, but it will be possible to connect the UML tablet to the input. (The UML tablet lets the user draw with a pen on a grid of wires and passes the co-ordinates of the pen to the computer every time it hits an intersection of two wires.) With this addition, the user can trace pictures already drawn on paper. Another input device that could replace the joystick is a tracker ball.

The internal method of drawing on the display is to string vectors together. This means that if a vector is changed all the vectors following it will be moved too. It would be wiser to rewrite the program to use vectors connected to fixed points throughout the picture instead of having only one fixed point at the origin. In this way, control could be exercised over the freedom of vectors to affect those following them. Such a revision of the structure of the program should not cause the commands to be changed.

It must be emphasised that this program, although usable, is very crude and that only fairly simple cartoons can be designed. Stick-figures and geometric objects are easily handled but complicated pictures are very difficult to draw and move about. However, as a pilot project, CARTOON DESIGN does demonstrate the feasibility ofusing interactive design techniques for producing animated cartoons on a computer and display.

Acknowledgements

I should like to thank Mr. Crispin Gray of the LUBFS group for encouraging me to start this project and for his help during its development. I am also grateful to those members of both LUBFS and the Computer Laboratory at Cambridge, who acted as guinea pigs for the program and made useful suggestions. In particular, I should like to thank Dr. Neil Wiseman for allowing me to use the alphanumeric subroutines he designed for the Scope Text Editor.

Appendix

(name) ::=

Three alphanumeric characters terminated by a carriage return.

Mode 1 - Drawing pictures

/name>

Begin to define a picture and name it. The origin of the picture is at the current position of the spot.

V

Draw a straight line from the last fixed position of the spot to its present position.

I

Draw an invisible line, as above.

J

Begin drawing a continuous visible line following the path of the spot. Type any character but J to stop.

(<name>

Begin to define a subroutine and name it. All subsequent vectors or subroutines will be included in the subroutine until it is closed.

)

Close the subroutme currently open.

*</name>

Insert the subroutine named at the lase fixed position of the spot.

@

Begin or end a string of alphanumerie characters which will be represented on the display. Inserts the supplied subroutines after the last fixed position of the spot.

rubout

Erase the vector or subroutine pointed to by the spot.

Mode 2 - Defining Operations

>

Move the spot to the next element in the current picture.

<

Move the spot to the previous element in the current picture.

linefeed

Perform the current operation from beginning to end.

.

Perform the next sub-operation in the current operation.

.<name>

Begin to define an operation and name it. If the name has been used before for another operation, the program goes to the beginning of that operation so the user can amend it.

,

End a sub-operation.

?

Erase the current sub-operation from the operation.

←

Make the picture named visible on the display.

##<name>

Make the picture named invisible on the display.

M

Redraw the vector pointed to by the spot so that it goes from its beginning to the new position of the spot.

V

Insert a visible vector after the element pointed to. The vector is a straight line between the present position of the spot and its previous position.

I

Insert an invisible vector, as above.

S<name>

Replace the subroutine pointed to with the alphanumeric library subroutine indicated.

@<alohanumeric character>

Replace the subroutine pointed to with the alphanumeric library subroutine indicated.

*<name>

Insert the subroutine named after the element pointed to with the spot.

O

Move the origin of the picture by adding the difference between the position of the origin and the current position of the spot.

Mode 3 - Listing the script and filming

!</name><number>

Add to the script the operation named and the number of times it is to be performed, where the number is a decimal not greater than 256. If no number comes between the operation name and the comma, the operation will be repeated during a performance of the script until the leftmost accumulator switch on the computer panel is flicked up. The switch will override the number after an operation any time it is in the up position. Unsets all flags.

?

Erase the last entry in the script. Unsets all flags.

P

Punch out the script in the computer on paper tape. A formfeed will be punched instead of end runout if the formfeed flag has been set. Beginning runout will always be punched. The script is not altered in the computer. Unsets all flags when finished.

R

Read in a script from paper tape until a formfeed or 6.3 in. of end run out is encountered. Unsets all flags when finished.

F

Set the flag for a flying read.

formfeed

Set the flag to punch a formfeed when the P command is used.

C

Set the flag for the cine camera.

linefeed

Perform the script in the store. If the flying read flag is set, the script will be read in from paper tape and performed until a formfeed is encountered on the tape. If the cine camera flag is set, the camera will take pictures. One, both or neither of the flags can be set. All flags are unset when the performance is finished.

References

ANDERSON, S E (1971). Generating Computer Animated Movies from a Graphic Console, Advanced Computer Graphics, eds. Parslow and Elliot Green, Plenum Press.

HOPGOOD, F R A (1969). GROATS, A Graphic Output package for Atlas using the SC 4020, Atlas Computer Laboratory.

HOPGOOD, F R A, and RALPHS, D (1971). CAMP and CAMPER on Atlas, Atlas Computer Laboratory.

KNOWLTON, K C (1964). A Computer Technique for Producing Animated Movies, SJCC.

BERENYI, I, and BUSBY, H (1971). Animation by Computer, Computer Aided Design, Winter, pp. 55-59.

FEESER, L J, and CUTRELL, J D (1971). Perspective Views and Computer Animation in Highway Engineering, Advanced Computer Graphics, eds. Parslow and Elliot Green, Plenum Press.

MEZEI, L (1969). SPARTA, A Procedure Oriented Programming Language for the Manipulation of Arbitrary Line Drawings, IFIP68, North-Holland.

NOLAN, J, and YARBROUGH, L (1969). An On-Line Computer Drawing and Animation System, , IFIP68, North-Holland.

NOLL, A M (1965). Computer Generated Three-Dimensional Movies, Computers and Automation, November.

PHILLIPS, R L (1971). Production of Computer Animated Films from a Remote Storage Tube Terminal, Advanced Computer Graphics , eds. Parslow and Elliot Green, Plenum Press.

TALBOT, P A, CARR, J W, COULTER, RR, and HWANG, R C. (1971). Animator: An On-Line Two-Dimensional Film Animation System, CACM, Vol. 14, pp. 251-258.