EMAIL: p_chan@shaw.ca
NAME:	Philip Chan
TOPIC: Adventure
COPYRIGHT: I SUBMIT TO THE STANDARD RAYTRACING COMPETITION COPYRIGHT.
TITLE: An Ill-Fated Adventure
COUNTRY:	Canada
WEBPAGE:
RENDERER USED:	POV-Ray version 3.1g
TOOLS USED: MainActor version 1.5
				Adobe Photoshop version 5.0 LE (for movie poster)
CREATION TIME: Approx. 55 hours of me working at the computer
					Total render time: 2 days, 2 hours, 36 minutes, 2 seconds
HARDWARE USED: Athlon 1700+ XP, Win95, 256Mb DDR RAM
VIEWING RECOMMENDATIONS: The MPEG appears brighter than the individual frames.
								 Please adjust monitor brightness so that the back wall
								 is not visible in the first frame.
ANIMATION DESCRIPTION: The ill-fated adventure of a young wizard.

DESCRIPTION OF HOW THIS ANIMATION WAS CREATED:

This animation was created entirely with POV's built in text editor.  Objects
are created primarily using Constructive Solid Geometry (CSG) of primatives
(i.e. boxes, planes, spheres, cylinders, torii, and possibly a few cones).
The motion of the objects is performed by translations and/or rotations of
objects, the camera, and the camera's look_at point dependent on POV's clock.
The animation is broken into 20 files (phases) so that clock=0 for one phase
corresponds to clock=1 of the next phase.  The animation is then rendered with
frames overlapping so that there aren't any "duplicate" frames.

The following is a more detailed description of the objects in the animation:

Dungeon:
The floors and ceilings consists of planes.  The texture is a modified one from
my last animation (E=mc2, July 2001).  The walls are a collection of boxes,
textured with a modified version of T_Stone28 in "stones.inc".  A normal which
matches the colour_map was added to the texture.

Staff:
The staff is made using CSG.  From bottom up, a collection of cylinders and
torii, topped with a stretched sphere.  The head is made of 3 prisms, and a
sphere for the gem.  The decorations are made from cylinders, torii and
spheres.  The gold and silver textures were taken from "metals.inc", with a
slight wrinkle normal added to the silver texture.  The material for the gem
was created by me, and based on the gem textures from my last still (Greed
and Treachery, February 2002).
The motion for the staff consists of a sinusoidal up and down movement, along
with a matching sinusoidal rotation slightly forward.  The order of the
rotation operations done on the staff ensures that it is always pointing in the
right direction.  Raising the staff for casting spells consists of a rotation
and upward translation.

Torch Brackets:
Fairly simple CSG.  The texture has a hybrid of two textures from "metals.inc"
as the bottom layer.  The top layer is a rust texture I created.  These "stand
out" in the dark a lot more than I wanted them to, but I didn't have time to
tweak the texture.  I guess they just reflect light a lot better than the
walls, since they don't have an ambient value.

Light Source:
The attenuating light source is surrounded by a media object.  The interior
consists of two media (so they add).  The first is a slightly turbulent
spherical media (the strong, white glow).  The second is a turbulent spotted
pattern (the blue wisps).  The second media also has a second spherical
density pattern (which multiplies with the first) to fade it out at the edges
of the light sphere.
I tried to keep the rotation of the light sphere relatively smooth by making
equations so that the angular velocity never jumps.  This is done by having the
angular velocity be 0 at the beginning and/or end of each phase, the equation
can then be relatively random, and the next phase can either pick up with the
angular velocity at end of the previous phase, or start with an angular
velocity of zero.  I could have just used random equations, but the carry
forward of final velocity of one phase as the initial velocity of another phase
would have become a big mess by the last phase.
The light source is translated to maintain the same position relative to the
camera, except when the camera is turning, when the light lags a little... well
sort of.  The light really follows a circular path (like the camera look_at),
with a little added so it gets where it should go.  A power of the clock
slightly above 1 is used to create a bit of lag.

First Spell:
The object is a modified version of the Big_Star object from my first still
(The Assault, October 2001).  The object has been scaled down, and the media
almost totally redone since the original looked horrible from up close.  The
pulsating effect is accomplished by scaling the object sinusoidally, while
also adjusting the fade_distance of the accompanying light_source.  The motion
of the spell is controlled in the same way as the camera (see below).  The
explosion at the end is done by replacing the original object with eight
objects which are essentially the "parent" object, minus the protruding cones.
The original light sources are also replaced by eight dimmer light sources,
which add up to be slightly brighter than the original light source to create
a bit of a flash.  The eight pieces are then given random initial velocities in
a while loop, and then fall due to gravity while fading.

Altar:
Simple CSG.  The stone textures are all from stones.inc.  The "magic keyhole"
in the middle is composed of a torus on the outside and a cylinder, quarter
torus, and sphere placed five times in a while loop.

Magic Barrier:
Just the difference of two cylinders textured with a semi-transparent,
alternating radial pattern with the frequency increased.  The light from the
barrier is just a light source half way between the top of the altar and the
ceiling.  The barrier also used the no_shadow keyword since the light source
is inside it.

Grail:
The grail is also made of CSG.  Half a sphere at the top, difference of two
cylinders and two torii to form the stem, and another torus to round off the
base.  The gems are prisms (using a conic sweep), set in spheres and then
attached to the grail.  The detail here can't really be seen in the animation.
The grail uses the no_shadow keyword to create the impression that the light
from the barrier is coming from all around it (rather than just a point
directly above it).  The no_shadow keyword is removed (by means of an #if
statement) when the bottom of the barrier clears the top of the grail.
The gold texture is from metals.inc.  The Ruby and Emerald textures are taken
from my last still (Greed and Treachery, February 2002).  

Gate:
A series of cylinders and boxes placed by while loops.  The spikes at the
bottom are cones with a sphere at the top, also placed in while loops.  The
gold emblem is the same as the one cut into the altar (this emblem is meant
to be associated with the trap).  The textures are taken from metals.inc.  Note
the gate is not rusted like the torch brackets as it is part of the magical
trap.

Slime:
The slime is a blob consisting of a large sphere in the middle and some other
spheres placed randomly around it in a while loop.  The material is just a
uniform, slightly transparent green, with a bit of ior (index of refraction).
Add a phong highlight and a tiny bit of reflection and that's it.
The fade out at the end is done by decreasing the transmit value in the pigment
to 0.  I guess I should have done something about the phong highlight during
the fade out too, but I didn't have time to worry about that.
There's also a little "drip" of slime that falls about the time when the gate
comes crashing down, but it's hardly visible since it falls fairly close to the
camera, and with the speed it got from realistic gravity, based in a 3 metre
high room, it only flashed into view for a split second.  This one is a blob
with too spheres joined by a cylinder component.

Camera Motion:
The camera look_at point starts 1 unit away from the camera.  Looking side to
side is done by having the look_at point move in the arc of a circle.  The last
turn is done using POV's vrotate function since the camera isn't pointing along
an axis.  The look_at point is calculated using POV's vcross function when
walking around a corner.  The cross product of either a -y or y vector with the
current vector pointing from the radius of the circle (taking directly from the
trigonometric equation for describing the arc) gives a vector in the direction
the camera is moving at that instant.  Looking in hind-sight, I realize it
probably would have been much easier to rotate the camera at the origin, and
then translate it into place.  I didn't realize the rotate and translate
changed the look_at point of the camera as well, until this started causing
problems for me.  At that point I fixed all the translate statements to I
wasn't moving the look_at point and translating the camera, but I had already
worked out how to turn the camera without using rotations, so I just went with
that rather than redoing it.