TITLE: Intruders at the gates (of paradise)
NAME: Duncan Gray
COUNTRY: Great Britain
EMAIL: duncang@eclipse.co.uk
WEBPAGE: www.eclipse.co.uk/duncang
TOPIC: Fortress
COPYRIGHT: I SUBMIT TO THE STANDARD RAYTRACING COMPETITION COPYRIGHT.
JPGFILE: dg_castl.jpg
ZIPFILE: dg_castl.zip
RENDERER USED: 
    POV-Ray 3.1g (.watcome.win32)

TOOLS USED: 
    None (bit of a purest like that ...)
            Image-Ready to convert output to JPG
CREATION TIME: Approx 2-3 weeks part time.

RENDER TIME: 
    9 hrs 40 mins @800x600 aa+.3

HARDWARE USED: 
    PII 450, 256Meg Ram

IMAGE DESCRIPTION: 


    The native fishermen have returned, and
    as the sun sets on this island paradise,
    the sea returns to find the warning signs.

    Intruders at the gates (of paradise)

DESCRIPTION OF WHY THIS IMAGE WAS CREATED:

This is my first go in the STILLS comp, though I have entered the ANIM
comp a few times.

I was working on an entry for the 'Slow-Motion' round of the ANIM
competition, it was nothing particularly special, I was entirely
re-using old characters and scenes, but it became clear about 2 weeks
before the ANIM round closed that I wasn't going to get it finished on
time. I decided to cut my losses, and to try and vindicate myself by
getting an entry into the STILLS comp instead.

Hope you like it.


DESCRIPTION OF HOW THIS IMAGE WAS CREATED: 


<Judges: I know the rules state that the judging of the entry includes
the reading of the accompanying TXT file. Don't feel obliged to read
this lot - it is intended for those interested in how the scene objects
were constructed but don't want to trouble themselves looking through
the code, and for those interested in re-rendering the scene for
themselves. If you are not interested in how it was built, feel free to
consider the TXT file as having stopped here. Thank you>

I wanted a smooth transition between the walls and turrets of the castle
and the surface of the beach, blobs seemed the logical way to do it. The
beach and the castle are therefore a single blob object. The 238,432
component sphere's are positioned using a range of macro's developed for
this scene, they include macro's to create the components of walls,
turrets, arrow-slits, and the surface of the beach itself. Once I had
these macro's working, the beach and castle came together pretty
quickly.

The palm tree is made of a trunk and crest - the trunk is pretty
straight-forward, a union of cones and toruses to create a stack of
plant-pot type shapes. A bumpy normal is applied for a little roughness
- though this is not particularly apparent in the final picture. The
crests of the palms are built in a similar manner to the leaves of the
plants. A single leaf is declared for each layer and repeated in a
circle for each layer of the crest. Three trees are built then repeated
to create the forrest.

This used up all my 256Meg of Ram. So I had to have a re-think. The
solution was instead of building each leaf out of 80 bi-cubic patches
(the individual 'tassels' on the trees) the leaves are build of two
bi-cubic patches, textured in a striped green/transparent texture
combined with a spine to the leaf made up of cylinders. The change in
appearance was minimal, but it drastically reduced the memory needed.

Next up was some foliage - the large and small plants are built in the
same way - Each leaf is made up of two bi-cubic patches, an array is
created to store the declaration of each leaf, one leaf is stored for
each layer, then the plant created by repeating a single leaf in a
circular pattern for each layer of the plant. This saves unnecessary
creation of leaf objects, as by this time, I was already getting tight
for memory.

The plants are positioned by the macro which generates the beach. Each
time a blob component is laid, the altitude of the point is evaluated.
As the height rises, the probability of a small plant appearing
increses. At about 4.5 units, big plants start appearing and again
become more probable as the altitude increases. This gave a nice
'natural' look to the plant placement, so I didn't bother tweaking it
any further.

The crab is built from blobs. Two macros's build the bulk of it - one
creates blob components that follows a cubic spline, the other a
bi-cubic patch. Both permit the colour of the component to be programmed
via a spline, and one also permits the blob component to be scaled based
on a spline. From here, construction of the crab was just a matter of
fiddling with the spline control points passed into the macros until it
looked right.

The boat is two blobs and a bunch of cylinders. The macro's used for the
crab came in handy to produce the hollowed out log and outrigger.

The water was built like the beach - blob components described by
bi-cubic patch parameters. The blob is merged with a plane so it
stretches to the horizon.

There is a hut in the woods somewhere - it's another blob, components
are arrange using a macro again. The hut roof is a bunch of cylinders.

And that's about it.

Oh, a word of warning: most of the macro's have a jitter parameter which
varies the placement of the blob components  - this is what provides the
uneven surface, which in turn meant I didn't have to do too much work on
the normals in the scene - the normal for the beach is a tiny granite
pattern, to produce the grainy effect. The undulations in the surface
_are_ undulations, not a normal. Blob components are evaluated using a
routine which estimates whether the component is in the field of view of
the camera, the component is aborted if it is out of view. This saves
shed-loads of memory, but does mean that if the camera is moved, or
rotated, the beach will change shape and the trees will jump around !
This will require the crab and the hut to be re-positioned by eye. (i.e.
so the crab isn't buried in the sand, and the hut doesn't have a tree
growing through the roof). To move the camera during scene construction,
it is necessary to move the camera directly, not using the cam_pos and
cam_tgt parameters.

N.B. Don't try and render it unless you have about 150Meg of free
memory. There are some declares in the top of the .POV file which switch
off or optimise parts of the scene. They are used to speed rendering
time, but setting the palm_cutoff variable to a very small number will
loose all the tree's. This drastically cuts the memory usage and should
allow 128Meg machines to render the scene.

