TAPESTRY: The Art of Representation and Abstraction
Animation Bottlenecks
Full-on, full-speed, full-screen animation places substantial demands on our computing resources. An animation involves the rapid retrieval or generation and display of a large volume of information in a very short time. It is important to appreciate where the bottle-necks exist in this information processing.
Limits to Computer Performance
Approach #1: Brute force ('real time') animation
If the definition of animation is the display of frames (pictures) fast enough to give the impression of motion, then the obvious way to do this is to have the program run as fast as possible, sending new frames to the screen as fast as possible, so as to achieve an acceptable 'frame rate' (20-30 fps). This means pushing the entire geometry model through the graphics pipeline 20-30 times per second! Which equates to doing each rendering in 1/30 of a second.
If the system is able to generate frames fast enough, you will have the impression that you are directly manipulating the model as you adjust viewing controls (imagine a program which rotates the rendered model, not some abstract axes or picture plane, when you activated the spin controls). Such a system is said to operate "in real time", meaning that there is no lag between the time you adjust the viewing control and the time the resultant image is displayed. Some systems employ boxes with knobs on them to enhance this further: one knob "connects" to the x-axis, one to the y-axis, and so on. Turning them instantly alters the display, giving the illusion of a direct mechanical linkage.
Needless to say, real time animation is the "holy grail" of animation, and is incredibly demanding of computer systems, even our newest super-duper systems with high-performance graphics cards, etc. There may not be a better way, but there must be a cheaper one! Let's look.
Minimize Computation Costs and 'go slow'
Animation is hard on computer systems in two distinctly different ways. It is very demanding of CPU time: Animation requires about 30 frames a second and individual photorealistic frames of 3D environments might take 6-12 hours each, so it might take two weeks to create one second of animation! Under such circumstances, anything that can be done to cut corners will be.
- One simple technique is to use each frame twice, effectively cutting the computation time in half.
- Another way to reduce computer time would be to compromise on the image quality, after all, the frame is only visible for a fraction of a second!
- Finally, what if we could isolate only those parts of the frame that had changed, and recompute what they looked like? If the ball is bouncing in an unmoving room, lets just compute what the room looks like once, and overlay the image of the bouncing ball on that. In essence, we turn the room into a stable, unmoving back-drop and animate the ball in front of it. Saturday-morning cartoons take great advantage of this technique. They simplify it further by disposing of a dimension: flat 2D images can be manipulated much more easily than a full 3D model. All you need is a good animator (human) at the controls.
Forget 'real time' -- Compute and Store
If we could store the finished frames in memory or on disk, we could then flash them up onto the screen in a rush later on. With the advent of large storage disks, this has become a much more practical approach.
For non-real-time systems, which compute a series of frames ahead of time, and store them until it's time to display them, the sheer size of a color picture can become a problem. A full-color (24 bits per pixel) image at only 640 x 480 pixels is 921,600 bytes, or almost one megabyte (1 MB) of data. At 30 frames per second, a 1 minnute animation requires 54,000 (30x60x60) megabytes of image data. These days that's not such a large amount of data to store, but the system must be capable of communicating upwards of 30 MB per second from somewhere to the screen. By and large, the only place that can be hooked to the screen at that speed is RAM memory. Ethernet is only about 1 MB per second, at full utilization. Hard disks communicate with the rest of the computer at about 1-4 MB per second. Neither is fast enough.
That's the problem, so what's the solution?
So, how do they do it?
There is, of course, no single solution. There are a variety, which depend on your needs and resources.
Approach #2: If you cannot store, display, or compute frames fast enough, don't!
This approach has been used for years. Let's say a program takes 20 minutes to create a frame, and cannot store them for later display. Why not write each one off to storage or "print" them to video tape or film as you go along, and then display the film at full speed when it is all done? This is done frequently, with techniques ranging from recording each frame on magnetic tape and then sending the tape off to be turned into 35mm film, down (up?) to snapping a 35mm slide of each frame, using a tripod to keep the camera position fixed, and manually bringing up each frame.
Approach #3: If RAM's the only place to do it, do it in RAM.
Many programs compute a sequence of images, storing each one in RAM, and then 'flip' though them rapidly to generate the animation. Obviously, this technique is limited by the amount of RAM available, and at 1 MB/frame, one second would require the complete RAM "supply" on most high-end systems!
Approach #4: If I can only get 1 MB/sec off my hard disk, figure out how to make that add up to 30 frames a second.
Most PC-based programs compress the data into a more compact form (standards with names like "MPEG" and "H.264" are evolving to do this, so that you can compress with one program and decompress with another). These programs get upwards of 40-50:1 compression ratios. That means a 1 MB/second disk system (your basic hard disk) would actually be able to dump enough data into the CPU to display 30 frames a second, if the CPU can decompress it that fast. The problem at the moment is that the time to decompress one of these images in software alone is way too long, so special add-in boards are being developed and marketed which do nothing but image compression and decompression. The PC marketplace now shows strong movement towards "entertainment PCs" with built-in decompression features for watching DVDs and online videos, so this is working well.
Approach #5: If you can't communicate the whole image fast enough, how about just sending the changes?
If small sections of the image are modified (as in the bouncing ball against a stable background), just store/transmit/display the alterations. The viewer sees the compound effect of the sequence of displays, but we only manipulate small amounts of data. Most modern compression schemes do this to achieve good results.
One interesting problem with this technique is that you cannot isolate a single "still" image or "video-bite" from the sequence without playing it from the beginning since the stored sequence is only a sequence of changes to a starting frame. This makes editing such sequences somewhat more difficult!
Note too, that full-frame dissolves (from one image to another) involve change throughout the every frame ... and don't compress well.
Approach #6: If none of the above are good enough? create specialized hardware!
Sometimes the approaches outlined above aren't suitable. If the camera moves much, then #4 won't work, and #2 and #3 generally rely on having a "setup time" between animation segments, when the CPU can work. Flight simulators and other high-end animation systems cannot afford to take this time out. They require specialized hardware.
There are now sophisticated computer systems available capable of rendering millions of Phong-shaded polygons per second. Such systems don't store the images, or transfer them around inside the machine, they simply generate them in real time, as needed. Only a few years ago they would cost you $25,000 or more. Now, most high-end gaming systems have these specs. Of course, model complexity is based on what they can render in 1/30th of a second, so you don't do whole cities in high detail with one of these, and there's (still) no way you can do raytracing in real time, even on simple models, so image features may prohibit use of real-time systems. [Keep in mind, however, that once the angle-factors are calculated in a radiosity renderer, images are quick to produce, quick enough to be done in real time on manysystems. ]
Since the gaming and video entertainment industries are (combined) MUCH larger than the general PC industry, we can expect to see continued improvements in realtime performance, and may take advantage of this performance for other purposes.
Last updated: April, 2014
