An experimental computer animation system has been developed which enables the design of three-dimensional animation at an IBM 2250/1130 display and the simultaneous automatic punching of control cards for the generation of movies on a SC-4020. The objects to be animated can be designed at the 1130/2250 display or they can be encoded manually when additional artistic freedom is required. The object description can be checked on the interactive display. An animation language has been written to control movie generating programs run in batch mode on the 360/91. This language consists of object and viewpoint time transformation descriptors. These transformations can be generated at the 1130/2250 as the animator manipulates the objects on display. The interactive display enables translation, rotation, distortion and duplication of objects in wire frame renderings with perspective viewing.
The animator can telecommunicate with a 360/67 to have the hidden lines eliminated on the display. Animation control cards are usually processed overnight to generate a movie which can be viewed the next day.
Now that many investigators [1][2]p3][4] have demonstrated that realistic pictures of three-dimensional objects can be economically computer generated, the major problem of three-dimensional graphics is the refinement of techniques for specifying three-dimensional scenes. Most objects as lists of points in space associated with specific x, y, z coordinates and a list of topological connections between these points. If the program handles wire frame or opaque flat surfaces or solid polyhedra, the vertex points of intersecting lines are stored. For curved surfaces, points on the curves are stored or the equations of the surfaces and limiting regions are stored [5]. For curved surfaces, points on the curves are stored or the equations of the surfaces and limiting regions are stored [6]. The determination of vertex points and surface equations is time consuming. Even for the simple object shown in Figure 1, the manual encoding may take six hours. This is because the building in Figure 1 is meant to represent a proposed building and dimensions must be used that are in scale with the design. Figure 2 is a sketch of a polyhedra that approximates a human head and Figure 3 is a typical SC-4020 presentation of that sketch, and these pictures demonstrate another aspect of modeling that can cause problems - the attainment of a shape that will be pleasing when viewed from any direction. Designing and encoding Figure 2 required about 60 hours even with a considerable amount of computer assistance. Another aspect of three dimensional presentation that is very significant is the specification or relative motion of objects within a scene either to mechanical or mathematical specifications or for artistic effects. Still another problem is the change in shape of a particular object in time.
When the objects in a scene are simple polyhedra or quadric surfaces, the problems of object description, placement, or distortion are trivial [7]. But when the objects in the scene are intended to simulate a specific machine or structure such as a specific airplane or an artistic object such as a Brancusi sculpture, then the problem of object specification is very difficult. This problem has received considerable attention [8][9], but results are tentative, highly specialized or unsatisfying. Almost all attempts at computer art produce works that if not made by machine, we would consider amateurish. And those works which prove pleasing, due to mechanical complexity or grace, usually have a cold, impersonal, even repellent aura. Perhaps this is the desired effect, but this is also a very limited artistic range. In any instance where a static two or three dimensional computer presentation evoked a deep response, for example C. Csuri's famous Sine Wave Man, the artist or designer involved most probably worked long and hard to achieve the effect. Perhaps that is the nature of art and we should never hope to be able to program beauty.
The only computer generated art which we generally enjoy are the automatically generated movies. Even though the specific objects tossed about and distorted are individually not necessarily beautiful, the continuous motion, the precision, the surprise and the wonder are universally experienced. When viewing William. Fetter's simulation of an airplane landing on an aircraft carrier, we can almost feel the three g impact.
Over the past two years, the authors have studied the problems of three-dimensional modeling and while we have had some success in developing techniques for object modeling and placement, we have found our best efforts have been in the specification of three-dimensional animation. Only in the design of an animated sequence have we been able to demonstrate significant results either for artistic or mechanical design purposes. The experimental system that has evolved enables an engineer or artist to compose an animated sequence in a few hours and to see the finished result the next day. Certainly the equipment involved is costly, but nevertheless, the contribution of the computer is significant.
As soon as the design of a three-dimensional animation scene was attempted it became obvious that blind encoding is almost impossible. The quality of SC-4020 three-dimensional movies were initially tested by picture generation from a FORTRAN program where the viewpoint coordinates, the scene transformations and the scaling was controlled by nested DO loops. Such coding for elaborate motions of the eye and scene was recognized as cumbersome so a simple tab card language was developed. A specific sequence elapsed time in seconds is indicated and the sequence change in viewpoint spherical coordinates and scale are specified. The rotation and translation of each object in the scene is also encoded. The program, run in a 360/91, reads in the specified viewpoint and object changes, sets up the scene in the initial position and by linear interpolation over the time span of the sequence, repositions the scene for every frame, updates the viewpoint and changes scale. Each frame is generated on the SC-4020. As soon as an artist tried to use all this animation capability, he became confused. The task of trying to keep track of centers of rotation, the extent of translations, the best viewpoint for observation, proper scaling and also trying to keep the objects from intersecting each other irrationally is impossible. Even the process of writing down all the numbers involved looked like hours of work for even a trivial movie. This is the classic problem of any controlled process: the more control to be exercised over the process, the more difficult it becomes to control the process.
Fortunately, we had recently implemented a very powerful object manipulation system on an 1130/2250 with telecommunication to a 360/67. The object manipulation program enables a designer to read from cards a few simple or complex objects which he then positions, and distorts. He can also duplicate specific objects and change the viewpoint for perspective projection of the scene displayed on the 2250 screen. The scene is displayed in wire frame mode during manipulation and after every specified change the perspective picture is regenerated. After a few major changes, if the designer becomes confused, he can transmit the scene description to the 360/67 via TSS; a hidden line elimination program resident and pre-compiled in the 360/67 will then process the scene description and pass back to the 1130/2250 data to display the scene without hidden lines. The designer usually waits about twenty seconds to see the more realistic presentation.
Because both the movie specification language and the object manipulation system operated on objects in the same way, and had a common data structure and even used the same hidden line elimination programs, it was clear that the two were compatible. A small effort was then undertaken to add two functions to the object manipulation system. One was to have the system keep a record or object changes and successive viewpoint and projection scales. The other was to punch on the 1130 card punch, whenever it was called for by pressing a selected program function key, a sequence viewpoint change card or an object motion card. The act of cards so produced could now be run in the 360/91 to produce the movie.
Five basic separate software packages were used for our work. The display and control system for the 1130/2250 is called GSERV and was especially written to enable FORTRAN interactive display capability with minimum core consumption. This system required about 4000 words of core and enables the response to interrupts from a light pen, the alphanumeric keyboard, the program function keys and a Sylvania capacitance tablet. GSERV enables the display of points, lines or characters. Interrupts, when detected, cause the GSERV assembly language programs to pass to the main FORTRAN program a vector whose components describe the source of the interrupt. For example, if a program, function key is depressed, GSERV will identify not only that a PFK has been depressed but also which one. The elements for picture display may be detectable points or lines, undetectable points or lines, or blank lines. Coordinates may be integer or real scaled to the 2250 raster locations or the elements may be displayed in raster coordinates directly. A character set is also available for display, but this has not been extensively used for three-dimensional work. GSERV keeps track of the picture elements and one level of organization of these elements into entities. Higher levels of organization are maintained by the FORTRAN programs.
The 1130/2250 FORTRAN processing program, called MADEL, was also designed to use a minimum of the available core. One of the key notions of our three-dimensional work is that objects and scenes should be composed by manipulating specific volumes not the lines or points which compose the geometric description or the projected image of the volume. MADEL was written to study the problems of manipulation of a scene description from an interactive console therefore developing the capability of disk storage for additional subroutines and scene or object descriptions was ignored. Indeed it is not yet clear whether it would be best to store object or scene descriptions in a remote 360/67 or on an 1130 disk.
A basic scene description is entered into MADEL by tab cards. These cards are two lists: one is the labeled vertex points in space; the other is a topological map organizing lines into planes, and planes into bounded volumes which are organized into objects. MADEL automatically processes the input list and sorts vertex points into objects and determines which two surfaces can be associated with a line. Rotation, translation and linear distortion are functions only of the geometric coordinates so if only a particular object is to be manipulated, the coordinates of only that object should be processed. The copy function involves a search of the topological map as well as the coordinate list. The automatic sorting of data is therefore very useful and simplifies the original scene description which at present must be done by hand. With MADEL, we have entered the object description of a single cube and by patient manipulation of this cube and many copies we have composed complex structures. As previously mentioned, MADEL was modified to enable an artist working at the 2250 to depress a PFK to punch a card which sums up the current manipulations on the last object specified. The artist can depress another PFK to record the change in perspective viewpoint and scale. Punching a card clears the storage locations for the data recorded on that card so an artist has to be very careful or he can inadvertently lose his results. The artist can request cards faster than the machine can punch so as a check, card images are also printed. The printer usually can keep up with the animation designer so the print out can be trusted. Incorrect cards or missing cards can be determined from a quick correlation.
The telecommunication software is SCAT4 and COM1130. A detailed description of this package is available from W. Sands Hobgood, at the Thomas J. Watson Research Center. SCAT4 enables a FORTRAN program at the 1130 to send and receive data. COM1130 operates in a similar way for the host 360/67. In our application, the artist depresses a PFK to initiate the transmission of the current vertex list and the topological map. During transmission, the display is blank but the scene reappears after the entire model has been transmitted. The artist then manipulates the viewpoint and scale of the scene incrementally with the program function keys, and he can then transmit the current viewpoint and scale at any time. Again, during transmission, the screen is blank and remains blank until data for the picture with the hidden lines removed is received by the 1130/2250 and the picture is displayed.
The FORTRAN hidden line eliminating pgoram, LEGER, is used in the 360/67 and in the 360/91 to generate the frames of the movie. The data structure and perspective projection schemes of MADEL and LEGER are identical. LEGER can be used to generate line drawings or shaded pictures with shadows cast from a remote light source. A detailed description of LEGER has been previously published [5]. LEGER was originally written to control a Calcomp plotter and the graphic potential of this program was made available for movie making on the SC-4020 by the development of Calcomp compatible software (CSS).
CSS acts as an interface between the SC-4020 manufacturer supplied FORTRAN callable subroutines, SCORS, and programs intended to operate with a Calcomp plotter. The operating system resident in the 360/91 allows a user to choose either 16 millimeter, 35 millimeter film output or 7 inch paper tape output on the SC-4020 or 28 inch paper output on the Calcomp plotter. We can also produce shaded pictures on the SC-4020. Such availability of graphic media has proven very helpful for debugging and object design. Details of the SC-4020 and Calcomp support systems have been printed in a special issue of the Research Center Newsletter [10].
It must be mentioned that work of this kind could not be undertaken without large available hardware and software. The authors are indebted to J. F. Jaffe, R. W. Ryniker, W. S. Hobgood, E. B. Horowitz, S. F. Seroussi and J. W. Meyer for their contribution to TSS telecommunications.
We would like to thank Dr. R. Hockney for his work on CSS and for hia deep personal commitment to the cause of computer generated movie making. We also appreciate the continued support and encouragement of L. A. Belady, F. Gracer and R. D. Tennison in this endeavor.
1. Warnock, John E., A Hidden. Line_Algorithm for Halftone Picture Representation, Technical Report 4-5, University of Utah.
2. Watkins, Gary S., A Real-Time Visible Surface Algorithm, Technical Report UTECH-CSc-70-101, University of Utah, June 1970.
3. Appel, Arthur, The Notion of Quantitative Invisibility and the Machine Rendering of Solids, IBM Research Report RC-1775, February 27, 1967.
4. Galimberti, R., and Montanari, V., An Algorithm, for Hidden Line Elimination, Comm. ACM, Vol. 12, 14, April 1969.
5. Appel, Arthur, Modeling in Three-Dimensions, IBM Systems Journal Vol. 7, 3, 4, 1968.
6. Woon, Peter, On the Computer Drawing of Solid Objects Bounded by Quadric Surfaces, Technical Report 403-3, New York Univeristy, 1969.
7. Sutherland, Ivan E., Computer Displays, Scientific American, June 1970, pgs. 58-59.
8. Gellert, George O., Geometric Computing, Machine Design, March 18, 1965 and April 1, 1965.
9. Wehrli, Robert, Smith, Max T., and Smither, Edward F., ARCAID-The Architects Computer Graphics Aid, Technical Report UTEC-CSc-70-102, The University of Utah, Computer Science Department.
10. Computing Center Newsletter, Vol. 3, No. 6, May 4, 1970, IBM T. J. Watson Research Center, Yorktown Heights, New York.