Rotating animations in MMA
- To: mathgroup at smc.vnet.net
- Subject: [mg2608] Rotating animations in MMA
- From: rustybel at foothill.net (Russell Towle)
- Date: Mon, 27 Nov 1995 21:35:45 -0500
Here is an example of the code I use to produce animations.
Needs["Graphics`Shapes`"] (*I read in this file to use the embedded
functions RotateShape and TranslateShape*)
(*Here is code to produce a right prism; the prism is regular, i.e., has
square lateral faces, when height is set to 1. It is centered on the
origin*)
Prism[n_Integer,height_] :=
Block[{d=((2*Sin[Pi/n])*height)/2},
Graphics3D[{N[Table[
Polygon[{{Cos[2Pi i/n], Sin[2Pi i/n], -d},
{Cos[2Pi (i+1)/n], Sin[2Pi (i+1)/n], -d},
{Cos[2Pi (i+1)/n], Sin[2Pi (i+1)/n], d},
{Cos[2Pi i/n], Sin[2Pi i/n], d}}],
{i, n}]],
Polygon[Table[N[{Cos[2Pi i/n],Sin[2Pi i/n],-d}],{i, n}]],
Polygon[Table[N[{Cos[2Pi i/n],Sin[2Pi i/n],d}],{i, n, 1, -1}]]}]]/;
n > 2
Prism[n_:12, height_:1] := Prism[n, height]
(*preview the object to be animated, assigning it a name; I usually use a
single letter, like g, but that's immaterial. Display the object with
Axes->True so that you can get an idea of what the PlotRange must be to
show all of it.*)
object=Show[Prism[12,6],
Boxed->True,
Axes->True,
ViewPoint->{1.199, -1.242, 1.010}]
(*Here is the Do loop which produces the animation frames. The iterator
specification is last; it is the variable i. My first step is to preview
the object, by setting the beginning and end of the loop to zero. Only one
frame is generated. If my PlotRange has been set properly, the entire
object is visible. I set PlotRange by choosing the largest dimension of
the object, dividing by 2, adding a little bit, and giving this value a
name, say, r. The prism above extends 3 units above and below the xy
plane, its largest dimension is 6, and I set r=6.25.
Unless I specify otherwise, the object has inherited the ViewPoint used for
the initial preview. I usually choose a ViewPoint fairly close to the
object, perhaps {0,0,2}. The distance from the object greatly affects its
colors; close ViewPoints result in richly saturated colors, which I like.
I then crop the preview image; on my Macintosh this means selecting it and
dragging its handles with the command key down. I crop it because,
especially when the ViewPoint is close to the object, the perspective
transformation in MMA leaves a rather large margin of empty space around
the object. Since it is the object I want to see, I crop as close as seems
esthetically proper. Then I resize the image, by selecting it and dragging
the handles: I make it larger. Within the constraints of memory, I wish
to have the object be as large as possible. In practice, this often means
merely restoring it to roughly its original size, say, 284 by 284 pixels.
But I have sometimes created larger frames, say, 400 by 480 pixels. But
memory use is a real bugbear. As the frames are created, one sees the
front end memory use meter filling. I very often find myself selecting
large blocks of frames in the middle of the process and then choosing
"Convert to Bitmap PICT," which destroys the Postscipt code but reduces
memory use significantly.
The process above, of cropping and resizing, takes some practice and
forethought. For instance, in the case of a prism which stretches, say, 10
units along the z axis but has a basal radius of only 1 unit, if one
previews at ViewPoint->{0,0,2} and then crops as detailed above, and then
rotates the prism about the x-axis, parts of it will swing out of view.
In an animation such as this the ViewPoint is fixed, and the object
rotates. This prism is symmetrical by a rotation of 60 degrees around the
z axis, so an animation will show continuous smooth motion by creating
frames in, say, 3- or 4- or 5-degree steps. In this case I have set the
iterator i to take steps of 3 degrees. I often find it easier to work in
degrees, rather than radians, when setting up animations. OK. Now, the
RotateShape function accepts three variables, in this form:
RotateShape[object, {zrotation, xrotation, zrotation}]. Don't ask me why
the last one isn't rotation about the y axis. At any rate, for the simple
animation below, only rotation around the z axis is done. I am using
degrees but the rotation matrix wants radians, so I write Degree i. The
iterator is incrementing in steps of 3, therefore the rotation hapens in
steps of 3 degrees. I know that the object will be carried into itself in
60 degrees, since it is a hexagonal prism. Since the iterator starts
counting at 0, I must stop counting at 57. Then, when I double-click any
frame to initiate animation, and the MMA animation default is in place, the
frames will show smooth, continuous rotation, since the first frame (when
i=0) will be displayed immediately after the 20th frame (when i=57). All
this is only to say that, in this case, the iterator specification will
look like {i,0,57,3}.
20 frames of a size such as 280 by 280 pixels will usually be produced
without memory problems on a typical platform. Of course, for animation,
the more RAM the better.
Where too little RAM may easily become a problem is when more complex or
less symmetrical objects are involved, or when more complex rotations are
involved. So far we have only rotated the hexagonal prism about its axis
of symmetry, and have only had to step through an interval of 60 degrees.
However, we might wish to rotate the axis of symmetry itself, while
rotating the prism about this axis. It requires a rotation of 180 degrees
to carry the prism into itself, in this case. We may suddenly realize that
a step of 3 is too small; we switch to 4, 5, even 6, to reduce the number
of frames. However, for now, stick with 3. Now, instead of 20 frames, we
need 60 frames. We write RotateShape[object, Degree i, Degree i, 0]. The
iterator now must be {i, 0, 177, 3}. I am using a Mac with 64 MB available
to MMA, and usually create frames around 320 pixels square. If the forms I
animate are not too complex, I can sometimes allocate much more memory to
the front end and let the kernel struggle along with just as little as
possible. Of course, one can also proceed in stages: First set the
iterator like this: {i, 0, 57, 3}; then save the frames to a separate
file, delete, and set the iterator like this: {i, 60, 117, 3}; save frames,
delete, then {i, 120, 177, 3}. When all the frames have been generated, I
usually use the Convert to QuickTime, with compression algorithm set to
Animation, bit depth to Thousands, quality to Best, and frames per second
to 12.
By combining the RotateShape function with the TranslateShape function
(which were read in from Graphics Shapes), one can create animations of
solar systems of polyhedra, pyramids spinning while orbiting prisms which
in turn spin while orbiting a pentagonal dodecahedron. TranlsateShape can
also be used to close-pack polyhedra which close-pack (like cubes, or
rhombic dodecahedra, or Platonic tetrahedra mixed with octahedra), and then
in an animation one can cause the close-packing to explode, by using an
iterator inside the TranslateShape (just as we used an iterator in
RotateShape, above).
I hope this is helpful. I find animation to be one of the most desirable
and wonderful features of MMA, and would like to see it used to its best
advantage.
If perchance I have made some dreadful error or omission in this, I would
be very pleased to hear about it. Or the same, if anyone makes good use of
these techniques.*)
r=6.25;
Do[
Show[
RotateShape[object,Degree i,0,0],
ViewPoint->{.5,.5,.75},
PlotRange->{{-r,r},{-r,r},{-r,r}},
Boxed->False,
Axes->False,
Background->GrayLevel[0]],
{i, 0, 0, 3}]
Russell Towle
Box 141
Dutch Flat, CA 95714
USA