Tohline: Quicktime Movies

Joel E. Tohline

Alumni Professor
Department of Physics & Astronomy
Louisiana State University

Generating Quicktime Animation Sequences
to Illustrate the Results of Astrophysical Fluid Simulations

Over the past 10 years, we have routinely generated animation sequences (movies) from our 3D hydrodynamic simulations in order to illustrate the results of each simulation for both local analysis and for more public broadcast. [See, for example, this movie ensemble, or this collection from a recent simulation.] Presently, the following steps are taken to generate each "Quicktime Movie" of our time-evolving 3D astrophysical fluid configurations:

At a given instant in time (a specified time step) during the hydrodynamic simulation, the array that specifies the three-dimensional mass-density distribution – RHO(J,K,L) = r(R,Z,q) – as well as the arrays that map from the integer indices to coordinates in space – R(J), Z(K), q(L) – are written out in binary format from the memory of the parallel supercomputer on which the simulation is executing to a disk that is accessible via the internet.

[For a typical grid resolution of 256³, this double-precision (64-bit) RHO array occupies 128 MBytes of storage. Note that, depending upon the manner in which the parallel I/O is handled by the hydrocode, it may be necessary to unscramble the binary data file before it can be properly interpreted by other machines. It may also be necessary to perform a "big-endian" to "little-endian" (or visa versa) conversion if the machine on which the visualization tasks are to be performed adopts a different standard from the parallel computer on which the hydro simulation has been performed.]

The RHO(J,K,L) array is read into a (usually serial, linux) computer and a "marching cubes algorithm" is employed to identify sequences of "vertices and polygons" (wireframe models) that map out various (usually four) isodensity surfaces within the three-dimensional fluid volume. These sequences of vertices and polygons are then written out to a data file in a format (usually .obj) that matches the preferred input format of our volume-rendering and ray-tracing program.

[If desired, the "wireframe" models that are defined by these sequences of vertices and polygons also can immediately be written out in, for example, an ASCII-based VRML format for viewing, given an appropriate VRML browser plugin.]

The wireframe models are read into Maya, which renders a two-dimensional image of our fluid model using sophisticated ray-tracing and volume-rendering techniques. Maya expects to find the vertices and polygons of each wireframe surface detailed in an ASCII file of ".obj" format. Maya also needs to be told what lighting and color schemes to utilize; from what angle and distance the "observer" is viewing the scene; at what pixel resolution the final image is to be generated; etc. This information is provided to Maya through the "MEL scripting language" [MEL = Maya Embedded Language].

The MEL commands that we feed into Maya have been generated through interactive MAYA sessions and trial & error. We have settled on, for example, a lighting and color scheme that seems to work quite well for most of our simulations. The MEL script that performs these chosen volume-rendering and ray-tracing tasks was written to a file by MAYA (while in an interactive session) in such a way that this file can be read back into MAYA while it is being run in a background (non-interactive) mode to perform the same set of visualization steps repeatedly on different sets of wireframe models.

While Maya is capable of generating a two-dimensional rendered image at virtually any specified pixel resolution, and of outputing the image in any of a number of standard formats, we have traditionally set up the MEL script to generate images having a resolution of 640 × 480 pixels and to write those images to disk in TIFF format.

The end product of following steps 1 - 4 is the generation of a single, 24-bit color (640 × 480 pixel) TIFF image, which will become a single frame of the movie. [This single image will have a binary file size of approximately 640 × 480 × 24 bits = 900 KBytes.] In order to generate a movie, a relatively large number of TIFF images must be produced at different times throughout a hydrodynamic simulation (preferably spaced by equal intervals of time); hence, steps 1-4 must be repeated many times.

[From experience, we have found that reasonably interesting animations are produced if the movie plays at 30 fps (frames per second) and we generate one TIFF image (movie frame) every 1/120^th of a rotation period (or of a dynamical time) of our astrophysical fluid system. This means that, as the movie plays, the system will rotate once every four seconds; and a 60-second movie will cover 15 rotation periods and will require the generation of 1800 TIFF separate images.]

If each of the individual TIFF images is assigned a filename that includes an integer suffix that numbers each TIFF image sequentially, and if all of the images are grouped together into a single file directory (folder), then various utilities exist that will "concatenate" the frames into a movie. (For example, on an SGI system, we have used "dmconvert"; on a Mac, we use a feature of Apple's "Quicktime Pro" software.)

Data compression: A single, color TIFF image of the resolution discussed above will have a file size of approximately 900 KBytes. Because a single movie can contain of order 2000 frames, an "uncompressed" movie will require of order 1.7 GBytes of disk storage! An individual movie file of this size is rather cumbersome. Fortunately, the various utilities that have been developed to concatenate sequences of images into movies offer a variety of compression formats. We generally produce movies in "Quicktime" format utilizing Quicktime's default (Sorenson Video 3) codec (COmpression/DECompression) algorithm.

— written in August, 2005