\documentclass[runningheads]{cl2emult}
\usepackage{graphicx}
\usepackage{amsfonts}
\usepackage{makeidx}  % allows index generation
\usepackage{multicol} % used for the two-column index
\usepackage{cropmark} % cropmarks for pages without pagenumbers
\usepackage{ulem}\normalem  % better underlining; not needed for final version
\makeindex            % used for the subject index
                      % please use the style sprmidx.sty with makeindex

\begin{document}
%%%%%%%%%%%%%%%%%%% All these definitions are placed inside the
%%%%%%%%%%%%%%%%%%% \begin{document} ... \end{document}
%%%%%%%%%%%%%%%%%%% to avoid interfering with anyone else's paper

\marginparwidth18mm \marginparsep1mm \let\mgp=\marginpar

%%%%Here are the def's we want to change for the final version
\def\marginpar#1{\mgp{\raggedright \tiny #1}} %Use this to show marginpars
%\def\marginpar#1{}   %Uncomment this to hide marginpars in final version
\def\datestamp{: \today} % for draft with timestamp
%\def\datestamp{} % for final version
\def\ixhelp#1#2{{\index{#1}\uline{#2}}} % use this for draft with underlines
%\def\ixhelp#1#2{{\index{#1}{#2}}} % use this for final version

% Help with indexing
\def\dfn#1{{\em\ix{#1}}}
\def\ix#1{\ixhelp{#1}{#1}}
\def\ixname#1#2{\ixhelp{#2, #1}{#1 #2}}

\def\evol/{Evolver}
\def\ov/{{\sl The Optiverse}} \def\hwm/{halfway model}
\def\cave/{{\small{CAVE}}} \def\vss/{{\small{VSS}}} \def\off/{{\small{OFF}}}
\def\sgi/{{\small{SGI}}} \def\avn/{{\small{AVN}}} \def\rtica/{{\small{RTICA}}}
\def\avnsc/{{\sc avn}}  %for use in environments of nonstandard size
\def\ntsc/{{\small{NTSC}}} \def\siggraph/{{\small{SIGGRAPH}}}
\def\ncsa/{{\small{NCSA}}}

\def\fig#1{Fig.~\ref{fig:#1}} \def\cfig#1{Color Plate~\ref{fig:#1}}
\def\endf#1#2#3{\caption[#1]{{\small #2}} \label{fig:#3} \end{figure}}
\def\hfig#1#2{\includegraphics[height=#2in]{figs/#1}}
\def\figh#1#2#3#4{\begin{figure}[tbp]
 \centerline{\hbox{\hfig{#1}{#2}}}\endf{#3}{#4}{#1}}
\def\figtwo#1#2#3{\begin{figure}[tbp]
 \centerline{ \hfig{#1A}{2} \hfil \hfig{#1B}{2} }
 \endf{#2}{#3}{#1}}
\def\figthree#1#2#3{\begin{figure}[tbp]
 \centerline{ \hfig{#1A}{1.5} \hfil \hfig{#1B}{1.5} \hfil \hfig{#1C}{1.5} }
 \endf{#2}{#3}{#1}}

\title*{Making the Optiverse:\protect\newline
        A Mathematician's Guide to \avnsc/, \protect\newline
        a Real-Time Interactive Computer Animator}
\toctitle{Making the Optiverse:\protect\newline
          A Mathematician's Guide to \avnsc/,
          a Real-Time Interactive Computer Animator}
\titlerunning{Making the Optiverse\datestamp}

\author{George K. Francis\inst{1}
   \and Stuart Levy\inst{2}
   \and John M. Sullivan\inst{1}}
\authorrunning{Francis, Levy and Sullivan\datestamp}

\institute{Department of Mathematics,
           University of Illinois, Urbana, IL, USA 61801
      \and National Center for Supercomputing Applications,
           University of Illinois, Urbana, IL, USA 61801}

\maketitle

\begin{abstract}
Our 1998 video \ov/~\cite{optiverse}
illustrates an optimal sphere eversion, computed automatically
by minimizing an elastic bending energy for surfaces.
This paper describes \avn/, the custom software program we wrote to
explore the computed eversion.  Various special features allowed
us to use \avn/ also to produce our video: it controlled the camera path
throughout and even rendered most of the frames.
\end{abstract}

\section{Introduction and History}

A \dfn{sphere eversion} is a mathematical process of turning a sphere
inside-out by a smooth deformation, or \ix{regular homotopy}.
We allow the surface to develop self-intersections, but at every
moment it must remain a smoothly immersed sphere with bounded curvature.
In 1959, \ixname{Stephen}{Smale}~\cite{Smale} proved abstractly 
that eversions were possible, but it took years for other mathematicians 
to discover explicit eversions, which at first were illustrated 
by hand-drawn pictures. 
In 1977 \ixname{Nelson}{Max} made a computer-animated film~\cite{Max},
realizing \ixname{Bernard}{Morin}'s 1967 vision of a particularly persuasive
eversion.  Over four decades, everting the
sphere has remained a rewarding problem in mathematical visualization and 
computer graphics, especially because of the challenge of animating a 
self-intersecting surface.

Our 1998 video \ixhelp{Optiverse, The}{\ov/}~\cite{optiverse}
illustrates an optimal eversion,
computed automatically by minimizing an elastic bending energy for surfaces.
We have described various aspects of this work in earlier papers.
Our computations~\cite{FSetal-minimax,CSE} of the sphere eversion were
performed in \ixname{Ken}{Brakke}'s \dfn{\evol/}~\cite{Bra-evol} using code
to minimize the \dfn{Willmore energy}~\cite{HKS-willmore}, an elastic
bending energy for surfaces.

Following Morin's tradition, we use the concept of a \dfn{\hwm/}, 
an immersed sphere (like those in \fig{hwms})
which is halfway inside-out in the sense that a symmetry
of the surface will exchange its two sides.
Our \hwm/ is a saddle critical point for
the bending energy; perturbing it off the saddle one way or the other,
and letting the surface flow downhill, we reach the round sphere, the
global minimum for energy.  To get an eversion, we start with the
round sphere, play this descent backwards to reach the \hwm/,
then apply the symmetry and play the descent forwards, now
down the other side of the saddle. 
%
\figtwo{hwms}{Halfway models for minimax eversions}
{These are the \hwm/s for the two simplest minimax eversions.
The Boy's surface (left), an immersed projective plane with three-fold
symmetry and a single triple point, minimizes Willmore's elastic
bending energy.  The figure actually shows an immersed sphere
double covering Boy's surface, with its two (oppositely-oriented)
sheets pulled apart slightly.  The Morin surface shown (right) also
minimizes Willmore energy; it has a four-fold rotational symmetry
which reverses orientation, exchanging the lighter and darker sides
of the surface.}

The \dfn{minimax eversion} we computed turns out to be equivalent
to one of Morin's original eversions.
Equivalence means they have the same sequence of topological events,
as illustrated in \fig{bivtile}.
Using the minimax technique, we can compute
tobacco-pouch eversions~\cite{Francis-tobacco}
with any order of rotational symmetry around an axis.
Our energy-minimization procedure gives these a more pleasing shape 
than earlier realizations of the Morin eversions, which were all
designed by hand even if executed on a computer.
For more information about the history of sphere eversions,
see~\cite{isama} and the references there,
especially~\cite{Levy-MW} and Chapter~6 of~\cite{Francis}.
%
\figh{bivtile}{4.9}{Two-fold eversion montage}
{This minimax sphere eversion is a geometrically optimal way
to turn a sphere inside out, minimizing the elastic bending
energy needed in the middle of the eversion.
We start at the top with a round sphere, and proceed clockwise.
Down the right-hand side we see the creation first of two double-curves,
and then of a pair of triple points.  (Another pair is created at
the same time in back; the eversion always has two-fold rotational
symmetry.)  Across the bottom, we go through the Morin \hwm/,
a critical point for the Willmore bending energy for surfaces whose
four-fold rotation symmetry interchanges its inside and outside surfaces.
The roles of the dark and light sides of the surface are then
interchanged, and up the left column, we see the double-curves disappear
one after the other, leading to the inside-out round sphere.
In the center, we shrink each triangle in the surface to a
quarter of its normal size, to better examine
the self-intersection curves just when
pairs of triple points are being created.}

Animations are a superb tool for communicating three-dimensional geometry,
especially when this changes in time through a homotopy~\cite{metareal}.
The current paper describes our custom software, \avn/.
We wrote this \ix{Real-Time Interactive Computer Animator} (\rtica/)
to explore our computed eversions and to understand their geometry
and topology visually.

The program \avn/ controls the visualization and animation of the
\dfn{topes} (triangulated models representing stages of the homotopy)
which have been precomputed by the
\evol/.  Originally the \rtica/ ran on \sgi/ workstations,
as in our demo~\cite{KorBrown} at Supercomputing'95.
There, we showed that a remote supercomputer could calculate the topes
for an eversion in real time and send the data over a high-speed network.
At the other end, \avn/ drove the animation in a
\cave/ virtual environment~\cite{CruzSan}, showing more
of the homotopy as the computation progressed.
Recent improvements in computing hardware and
standard graphics libraries have enabled \avn/ to be
rescalable~\cite{rrtica}: it now runs well even on laptops.

Our \rtica/ \avn/, though built for interactive exploration,
also contains features that made it the perfect tool for
generating our video \ov/.  To achieve \ix{cinematographic unity} in
our short movies we employ a single camera shot: a continuously
changing view of our subject and its metamorphoses. 
We used \avn/ to plan and execute the splined camera path.
This meant that when we needed to make a 2-minute
\siggraph/ cut~\cite{ov-SIGGRAPH} of our 7-minute video,
we could do so without any abrupt transitions simply by
editing the trace files of keyframes and making a new continuous spline.

To show a sphere eversion, a variety of rendering styles are needed because
no single method provides all the useful visual information about a 
nonintuitive phenomenon like self-intersecting surfaces.
The frames for most of the scenes in \ov/ were computed by \avn/ itself;
for those requiring transparency, \avn/ controlled the rendering
in Renderman.

The mathematician shares one significant attribute with the artist:
both prefer to make their own tools rather than limit their creativity 
to the constraints of ready-made tools available ``off the shelf''. 
This paper describes the features and rendering styles we put into our
real-time interactive animator in order to best display sphere eversions.
We hope these will provide a model for builders of similar
geometric animation software.

\section{The \avnsc/ Interface}

Like most \rtica/s developed at the University of Illinois,
\avn/ is written to display graphics either
on a workstation monitor or in the \cave/. The graphical output is 
(almost) the same either way, but the user's input is necessarily a bit 
different.  Here, we will describe primarily how \avn/ is controlled
from a workstation keyboard and mouse.  In the \cave/, the vastly
more flexible wand replaces the mouse, but chords played on the
three wand buttons must substitute for a limited subset of keyboard functions.
There are several command-line options which can be invoked when starting \avn/;
we will not discuss these here, but
many of them are designed to optimize its use for automatic rendering.

\subsection{Input gadgets}

Since the purpose of an \rtica/ is to manipulate a running animation, 
we prefer to have the controls be visually as subtle as possible.
Instead of the widgets (like pull-down menus and separate control 
windows) found in a typical graphical user interface, we exclusively
use keyboard shortcuts, which we call \dfn{gadgets}.
A touch typist can control the \rtica/ while continuing to
watch the animation.  With this scheme, the entire visual system
is devoted to observing the homotopy; a separate cognitive
channel is dedicated to the controls.
Although keyboard controls may have a slightly steeper
learning curve for novices, \avn/  provides a mnemonic help screen 
to explain the commands.  There is also an unobtrusive \dfn{heads-up display}
showing important parameter information through text
rendered directly in the graphics window, as shown in \fig{graffiti};
this display can be switched off when desired.
%
\figh{graffiti}{3.5}{The heads-up display}{The initial screen of \avn/
shows the \hwm/ of the eversion, with slight gaps between the triangles.
Values of various parameters are drawn in the heads-up display.}

The ease of use of our keyboard gadgets comes from the fact
that each key is devoted to a single parameter, and all gadgets behave
in one of a few simple ways.  For a discrete parameter taking two or
more possible values, the keypress cycles forward through the loop.
For a real-valued parameter, the keypress increases it by
a fixed amount (either linearly or exponentially, as appropriate).
In either case, the same key shifted has the opposite effect,
cycling backwards or decreasing the real number.
Any parameter (discrete or continuous)
can be set directly to a desired value by typing
a decimal number before pressing the associated key. 

There are \dfn{toggles} (two-element cycles) which
turn on or off, for instance, the binocular-stereo mode,
the heads-up display, and the motion through the homotopy.

An example of a continuous gadget is the \dfn{nose separation},
meaningful only in stereo mode.  It is normally a positive value
for cross-eyed stereo, and must be adjusted suit the viewing conditions
around any given monitor.  Keypresses {\tt n}/{\tt N} change
the nose by a constant factor.  But to switch to wall-eyed stereo,
the key sequence {\tt -.06n} will set the nose to be negative,
from which point it can again be adjusted exponentially.

In \avn/, our other \dfn{optical gadgets} control
the camera's projective transformation
in the way we prefer; instead of directly using the parameters
that must be supplied to the $\textrm{\ix{Frustum}}(-x,x,-y,y,n,f)$ command in
the standard graphics library OpenGL, we use
$$\textrm{Frustum}(-\rho \zeta, \rho \zeta, -\zeta, \zeta, \omega \zeta, f).$$
Here, $\rho$ is the aspect ratio of the viewing window, which is computed
automatically whenever the window is resized;
$\omega$ is the focal distance (as for a camera lens);
$f$ is the far clipping plane;
and $\zeta$ is an abstraction suggesting the observer's size relative
to the object being viewed.

Increasing $\zeta$ alone will not affect the perspective of the image drawn;
it only affects the near clipping plane.  Using this clipping, we can
either fly through a small opening in the surface or recreate the effect of
transparent patches (the \dfn{windows} of~\cite{Francis}) which reveal 
hidden structural details.  To isolate the neighborhood of an especially 
interesting feature we maneuver into place
a separate resizeable cubical \ix{clipping box}.
\figthree{triple}{Clipping box}
{Using the clipping box to examine the neighborhood of a triple point.}

\subsection{Rendering styles}

The \dfn{rendering gadgets} control the appearance of the surface.
Our sphere eversions are computed using triangulated approximations
to smooth surfaces.  We like to display these triangles, to emphasize
the discrete nature of the computations.  (In a binocular stereo, 
this also provides more edges for the viewer's eyes to lock onto.)  
We thus never use smooth shading.

When turning a sphere inside-out, we want to distinguish the two sides
of the surface, so we use different \ix{color ranges} (orange and blue).
But in order to most clearly
see self-intersections, the exact color of any triangle within
its range is determined by its normal vector, in particular the
vertical component along the symmetry axis.  (These colors do not stay
fixed to particular triangles through the homotopy -- indeed the
triangulation of the sphere is not fixed -- but instead reflect
the spatial orientation of the triangle at a given time.)
Thus, at the halfway stage in the Morin eversion, the outward-facing
sheets near the quadruple are colored yellow and purple, while those near
the opposite isthmus point are red and indigo.  An individual triangle's
two sides range in color from yellow/indigo to red/purple.
\marginpar{If we are allowed a color figure, perhaps the color
version of bivtile should go here, instead of the BW version above.}

As mentioned, we find that complicated immersed surfaces are
best viewed with a number of different techniques for revealing
the internal structure.  It is cumbersome to handle transparency 
correctly with the alpha channel in OpenGL: we would have to depth-sort
the facets and subdivide those that intersect.
Thus for the transparent scenes in \ov/ (see \fig{transp},
we instead use the custom \ix{soap-film shader} for Renderman
originally described in~\cite{leon}.
%
\figh{transp}{4.9}{Transparent eversion montage}
{This is the same minimax eversion shown in \fig{bivtile},
but now rendered transparently like darkened soap film.
Again starting from the round sphere (top, moving clockwise),
we push the north pole down, then push it through the south pole (upper right)
to create the first double-curve of self-intersection.
Two sides of the neck then bulge up, and these
bulges push through each other (right) to give the second double-curve.
The two double-curves approach each other, and when
they cross (lower right) pairs of triple points are created.
In the \hwm/ (bottom) all four triple points merge at
the quadruple point, and five isthmus events happen simultaneously.
The second half of the eversion (left) proceeds through exactly
the same stages in reverse order, after making a ninety-degree twist.
The large central image belongs between the two lowest ones on the
right, slightly before the birth of the triple points.}

The soap-film shader has the very important feature that,
as for physical films,
the surfaces are less transparent when viewed edge-on.
But it does not exactly duplicate soap-film optics.
In the sphere eversion, it is important to note the surface self-intersections.
True soap-films may meet along triple junction lines
(Plateau borders), which show up naturally in a rendered view.
But soap films never cross, and indeed
an intersection of fully transparent surfaces is almost invisible.
Thus the soap film in the transparent scenes in \ov/ was artificially darkened:
it absorbs about half the incident light rather than none.

We wrote a Perl script to convert an \avn/ trace of camera motions
into a sequence of Renderman input files that recreate the same moves.
Although the actual rendering was slower, we were able to use the
same method (described below) for planning and editing these scenes
as for those rendered directly by \avn/.

For interactive use, \avn/ provides other ways to see internal
structure.  It can shrink each triangle (towards its
barycenter) by any factor, leaving gaps between the triangles.
Conversely, \avn/ can draw just the borders of each triangle, leaving
triangular windows in a framework of mullions with a distinctive,
aesthetic appeal, as in \fig{styles}.
%
\figtwo{styles}{Gapped halfway model and framework gastrula}
{We can use \avn/ to display internal structure by shrinking
each triangle, as in the \hwm/ (left) to focus on the elaborate
double locus, or by drawing just a triangular framework,
as we see in the late gastrula stage of the eversion (right).}

A topological understanding of the sphere eversion requires
seeing the changes in the \dfn{double locus}, the set of self-intersection
curves of the sphere.  To aid in its visualization, the input
files to \avn/, which consist of triangle lists in binary \off/ form
for each tope, are supplemented with precomputed self-intersection
curves~\cite{CSE}.  Our \rtica/ renders a smoothed tube around the double
locus, whose radius is controllable.  When the gaps between
the displayed triangles are large, the double locus becomes more
prominent visually.  Additionally, \avn/ can turn off the display
of the triangles altogether, or display only those triangles near
to or far from the double locus.

Further, \avn/ allows mapping a texture onto each triangle of
an everting sphere.  In this manner, we can show floating dots at the
centers of the triangles, or other pleasing patterns.
Using this feature, \avn/ was used to render scenes suggestive of
space-time quantum fluctuations in the early universe,
for an exhibit which opened in summer of 2001 at the \ix{Big Bang}
theater at the Hayden Planetarium in New York.

\subsection{Sonic output}

Another aspect of the user interface in \avn/ is the \ix{parambient
music} which it plays, alerting the viewer to interesting
events and features.  We will not attempt here to give more than
the briefest outline of how this works.

The music for \avn/ was composed for us
by \ixname{Camille}{Goudeseune} using the \ncsa/'s
\dfn{Virtual Sound Server}~(\vss/).
His coinage \emph{parambient} suggests ambient music controlled
by various parameters.  The music has a steady beat and
harmony, but subtly changes character
to reflect the changing values of the parameters.  In \avn/
the basic parameter is the bending energy of the current tope.
This is of course lowest for the round spheres at either end
of the eversion, and highest for the \hwm/.

Additionally, \ix{topological events} in the eversion (creation or
annihilation of double curves or triple points, for instance)
trigger distinctive clangs of bells in the music.  You cannot miss
being reminded that something special has happened.

This parambient music is generated in real time by \vss/, in response to
whatever interactive tour you choose through the eversion.
Just as the rendering of video frames was performed off-line by \avn/ from
trace files, Goudeseune took the same trace files (showing the
fixed tour that \ov/ takes through the eversion) and used \vss/ off-line
to render a high-quality audio track for our video.

\section{Timing, Navigation, Tracing, and Splining}

Animators need a notion of timing in order to make events
happen in sequence.  We use \avn/ for interactive exploration
(on machines of widely varying speeds), for tracing and replaying
fixed tours that can be edited by hand, and for rendering high-quality
video sequences.  For this reason we have built a flexible timing 
scheme into \avn/, one based either on real wall-clock time
or on a fake time that fixes a desired frame rate.
When using \avn/, you watch the everting sphere from
a camera that flies through space, using one of two different
navigation modes.
The \rtica/ also allows you to write selected
interactive commands and changes of state to a trace file.
Our Perl scripts can spline between keyframes in the trace file,
producing a smooth camera path for later playback.

\subsection{Timing modes}

The program \avn/ shows a surface which undergoes severe but
smooth deformations over time (a homotopy),
from the point of view of someone navigating through space
and rotating the surface.
When \avn/ is ready to render a new frame (on the workstation
monitor or the walls of the \cave/), in order to know what to draw,
it needs to know how much time $\Delta t$ has elapsed since the previous frame.
We have found it very useful to have two modes: in the first
$\Delta t$ is the elapsed time (in seconds) on the wall clock, while in the
second it is a fixed value per frame (adjustable by the user).
We call these \dfn{wall-time} mode and \dfn{fake-time} mode, respectively.
In either case, \avn/
sums these elapsed times $\Delta t$ to get its notion of current time,
which is shown on the heads-up display.

Many computer animation programs, by not even considering the issue,
use only fake-time mode.
When they are run on a newer, faster machine, they show homotopies
much too fast, and the navigation controls are much too sensitive.
Less wall-clock time has elapsed on the new machine (which might be rendering
100 frames per second instead of 10), but the \rtica/ makes just as
much change to the display (every $10\;$ms) as it would have
(every $100\;$ms) on the slower machine.
Even on a given machine, the frame-rate you obtain
may vary by a factor of ten as the homotopy proceeds from simpler
to more complicated topes or as you switch between rendering styles.

That is clearly unsatisfactory, and we prefer
to use wall-clock time for most interactive purposes.
Suppose we have set a homotopy speed of 10 topes per
second (meaning that the tope number is advanced
by $10\Delta t$ for each frame) and that the mouse position
controlling navigation corresponds to a rotation rate of 
$48^\circ$ per second (meaning a rotation of $48^\circ\Delta t$ each frame).
Then in wall-time mode,
independent of the computer hardware's rendering speed,
a 300-tope eversion really will take (nearly) 30 seconds
and the rotation will be at the speed of $8\;$rpm.

However, under special circumstances, we switch to fake time.
First, on a computer whose rendering rate is too slow
to present the illusion of continuous motion,
we don't want to make as big a jump between frames as the
time experienced would suggest.  The viewer sees a sequence
of static frames, and may prefer to have a constant change between them,
even if they take variable times to render.

Second, when \avn/ renders frames for later video playback,
we know that the frames will be presented at a fixed rate ($30\;$fps for
\ntsc/).  Thus we need to render them in fake-time mode (with $\Delta t=1/30$),
so that we get the right images no matter how long the rendering takes.

Finally, while we can treat animation time and viewpoint as continuous
quantities, we can't do the same for the precomputed topes.  We cannot
easily produce a model representing an arbitrary point
in the homotopy sequence: since the triangulations of adjacent topes
differ from each other, there is no notion of corresponding vertices
and thus no way to interpolate between topes.
Instead, at each frame \avn/ rounds the desired tope number
to the nearest integer.  This works well unless the tope rate
(in topes per displayed frame) is near but not equal to a small integer,
in which case the uneven motion of the surface can be distracting.
Using fake time here allows the tope rate to be a fixed exact integer,
at the expense of a less accurate connection with wall-clock time.

\subsection{Navigation modes}

There are two principal modes of navigatation in \avn/, flying and turning.
These have evolved from an original idea by \ixname{Glenn}{Chappell}
and \ixname{Chris}{Hartman}, and now serve multiple purposes.
The program views a single (changing) object in space through a movable
camera.  In both modes, a mouse-button (or thumb-button in the \cave/)
controls forward/backward motion of the camera.
(In the \cave/, the camera can also be moved sideways for finer adjustment.)

Also in both modes, the mouse position (relative to the center of the screen)
controls the angular velocity of rotation.  (In the \cave/, the wand
orientation relative to a neutral position controls this rotation.)
The difference between the modes comes in how this rotation is applied.

In \dfn{turn mode}, the rotation is that of the object being viewed.  
It rotates around its own center (or more properly the origin of its 
coordinate system) at the given angular velocity.  If we are looking at 
the center of the object, it stays fixed in our field of view.
In \dfn{fly mode}, on the other hand, the camera rotates about its own
current position, panning across the sky,
so that we might turn our attention away from the object on display
or change the direction of our forward flight.
 
If the camera happened to be at the center of object's coordinate system,
then these two modes would be equivalent: the relative rotation of
camera and object is the same either way.  However, we choose to
draw a fixed firmament of stars (based on an actual star chart),
which we think of as points of light at infinity in different directions.
These rotate across our field of view if we rotate the camera, but
not if we rotate the object.  (Because the stars are infinitely far away,
there is no change in their appearance as the camera is translated.)

Suppose the current camera is facing in a direction $\vec{T}$,
which is also the direction of forward camera motion;
and suppose $\vec{U}\perp\vec{T}$ is the upwards direction
in the present tilt of the camera.
On a workstation console, the mouse gives us only two
degrees of freedom to specify an angular velocity.
We use these to give rotations around axes perpendicular to $\vec{T}$.
In aeronautical terms, rotation around $\vec{U}$ is called \dfn{yaw},
and rotation around $\vec{T}\times\vec{U}$ is called \dfn{pitch}. 
The third possible rotation is a \dfn{roll} around the axis $\vec{T}$.
(In the \cave/, there are three parameters of wand orientation,
which map exactly to pitch, yaw and roll. On the console,
extra mouse buttons allow roll at fixed speed, to the left or right.)

A camera path is naturally a \dfn{framed space curve}; the camera 
orientation gives an orthonormal frame moving along the path. 
For a camera that always moves forward along the direction it faces,
this is an \dfn{adapted frame}: the camera direction equals the 
tangent vector $\vec{T}$ to the curve, as above.
But there is more than one way to adaptively frame a space curve~\cite{Bishop}.
A path generated only by pitch and yaw (avoiding roll)
is framed with zero twist (in its \ix{Bishop frame}).
We feel this produces the nicest camera paths for abstract spaces,
since without roll, objects don't needlessly rotate around the viewing axis.
This is why pitch and yaw are the two rotations
most readily available in our navigation system.

By contrast, \ix{airplane flight} typically uses pitch and roll: the tail
rudder has limited ability to create yaw, and passengers would
not appreciate sideways acceleration.  A path generated with no yaw
is framed with its \ix{Frenet frame}.  Computerized flight simulators
follow this scheme, in contrast to our navigation modes.

Many stages in our sphere eversions have tunnels (see \fig{ear})
and it can be an interesting challenge to fly through such a tunnel
without hitting the surface.
\figtwo{ear}{Tunnel and ear}
{A curved chamber of the everting sphere, opening into an ``\ix{ear}'' ---
inside and outside views.}

Note that most nonmathematical movies show objects on the earth.
Here, yaw and roll are usually coordinated so that the
vertical direction in the image plane always corresponds to
the vertical direction of gravity.  
This requires a particular combination of roll and yaw (and loses meaning
if the camera ever points straight up or down).  These considerations
are not important for a visualization in an abstract isotropic space.

\subsection{Tracing a tour}

When exploring the Optiverse with \avn/, you can leave a trace of
your peregrinations. The resulting \dfn{trace file} can subsequently be
replayed for the purpose of editing your work, entertaining an audience,
or rendering high resolution frames for a video.
When tracing is activated, \avn/ will record the settings of
all user-controlled parameters for later playback.  With continuous
tracing, the camera and object positions are traced each time a
frame is rendered, and other parameters are recorded whenever they are changed.
With keyframe tracing,
the state is saved only when you press a special key.
All entries in the trace files are marked with the current time.

Because the trace files are plain text files, and identify the values
of different gadgets with the same letters that are used interactively
to adjust them, it is relatively straightforward to edit them by hand
or simply concatenate them.  We have also developed Perl scripts which
can, for instance, adjust the timing in a trace file.

When playing back a trace,
the timestamps tell \avn/ how fast to proceed
(in terms of the wall time or fake time in effect at playback).
Most parameters are linearly interpolated in time,
between the recorded values.

We represent rotations as unit \ix{quaternions} (points in the three-sphere),
rather than by orthogonal matrices,
both internally and in the trace file. But we do not, ordinarily, use 
spherical angular interpolation or higher-order spherical splining. 
We interpolate linearly in four-space and then project radially to
the unit three-sphere. This has the happy effect of slightly smoothing
an otherwise sharp corner in a camera path that interpolates preset
keyframes. 

For final video production, we want to use smoother motions.  Typically, we
record keyframes in a trace file, edit it as necessary, and then
run it through a script which computes cubic interpolating splines
(for parameters like tope number as well as camera positions)
and dumps out a more comprehensive trace file with thirty entries
per second, explicitly defining every desired video frame.

When rendering frames for the video, \avn/ renders each frame
(using OpenGL) at twice video resolution, then shrinks the resulting image
to the desired size by averaging adjacent pixels.
In this way, we achieve \ix{antialiasing} for the many straight lines
(borders between triangles) in our pictures.

The combination of all the features we have described made \avn/
an excellent tool for video production as well as interactive
exploration.  In fact, to produce the
video {\sl \ix{Knot Energies}}~\cite{knot-vid},
Sullivan had to make only slight adaptations to \avn/, using its
ability to draw smooth tubes around the double locus to render
evolving knotted curves in space.

%\bibliographystyle{hamsplain}
%\bibliography{vismath}
\begin{thebibliography}{99}
\addcontentsline{toc}{section}{References}

\providecommand{\bysame}{\leavevmode\hbox to3em{\hrulefill}\thinspace}

\bibitem{leon}
Frederick~J. Almgren, Jr. and John~M. Sullivan, \emph{Visualization of soap
  bubble geometries}, Leonardo \textbf{24}:3/4 (1992), 267--271.  Reprinted
  in {\sl The Visual Mind} (M.~Emmer, ed.), MIT Press, 1993.

\bibitem{Bishop}
Richard~L. Bishop, \emph{There is more than one way to frame a curve}, Amer.
  Math. Monthly \textbf{82} (1975), 246--251.

\bibitem{Bra-evol}
Kenneth~A. Brakke, \emph{The {S}urface {E}volver}, Experimental Math.
  \textbf{1}:2 (1992), 141--165.

\bibitem{CruzSan}
Carolina Cruz-Neira, Daniel~J. Sandin, Thomas~A. DeFanti, R.~V. Kenyon, and
  John~C. Hart, \emph{The {CAVE}: Audio-visual experience automatic virtual
  environment}, Communications ACM \textbf{35}:6 (1992), 65--72.

\bibitem{Francis-tobacco}
George Francis, \emph{Drawing surfaces and their deformations: {T}he {T}obacco
  pouch eversions of the sphere}, Math. Modelling \textbf{1} (1980), 273--281.

\bibitem{Francis}
\bysame, \emph{A Topological Picturebook}, Springer, New York, 1987.

\bibitem{metareal}
\bysame, \emph{Metarealistic rendering of real-time interactive computer
  animations}, to appear in {\sl The Visual Mind II} (M.~Emmer, ed.),
  MIT Press, 2002.

\bibitem{KorBrown}
George Francis, John~M. Sullivan, Ken Brakke, Rob Kusner, Dennis Roseman, Alex
  Bourd, Chris Hartman, Glenn Chappell, and Jason Rubenstein,
  \emph{{LATERNA matheMAGICA}},
  in {\sl Virtual Environments and Distributed Computing at SC'95}
  (H.~Korab and M.D.~Brown, eds.), ACM/IEEE Supercomputing'95, 1995.

\bibitem{CSE}
George Francis, John~M. Sullivan, and Chris Hartman, \emph{Computing sphere
  eversions}, in {\sl Mathematical Visualization}
  (H.-C.~Hege and K.~Polthier, eds.), Springer, 1998, pp.~237--255.

\bibitem{FSetal-minimax}
George Francis, John~M. Sullivan, Robert~B. Kusner, Kenneth~A. Brakke, Chris
  Hartman, and Glenn Chappell, \emph{The minimax sphere eversion},
  in {\sl Visualization and Mathematics} (H.-C.~Hege and K.~Polthier, eds.),
  Springer, 1997, pp.~3--20.

\bibitem{HKS-willmore}
Lucas Hsu, Rob Kusner, and John~M. Sullivan, \emph{Minimizing the squared mean
  curvature integral for surfaces in space forms}, Experimental Math.
  \textbf{1}:3 (1992), 191--207.

\bibitem{Levy-MW}
Silvio Levy, \emph{Making Waves: A guide to the ideas behind {Outside In}}, AK
  Peters, Wellesley, MA, 1995.

\bibitem{Max}
Nelson~L. Max, \emph{Turning a sphere inside out}, 1977, narrated film
  (21 min).

\bibitem{Smale}
Stephen Smale, \emph{A classification of immersions of the two-sphere}, Trans.
  Amer. Math. Soc. \textbf{90} (1959), 281--290.

\bibitem{knot-vid}
John~M. Sullivan, \emph{Knot Energies}, in {\sl VideoMath Festival at ICM'98}
  (H.-C.~Hege and K.~Polthier, eds.), Springer, 1998,
  narrated video (3 min).

\bibitem{isama}
\bysame, \emph{``{T}he {O}ptiverse'' and other sphere eversions},
  in {\sl ISAMA 99}, The International Society of The Arts,
  Mathematics and Architecture, Univ. of the Basque Country,
  1999, pp.~491--497.  Also available as \mbox{arXiv:math.GT/9905020}.

\bibitem{rrtica}
\bysame, \emph{Rescalable real-time interactive computer animations},
  in {\sl Multimedia Tools for Communicating Mathematics},
  Springer, 2001, proceedings
  of the November 2000 conference in Lisbon, to appear.

\bibitem{optiverse}
John~M. Sullivan, George Francis, and Stuart Levy, \emph{The {O}ptiverse},
  in {\sl VideoMath Festival at ICM'98} (H.-C.~Hege and K.~Polthier, eds.),
  Springer, 1998, narrated video (7 min).  See also
  \mbox{http://new.math.uiuc.edu/optiverse/}.

\bibitem{ov-SIGGRAPH}
\bysame, \emph{The {O}ptiverse}, in {\sl SIGGRAPH Video Review},
  Electronic Theater vol.~125, ACM--SIGGRAPH, 1998, narrated video (3 min).

\end{thebibliography}

%INDEX%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\addcontentsline{toc}{section}{Index}
\flushbottom
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}
