Chapter 6 Computer-Based Animation
To animate something is, literally, to bring it to life. An animation covers all changes that have a visual effect. Visual effects can be very different attributes: positions (motion dynamics), form, color, transparency, structure, and texture of an object (update dynamics), as well as changes in lighting, camera position, orientation, and focus.
This chapter covers primarily computer-based animation, since this type of animation constitutes a “medium” of integrated multimedia systems. Today, computer-based animations are produced, edited, and generated with the help of a computer using graphical tools to create visual effects. Naturally, the discipline of traditional, noncomputer-based animation continues to exist. Interestingly, many steps of conventional animation appear to be ideally suited for support by computer.
6.1 Basic Concepts
6.1.1 Input Process
Before the computer can be used, drawings must be digitized to create key frames, where the entities being animated are at extreme or characteristic positions. These digitized images can be produced by the computer using appropriate programs or created by digitizing photos (pictures of real objects) or drawings. The drawings may need to be carefully post-processed (e.g., filtering) in order to clean up any glitches arising from the input process.
6.1.2 Composition Stage
Individual frames in a completed animation are generated by using image composition techniques to combine foreground and background elements [FDFH92]. By placing low-resolution digitized frames of an animation in a grid, a trailer film (pencil test) can be generated using the pan-zoom feature available in some frame buffers. The frame buffer can take a particular portion of such an image (pan) and enlarge it up to the size of the whole screen (zoom). This process can be repeated with the various elements contained in an animation’s frames. If this procedure is done fast enough, then the effect of continuity results. Since each frame of an animation is reduced to a small portion of the total image (1/25 or 1/36) and then enlarged to the full image size, the resolution of the monitor can be effectively reduced.
6.1.3 Inbetween Process
The animation of movement from one position to another requires the composition of frames with intermediate positions (intermediate frames) between key frames. In computer-based animation, this inbetween processing is done using interpolation methods. In interpolation, the system obtains only the beginning and end positions. Linear interpolation, sometimes called lerping, is the simplest method, but is subject to numerous limitations. For example, if one uses lerping to calculate the intermediate positions of a ball that has been thrown in the air and uses only three key frames, as shown in Figure 6-1(a), then the resulting motion of the ball, depicted in Figure 6-1(b), is totally unrealistic.
Figure 6-1 Linear interpolation of the motion of a ball: (a) key frames, (b) additional intermediate frames.
Due to the disadvantages of lerping, splines are often used to smooth out the interpolation between key frames. Splines can be used to smoothly vary different parameters as a function of time. With splines, individual points (or individual objects) can be moved in a natural fashion through space and time. However, the entire inbetween problem is not solved.
Inbetween processing also includes interpolation of the form of the objects in the intermediate frames. Some methods have been developed, including one by Burtnyk and Wein [BW76]. The authors develop a skeleton for a motion by choosing a polygon that describes the principal shape of a two-dimensional figure (or part of the figure) as well as the vicinity of the shape. The figure is represented in a coordinate system based on the skeleton. The intermediate processing proceeds by interpolating the characteristics of the skeleton between the key frames. A similar technique can also be transferred to the three-dimensional domain. In general, the process of interpolation between key frames is a complex problem.
6.1.4 Changing Colors
To process color changes, computer-based animation uses the Color Look-Up Table (CLUT) or Look-Up Table (LUT) of the graphics memory and the double buffering method, whereby two parts of a frame are stored in different areas of graphic memory. The graphic memory is divided into two fields, each having half as many bits per pixel as the whole graphic memory.
The animation is generated by manipulating the LUT. The simplest method is to cyclically change the colors of the LUT, thereby changing the colors of different parts of an image. Performing LUT animation is relatively fast. If a frame buffer of size 640×512 pixels uses eight bits per pixel for color, then an image contains 320Kbit of data. Transferring a new image into the frame buffer, which takes place every 1/30 of a second, would require a bandwidth of over 9Mbit/s. On the other hand, new LUT values can be sent very quickly since LUTs typically contain on the order of a few hundred to a thousand bytes.
6.2 Specification of Animations
Various languages exist to describe animations and new formal specification are currently being researched and further developed.
These specifications can be divided into the following three categories:
• Linear-List Notations
In linear list notation each event in an animation is described by a beginning frame number, an end frame number, and an action (event) that is to be performed. Actions typically accept input parameters in the form of an instruction such as the following:
42, 53, B, ROTATE “PALM”, 1, 30.
This instruction means that between frames 42 and 53, the object denoted PALM should be rotated 30 degrees around axis 1. A table determines the rotation in each individual frame, allowing for animations with either uniform or accelerated movement [FDFH92].
Many other linear list notations have been developed. Other notations are supersets of linear lists, an example being Scefo (SCEne Format) [Str88], which also includes the specification of groups and object hierarchies as well as transformation abstractions (so-called actions) by using constructs from high-level programming languages.
• High-Level Programming Language Notations
Another way to describe animations is by embedding animation control in a general-purpose programming language. The values of variables in the language can then be used as parameters for animation routines.
ASAS is an example of such a language [Rei82] based on an extension of LISP. The language’s primitives include vectors, colors, polygons, surfaces, groups, points of view, subworlds, and aspects of lighting. ASAS also includes a large collection of geometric transformations that operate on objects. The following ASAS program fragment describes an animated sequence in which an object called my-cube is rotated while the camera pans. This fragment is evaluated for each frame in order to generate the entire sequence.
(grasp my-cube); Make the cube the current object
(cw 0.05); Small clock-wise rotation
(grasp camera); Make the camera the current object
(right panning-speed); Move it to the right
• Graphical Languages
A problem with traditional, textual programming languages is that graphical actions cannot be easily visualized by examining scripts. Graphical animation languages describe animations in a more visual fashion. Such languages are used to name and edit the changes taking place simultaneously in an animation and to visualize the effects created. The description of actions to be carried out is done using visual paradigms. GENESYS [Bae69], DIAL [FSB82] and the S-Dynamics System [Inc85] are examples of such systems.
6.3 Methods of Controlling Animation
Animation control is independent of the language used to describe animation. There are various techniques for controlling animation.
6.3.1 Explicitly Declared Control
Explicit control is the simplest type of animation control. In explicit control, the animator provides a description of all events that could occur in an animation. This can be done by specifying simple transformations—such as scalings, translations, and rotations—or by specifying key frames and methods for interpolating between them. Interpolation can be specified either explicitly or, in an interactive system, through direct manipulation with a mouse, joystick, data glove, or other input device. An example of this type of control is the BBOP system [Ste83].
6.3.2 Procedural Control
Procedural control is based on communication among different objects whereby each object obtains knowledge about the static or dynamic properties of other objects. This information can be used to verify that objects move in a consistent fashion. In particular, in systems that represent physical processes, the position of an object can influence the movement of other objects (for example, ensuring that balls cannot move through walls). In actor-based systems, individual actors can pass their positions along to others in order to influence their behavior.
6.3.3 Constraint-Based Control
Although some objects in the real world move along straight lines, this is not always the case. Many objects’ movements are determined by other objects with which they come in contact. It is thus much simpler to specify an animation sequence using constraints (usually determined by the environment) instead of explicit control. Sutherland’s Sketchpad [Sut63] and Borning’s ThingLab [Bor79] are examples of systems using constraints for control.
Currently much work is underway on support for hierarchies of conditions and on determination of motion. Many of these efforts allow for the specification of constraints that take into account the dynamics of real bodies and the structural properties of their materials.
6.3.4 Control by Analyzing Live Action
By examining the motions of objects in the real world, one can animate the same movement by creating corresponding sequences of objects. Traditional animation uses rotoscoping. A film is made in which people or animals act out the parts of the performers in the animation. Afterwards, animators process the film, enhancing the background and replacing the human actors with the animated equivalents they have created.
Another such technique is to attach indicators to key points on the body of a human actor. The coordinates of the corresponding key points in an animated model can be calculated by observing the position of these indicators. An example of this sort of interaction mechanism is the data glove, which measures the position and orientation of the wearer’s hand, as well as the flexion and hyperextension of each finger point.
6.3.5 Kinematic and Dynamic Control
Kinematics refers to the position and velocity of points. A kinematic description of a scene, for example, might say, “The cube is at the origin at time t=0. Thereafter it moves with constant acceleration in the direction (1 meter, 1 meter, 5 meters).”
In contrast, dynamics takes into account the physical laws that govern kinematics (for example, the Newtonian laws for the movement of large bodies, or the Euler-Lagrange equations for fluids). A particle moves with an acceleration proportional to the forces acting on it; the proportionality constant is the mass of the particle. A dynamic description of a scene might be: “At time t=0, the cube is at position (0 meter, 100 meter, 0 meter). The cube has a mass of 100 grams. The force of gravity acts on the cube.” The natural reaction in a dynamic simulation is that the cube would fall.
6.4 Display of Animation
To display animations with raster systems, the animated objects (which may consist of graphical primitives, such as lines or polygons) must be scan-converted and stored as a pixmap in the frame buffer. A rotating object can be shown by displaying successive views from slightly different locations.
The scan-conversion must be done at least 10 (preferably 15 to 20) times per second in order to give a reasonably smooth visual effect; hence a new image must be generated in at most 100ms. The actual scan-conversion of an object should take only a small portion of this time. For example, if the scan-conversion took 75ms, only 25ms remain to erase and redraw the complete object on the screen; this is not enough time, and the result is a distracting ghost effect.
“Double buffering” is used to avoid this problem. As an example, consider the display of a rotation animation [FDFH92]. Assuming that the two halves of the pixmap are image0 and image1, the process is as follows:
Load LUT to display values as background color
Scan-convert object into image0
Load LUT to display only image0
Repeat
Scan-convert object into image1
Load LUT to display only image1
Rotate object data structure description
Scan-convert object into image0
Load LUT to display only image0
Rotate object data structure description
Until (termination condition).
If rotating and scan-converting the object takes more than 100ms, the animation is quite slow, but the transition from one image to the next appears to be instantaneous. Loading the LUT typically takes less than 1ms [FDFH92].
6.5 Transmission of Animation
Animated objects can be represented symbolically using graphical objects or scan-converted pixmap images. Hence, the transmission of an animation may be performed using one of two approaches:
•The symbolic representation (e.g., circle) of an animation’s objects (e.g., ball) is transmitted together with the operations performed on the object (e.g., roll the ball). The receiver displays the animation as described earlier. Since the byte size of such a representation is much smaller than a pixmap representation, the transmission time is short. However, the display time is longer since the receiver must generate the corresponding pixmaps.
In this approach, the bandwidth (e.g. bytes/second) required to transmit an animation depends on (1) the size of the symbolic representation structure used to encode the animated object, (2) the size of the structure used to encode the operation command, and (3) the number of animated objects and operation commands sent per second.
•The pixmap representations of the animated objects are transmitted and displayed by the receiver. The transmission time is longer compared to the previous approach because of the size of the pixmap representation. However, the display time is shorter.
The necessary bandwidth is at least proportional to the size of a single pixmap image and to the image repetition rate. These values are significantly higher than in the case of a symbolic representation.
6.6 Virtual Reality Modeling Language (VRML)
The Virtual Reality Modeling Language (VRML) is a format for describing three-dimensional interactive worlds and objects that can be used together with the World Wide Web. For example, VRML can be used to generate three-dimensional representations of complex scenes such as illustrations, product definitions, or Virtual Reality presentations.
The idea of a platform-independent standard for 3-D WWW applications originated in May 1994 at the “First International Conference on the World-Wide Web.” Immediately afterwards, the Internet magazine Wired set up a mailing list to collect proposals and suggestions on the topic. Five months later, in October 1994, VRML 1.0 was presented at the “Second International Conference on the World-Wide Web.” Two weeks after SIGGRAPH 95 (in August 1995), the VRML Architecture Group (VAG) was established. As technical development of the language progressed, the VAG focused increasingly on the standardization process. In January 1996, the VAG called for submission of proposals for VRML 2.0. Proposals submitted by Apple, the German National Research Center for Information Technology (GMD), IBM Japan, Microsoft, and Silicon Graphics, Inc. (SGI), were voted on in March 1996 over the Internet. The “Moving Worlds” proposal submitted by SGI was accepted by a majority and considered to be the working basis for VRML 2.0. VRML 2.0 was publicly presented on August 6, 1996 at SIGGRAPH 96.
VRML was adopted as international standard ISO/IEC 14772, prepared by Joint Technical Committee ISO/IEC JTC 1, the Information Technology Sub-Committee 24 (computer graphics and image processing) in cooperation with the VRML Architecture Group (VAG) and the VRML mailing list ([email protected]). ISO/IEC 14772 is a single standard under the general title Information Technology—Computer Graphics and Image Processing—Virtual Reality Modeling Language [Org97].
VRML is capable of representing static and animated objects as well as hyperlinks to other media such as sound, motion pictures, and still pictures. Interpreters (browsers) for VRML are widely available for many different platforms, as are authoring tools for generating VRML files.
VRML is a model that allows for the definition of new objects as well a registration process that makes it possible for application developers to define common extensions to the base standard. Furthermore, there are mappings between VRML elements and generally used features of 3-D Application Programmer Interfaces (API) [ANM96].
There are three ways of navigating through a virtual world:
• WALK: Movement over the ground at eye-level (the ground lies in the x-z plane).
• FLY: Movement at any height.
• EXAMINE: Rotating an object in order to examine it more closely during design.
The following color animation is an example of a VRML animation:
Color interpolator
This example interpolates in a 10-second long cycle
from red to green to blue
DEF myColor ColorInterpolator{
key [ 0.0, 0.5, 1.0]
keyValue [ 1 0 0, 0 1 0, 0 0 1] # red, green, blue
}
DEF myClock TimeSensor{
cycleInterval 10.0 # 10 second animation
loop TRUE # animation in endless loop
}
ROUTE myClock.fraction_changed TO myColor.set_fraction
A more complex example demonstrates the capability of VRML to describe interactive animations of 3-D objects as well as camera parameters:
Elevator
Group {
children [
DEF ETransform Transform {
children [
DEF EViewpoint Viewpoint { }
DEF EProximity ProximitySensor { size 2 2 2 }
<Geometry of the elevator: a unit cube
at the origin with a door>
]
}
]
}
DEF ElevatorPI PositionInterpolator {
keys [ 0, 1]
values [ 0 0 0, 0 4 0] # a floor is 4 meters tall
}
DEF TS TimeSensor { cycleInterval 10 } # 10 second travel time
DEF S Script {
field SFNode viewpoint USE EViewpoint
eventIn SFBool active
eventIn SFBool done
eventOut SFTime start
behavior "elevator.java"
}
ROUTE EProximity.enterTime TO TS.startTime
ROUTE TS.isActive TO EViewpoint.bind
ROUTE TS.fraction_changed TO ElevatorPI.set_fraction
ROUTE ElevatorPI.value_changed TO ETransform.set_translation
This example of a camera animation implements an elevator that facilitates access to a two-dimensional building that has many floors. It is assumed that the elevator is already on the ground floor and doesn’t have to be moved there first. In order to go up, the user must enter the elevator. A so-called proximity sensor triggers upon entry, automatically starting the elevator. The control buttons are located outside of the elevator.
Further details about VRML can be found in [ANM96].