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.