EMAIL: RStrick448@aol.com NAME: Rob Strickland TOPIC: Physics & Math COPYRIGHT: I SUBMIT TO THE STANDARD RAYTRACING COMPETITION COPYRIGHT. TITLE: Chain Reaction COUNTRY: USA WEBPAGE: None (yet) RENDERER USED: Special compile of POVRay 3.01 as an NT console application which implements motion blur. TOOLS USED: PhotoShop to create texture maps, convert final image to JPEG RENDER TIME: 68 hours 16 minutes HARDWARE USED: Pentium 100 w/ 64M RAM, NT 3.51 IMAGE DESCRIPTION: The picture is of a lecture demonstration which I used for college physics classes. Its purpose was to demonstrate how a nuclear chain reaction grows exponentially, starting from a single nucleus splitting. The equipment consisted of about 40 mousetraps, and a pair of ping pong balls for each trap. Each mouse trap represented the nucleus of a uranium or plutonium atom, and each ball represented a neutron. When fission occurs, a nucleus splits into several pieces, and also emits a number of neutrons. Each of these neutrons can strike other nuclei, causing them to fission, etc. When a mouse trap is triggered, it propels the 2 balls into the air, which may then set off other traps. The demonstration is started by dropping a single ball onto the center of the assembly, and within seconds there are balls flying everywhere, and just as suddenly the demonstration is complete. Although this was probably one of the least quantitative demonstrations, as well as the one I dreaded the most (try setting 40 mousetraps and placing ping pong balls on them without getting snapped!), it was always a big hit with the students. I hope they still remember it, and that perhaps when they hear the word "Physics", it is one of the first images that pops into their minds. In this image, we have captured the trap in the center of the picture at the moment of fission, starting to accelerate its "neutrons" into the air. Surrounding it are other traps waiting to be triggered, as well as others already spent. DESCRIPTION OF HOW THIS IMAGE WAS CREATED: All of the geometry was hand created in the POV editor using CSG operations on basic shapes. The spring is built up from sections of torii, and I wrote a general include file (helix.inc) to generate springs. I closely modeled the items from real ones I bought at the hardware store; only the logos have been changed to protect the innocent. For the textures, I started from some of the basic wood and metal textures in the standard POV include files, then tweaked and modified them to get the exact effect I wanted. Once I had the basic elements constructed, I then placed them together in a file and hand tweaked the positions for the final composition. When I had a first draft of the image, it just looked too static. The impressive thing about this demonstration was how ping pong balls are zipping all over the place and mouse traps are snapping shut. To try to better convey the sense of action, I decided to add motion blur to the image. A quick talk with the IRTC admins ruled out using any post-processing to achieve this, so I rolled up my sleeves and made a stab at incorporating the feature into POVRay itself. What I came up with is an extension of the animation loop. If you look at my scene file, you can see it is set up as if I were making an animation, with the clock variable used to determine the locations of some objects. It can be rendered with a normal version of POVRay, but will only show the image as it appears at a given instant. I added an additional parameter +KMn, where n is the number of times each frame is rendered, with the clock variable incrementing smoothly. Since I was just rendering a single frame, the clock variable ranged from 0 to 1, and I used +KM40, so the image was sampled at clock = 0.000, 0.025, 0.050,... 0.975. Each time the image is rendered, the results are accumulated in a special temporary file. The values are stored as floats to minimize errors and because gamma correction is not performed until the final file is written. After all the sample frames are rendered, POV then reads the temporary file and write out the final file in any of the supported formats. It's probably not the quickest way to render motion blur (rerendering the image 40 times explains the long render time listed at the top), but I was in a hurry to hack something together before the deadline.