Anyone who attempts to simulate complex physical phenomena soon realizes that literal simulation is far beyond the capabilities of today's hardware or software. If fact, such literal simulation is not really necessary to make adequate pictures. All that is necessary is that the errors be confined to situations which are not visually apparent. This may involve generating models that only work in the geometric situations of interest, but break down when view from an un-planned-for direction. It may involve mechanisms where manual intervention is required to perform some global decision making about visibility. It may involve some numerical approximation that generates the wrong picture, but it is not wrong enough to be immediately apparent except with detailed examination of the image.
Here follows an outline of some techniques which have been used to good effect in production of several "realistic" space simulation movies at JPL and in the production of several more schematic animations for the Mechanical Universe. Many of these at first seem like very special purpose tricks, but, as we all know, a "technique" is a "trick" that you use more than once.
(I would like to credit Bill Etra for the title of this paper.)
Changing the resolution of the database based on number of pixels covered is a fairly standard trick. Many of the moons of a planet are far enough away to only cover a fraction of a pixel. The main control program of the space scene renderer either draws a texture mapped sphere or a simple anti-aliased dot. The pixel size at which this transition occurs is set manually after making a few test frames. The color of the dot is also manually chosen to be approximately the same intensity of a sphere at the same size.
A similar database/rendering switch was used in a scene depicting a flight over the moon Mimas. When situated near the north pole it was rendered with a bump mapped sphere. When near the large crater at the equator it was rendered as a brute force polygon mesh. The transition was made manually by first generating the frames near the pole, stopping frame production, and editing the control file to cause it to invoke a different rendering program, and then re-starting production. The transition was done when flying over the night side of the moon where the image was too dark to notice the slight change in appearance.
Saturn ring kluges
Painting moon maps with crater shadows built in.
Texture maps are stored and utilized as pixel arrays. This means the rendering program is insensitive to the kluges used to generate these arrays in the first place. All it takes is for the rendered image to look right.
Many of the moon maps were re-constructed from real photographs of the moons sent back by an earlier spacecraft. This basically involves constructing an effective viewing transformation for the real image, transforming pixels in map space into the pixel space of the real image (via this transformation), picking up the intensity of the real image, and finally placing it in the texture map. (sort of like running a rendering program in reverse). The viewing geometry is known fairly precisely at the time the image was made from spacecraft orbit data, but some adjustment must always be done. The image is never seems to be centered correctly, so an interactive program was used to fine tune the reconstructed viewing transform so that the simulated silhouette edge of the moon matched that on the real image. Further, when this 'unwrapping' process is completed, only about half the map is generated (the half facing the viewer). The map still has the effect of the light source direction scaling the intensities however. Moons are not perfect Lambert reflectors so some empirical juggling was done to construct effective lighting functions which, when divided into the picture, fairly nicely flatten out the global gradations in shading across the map. Next, the data around the edges of this covered area is usually pretty ratty since it comes from a stretched out part of the image. Several overlapping real pictures are needed to completely cover the moon. These never seem to have matching intensities at their edges. This is manually fiddled with to get them all about the same brightness and then they are blended together with weighting function adjusted to disguise the seam between pictures. Finally, some of the moons were not completely covered with pictures. The simple expedient of "cosmetically enhancing" the map was done by using a painting program.
For texture maps that are completely hypothetical, some other lighting tricks were employed. Much of the lighting of a moon is caused by surface irregularities. This might be ideally modeled by bump mapping. The problem is that bump mapping is a bit slow. Also the craters or mountains tend to be rather small creating bump aliasing problems. Finally, the artists employed were more used to thinking about painting illuminated surfaces rather than sculpting topographic maps. For these reasons, the artists typically painted the shadows of craters etc. right into the maps. The moon was then rotated so the sub-solar point (as painted) pointed in the direction of the sun (as modeled by the orbit calculations). It looks fine for that particular scene, but a bit fishy if a simulation is done for a different time.
The concept of realism has to be stretched slightly when making space scenes or they will look rather boring. For the most part, the objects in a typical scene have radically different intensities. To simulate Jupiter with its intensity scaled to 0 to 255 intensity values, the moons would be almost dead black. Likewise, the spacecraft are typically enclosed in light absorbing cloth to improve their heat retention capabilities. Therefore the relative intensities of most objects in the scene are adjusted independently to make them all show up at a similar intensity.
Another thing to remember is that there are no fill lights in space. The whole scene is "really" illuminated by one bright point light source. This is ideal for computer graphics but looks too harsh to be able to perceive shapes. This is especially a nuisance when you realize that half the viewing direction you can pick are on the night (black) side of an object. Thus, for viewing ease, some ambient and fill lights were usually added to the simulations.
Most simple objects can be modeled with polygons, surfaces of revolution or extrusions. The Voyager spacecraft, however, is built up of a large number of thin struts and booms. A special modeling primitive was built into the polygon rendering program to model tubes directly as beginning-point, ending-point, and radius. This is converted into a standard unit cylinder with the appropriate orientation and scaling parameters. Then during rendering, each cylinder is converted into two long thin polygons. Their outer edges were calculated from the mathematical silhouette outline of the cylinder (in screen space). The common edge between them is calculated as that line where there is a local maximum in intensity when scanning across the tube. Thus the cylinder was modeled with two optimally chosen polygons. This is actually a fairly simple 2D calculation. This works fine and saves polygons (important in a memory restricted environment) but breaks down when you get too close to the tube and notice the strange appearance of their ends.
The main animation system currently in use allows for a collection of primitive objects to be subjected to an arbitrary set of nested homogeneous transformations. It is not good at shape alterations. One can, however, do more with matrices than might be expected. For example, a vibrating string was animated by beginning with a (rigid) primitive flexed string, and scaling it by zero along the perpendicular axis to make a straight string. Then animating the scale factor back and forth between positive and negative values caused it to twang. Similarly, a vector arrow was made to appear to bend by modeling it bent and scaling it by zero when it needed to be straight. The arrowhead was modeled as a separate object and animated to follow the body of the arrow as it flexed.
Another particularly interesting example is the illustration of conic sections with variable eccentricities. These can be generated by using the homogeneous perspective transformation to distort a circle into any desired conic. Given the polar equation for a general conic:
r = p/(1+e cos(theta))where e=eccentricity
one can generate the conic by transforming a circle formed from sines and cosines by the perspective matrix:
[cos(theta) sin(theta)
0 1] | p 0 0 e |
| 0 p 0 0 |
| 0 0 0 0 |
| 0 0 0 1 |
A perspective transform is therefore used in two places, once in the normal sense to view the entire scene, and once, as above, as a modeling transform.
Z sorted line renderer
Saturn ring splitting and making sure halves don't overlap
Painters algorithm complications (intertwined objects)
Jupiter magnetic field
Transparent spinning top with internal structure
Spinning gyroscope wheel with superimposed force vectors
Parabolic silhouette edges (snip out bad frames with scissors )
Explicit drop shadows of letters,
'local' color and 'global' color
shadows of solid objects on flat surfaces
perspective (local light) shadows
Rings of Saturn
Planet on rings
Satellite shadows (black dots)
Eclipse shadows, approx. with spheres, umbra/penumbra
Fog simulation (avoids drawing too many spheres of NaCl)
Darkened edge lines (Jupiter magnetic field)
Playing with depth cueing (Jupiter field)
Shading background (vector-land)
3 levels of glow on zooming into nucleus
Explicit fade outs as objects recede
Bump mapping problems at terminator
Puff of smoke (scaling up and fading)
Explosion (scaling up and fading)
sparkles (fuse on 8 ball)
fuzzy lines overlapping
earth atmosphere on MU open
Sub-sampling
Edge blending
Ring shadows
Sleazy lines, limitations with wide lines
Sub-sampling
Global pre-filtering (removing hi frequencies from pattern)
Specialized pre-filtering based on shape the texture will be mapped to (e.g. spheres)
Streaks of ring particles (comet shaped, rather than Gaussian)
Time smearing texture patterns
Trails of moving particles as explicitly drawn lines
Logarithmic zooms
When to double/single frame