\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
{\em 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 (not should you)
define the World object explicitly in the input file.

The fact that the World object is stored as a List will lead to a
loss of performance in cases where the World object contains, for
example, a single CSG object.  In the non-beta release of \rayshade 4.0,
there will be no such loss of performance in these and similar cases.

\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}{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}{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 ``top'' 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 equate $u$ with the $x$ coordinate of the point of intersection,
and $v$ with the $y$ coordinate.

\begin{defprim}{hf}{{\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 isoscoles triangles.
\end{defprim}
See Appendix B 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$ dependant 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 basic CSG
operators are Union, Intersection, and Difference.  Each operator
takes two objects, and produces a single object result.  Union is just
the object encloses the space occupied by both the given objects.
Intersection returns the object which encloses the space where the two
given objects overlap.  Difference is an order dependent operator.  It
returns the first object minus the space where the second overlapped
the first.  By combining multiple levels of CSG operators, complex
objects can be produced from simple primitives.

The formal CSG model should return actual altered objects from each
operation.  In {\em rayshade}, however, it is more convenient to maintain
the tree structure of the operations, and apply the operators on a per
ray basis.  Therefore, it is difficult to verify the consistency of
the model ``on-the-fly.''  A consistent CSG model is one which is made
up of solid objects with no dangling surfaces.  In {\em rayshade},
it is possible to construct inconsistent models, which will appear
wrong in the final images.  This is discussed below.

\subsection{CSG in Rayshade}

CSG in \rayshade can operate properly
on the following primitives: box, sphere,
torus, and blob.
These primitives are by nature consistent.  They all
enclose a portion of space (no hole from the "inside" to the
"outside"), they all have surface normals which point outward (they
are not "inside-out"), and they do not have any extraneous surfaces.
\Rayshade should always produce correct results with these four
object types (with one exception described later).

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

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 are simple CSG objects using the four consistent
% primitives:
% 
% union box ... difference ...

\subsection{Potential CSG Problems}

Using the consistent primitives, it is still possible to create
visually incorrect results.  This occurs when surfaces exactly
coincide.  For example, subtracting a box from another box to make a
square cup, the result will be wrong if the tops of both boxes
coincide.  To correct this, make the inner box (being differenced),
slightly taller than the outer box.  This error also occurs when two
objects of different colors have surfaces in the same place.  Avoid
this as well.

Some folks feel that the union operator is unnecessary, since just
listing two objects together in an aggregate results
in an image the appears to be the same
While it may look the same on the outside, inside the
objects there are extraneous surfaces.  For example, two spheres
which slightly overlap have portions of their surface which are inside
both spheres (and thus inside the result object) that do not separate
inside from outside.  The following examples would show this
quite clearly, were we too add one:

What happens if you have an inconsistent object?  What will you see?
The final (strange) \rayshade image will appear to show an object which
is shaped like the union of your objects (even when you used
intersection), with the wrong surface shading on the objects.  It will
appear to be inside out in places, and correct in other places.  The
inside-out sections indicate the area where the problem lies.  Check
for polygons with incorrectly specified normals.  Also check for
surfaces which exactly coincide, because these appear as partial
objects; a swiss cheese effect.  Be very careful that what you
consider to be the interior is completely closed.

A note about cylinders:  By default, they don't have end caps, so they
aren't consistent primitives.  You must add the caps by listing the
cylinder with its caps in an aggregate.  Be sure to get the endcap
disc oriented the right direction.  The same holds for cones.

\section {Named Objects}

A name may be associated with (optionally transformed
and textured) 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 present associated with
	the object being instantiated.
\end{defkey}
