\chapter{Object Definition}

Objects in {\rayshade} are composed of relatively simple {\em primitive}
objects.  These primitives may be used by themselves, or they
may be combined to form more complex objects known as {\em aggregates}.
A special family of aggregate objects,
{\em Constructive Solid Geometry} or CSG
objects, are the result of a boolean operations applied to
primitive, aggregate, or CSG objects.

This chapter describes objects from a strictly geometric point of
view.  Later chapters on surfaces, textures, and shading describe
how object appearances are defined.

An {\em instance} is an object that has optionally been transformed
and
textured.  They are the entities that are actually rendered by
{\rayshade}; when you specify that, for example, a textured
sphere is to be rendered, you are said to be instantiating
the textured sphere.
An instance
is specified as a primitive, aggregate, or CSG object that
is followed by optional transformation and texturing information.
Transformations and textures are described in Chapters 7 and 8 respectively.

\section{The World Object}

Writing a {\rayshade} input file is principally
a matter of defining a special aggregate object, the World object,
which is a list of the objects in the scene.  When writing a {\rayshade}
input file, all objects that are instantiated outside of object-definition
blocks are added to the World object; you need not (nor should you)
define the World object explicitly in the input file.

\section{Primitives}

Primitive objects are the building box with which other objects are
created.  Each primitive type has associated with it specialized
methods for
creation,
intersection with a ray,
bounding box calculation,
surface normal calculation,
ray enter/exit classification,
and for the computation 2D texture coordinates termed {\em u-v}
coordinates.
This latter method is often referred to as the {\em inverse mapping}
method.

While most of these methods should be of little concern to you, the
inverse mapping methods
will affect the way in which certain textures are applied to primitives.
Inverse mapping is a matter of computing normalized $u$ and $v$ coordinates
for a given point on the surface of the primitive.  For planar objects,
the $u$ and $v$ coordinates of a point are computed
by linear interpolation based upon the $u$ and $v$ coordinates assigned
to vertices or other known points on the primitive.  For non-planar
objects, $uv$ computation can be considerably more involved.

This section briefly describes each primitive and
the syntax that should be used to create an instance of the primitive.
It also describes the inverse mapping method, if any, for each type.

\begin{defprim}{blob}{{\em thresh st r} \evec{p} [{\em st r} \evec{p} \ldots]}
	Defines a blob with consisting of a threshold equal to {\em thresh},
	and a
	group of one or more metaballs.  Each metaball is defined by 
	its position \evec{p}, radius {\em r}, and strength {\em st}.
\end{defprim}
The metaballs affect each other according to a superimposed
density distribution:
\[
F(x,y,z) = \sum_{i=0}^n b_{i}e^{-d_{i}} - T = 0
\]
There is no inverse mapping method for blobs.

\begin{defprim}{box}{\evec{corner1} \evec{corner2}}
	Creates an axis-aligned box
	which has \evec{corner1} and \evec{corner2} as
	opposite corners.
\end{defprim}
Transformations may be applied to the box if a non-axis-aligned instance
is required.  There is no inverse mapping method for boxes.

\begin{defprim}{sphere}{{\em radius} \evec{center}}
	Creates a sphere with the given {\em radius} and centered at the
	given position.
\end{defprim}
Note that ellipsoids may be created by applying the proper scaling
to a sphere.  Inverse mapping on the sphere is accomplished
by computing the longitude and latitude of the point on the sphere,
with the $u$ value corresponding to longitude and $v$ to latitude.
On an untransformed sphere, the $z$ axis defines the poles, and the
$x$ axis intersects the sphere at $u = 0$, $v = 0.5$.  There are
degeneracies at the poles: the south pole contains all points of
latitude 0., the north all points of latitude 1.

\begin{defprim}{torus}{{\em rmajor rminor} \evec{center} \evec{up}}
	Creates a torus centered at \evec{center} by rotating
	a circle with the given minor radius around the center
	point at a distance equal to the major radius. 
\end{defprim}
In tori inverse mapping,
the $u$ value is computed using the angle of rotation about the
up vector, and the $v$ value is computing the angle of rotation
around the tube, with $v=0$ occuring on the innermost point of the tube.

\begin{defprim}{triangle}{\evec{p1} \evec{p2} \evec{p3}}
	Creates a triangle with the given vertices.
\end{defprim}

\begin{defprim}{triangle}{\evec{p1} \evec{n1} \evec{p2} \evec{n2}
	\evec{p3} \evec{n3}}
	Creates a Phong-shaded triangle with the given vertices and
	vertex normals.
\end{defprim}
For both Phong- and flat-shaded triangles, the $u$ axis is the
vector from \evec{p1} to \evec{p2}, and the $v$ axis the vector
from \evec{p1} to \evec{p3}.  There is a degeneracy at
\evec{p3}, which contains all points with $v = 1.0$.  This default
mapping may be modified using the {\tt triangleuv} primitive described
below.

\begin{defprim}{triangleuv}{\evec{p1} \evec{n1} \evec{uv1}
  \evec{p2} \evec{n2} \evec{uv2}
  \evec{p3} \evec{n3} \evec{uv3}}
	Creates a Phong-shaded triangle with the given vertices,
	vertex normals.  When performing texturing, the
	{\em uv} given for each vertex are used instead of the
	default values.
\end{defprim}
When computing $uv$ coordinates within the interior of the
triangle, linear interpolation of the coordinates associated with
each triangle vertex is used.

\begin{defprim}{poly}{\evec{p1} \evec{p2} \evec{p3} [\evec{p4} \ldots ]}
	Creates a polygon with the given vertices. The vertices
	should be given in counter-clockwise order as one is
	looking at the ``front'' side of the polygon.  The number of
	vertices in a polygon is limited only by available memory.
\end{defprim}
Inverse mapping for arbitrary polygons is problematical.
{\Rayshade}
punts and equates $u$ with the $x$ coordinate of the point of intersection,
and $v$ with the $y$ coordinate.

\begin{defprim}{heightfield}{{\em file}}
	Creates a height field defined by the altitude data stored
	in the named {\em file}.  The height field is based upon
	perturbations of the unit square in the $z=0$ plane, and is
	rendered as a surface tessellated by right isosceles triangles.
\end{defprim}
See Appendix C for a discussion of the format of a height field file.
Height field inverse mapping is straight-forward:  $u$ is the
$x$ coordinate of the point of intersection, $v$ the $y$ coordinate.

\begin{defprim}{plane}{\evec{point} \evec{normal}}
	Creates a plane that passes through the given point and
	has the specified normal.
\end{defprim}
Inverse mapping on the plane is identical to polygonal inverse mapping.

\begin{defprim}{cylinder}{{\em radius} \evec{bottom} \evec{top}}
	Creates a cylinder that extends from \evec{bottom} to \evec{top}
	and has the indicated {\em radius}.  Cylinders are rendered
	{\em without} endcaps.
\end{defprim}
The cylinder's axis defines the $v$ axis.  The $u$ axis wraps around the
cylinder, with $u=0$ dependent upon the orientation of the cylinder.


\begin{defprim}{cone}{$rad_{bottom}$ \evec{bottom} $rad_{top}$ \evec{top}}
	Creats a (truncated) cone that extends from \evec{bottom} to
	\evec{top}.  The cone will have a radius of $rad_{bottom}$ at
	\evec{bottom} and a radius of $rad_{top}$ at \evec{top}.
	Cones are rendered {\em without} endcaps.
\end{defprim}
Cone inverse mapping is analogous to cylinder mapping.

\begin{defprim}{disc}{{\em radius} \evec{pos} \evec{normal}}
	Creates a disc centered at the given position and with the
	indicated surface normal.
\end{defprim}
Discs are useful for placing
endcaps on cylinders and cones.
Inverse mapping for the disc is based on the computation of the
normalized polar coordinates of the point of intersection.  The
normalized radius
of the point of intersection is assigned to $u$, while the normalized angle
from a reference vector is assigned to $v$.

\section{Aggregate Objects}

An aggregate is a collection of primitives, aggregate, and CSG
objects.  An aggregate, once defined, may be instantiated at will,
which means that
copies that are optionally transformed and textured may be made.
If a scene calls for the presence of many geometrically identical
objects, only one such object need be defined; the one defined object
may then be instantiated many times.

An aggregate is one of several possible types.  These aggregate types
are differentiated by the type of ray/aggregate intersection algorithm
(often termed an {\em acceleration technique} or {\em efficiency scheme})
that is used.

Aggregates are defined by giving a keyword that defines the
type of the aggregate, followed by
a series of object instantiations and
surface definitions, and terminated using the {\tt end} keyword.
If a defined object contains no instantiations, a warning message
is printed.

The most basic type of aggregate, the {\em list}, performs
intersection testing in the simplest possible way:  Each object in the
list is tested for intersection with the ray in turn, and the closest
intersection is returned.

\begin{defkey}{list}{\ldots {\tt end}}
	Create a List object containing those objects instantiated between
	the {\tt list}/{\tt end} pair.
\end{defkey}

The {\em grid} aggregate
divides the region of space it occupies into a number of discrete
box-shaped
voxels.  Each of these voxels contains a list of the objects that
intersect the voxel.  This discretization makes it possible to
restrict the objects
tested for intersection to those that are likely to hit the ray,
and to test
the objects in nearly ``closest-first'' order.

\begin{defkey}{grid}{{\em xvox yvox zvox} \ldots {\tt end}}
	Create a Grid objects composed of {\em xvox} by {\em yvox} by
	{\em zvox} voxels containing those objects
	instantiated between the {\tt grid}/{\tt end} pair.
\end{defkey}
It is usually only worthwhile to ``engrid'' rather large,
complex collections of objects.  Grids also use a great deal more
memory than List objects.

\section {Constructive Solid Geometry}

Constructive Solid Geometry is
the process of building solid objects from other solids.
The three CSG
operators are Union, Intersection, and Difference.  Each operator
acts upon two objects and produces a single object result.
By combining multiple levels of CSG operators, complex
objects can be produced from simple primitives.

The union of two objects results in an
object that encloses the space occupied by the two given objects.
Intersection results in an object that encloses the space where the two
given objects overlap.  Difference is an order dependent operator; it
results in the
first given object minus the space where the second intersected
the first.

\subsection{CSG in {\Rayshade}}

CSG in {\rayshade} will generally operate properly when applied to
conjunction with
on boxes, spheres,
tori, and blobs.
These primitives are by nature consistent, as they all
enclose a portion of space (no hole from the ``inside'' to the
``outside''), have surface normals which point outward (they
are not ``inside-out''), and do not have any extraneous surfaces.

CSG objects may also be constructed from aggregate objects.
These aggregates contain
whatever is listed inside, and may therefore be inconsistent.
For example, an object which contains a single triangle will not
produce correct results in CSG models, because the triangle does not enclose
space.  However, a collection of four triangles which form a pyramid
does enclose space, and if the triangle normals
are oriented correctly,
the CSG operators should work correctly on the pyramid.

CSG objects are specified by surrounding the objects upon
which to operate, as well as any associated surface-binding commands,
by the operator verb on one side and the {\tt end}
keyword on the other:

\begin{defkey}{union}{$<${\em Object}$>$ $<${\em Object}$>$
[$<${\em Object}$>$ \ldots] {\tt end}}
	Specify a new object defined as the union of the
	given objects.
\end{defkey}

\begin{defkey}{difference}{$<${\em Object}$>$ $<${\em Object}$>$ 
[$<${\em Object}$>$ \ldots] {\tt end}}
	Specify a new object defined as the difference of the
	given objects.
\end{defkey}

\begin{defkey}{intersect}{$<${\em Object}$>$ $<${\em Object}$>$
[$<${\em Object}$>$ \ldots] {\tt end}}
	Specify a new object defined as the intersection of the
	given objects.
\end{defkey}

Note that the current implementation does not support more that two
objects in a CSG list (but it is planned for a future version).

% The following aren simple CSG objects using the four consistent
% primitives:
% 
% union box ... difference ...

\subsection{Potential CSG Problems}

A consistent CSG model is one which is made
up of solid objects with no dangling surfaces.  In {\rayshade},
it is quite easy to construct inconsistent models, which will usually
appear incorrect in the final images.
In {\rayshade}, CSG is implemented by maintaining
the tree structure of the CSG operations.  This tree is traversed,
and the operators therein applied, on a per-ray basis.
It is therefore difficult to verify the consistency of
the model ``on the fly.''

One class of CSG problems occur when
surfaces of objects being operated upon
coincide.  For example, when subtracting a box from another box to make a
square cup, the result will be wrong if the tops of the two boxes
coincide.  To correct this, the inner box should be made
slightly taller than the outer box.
A related problem that must be
avoided occurs when two coincident surfaces are assigned
different surface properties.

It may seem that the union operator is unnecessary, since
listing two objects together in an aggregate results
in an image that appears to be the same.
While the result of such a short-cut
may appear the same on the exterior, the interior
of the resulting object will contain
extraneous surfaces.
The following examples show this quite clearly.

\begin{verbatim}
    difference
      box -2 0 -3  2 3 3
      union  /* change to list; note bad internal surfaces */
        sphere 2 1 0 0
        sphere 2 -1 0 0
      end
    end rotate 1 0 0 -40  rotate 0 0 1 50
\end{verbatim}

The visual evidence of an inconsistent CSG object varies depending
upon the operator being used.
When subtracting a consistent object from and
inconsistent one, the resulting object will appear to be
the union of the two objects, but the shading will be incorrect.
It will appear to be inside-out in places, while correct
in other places.  The inside-out sections indicate the areas
where the problems occur.
Such problems are often caused by
polygons with incorrectly specified
normals, or by surfaces that exactly coincide (which
appear as partial ``Swiss cheese'' objects).

The following example illustrates an attempt to subtract a sphere from
a pyramid defined using an incorrectly facing triangle.  Note
that the resulting image obviously points to which triangle is
reversed.

\begin{verbatim}
    name pyramid list
        triangle 1 0 0  0 1 0  0 0 1
        triangle 1 0 0  0 0 0  0 1 0
        triangle 0 1 0  0 0 0  0 0 1
        triangle 0 0 1  1 0 0  0 0 0  /* wrong order */
    end

    difference
        object pyramid scale 3 3 3 rotate 0 0 1 45
            rotate 1 0 0 -30 translate 0 -3.5 0
        sphere 2.4 0 0 0
    end
\end{verbatim}

By default, cylinders and cones do not have end caps, and thus
are not consistent primitives.  One must usually
add endcaps by listing the
cylinder or cone with (correctly-oriented) endcap discs in an aggregate.

\section {Named Objects}

A name may be associated with any primitive, aggregate, or CSG
object through the use of the {\tt name}
keyword:

\begin{defkey}{name}{{\em objname} $<${\em Instance\/}$>$}
	Associate {\em objname} with the given object.  The
	specified object is not actually instantiated; it
	is only stored under the given name.
\end{defkey}

An object thus named may then be instantiated (with possible
additional transforming and texturing) via the {\tt object} keyword:

\begin{defkey}{object}{{\em objname} [$<$Transformations$>$] [$<$Textures$>$]}
	Instantiate a copy of the object associated with {\em objname}.
	If given, the transformations and textures are composed
	with any already associated with
	the object being instantiated.
\end{defkey}
