The use of the visual process for the perception and assimilation of ideas is well recognized by educators, psychologists, as well as computer scientists. The popularity of movies and television and the concomitant growth in visual literacy of the viewers of these media are two factors exploited by those who wish to communicate ideas using these media. The world which comes across on the movie or TV screen is the camera's eye view of the visual world (as opposed to our visual field, that which our eyesight and brain perceive of the visual world, or reality, see Gibson [6]); and as such it is an image of reality. This can include images of beautiful scenery, complex human interactions, or of a printed page illustrating a lecture. Any ideas which are communicated by these devices, while relying upon imagery, tend to inform the viewer by creating the illusion that he is there, so how and why would he act, or they inform him by straightforward strings from some generally accepted language (as in the case of a screen full of text). Bruner, a cognitive theorist, feels that information acquisition proceeds through three stages: [5]
As a child develops he progresses through these three stages. Most of the things we learn in school or from books are by symbolic means. Imagery can back up symbolic and enactive paths of learning with varying degrees of success.
Iconic communication itself, using pictures, figures, or visual images in combination with motion in the cases of movies, cartoons, and TV, is not so well understood as an idea transporter. With the fusion of the abstract symbol manipulative, computational power of the computer and the concrete world of visual imagery (in an animated movie in this case) it was hoped to study the problem of idea expression and perception through images. The motivation for producing a computer animated film was simple - it was a course requirement for a graduate seminar led by Prof William Huggins at Johns Hopkins University. Titled Iconic Communications, the intent of the course was to produce a movie, and thereby develop and learn the computer related techniques, as well as develop the potential of iconic modes of communication by research in the related areas of: computer graphic systems and devices and data structures; machine perception, pattern recognition, and syntax of pictures; memory, perception, and cognitive psychology; education, geometry, and visual syntax.
This sort of interdisciplinary study was interesting as well as very fruitful for those of us in technical fields, such as electrical engineering or computer science, who were looking for new applications or who only vaguely understood present applications of advanced computer graphic technology.
The use of computers for the production of animated movies is not new. Several on-line and off-line methods exist with varying degrees of interactive capability. Baecker [3][4] at M.I.T. produced the GENESYS system, making use of the TX-2 computer and graphics system, which permitted the animator/operator to specify on the graphic screen (1) images to be moved about as well as (2) schedules by which they were to be moved. All of this was done on-line and little or no programming was necessary by the animator. The images used were anything that the user could draw, alleviating him from tediously specifying coordinate input. The feedback of results was immediate. One result of taking programming away from the user was that the computer spent its time keeping track of the animator's on-line doodlings instead of offering computational or problem solving power directly toward what to do with these doodlings. The specification of pictures and their driving functions was very good for simple and fast cases but not really suitable for an extended animated effort. Spending a short amount of time to produce a short sequence tended to make the effect of the image short-lived.
Others, including Anderson [1][2] and Knowlton [8][9] spent their time developing elaborate list processing languages and stacking data structures (as in CAMP and BEFLIX). These specialized languages required much understanding on the part of the animator but his facility for taking advantage of the computer's computational power rose correspondingly. The usual technique was to write the program in the specialized movie language, run it on a computer graphics terminal, film it, and then postprocess the film to add color or special effects. Some strikingly beautiful films were produced by Knowlton at Bell Labs and are available on loan from there. Not much attention was paid in these efforts to what images were used or what ideas should be communicated. Visual effects were sufficient to prove the technology.
More recently, at the University of Pennsylvania's Moore School, Talbot, et al.[9], have attempted to fuse the on-line interactive approach to movie specification with the remote computational power of a large computer for the final movie production. They also developed a specialized hierarchical language (with a formal Backus Naur syntax specification) for the animator to specify his pictures, motion, scenes, and movie segments. The on-line activity consisted of drawing on the DEC-338 scope, working in one of the picture definition modes mentioned above, and then reviewing the rough construction of the movie immediately. When the animator was satisfied with his rough draft he entered transmission mode and the outline of the movie was sent to a remote IBM 360/65. There the draft of the movie was translated into the final movie generation commands to drive a SC-4020 microfilm plotter. The main point was to be able to review movie production at any stage as well as to specify everything on-line. Data entry was again a problem, figure manipulation awkward, and no concentration was made on types of images, what their effects and relationships should be and how to get ideas across. The preoccupation with hardware and syntax specification has obfuscated idea communication.
Our animation system at Johns Hopkins possesses all the so-called drawbacks. It is not on-line, no expensive graphics equipment is available, only a second generation IBM 7094 computer. Turn around for the finished movie is slow since no SC-4020 plotter is owned either. Tapes must be sent someplace that has one, delaying things by several weeks. Short term feedback of a coarse nature is available from the computer's line printer, and outputs can be had within an hour or so, typical of a batch operation. The draw package used by animators, entitled MOGUL-Movie Oriented Graphical Utility Language [7] and developed by Prof. Huggins, Tom Hoffman, and Jerry Yochelson, is a FORTRAN based system and requires that the user understand that widely known language. As such, though, the user has at his command all the computational routines he can program. Data input for animator specified images in two or three dimensions is as easy as FORTRAN allows. The time invested in learning how to program and working out movie scenes on graph paper is well invested, however, and may even overcome all the previously mentioned handicaps, or at least show that lack of equipment is not always a handicap. Those of us with programming experience enjoyed the ability to work with an animation system in a familiar language. The preciseness of a computer language (but not the restriction of a special purpose language) and the slight delay in feedback of results made us be more sure of what we wanted to see, and eliminated the draw it and play it right back looseness of on-line systems. We found that for at least 75 percent of the movie's preparation the immediate feedback is not necessary if we had a good idea (through time spent on a storyboard and basic visual techniques) of how the movie should go. Admittedly the final polishing up would have been easier with immediate checks, but costs prohibited this.
Since all of my spare time during the summer is spent on the water, when asked to make a film about an idea, the one which naturally occurred to me was that of a sailboat making its way around a race course, thereby demonstrating basic sailboat aerodynamics. The first step in my animation effort was to lay out a storyboard. This is the sequence of key scenes in the movie along with a brief explanation of what is happening. Briefly the storyboard of the Sailing movie goes like this (see Figures 4-9, also an intermediate version 16mm film of Sailing and several other students' works is available) [12]. An outline of a boat with mast and sail appears, centered on the screen. The boat representation is similar to those found in sailing text and rulebooks, reinforcing its familiarity. The boat then shrinks as a race course appears. The course consists of three flag buoys and wind arrow, pointing from left to right. The boat shrinks to normal size and begins sailing around the course. The boat tacks up the first leg, illustrating the relative position of boat and sail necessary for movement against the wind. The boat reaches down the second leg, jibes, and reaches down the third leg, with the sail farther out moving faster than on the first leg. Midway up the first leg again the boat grows, buoys disappear but wind arrow remains. The next sequence attempts to demonstrate the aerodynamic principles of a sail in terms of force vectors and parallelograms of forces. Three arrows grow out of the center of the sail representing forces acting on the sail. One is parallel to the wind arrow, the sum of forces developed by the wind; the other two are perpendicular and parallel to the surface of the sail, the components. The component perpendicular to the surface of the sail in turn has components parallel and perpendicular to the axis of the boat. The first of these will drive the boat forward while the latter will drive it sideways. With a keel or centerboard the sideways force is largely resisted. The forward driving force acting on the boat then results. Arrows in the forward and sideways directions are drawn. Two, force rectangles are now on the screen. They grow and shrink simultaneously with the wind arrow to illustrate that forces developed are proportional to wind velocity. The various component arrows grow and shrink and change direction as the sail is overtrimmed and overeased, illustrating the optimum position of trim - that point at which the forward driving arrow is longest.
Arrows disappear. Boat shrinks back to normal size and continues on its second lap around the now appearing racecourse. After reaching leg three it slowly shrinks to nothing and heads toward the edge of its world.
One of the goals of the movie experience was to develop some general rules, heuristics, or theories upon which future work could be based. At least we could find out some things not to do. One of the greatest difficulties concerned the use of symbols or images to express ideas. Which are correct, good, or effective, etc? What is the criterion (or grammar) for judging visual images? How does one even make graphic an idea without moving from the iconic to the symbolic level of communication? The medium is hard line black and white to start with. Using any sort of standardized symbols or representations immediately brings on a whole set of preconceptions (or ignorances) and prejudices on the part of the viewer, and if these are not complementary to the idea being shown they can sidetrack the communication process. In the case of the sailboat, I felt that anyone who thought of sailing rulebooks when he saw my sailboat would be thinking of rules and principles, and that was what I was trying to show so it was a useful image.
The use of text or mathematical languages was also discussed. We felt that any reliance upon text should be minimized. Words or letters only detracted from the intent to stay at the iconic level. When used for emphasis, reinforcement, or clarification, however, text has a place. Similarly, mathematical symbols or any other formal symbolic language more often than not gets in the way of the showing, if not also the conceptualizing of visual explanations. Languages are useful here only in the knowledge that they can be called upon sometimes to write down the process being shown. The literacy of the audience with respect to the language being shown (or not shown) must also be considered.
One thing that had to be well worked out in advance and which was a continual cause of surprise after finally viewing the movie was the layout of images or occupancy of the screen. Given a full, two dimensional square or three by four rectangle for a screen we were acutely aware of empty spaces. The full screen has to be used for motion and action for full spatial effect, but by no means should it be filled with clutter. One of the main advantages of the medium is that it is completely bare bones, stripped of all extraneous detail, and this should be used to best advantage by retaining a simplicity of imagery bordering on paucity. The center of the screen is the key spot for any important activity or attention getting. Split screen or simultaneous occurrences divide attention and effectiveness.
Abstractions and relationships are difficult to portray. The choice of images, their size, relative position, order of appearance and movement all can suggest functions, relationships, and dependencies. There is the difficulty of avoiding coincidental though erroneous suggestions of relations versus the valid suggestions of intended relations. Does the fact that one object precedes another on the screen or that it is larger than another indicate that it is more important? If one event happens before another does it imply cause and effect or time sequence? Questions like this have to be considered for individual cases to be sure that the animator's intentions are being realized. Importance is often indicated by size, positioning at the center, illumination (blinking), and motion. The relationship of cause and effect was never satisfactorily protrayed. In one film the anthropomorphic symbol of a detached hand had to be introduced to cause a switch to be thrown.
The obvious capability of a movie for showing motion cannot be too strongly stressed. Without background sensory cues, however, some sort of frame of reference has to be established to inform the viewer of his or an object's motion. A world of lines, edges, and boundaries is being dealt with, not one of textures and surfaces. Motion of objects within the screen boundaries can mean all sorts of things. The capability of the computer to calculate regular paths also adds to the possibilities. If two objects move simultaneously, or in some synchronized fashion, or with the same pattern an obvious relationship suggestion is being put forward. One problem engendered by the capability of (and the expectation of) motion in the movie is that of bringing images on and off the screen. Should they just appear, pop on, or should they grow or should they come on from the left (or right)? For the illustration of static concepts this is more of a worry than for cases where motion on and off the screen can seem natural.
Timing is the other major tool the animator has to work with, but it is also the most difficult to handle properly. Difficulties in the proper use of the screen area can be resolved using the line printer output, but timing problems never are fully resolved until the completed movie is seen. This is one instance where a preliminary viewing of the movie on a graphics terminal would be useful so that timing could be improved without making a whole other movie. Slowing down the action is one way to illustrate importance, up to the point where things become painfully obvious. Speeding up activity moves the viewer over less important or intermediate material. Judging what fast and slow are is difficult, though, and we really had to see a boring thing happening for an interminable time to understand what too slow was. One rule of thumb we started with to judge how long a sequence should take was to equate the timing with how long a verbal explanation would take. Motion of an object relative to stationary objects or at a faster speed than other objects is one way to command attention. Repetition of action, even with slight variations, is important for facilitation understanding of difficult material. The redundancy of presentation should increase with the complexity of the visual material. It is in the production of repetitive sequences of highly redundant though complex material that the computer comes into its own. Hand animation requires each intermediate frame of a cartoon to be drawn while a computer can painlessly calculate endless numbers of slightly varying scenes. Pauses in activity are very useful as punctuation, giving the viewer time to digest what he has just seen rather than overwhelming him with too much action in too short a time. Fades, holds in action, and jumps to new scenes also serve useful punctuation purposes, each with different effects.
The sequence of steps we followed to produce animated movies is illustrated in Figure 1. The basic tools the animator has are his skills as a FORTRAN programmer, the ability to draw points and lines between them furnished by the MOGUL system, the computer, and the final film medium. The MOGUL system was developed mostly out of our experience in Dr. Huggins' seminar and contains those elements of programming which were always needed for film production, hopefully freeing the animator to deal with image entities and motions rather than coordinate details. It is a structured set of functions built of the compiler level FORTRAN programming language. Those interested in the complete system should refer to Tom Hoffman's paper[7]. Only the salient features of it will be presented.
MOGUL actually consists of three sections. The first and largest is the set of drawing functions, the DRAW package, which enables the animator to create images, manipulate them, and set up operation codes to be interpreted when the images are to be drawn. The second section is the executive portion, MOGI, which keeps track of frame numbers and screen dimensions.
The user defines the dimensions of the two dimensional real plane in which he is going to draw things, e.g., a square grid of 1024 points running from 0.0 to 1023.0 in both x and y directions; then MOGI windows any coordinates outside of this area. When output on some sort of device is called for, MOGI normalizes coordinates and then calls on some device driving program. MOGI also administers the mode of movie generation, debugging or production. The third section, the Device Driver section of MOGUL contains the device dependent output code to translate from the normalized coordinates of MOGI and command a printer, microfilm plotter, or scope to produce visual images. The animator's program is actually a subroutine called MOVIE which is called from MAIND, the first program entered. MAIND initializes the system, calls MOVIE, then finalizes the system and returns to the IBSYS Monitor. The user must return himself (via a RETURN statement) to MAIND to terminate his job properly.
The screen is a partition of the two dimensional real plane with the limits of the partition defined by user specified parameters. The routine is:
CALL SETAX (ZLL, ZUR)
or
CALL SETAX (XLL, YLL, XUR, YUR)
where (XLL, YLL) and (XUR, YUR) are the coordinates of the lower left and upper right corners of the window enclosing the usable screen area. The screen can also be considered a complex plane with points whose coordinates are given by a real (x) part and a complex (y) part. Thus ZLL represents the lower left and ZUR the upper right points just mentioned, and
ZLL =CMPLX(XLL, YLL)
ZUR =CMPLX(XUR, YUR)
Any object which appears on the plane is a collection of x and y coordinate points with lines drawn between them. An object is then a 2×N real array or block, with the first row being the x coordinates and the second row being the y coordinates, or a 1×N complex array with the real part equal to the x coordinate and the complex part equal to the y coordinate of a point. Blocks have associated with them names, e.g., Boat, Sail, etc., somewhat indicative of what the coordinate points represent. This name of the block contains a pointer to the location of directory information describing the block. The value of the real FORTRAN variable Block is the index of the array XYC where the directory information for Block resides. Included in the directory is the length of the block; its index (a pointer to the location of the block's coordinates in the array XYC); the opcode which specifies whether no lines, disconnected lines, or connected lines should be drawn between points, or where characters should go; the width of lines; and the intensity of plotting. Everything on the screen is specified by a block, facilitating the use of general manipulation routines which always operate on blocks. Only by the opcode of a block is the interpretation of its contents determined.
Storage is considered to be a one dimensional contiguous complex array, and all blocks and descriptors are stored in this array. The array has three equivalent names: XYC, XYP, and IP, depending on whether one likes to work with complex numbers, real numbers, or integers, respectively, as coordinates. In the lower end of XYC go the block contents. In the upper end go the block descriptors. Creations, length adjustments, and deletions of blocks are administered using the index variables of XYC. XYC is declared in a COMMON statement, making it available to any subroutine of the animator.
Figure 2 shows the contents of the directory for a block. Figure 3 depicts the allocation of storage for block information.
Storage for blocks is allocated and all housekeeping of pointers is taken care of by the following functions:
CALL CREATE (N, BLK)
or
BLK=CREATE (N, BLK)
makes space for a block of size N and sets BLK equal to the pointer to the block directory. The value equals the returned pointer.
BLK=SETUP (N, TYPE)
creates a block big enough to contain N things of type TYPE, where TYPE can be connected lines (N-1 points needed), disconnected lines (2N points), or characters. Other directory information is set and the value of the function equals the pointer to the block.
CALL COPY (FROM, TO)
or
TO=COPY (FROM, O)
copies the block FROM into the block TO, adjusting the length of TO if necessary. Directory information is copied also.
Blocks are erased and their space returned to free storage by:
CALL DELETE (BLK1, BLK2, ... , BLKn)
As can be seen block functions can be effected either by subroutine calls or by function calls which return a value. There are cases in writing a movie program where both are useful, though consistency in calls is to be preferred to avoid errors. Primitive functions are available to set or return the value of block directory information if this is necessary.
Objects to be drawn can be specified in two ways. Either the animator plots his drawing on graph paper and then enters the point coordinates, or he specifies some function to calculate the points. The Sailing movie uses both methods. For example the boat and sail were entered as points from a drawing on graph paper, while the mast and buoy were calculated from an equation for the points on a circle. Thus, blocks must be prepared to receive data in several ways. Data can be loaded point by point into a block with the following sequence:
CALL BUILD (BLK)
initializes the function COORD to begin placing data into BLK beginning at the first column of BLK.
CALL COORD (Z)
or
CALL COORD (X, Y)
places the complex coordinate Z or the real coordinates X, Y into the next column of BLK.
A whole array of coordinates can be loaded into a block using:
CALL LOAD (I, N, XY, BLK)
or
BLK =LOAD (I, N, XY, BLK)
loads N coordinates from the complex array XY into BLK beginning at the I column. The second usage returns the pointer to BLK as its value.
Once objects to be displayed have been created and assigned to blocks, the animator must decide what to do with them. Scaling and translation are the two main manipulations he may perform, and these are done by applying arithmetic operations to blocks (which in fact contain complex, real, or integer numbers, depending upon interpretation). Complex variables and complex arithmetic permit handling of two dimensional data with one statement. Scaling is done by a series of complex multiplications of block points by a complex scale factor. Translation is done by adding a complex translation factor to every block point.
CALL SCALE (SFACT, FROM, TO)
or
TO =SCALE (SFACT, FROM, O)
scales the block FROM by the complex scale factor SFACT and places the results in TO
CALL TRANS (TFACT, FROM, TO)
or
TO =TRANS (TFACT, FROM, O)
translates the block FROM by the complex translation actor TFACT and places the results in TO
CALL SCLTRN (SFACT, TFACT, FROM, TO)
or
TO=SCLTRN (SFACT, TFACT, FROM, O)
scales and translates
With the use of a scale factor defined as follows:
SFACT =CMPLX(FACTR, 0.0)
*CMPLX(COS(ANGLE), SIN(ANGLE))
=MAG (FACTR)ROTD(ANGLE)
an object will be FACTR times larger and rotated by ANGLE degrees from its former position. MAG and ROTD are defined as above in MOGUL. Neither scaling and translating operations change the data in the block FROM. Scaling of an object occurs about the origin about which the object was defined. If the origin is the origin of the screen coordinates rotations and magnifications will be with respect to this point. A more useful convention is to define all objects with an origin within them so regular rotation and scaling will result. Translation occurs with respect to the object's previous position.
Objects are drawn using the following routines:
CALL DRAW (BLK1, BLK2, ... , BLKn)
causes the output of the n blocks to the Device Driver program where they are drawn according to their directory information.
CALL DRAWST(SF1, TF1, BLK1, SF2, TF2, BLK2, ..., SFn, TFn, BLKn)
causes the scaling by SFi, translation by TFi, and drawing of a copy of BLKi. The copy is then deleted leaving BLKi intact. Argument list is one or more triplets.
To roll the film between frames, one logically calls:
CALL ROLL
advances film 1 frame.
or
CALL ROLL (NFRMS)
advances film NFRMS frames.
Working from his storyboard, the animator knows what objects he wants to display when. Once he has entered or calculated the point coordinates of an object in his program he must specify the dynamics of the object. The usual method for doing this in FORTRAN based MOGUL is with DO loops, where the scale and translation factors change incrementally with the iterations in the loop. This is fine if only one object is being displayed or if all the objects are scaled and translated with the same factors. When different sized objects or different motions are required there must be nested loops or different factors for each. A movie is then a series of DO loops where each loop describes some sequence of frames and contains the following basic elements:
DO 10 I=1, NFRMS
SFACT (I)= ...
TFACT (I)= ...
...
CALL DRAWST (SFACT(I), TFACT(I), BLOCK)
CALL ROLL
10 CONTINUE
The computer is doing the job of interpolating and specifying all the intermediate frames here, where in conventional animation each frame has to be specified individually. Even commercial animation studios are getting away from this frame by frame drudgery, though, by using over and over certain stock positions, motions, and expressions for characters. The result is somewhat crude and jerky animation. One should really see the old Walt Disney full length animations to appreciate the Rolls Royce versus the Chevrolet approach to animation which is apparent now. Of course no one can pay 750 artists fifty cents an hour anymore either.
DO loops progress at a linear rate and all motions are not necessarily linear. Variable increments in translation factors must then be calculated. Another difficulty arises in the drawing of an object composed of various smaller objects. Other than by nesting subroutine calls or drawing each component separately in its assembled position, the big object cannot be drawn all at once as one large block. There is no hierarchy for nesting blocks composed of other blocks. In the Sailing movie the boat consisted of a hull, a mast, and a sail all of which had to move and rotate as an entity. A subroutine was defined which in turn called all these component blocks and then drew them with the specified parameters.
All of the objects which appear in the film are defined as prototypes. Some I drew myself, such as the boat, arrows, and basic sail. Others, such as the wind modified sail and the mast (a circle) result from calculations. The prototype blocks all have an origin within them. For manipulations either the implicit scaled and translated copy produced in DRAWST or an explicit scaled and translated copy of the prototypes is used to retain the original models.
The final movie which I produced for the seminar was really only an intermediate version, since the MOGUL system was not complete then. However, it illustrates all the points I wished to make, and only a few bugs and the inconvenience of not having all the DRAW functions sets it apart from the latest version. After watching it and watching others' reactions to it I am satisfied that it is getting some of the ideas across I wanted. The film did reveal to me that I must have had an audience in mind which had some sailing knowledge. Many more of the little points were picked up by these people than by those with no sailing background. The latter saw an interesting little boat move about the screen, but without any sympathy for the problems of sailing they missed the basic points of tacking into the wind and correct sail trimming. The strongest point of the film (and possibly, the medium) is its absolute attention getting capability as well as the elimination of all extraneous background material.
There are limitations to this method of communication. Computer animation has many of the strengths of a computer directed system but the artist as animator is farther removed from his final product. Though he is spared the necessity of drawing many slightly varying drawings and though he can calculate, modify, and display phenomena not observable or feasible in the natural world, he cannot express the artistic technique or capability that would be evident if he were holding the pen. Rather than an artist, an artist-programmer-psychologist-computer scientist is required. The attempts mentioned earlier to provide online animation facilities to those uninitiated in the ways of computers only debilitates the capabilities of both parties. Advantage should be taken of the requirement that the animator have some technical knowledge of the system as well as some awareness of the problems involved in iconic communications. Perhaps a simple enough language or computer will be developed some day which will enable an animator to think out and then immediately create his cartoon sequence. At the moment I think this is not true, nor is it necessarily a bad thing either. The preciseness of computers actually aids in formalizing the images to be used in a communications process.
The results for iconic communications I think are just beginning. The visual medium is good, but it takes too long to get thoughts displayed just right. Other than generalized heuristics there is no formal syntax or set of models which can help a potential image communicator. Measurement of the effectiveness of idea transmission, validity of images used, relationships portrayed, all these subjects still pose many questions. Thoughts have been entertained to match up the computer with a TV screen and dump digital information in a video format onto black and white or color monitors. Technically feasible (and marketed) the concept may lower the cost and time involved in producing animations, as well as bring the manifestation of computer generated images closer to home.
1. S E ANDERSON, A list processing system for effectively storing computer animated pictures, Technical Report TR-67-6 Electrical Engineering Department Syracuse University Syracuse NY 1967.
2. S E ANDERSON, D D WEINER A computer animation movie language for educational motion pictures, Proc AFIPS 1968 FJCC Vol 33 P2 AFIPS Press Montvale NJ pp 1317-1320.
3. R M BAECKER, Interactive computer-mediated animation, PhD Diss Dept of Electrical Engineering MIT Cambridge Mass March 1969.
4. R M BAECKER, Picture driven animation, Proc AFIPS 1969 SJCC Vol 34 AFIPS Press Montvale NJ pp 273-288.
5. J S BRUNER, Toward a theory of instruction, Harvard Univ Press Cambridge Mass 1967.
6. J J GIBSON, The perception of the visual world, Riverside Press Cambridge Mass 1950.
7. T V HOFFMAN, MOGUL: Movie Oriented Graphical Utility Language Manual for Iconic Communications, Seminar Dept of Elec Eng The Johns Hopkins University Baltimore Md Sept 1971.
8. K C KNOWLTON, A computer technique for producing animated movies, Proc AFIPS 1964 SJCC Vol 25 Spartan Books NY pp 67-87.
9. K C KNOWLTON, Computer produced movies, Science 150 Nov 1965 pp 1116-1120.
10. P A TALBOT, J W CARR, R R COULTER, R C HWANG, Animator: An on-line two-dimensional film animation system, Comm ACM 14 4 April 1971 pp 251-259.
11. S M ZWANG, D KASIK, I SMITH, Sailing, make-break switch, and station break, 16mm black and white silent film available from author or Iconic Communications Seminar Dept of Elec Eng The Johns Hopkins Univ Baltimore Md.
1. W H HUGGINS, D R ENTWISLE Computer animation for the academic community, Proc AFIPS 1969 SJCC Vol 34 AFIPS Press Montvale NJ pp 623-627.
2. W H HUGGINS, D R ENTWISLE Exploratory studies of films for electrical engineering, Report to US Office of Education Sept 1968 Dept of Elec Eng The Johns Hopkins University Baltimore Md.
3. W H HUGGINS. Film animation by computer, Mechanical Engineering Feb 1967 p 26.