TITLE: By the Book
NAME: Aaron Gage
COUNTRY: USA
EMAIL: agage@mines.edu
WEBPAGE: http://www.mines.edu/students/a/agage
TOPIC: Transportation
COPYRIGHT: I SUBMIT TO THE STANDARD RAYTRACING COMPETITION COPYRIGHT.
MPGFILE: amgtrans.mpg
ZIPFILE: amgtrans.zip
RENDERER USED: 
    POVray 3.0 for Linux

TOOLS USED: 
    Terrain Maker, rain simulator program written for this animation

CREATION TIME: 

        Design: four weeks
        Rendering: about 900 hours (29240 bogomip hours)

HARDWARE USED: 

        i486DX2/66 running Linux 2.0.28 (185 frames)
        3 Pentium 166 machines running Linux 2.0.29 (remaining frames)
        All machines had 32MB RAM; Pentium CPU time granted by CSM Math Dept.

ANIMATION DESCRIPTION: 


        One of the cheapest forms of transportation does not involve any
physical movement: through a book you can see the marvels of this world
or another.  From Mithil Stonedown to the Elemesnedene of the Elohim,
Lothlorien to the depths of Khazad-Dum, and Devon Ride to the delta at
Tear, great distances can be covered only by flipping a few pages.

DESCRIPTION OF HOW THIS IMAGE WAS CREATED:

        As this was only my second animation, I still had a few things to test
with this submission.  First, I wanted to see how well 1000 frames would fit
under the 3MB limit (and with my time and computer resources).  I wanted to
try to animate a particle system again, learn how to do smooth motion over
time, and also to use some POVray features that I had not before (like
atmosphere).  Keeping this on topic would have been rather hard, but the
wording of the topic description "any sort of device or method for transporting
people or things from one place to another" was general enough for me to get
away with this.

        The entire animation was described within a single .pov file, using
a single clock (in case I suddenly found that the animation was too large
and needed to be done in less frames).  They should be included in the
accompanying .zip file, but here are the basics.

        Most of my camera and object movements were done as trigonometric
functions so that starts and stops would be smooth.  Most of the transitions
(like when the camera passes into the book or out of the cloud bank) were
done by using the clock variable with the transparency channel, so the scene
would become totally visible right as the camera reached it.  I really like
this effect, and will probably use it heavily in the future.

        The book was an object I had used for my first submission to the
IRTC (which I now see a number of flaws with :) with some modifications.
All of the lettering was done for this animation, which took some work,
since you may notice that all of the lines of text inside the book are the
same number of characters long.  The table at the end was also used before,
with some wall panels, as appeared in the Chromatic Scale image.

        There is a minor defect in the halos that create the cloud scene
about a third of the way through.  I tried to correct this by incrementing the
max_trace_level to 15, but even that did not cure it (though it fixed a
number of others).

        The terrain scene was done with Terrain Maker 1.0.  I would have liked
being able to move the camera around during the animation of this part, but I
did not have the time to rigorously piece together the entire landscape so
that this would have worked.  An atmosphere is used to dim the mountains in
back, which also makes the lightning effects much nicer.

        The rain was animated by a program I wrote for that purpose.  I
did a weak implementation of a particle system as I understand them: basically,
I defined a source as a square region under which particles would be generated
and allowed to fall.  The rate of new drops being added to the system increased
throughout the animation, until there were more than 16000 individual drops
being animated per frame.  I had originally envisioned having more than 100K
total drops in the animation, but 96MB of RAM + swap does not go that far.
I suppose that 20 solid seconds of rain might be a bit much, but I am not
too worried about that.

        The bolts of lightning that actually reach the ground were done as
blobs with random paths within a narrow cylinder.  The flashes in the sky
are just very short-lived point light sources.

        The mpeg version of the animation was created with mpeg_encode for
Linux.  I would like to find an encoder that will let me add sound as well,
but for now this is not a concern.  A majority of the animation frames were
rendered on machines that belong to the Colorado School of Mines
Mathematical and Computer Sciences math lab over spring break (when they
are otherwise unused).  These machines were not dramatically faster than
my PC, but three of them together make a difference.  It is fortunate that
they were dual boot to Linux, because my rain simulator must be synchronized
to POVray through user signals executed as Pre_Frame_Commands, and doing this
under another operating system would have been ugly.

        Contrary to my usual paranoia, I plan to have the attached .zip file
include full source to this animation.  If anyone really wants to steal my
work, they'll have to commit about a thousand CPU hours to recreating the
frames that I am burning onto CD.

        Incidentally, I gave a measurement of creation time in terms of
bogomip hours.  For those who are wondering, I will explain.  The Linux
kernel calculates the speed of the system processor when it boots for the
sake of synchronizing the devices.  Bogomips is a 'bogus' MIPS, meaning
that it is not a very scientific way to describe how fast a system is, but
it does at least give a basis for comparison.  Since I ran this animation
on three different configurations of computers, with bogomips ranging from
32 to 199 on those systems, it is difficult to say just how much computer
time was needed.  To answer this problem, I calculated all of the hours each
machine spent rendering, and multiplied that by the bogomips rating for the
CPU.  This gives us a new unit: the bogomip hour.

        What this means is that my i486DX2/66, which is rated at 32 bogomips,
would have taken close to 900 hours to finish this project.  The actual
amount of time is approximately 28000 BMh / 32 BM = 875 hours.  Now, if I
had a new Pentium Pro 300Mhz to play with, running at nearly 200 bogomips,
the entire project would have taken 28000 BMh / 200 BM = 140 hours (about
six days).

        All I wanted to do with the bogomip hour unit was to give a common
basis for figuring out what kind of time it would have taken to run this
animation again on different hardware.  To say it took 1000 hours is pretty
meaningless otherwise.  Again, the bogomip hour is not a very scientific
idea, but it gives an idea of magnitude, which is all I wanted.

        For those running Linux, the bogomips rating of your machine will
flash by when you boot, or you can type cat /proc/cpuinfo to see it.  For
other systems, I believe that programs can calculate it, but I'm not sure
where you'd find one.

VIEWING RECOMMENDATIONS: 

        MPEG-1 format, 320x240 resolution, 30fps, 24-bit color (True color)
        If viewed with less than 16M colors, banding will occur.
        Works with mpeg_play and the Win95 movie player (ActiveMovie?)
        Recommended accompaniment is "Storms in Africa" (Enya: "Watermark")