Animation Techniques in BRL-CAD

The first step in creating an animation sequence is the definition of ``key-frames.'' These are descriptions of what the scene should look like at ``key'' moments in the animation sequence. Some key-frames are readily recognized. The frame in which the camera or an object starts or stops moving is important. Likewise, the moment when an object changes direction or velocity is also important. It is good to define one or two key-frames before and after each of these points of change.

Generating key-frames with mged is easy. The user displays the wireframe of the desired geometry and manipulates the display until the desired view is achieved. To save the key-frame information in a file, the mged keyboard command ``saveview'' is used. This command creates a shell script with the proper invocation of the rt program to render the current scene. The argument to the ``saveview'' command is the filename for the shell script. Note that the keyboard command ``saveview'' is distinct and different from the menu option visible in the button menu on the geometry display.

To keep things orderly and make later processing easier, it is recommended that the user specify key-frame filenames which have a common prefix followed by a number indicating the time in the animation sequence at which the key-frame occurs.

For our first example, we will create a simple animation with the ``moss.g'' model. The objective is to begin the animation sequence with a view of the geometry from the front corner of the platform. As time goes by, the viewer's location (the ``eye point'' or ``eye_pt'') moves upward in an arc over the geometry until the viewer is looking directly down on the center of the platform. To give a natural feeling of flight, the eye point should accelerate and decelerate at the beginning and end of its travel respectively. This is achieved by adjusting the number of degrees of elevation the eye will raise in each second of the animation. In the first (and last) three quarters of a second of the animation, the eye raises only 2 degrees of elevation above the plane. In the following second 8 degrees of arc are covered. At the 4 second mark the eye is looking down at a 45 degree angle.

mged moss.g

attach (nu|tek|tek4109|ps|plot|sgi|X)[nu]? sgi
ATTACHING sgi (SGI 4d)
Gary Moss's "World on a Platter" (units=mm)
mged> e all.g
408 vectors in 1 sec
mged> center 20 0 0
mged> size 200
mged> ae 45 0
mged> saveview moss_0
mged> ae 45 2
mged> saveview moss_0.75
mged> ae 45 10
mged> saveview moss_1.75
mged> ae 45 45
mged> saveview moss_4
mged> ae 45 80
mged> saveview moss_6.25
mged> ae 45 88
mged> saveview moss_7.25
mged> ae 45 90
mged> saveview moss_8
mged> q

At this stage there are seven key-frame files in the current directory with the names:

	moss_0		moss_1.75	moss_6.25	moss_8
	moss_0.75	moss_4		moss_7.25

	

A look at the contents of one of the key-frame files shows that the scene is stored as four separate elements. These elements are the geometry being displayed, the size of the viewing cube or ``viewsize'', the location in 3 dimensional space of the camera or ``eye_pt'', and the ``orientation'' of the geometry within space. All animations which involve the observer moving about a static object can be generated from these parameters.

Recall that these key-frames do not represent all of the images necessary to produce the animation. They only specify the significant moments in the animation. It is necessary to generate the ``in-between'' frames as well to turn the key-frames into a smooth animation. The values for the ``viewsize,'' ``eye_pt'' and ``orientation'' attributes of these ``in-between'' frames are generated by interpolating the values which describe the key-frames.

The first step in creating an animation sequence is the definition of ``key-frames.'' These are descriptions of what the scene should look like at ``key'' moments in the animation sequence. Some key-frames are readily recognized. The frame in which the camera or an object starts or stops moving is important. Likewise, the moment when an object changes direction or velocity is also important. It is good to define one or two key-frames before and after each of these points of change.

Generating key-frames with mged is easy. The user displays the wireframe of the desired geometry and manipulates the display until the desired view is achieved. To save the key-frame information in a file, the mged keyboard command ``saveview'' is used. This command creates a shell script with the proper invocation of the rt program to render the current scene. The argument to the ``saveview'' command is the filename for the shell script. Note that the keyboard command ``saveview'' is distinct and different from the menu option visible in the button menu on the geometry display.

To keep things orderly and make later processing easier, it is recommended that the user specify key-frame filenames which have a common prefix followed by a number indicating the time in the animation sequence at which the key-frame occurs.

BRL-CAD has a utility for performing interpolation called tabinterp. It operates on files containing columns of numbers. The left-most column is always used to hold the time in the animation at which the data in the other columns occurs. A column is referred to as a ``channel.'' Lines beginning with a ``#'' character are considered to be comments, and are ignored by tabinterp. Table A shows an example input file for tabinterp.

	#Time	X	Y	Z
	0	100	0	0
	1	 74.24	51.98	42.23
	2	-91.85	91.85	75

This table has four channels (columns). The leftmost channel is always the ``time channel''. In this instance the ``time channel'' has the values 0, 1, and 2. The time channel has no inherent unit associated with it. These values could represent microseconds, seconds, minutes, etc. depending upon the motion being specified. The second column contains the first actual data channel in this file. In this instance it is an X coordinate. There are three data channels in this file. The contents of the file are said to form an interpolation table.

To create the ``in-between'' frames of our animation, we need to extract the values which are arguments to the ``viewsize'', ``eye_pt'', and ``orientation'' commands to rt stored in the key-frame files. These values must be tabulated for input to tabinterp.

While it would be possible to concatenate the key-frame files and edit the result by hand to create the table, this would be tedious for all but the simplest animations. Instead it is recommended that a shell script such as the ``key-chans'' shown below be employed to do the work.

 #!/bin/sh
    if [ "$#" != "1" ] ; then
      echo "Usage: $0 basename"
      exit
    fi
    awk '/^viewsize/ { print FILENAME " " $2}'  $1* | \
        sed -e 's/;//' -e "s/^$1//" | sort -n > chans.vsize

    awk '/^eye_pt/ { print FILENAME " "  $2  " " $3 " " $4}' $1* | \
        sed -e 's/;//' -e "s/^$1//" | sort -n > chans.eyept
    awk '/^orient/ { print FILENAME " " $2 " " $3 " " $4 " " $5}' $1* | \
        sed -e 's/;//' -e "s/^$1//" | sort -n > chans.orient

This shell script creates the three files ``chans.vsize'', ``chans.eyept'', and ``chans.orient'' from key-frame files which share the same basename (such as ``moss_''). The shared basename is specified on the command line.

% key-chans moss

The files ``chans.vsize,'' ``chans.eyept,'' ``chans.orient'' now contain the values needed for interpolation. The file ``chans.vsize'' contains the argument to the ``viewsize'' directive in the key-frame files. Likewise, ``chans.eyept'' contains the X, Y, and Z arguments to the ``eye_pt'' directive and ``chans.orient'' contains the quaternion *|* argument to the ``orientation'' directive.

Now the key-frame data can be interpolated. The tabinterp program reads commands from standard input until end-of-file is found. Commands specify files from which interpolation tables should be read, which channels in the tables should be used, what type of interpolation should be applied, and the range of time over which values are needed. When end of file is reached, tabinterp performs any interpolations requested and writes out the requested results.

% tabinterp <<EOF>> chans.
all
file chans.vsize 0;
file chans.eyept 1 2 3;
file chans.orient 4 5 6 7;
times 0 8 3;
interp spline 0 1 2 3 4 5 6 7;
EOF  
cmd: file chans.vsize 0
chan 0:  File 'chans.vsize', Column 1
cmd: file chans.eyept 1 2 3
chan 1:  File 'chans.eyept', Column 1
chan 2:  File 'chans.eyept', Column 2
chan 3:  File 'chans.eyept', Column 3
cmd: file chans.orient 4 5 6 7
chan 4:  File 'chans.orient', Column 1
chan 5:  File 'chans.orient', Column 2
chan 6:  File 'chans.orient', Column 3
chan 7:  File 'chans.orient', Column 4
cmd: times 0 8 3
cmd: interp spline 0 1 2 3 4 5 6 7
performing interpolations
writing output
%

In this instance, the data from the ``viewsize'' interpolation table is read into channel 0 of tabinterp. The eye point data is acquired from another file to fill channels 1, 2, and 3. The orientation table data are read into channels 4, 5, 6, and 7. The user command ``times 0 8 3'' indicates that interpolation is to be performed for the time sequence starting at time 0, through time 8 with 3 frames per time step. If each time step represents a second, this is not enough frames per second for a finished product such as a videotape, but it will be sufficient to create a preview of the sequence. It would not be wise to expend the CPU time required to compute all of the frames before we are certain that we have the sequence correct.

The last command to tabinterp selects a spline interpolation for channels 0 through 7. When tabinterp runs out of commands to process it performs the interpolation. The file ``chans.all'' contains the result of the interpolation.

Each column in chans.all represents one channel from the tabinterp session. The leftmost column is always the time channel. The column next to that is data channel 0 from the tabinterp session. An examination of the time channel on the left will reveal that the sequence runs from time 0 through time 8 and that there are 3 lines (frames) for every integer time step.

This example used only spline interpolation. There are other interpolation techniques available including step, linear, and circular spline (cspline). With step interpolation, a channel value is simply copied to intermediate time points until a new value is encountered. The circular spline technique makes certain that the starting and stopping conditions of the time sequence are identical. The second derivative of the curve at the endpoints are made to be the same. This is useful when a seamless loop of values is desired.

The program tabsub uses the output from a run of tabinterp along with a template file to write an animation script for rt. There are many types of ``macros'' which tabsub recognizes in the template. An understanding of two of these is necessary for the current example. The character ``@'' followed by an integer (such as @2) is replaced by data from the interpolation channel of that number. Note that ``@0'' refers to values from the first data channel from the interpolation. It does not refer to the time channel. The macro ``@(line)'' is replaced with the line number of the file from which the data was read. The @(line) macro serves primarily to indicate the animation frame number. A template file (``moss.proto'' for this example) should be created:

%  cat moss.proto 
viewsize @0;
eye_pt @1 @2 @3;
orientation @4 @5 @6 @7;
start @(line);
end;

This file can be used in conjunction with tabsub to create an animation script for rt.

% tabsub moss.proto chans.all > moss.rtanim

The resultant file ``moss.rtanim'' is rather long, so for illustration purposes only the commands for the first two frames are shown here.

% head -n 12 moss.rtanim
viewsize 200;
eye_pt 90.7107 70.7107 0;
orientation 0.270598 0.653281 0.653281 0.270598;
start 0;
end;

viewsize 200;
eye_pt 90.6992 70.6992 1.11757;
orientation 0.26908 0.649617 0.656908 0.2721;
start 1;
end;

Under a future version of BRL-CAD and beyond, the user will have the ability to preview animations using mged. Users running a 4.[012] release should skip this section. This is a useful check to run before expending the CPU time to compute the images with rt.

%mged moss.g

attach (nu|tek|tek4109|ps|plot|sgi)[nu]? sgi
ATTACHING nu (Null Display)
Gary Moss's ``World on a Platter'' (units=mm)
mged>  preview moss.rtanim
tree
eyepoint at (0,0,1) viewspace
db_lookup:  could not find 'EYE_PATH*'
mged>  e all.g

Don't let the ``db_lookup'' message frighten you. This is just mged telling you that there wasn't an EYE_PATH overlay prior to your first ``preview'' command. This is the name of the ``pseudo-object'' that mged creates for storing the overlay. This object is not written into the geometry database. The preview command paints a small ``L'' shape at the eye point for each frame and connects all the corners together. The location of the ``L'' indicates the location of the eye for the frame. The orientation of the ``L'' is in the plane perpendicular to the viewing direction for the frame.

Look carefully at the path the eye will take during the animation. In this instance we want the path to form an arc from near one of the corners of the platform to a point directly over the top of the platform. Does it look like what was intended? Does the arc seem to pass through any of the objects? On a machine which supports fast polygon rendering, such as the Silicon Graphics Iris, displaying the geometry with the ``ev'' command instead of the ``e'' command will make finding eye/geometry collisions much easier.

Once you are convinced that the eye path is correct you are ready to produce a test animation. The file ``moss.rtanim'' can be fed directly to rt either from the command line or in a shell script. The invocation of moss.rt shown below will generate images that are 200 pixels square. This is a good size to use for an initial rendering. It will let us preview our animation before committing the resources to generate the complete animation.

% cat moss.rt
#!/bin/sh
rt -M $* -o moss.pix moss.g 'all.g' 2>> moss.log / moss.rtanim

% moss.rt -s 200

Once the frames have been computed, they can be turned into a ``postage stamp animation''. The ``pixtile'' program takes many small images and creates a bigger image from a mosaic of the small images. This image can then be displayed on a framebuffer, and the animation sequence played using the ``fbanim'' command.

% mv moss.pix moss.pix.0
% fbserv -S 1024 0 /dev/sgip
% setenv FB_FILE :0
% pixtile -s 200 -S 1024 moss.pix | pix-fb -h
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
% fbanim -S1024 -s200 -p5 200 25 3

Figure 1. 

moss.mpg

The animation of objects is accomplished by specifying matrix transformations to be applied to database elements before each image is calculated. This allows any solid or combination in the model to have its definition independently rotated, moved, or re-sized as the animation proceeds.

In BRL-CAD matrices are stored in a traditional mathematics form. This is different from (the transpose of) the form used in most texts on computer graphics. In BRL-CAD matrices are stored as follows:

Figure 2. 

As a result, points and vectors in 3 dimensional space are represented as 4-tuple column vectors. Points and vectors are therefore properly transformed by the matrix equation:

Figure 3. 

Individuals who are unfamiliar with matrix transformations in general and homogeneous coordinate systems in specific are urged to study one of the many texts on this subject.

The matrix operations in a BRL-CAD database can be thought of as living in the arcs of the directed acyclic graph. In slightly simpler terms, the matrix lives between an object (either primitive solid or combination record) and the parent combination record in the model tree. The model coordinate system is on the ``left'' end of a ``stack'' of matrix multiplications which is built up as the graph is traversed. When traversing the graph from the root to the leaves, matrices encountered on the arcs are applied to the ``right'' of the matrix equation. For example, the graph formed by ``all.g'' from our geometry file ``moss.g'' can be thought of as the following table:

Figure 4. 

Purists will note that MatrixA is not directly stored in the database. It exists as a conceptual aid to editing models and creating animations. In reality MatrixA will be combined with each of the matrices MatrixPr, MatrixBr, MatrixEr, MatrixCr, MatrixTr, MatrixLr from the table above.

The program rt would transform the origin (and other parameters) of ``tor'' with the following matrix equation:

Figure 5. 

Each of the matrices in the database can be altered individually during the animation. It is also possible to replace the ``stack'' matrix which has been accumulated. These operations are achieved with the ``anim'' command in the input script to rt. The command has the form:

anim Path matrix Operation [Matrix]; where Path specifies the arc where the operation takes place. Either a specific use of the matrix within the model, or all uses of an arc within the model can be specified. where Path specifies the arc where the operation takes place. Either a specific use of the matrix within the model, or all uses of an arc within the model can be specified.

Figure 6. 

For example, the following command always replaces the matrix on the arc between ``arm'' and ``hand'' with a new matrix:

		anim arm/hand matrix rarc
		1    0    0    0
		0    1    0    0
		0    0    1    0
		0    0    0    1

Whereas in the next example the matrix will be replaced only when ``arm/hand'' occurs as a direct child of ``body/left'' in the database tree. This would permit the left and right hands to be modeled as different instances of a single hand prototype, and still allow the left hand to be manipulated without affecting the right hand.

		anim body/left/arm/hand matrix rarc
		1    0    0    0
		0    1    0    0
		0    0    1    0
		0    0    0    1;

Finally, a command of the form:

		anim hand matrix rarc
		1    0    0    0
		0    1    0    0
		0    0    1    0
		0    0    0    1;
	

operates on any arc which ends in a node called ``hand'' regardless of where it occurs in the model hierarchy. Note that element ``hand'' in these examples above is not a leaf node (primitive solid) in the model graph (With version 4.2 of BRL-CAD and beyond the user will be able to manipulate the matrices on the arcs between primitive solids and their parent combinations).

All object parameters in the database are stored using millimeters as the unit of measure. As a result, all matrix operations are carried out in units of millimeters. It is important to remember this when preparing matrices for use with the rt anim command. An example rt session will serve to illustrate the proper use of the anim command.

The following shell script ``trans.sh'' runs rt to create two separate images. The first is saved in the file ``trans.pix.1'' and is approximately the view selected for the key-frame ``moss_8'' in Section 2. The ``pix-fb'' utility can be used to display these images on the framebuffer.

#!/bin/sh
rt -M $* -o trans.pix moss.g 'all.g' 2>> trans.log <<EOF
viewsize 200;
eye_pt 20.0 0.0 100;
orientation 0.0 0.0 0.924 0.383;
start 1;
clean;
end;
start 2;
clean;
anim all.g/tor.r matrix rarc
        1 0 0  0
        0 1 0 80
        0 0 1  0
        0 0 0  1;
end
EOF

Figure 7. 

The second image is saved in ``trans.pix.2'' and is the same except that the matrix on the arc between ``all.g'' and ``tor.r'' is replaced with a new matrix. This matrix has the effect of translating the torus 80 millimeters along the Y axis of the model coordinate system.

It is time to re-visit the animation sequence we developed in Section 2. We are going to add animation of the objects in the scene to the existing eye-point movement already created. The ellipsoid will be given a constant velocity along a vector which will take it through the center of the torus.

To make the ellipsoid pass through the center of the torus we must determine the vector from the center vertex of ``ellipse.s'' to the center vertex of ``tor''

% mged moss.g

attach (nu|tek|tek4109|ps|plot|sgi|X)[nu]? sgi
ATTACHING sgi (SGI 4d)
Gary Moss's "World on a Platter" (units=mm)
mged> l all.g
all.g:  all.g (len 6) --
  u platform.r
  u box.r [-23.6989,13.41,8.02399]
  u cone.r [22.0492,12.2349,2.11125e-07]
  u ellipse.r [14.6793,-41.6077,38.7988]
  u tor.r
  u light.r
mged> l ellipse.s

ellipse.s:  ellipsoid (ELL)
        V (16.1309, 46.6556, -3.72252)
        A (14.8761, 0, 0) mag=14.8761
        B (0, 8.98026, -8.98026) mag=12.7
        C (0, 8.98026, 8.98026) mag=12.7
        A direction cosines=(0.0, 90, 90)
        A rotation angle=0, fallback angle=0
        B direction cosines=(90.0, 45, 135)
        B rotation angle=90, fallback angle=-45
        C direction cosines=(90.0, 45, 45)
        C rotation angle=90, fallback angle=45

mged> l tor

tor:  torus (TOR)
        V (4.91624, -32.8022, 31.7118), r1=25.4 (A), r2=5.08 (H)
        N=(0, 1, 0)
        A=(0, 0, 1)
        B=(1, 0, 0)
        vector to inner edge = (0, 0, 20.32)
        vector to outer edge = (0, 0, 30.48)
mged> q

Doing a little vector math we find the vertex of the ``ellipse.s'' as it is found in ``all.g'' is at:

Figure 8. 

ell.mpg

Now we subtract this from the origin of ``tor'' to get a vector that will translate ``ellipse.s'' to the center of the torus. This vector is scaled by a factor to 2 to get a ``net displacement'' vector for the ellipsoid.

Figure 9. 

We can now create a new interpolation table with motion values to be interpolated. The ellipse will start moving half a second after the sequence starts. It will reach its destination half a second before the end of the sequence. Assuming that the time channel is being specified in units of seconds, the following table results:

chans.ellanim

		0.5     0          0       0
	7.25  -51.78792  -75.7002 -6.72896

The interpolation is done much as it was in Section 2. The data from ``chans.ellanim'' is read into interpolation channels 8, 9, and 10 within tabinterp. The use of linear interpolation ensures that the ellipse will move at a constant rate to its destination.

  
% tabinterp << EOF > chans.all
file chans.vsize 0;
file chans.eyept 1 2 3;
file chans.orient 4 5 6 7;
file chans.ellanim 8 9 10;
times 0 8 3;
interp spline 0 1 2 3 4 5 6 7;
interp linear 8 9 10;
EOF 
cmd: file chans.vsize 0
chan 0:  File 'chans.vsize', Column 1
cmd: file chans.eyept 1 2 3
chan 1:  File 'chans.eyept', Column 1
chan 2:  File 'chans.eyept', Column 2
chan 3:  File 'chans.eyept', Column 3
cmd: file chans.orient 4 5 6 7
chan 4:  File 'chans.orient', Column 1
chan 5:  File 'chans.orient', Column 2
chan 6:  File 'chans.orient', Column 3
chan 7:  File 'chans.orient', Column 4
cmd: file chans.ellanim 8 9 10
chan 8:  File 'chans.ellanim', Column 1
chan 9:  File 'chans.ellanim', Column 2
chan 10:  File 'chans.ellanim', Column 3
cmd: times 0 8 3
cmd: interp spline 0 1 2 3 4 5 6 7
cmd: interp linear 8 9 10
performing interpolations
writing output
%

An appropriate template such as the one below must be created for use with tabsub.

% cat ell.proto
viewsize @0;
eye_pt @1 @2 @3;
orientation @4 @5 @6 @7;
start @(line);
clean;

anim all.g/ellipse.r matrix rmul
  1 0 0 @8
  0 1 0 @9
  0 0 1 @10
  0 0 0 1;
end;

% tabsub ell.proto chans.all > ell.rtanim

Note the use of the ``clean'' command to rt at the beginning of each frame in the template. This is required after the ``start'' for each frame in rt animation scripts which use the ``anim'' command. This command tells rt (librt actually) to forget any accumulated animation matrices, thereby restoring the geometry to the form it has in the database.

We can preview the path that the ellipse will take by creating a plot file which can be used as an overlay in mged. (In version 4.2 of BRL-CAD and beyond the animation sequence can also be viewed using the mged ``preview'' command.)

% awk '{print $2+30.8102 " " $3+5.0479 " " $4+35.07628}' chans.ellanim | \ xyz-pl > ell.pl % mged moss.g

attach (nu|tek|tek4109|ps|plot|sgi|X)[nu]? sgi
ATTACHING sgi (SGI 4d)
Gary Moss's "World on a Platter" (units=mm)
mged> e all.g
408 vectors in 0.459896 sec
mged> overlay ell.pl
db_lookup:  could not find '_PLOT_OVER*'
mged>

The ``overlay'' command creates pseudo entries of the form ``_PLOT_OVERLAY_'' in the version of the database in memory. These are used to store the vectors of the overlay. They are never actually objects in the geometric database on disk. The next time the overlay command is given, the ``_PLOT_OVER*'' objects are removed and re-created. As a result, the message:

db_lookup: could not find '_PLOT_OVER* is not a cause for concern.

Once again, a postage stamp animation can be created to view the positioning and motion of the camera and objects.

% rt -M -s200 -o ell.pix moss.g 'all.g' >& ell.log < ell.rtanim
% mv ell.pix ell.pix.0
% pixtile -s 200 -S1024 ell.pix | pix-fb -h
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
% fbanim -h -p 5 200 25 3

Figure 10. 

The pixtile program creates a mosaic of the smaller image on the framebuffer. The resultant framebuffer image is animated using the fbanim program.

With the animation tables used in the moving ellipsoid example from Section 3, we can create all the frames for a full-speed videotape recording. It is important to avoid file name conflicts between the images created for the postage stamp animation and the frames for the video. Either tell rt to create frames with different names, or the postage stamp frames must be renamed or removed before computing the video frames. Failure to do so will cause rt to believe that the postage stamp frames are completed frames for the video animation. In the following example, the frames will be created with the name ``ell_vid.pix'' to avoid conflict.

The arguments to the ``times'' command of tabinterp is slightly different from the previous example. The difference is the number of frames per integer time step (seconds) is increased from 3 to 30.

% tabinterp << EOF > chans.all
file chans.vsize 0;
file chans.eyept 1 2 3;
file chans.orient 4 5 6 7;
file chans.ellanim 8 9 10;
times 0 8 30;
interp spline 0 1 2 3 4 5 6 7;
interp linear 8 9 10;
EOF

cmd: file chans.vsize 0
chan 0:  File 'chans.vsize', Column 1
cmd: file chans.eyept 1 2 3
chan 1:  File 'chans.eyept', Column 1
chan 2:  File 'chans.eyept', Column 2
chan 3:  File 'chans.eyept', Column 3
cmd: file chans.orient 4 5 6 7
chan 4:  File 'chans.orient', Column 1
chan 5:  File 'chans.orient', Column 2
chan 6:  File 'chans.orient', Column 3
chan 7:  File 'chans.orient', Column 4
cmd: file chans.ellanim 8 9 10
chan 8:  File 'chans.ellanim', Column 1
chan 9:  File 'chans.ellanim', Column 2
chan 10:  File 'chans.ellanim', Column 3
cmd: times 0 8 30
cmd: interp spline 0 1 2 3 4 5 6 7
cmd: interp linear 8 9 10
performing interpolations
writing output
The new prototype contains an invocation of the ``framedone.sh'' script to process each image as it is completed.
% cat ell.proto.2
viewsize @0;
eye_pt @1 @2 @3;
orientation @4 @5 @6 @7;
start @(line);
clean;
anim all.g/ellipse.r matrix rmul
  1 0 0 @8
  0 1 0 @9
  0 0 1 @10
  0 0 0 1;
end;
! framedone.sh ell_vid.pix @(line);

% tabsub ell.proto.2 chans.all > ell.rtanim It is likely to be quite a while before all the images are computed. The rendering should be done as a batch job or detached process using a script similar to the ``ell2.rt'' script below. % cat ell2.rt

#!/bin/sh
rt -M -w1440 -n 972 -V1440:972 -J1 -o ell_vid.pix moss.g all.g 2>> ell.log < ell.rtanim

% ell2.rt & For instance it took almost ten hours to compute and process the 241 1440x972 images of our trivial geometry for an 8 second animation on a Silicon Graphics 4D/280. The final compressed images occupied approximately 39 MB of disk space.

Once all the frames have been computed it is time to record them onto videotape. There are a variety of tools and techniques for accomplishing this task. See [Kennedy91] for a description of some of the variety of equipment which has been used at the Army Research Laboratory for this purpose. Only one of these techniques will be covered here.

The Abekas A60 digital video disk stores 25 seconds or 750 frames of video on a high-performance disk. Frames on this disk can be played at full video speed. The A60 provides video output as both CCIR 601 digital video and an analog signal that is either R,G,B or Y,R-Y,B-Y. This analog signal can be readily converted to a format for input to a video tape recorder.

Frames can be stored on disk either from a video input or by loading individual frames through an ethernet interface. It is the latter which makes the device particularly useful in creating computer-generated video productions.

Under BRL-CAD, access to the Abekas A60 is achieved through the framebuffer library. *|* Conceptually, the A60 has 750 unique framebuffers. The framebuffer device ``/dev/ab'' supports the A60. There are two very important options to this particular framebuffer. The first specifies the host address of the A60 on the TCP/IP network. The host name or address for the A60 is specified by an at-sign ``@'' followed by the appropriate name or address. For example, the framebuffer device ``/dev/ab@vidisk'' specifies that an A60 connected to the network with the host name of ``vidisk'' should be used. The individual frame (or framebuffer) within the A60 is specified by a sharp-sign ``#'' followed by the integer frame number. Thus the full specification of a framebuffer device might be:

/dev/ab@vidisk#27

This specifies the frame 27 on the Abekas A60 with the host name ``vidisk''. This can be used with any of the framebuffer utilities, such as the ``pix-fb'' utility shown here:

% pix-fb -F/dev/ab@vidisk#27 -w 720 -n 486 ell_vid.pix.27

This loads the image file ``ell_vid.pix'' into frame number 27 on the A60 called ``vidisk''.

Two more options worth noting are the ``o'' and ``v'' options to the A60 framebuffer device. The ``o'' option indicates that this is an ``output only'' access of the framebuffer. The overhead of retrieving the image already in the framebuffer is skipped when this option is specified. The ``v'' option turns on verbose logging of the access to the framebuffer. This is primarily useful to enable the user to watch the progress of the framebuffer access.

This can be generalized into a shell loop to load the 241 ``ell_vid.pix'' images into the A60.

% mv ell_vid.pix ell_vid.pix.0
% foreach i (`loop 0 240`)
? pix-fb -F/dev/abov@vidisk#$i -w 720 -n 486 ell_vid.pix.$i
? end

In this example successive images are loaded into successive video frames (framebuffers) in the A60. As each frame is loaded, the user will see output indicating that the image is converted to YUV format and then loaded into the A60.

Once the entire sequence (or a 25 second segment) has been loaded into the A60, the sequence can be played and captured using a video tape recorder. A collection of 25 second video sequences can be edited together using a television studio or post-production facility to create longer sequences.

Visualization of models in BRL-CAD need not be restricted to viewing static images. With the use of tabinterp and tabsub the task of creating motion picture sequences becomes quite manageable. The result is that models can be viewed from a variety of positions as they move, change, and evolve over time.

The tools discussed represent only one conceptual approach to the problem of specifying frames to be generated for an animation sequence. With the advent of ubiquitous desktop graphics displays, it should be possible to create the sequences using a more visual and interactive approach. Creating tools for this remains an area for further work.

The authors wish to thank Mike Muuss and Phil Dykstra for creating the animation capabilities within rt and mged. The authors also thank Mike Muuss for providing the documentation for tabinterp and tabsub that appears in Appendix A and Appendix B respectively.