The first key class is the MovieMaker class, which contains methods for managing the construction of the frames. The output of each of these methods is an array of ObjectGroup objects (from the plotter package), each of which is one frame of the movie. Other classes will then operate on this array of movie frames.
For construction, it is assumed that the data is stored in separate files/sources, each of which contains the data for one frame. The algorithm, then, is to take a DataReader of the right type and iterate through the list of data sources, calling the utilities of the plotter package with each source to construct the corresponding frame.
Once the frames are constructed, it makes sense to write the frames themselves to file in a sensible format, rather than reconstructing them every time. Since it is not certain what output format will be desired, this functionality is delegated to a MovieIO object that provides the methods for reading and writing movie frames. Subclasses of this abstract class implement different output formats.
Once the frames are constructed, they need to be animated. In Java3D, animation is provided via an Alpha object and a Behavior object. An Alpha object is synchronized with the system clock and, essentially, maps time to a periodic function with minimum and maximum values of 0 and 1. The Behavior object then uses this value to determine which frame to view - when alphaValue=0, the first frame is shown, when alphaValue=1, the last frame is shown, with the intermediate behavior depending on the construction of the Alpha object and the design of the Behavior class. How the view is switched from one frame to another is also implementation dependent.
The following algorithm is currently implemented. The BranchGroup within each frame is stored under a Switch object (a Java3D class). Ten frames are stored under each Switch object (except for the last set, which may have less than 10), and the Switches are themselves stored under one main Switch object. This design produces more of a tree structure rather than making all the frames a child of one object. All of this functionality is performed by the SwitchMovie class. Then, a SwitchMovieBehavior object is constructed which uses the alphaValue from the Alpha object to select which frame should be shown (by picking the correct child of the correct Switch object). In this way, each frame is replaced by the next frame as time advances.
This is, of course, only one possible algorithm. We are currently experimenting with different possibilities, and exploring how to construct this package to allow multiple movie algorithms.
An interesting consequence of the Alpha object paradigm is that
restarting the movie after stopping it is not trivial. Stopping can
be handled simply by stopping the updating of which frame to view.
However, the alphaValue is directly tied to the system clock: the
algorithm is essentially
alphaValue = ( now - startTime)/cycleLength MOD 1.
Therefore, in order to restart the movie at the correct frame, one
would have to save when it was stopped and construct a new Alpha
object with the proper offset at restart. This hasn't been implemented
yet, mostly since the entire process of making movies hasn't converged
on a fixed method yet. For this reason, the current movies only cycle
forever, there is no stop or restart.