TITLE: Dominos
NAME: Kent D. Johnson
COUNTRY: U.S.A.
EMAIL: kentdj@revealed.net
TOPIC: Toys
COPYRIGHT: I SUBMIT TO THE STANDARD RAYTRACING COMPETITION COPYRIGHT.
MPGFILE: domino.mpg
ZIPFILE: domino.zip
RENDERER USED: 
    POVRay 3.1 beta 4

TOOLS USED: 
    MS Excel, MS Access, MS Word, CMPEG, Micrografx Picture
Publisher, Micrografx Designer, Notepad, Dave's Targa Animator, MS
VidEdit, AVIRip

CREATION TIME: 
    About 12 hours planning and programming, 50.5 hours
rendering (estimated time based on the average time per frame for the
first 360 frames) - parse time is estimated to be a little under 40.5
hours and tracing time is estimated to be about 10.25 hours, 10
minutes to create the fade out at the end of the animation, 25
minutes to convert to MPEG.  8 more hours to cut the size down to 3
MB.  Total creation time is thus approximately 70 hours.

HARDWARE USED: 
    Pentium Pro 200 MHz, 128MB RAM, Windows NT4 SP3

ANIMATION DESCRIPTION: 
    Back in the 70's (whoops, better make that the
_19_70's to be Y2K compliant) when I was a child, every so often
there would be a little blurb on the news or during Saturday morning
cartoons (WonderTwin powers - ACTIVATE!  Shape of...conic section!
Form of...sky sphere!) about some group of kids who set a new world
record for setting up and toppling dominos (or is that dominoes? -
Dan Quayle, help me out here).

Unfortunately, whenever I tried to do it myself I would either bump a
domino and destroy my work or I'd get the spacing wrong on a corner
and the topple wouldn't work.  Well, I have none of those problems
with POVRay since I can MAKE the next domino fall whether I set
things up right or not.

Anyway, this is my tribute to that wonderful toy that has fascinated
kids (and adults) for decades - the domino.
P.S., I think there's some kind of game you can play with dominos
too, but that may just be an urban legend :-)


VIEWING RECOMMENDATIONS: 
    Microsoft ActiveMovie works well for me, but
any viewer that supports I, P & B frames should work.

DESCRIPTION OF HOW THIS ANIMATION WAS CREATED: 
    Let me start off by
saying I'm not entirely satisfied with this animation.  Although I
had been thinking along the lines of dominos for about a week prior,
I didn't really sit down to do any work or planning on this thing
until July 6, just 10 days before the due date. So as I tweaked
things along the way, eventually I had to just accept things as they
were and do the final render.

I think the biggest blessing in the creation of this animation was
the Windows version of POVRay 3.1 (beta 4).  I don't think I could
have done things as quickly and easily as I did without the use of
POVRay 3.1's arrays.  Thank you Chris Cason and the POV-Team.

As far as how the animation was created, I started off with picking
the dimensions of the domino.  To keep things simple, I chose 1.00
units tall, 0.50 units wide and 0.25 units thick. Each domino is
simply two boxes (one for the top and one for the bottom) unioned
together. I was going to eventually replace the box with a more
complicated model of a domino, but after looking at several test
renders I found it didn't add anything to the animation. I decided on
0.50 units between the dominos when they are in a straight line.  I
then decided on an initial falling rate of 3 degrees per frame for a
newly struck domino.  This yielded 10 frames between the start of
domino motion and when the domino strikes the next domino at 30
degrees.  This would have been great if I knew all the judges had
high end pentium II/alpha/sgi/powerpc computers.  So I chopped that
down to three frames with a fall rate of 12 degrees per frame, which
I started at 6 degrees to simulate the initial acceleration of the
newly struck domino.

Once a domino has contacted the next domino, its fall rate is
controlled by the next domino since its leading edge must remain in
contact with the back face of the next domino (which is now falling
at the rate of 12 degrees per frame) until it is resting on the
bottom edge of the next domino.  Let's just say the math got REAL
messy REAL fast (the way I did it anyway), so I gave up on the
mathematical way of doing things and went to the empirical method.  I
fired up Micrografx Designer and drew two profiles of a domino and
proceeded to tip the first against the second at various angles to
determine the values I needed. MUCH quicker and nicer than integrals
and differential equations :-)

I originally wanted to have all kinds of fancy patterns and paths of
dominos, but once I realized how many dominos were going to be needed
(I used 5,200) I realized how difficult it would be to program each
individual location.  So I settled on on a single line of dominos
that cuts through the middle of a rectangular field of dominos,
setting off a perpendicular line of dominos falling as it goes.

All the dominos are on the same level horizontally, so I only needed
to calculate the 'x' and 'z' coordinates of each domino.  I used
Microsoft Excel to do this.  I gave each domino the following
properties: 'xpos', 'zpos', 'theta', and 'domEq'. Xpos and Zpos are
simply the x and z coordinates of the domino. Theta is the direction
the domino initially faces. The domEq property is what I refer to as
the 'domino equivalent position'.  Perhaps I can best explain it by
saying that two dominos that have the same domEq value will start
falling at the same time in the animation. Using Excel allowed me to
quickly assign the positions of each domino relative to the previous
domino.  That allowed me to copy and paste one row to use as the
basis for all the other rows.  After 'creating' all the dominos in
Excel I used a macro to copy all the data into a single column.  I
then exported it to Microsoft Access and added a field for domino
color (default color is blue). I then graphed the pattern of red
dominos and used the filter feature of Access to manually change the
color of the appropriate dominos. I then used MS Access to output the
xpos.inc, zpos.inc, domcolor.inc, theta.inc and domeq.inc files in
rtf format.  I then used MS Word to convert to them to text. (That
whole procedure sounds a lot more complicated than it is.)

My original thought was to use colored dominos that didn't have spots
on them, but I decided to go ahead and put them on, even though it
increased parsing/rendering time by a factor of 5 or better.  The
spot values for each domino are determined by taking the modulus of
each domEq value by a constant value (7 for the top of each domino
and 6 for the bottom).  It probably would have been faster to use
another include file for the spot values, but I had never used the
#switch...#case feature before and I wanted to try it.  The spots are
placed on the dominos by differencing one or more spheres from the
face of the domino.  It worked great as soon as I stopped trying to
put the spots on the wrong side of the domino!

As far as the background goes, I considered a number of different
things - a child's toy room, a wooden floor, even the dreaded
checkered floor with silver dominos (just kidding).  But after using
a simple white plane in my test renders, I decided I kind of liked
the look with that hazy edge off in the distance (okay, okay...the
lack of time to do something fancier had a little to do with it as
well).

I downloaded Patrick's Curve Generator and did some test renders with
two boxes representing the field of dominos.  The results were
horrendous, with some of the camera location values flying WAY away
from what I expected (it sure is easy to mess up a cubic spline,
isn't it?).  With not much time remaining before I needed to start my
final renders, I went back to Excel and used it to generate the
camera path include files (camlook.inc and camloc.inc).  Finally it
was time to run my final renders at 320x240 with AA 0.3, so I emailed
the files to work (my home computer is a P75 with 16 MB and would
have taken an hour just to parse each frame) and started POVRay a
running over the weekend.

On Monday I returned to discover my error - I used the wrong INI file
to render and I ended up rendering ONE lousy frame because I didn't
have animation turned on.  AUGHHH!  Fortunately the render finished
on the afternoon of the submission date.  I then made a number of
copies of the final frame and faded them to black using Micrografx
Picture Publisher. The task would have been pretty simple to do using
POVRay alone, but it would have taken too long to render.  And since
the fade isn't really an important part of the animation (I really
only did it to make it look better when used as a screen saver) I
decided to go ahead and use a paint program.

I used CMPEG to convert the TGAs to MPEG.  Unfortunately it ended up
closer to 4MB than 3.  So I used DTA to average every other frame
together and saved it as an FLC file.  I then spent about 8 hours
trying to find the right tools to get it converted to a good MPG.
Using MS VidEdit gave me a good quality AVI, but I couldn't get a
good quality MGG out of AVI2MPG1 so I had to go get the AVIRIP
utility to output TGA files (DTA could have done this too, but it
only output 8-bit TGAs and CMPEG needed 16- or 24-bit).  Finally I
got the animation made with about a half hour before the deadline to
spare. Hopefully after the judging is done I can replace this version
with the much better quality 4MB one I made first.

I have included all the files needed to render the animation using
POVRay for Windows 3.1 beta 4.  But I didn't include the Excel and
Access files due to size constraints and since they were only used to
generate the include files anyway.

