System: rayshade version 4.0 Patch #: 3 Priority: HIGH Subject: Date: Mon Feb 3 13:22:58 EST 1992 From: Rayshade Construction Co. Description: Repeat-By: Fix: From rn, say "| patch -p -N -d DIR", where DIR is your rayshade source directory. Outside of rn, say "cd DIR; patch -p -N #define PATCHLEVEL 3 Index: Doc/Guide/running.tex *** old/Doc/Guide/running.tex Mon Feb 3 12:49:54 1992 --- new/Doc/Guide/running.tex Fri Jan 17 10:29:15 1992 *************** *** 1,11 **** \chapter{Running Rayshade} ! {\em Rayshade} can take anywhere from seconds to weeks to render an image. The exact time required is a function of the speed of the machine(s) on which you're working, the complexity of the scene, and how ``good'' you want ! the final image to be. Creating a finished ray-traced image is an iterative process. Usually, many test renderings are made at low resolution and with --- 1,12 ---- \chapter{Running Rayshade} ! {\Rayshade} can take anywhere from seconds to weeks to render an image. The exact time required is a function of the speed of the machine(s) on which you're working, the complexity of the scene, and how ``good'' you want ! the final image to be. \footnote{Appendix D describes some simple ! ways to accelerate the rendering process.} Creating a finished ray-traced image is an iterative process. Usually, many test renderings are made at low resolution and with *************** *** 13,35 **** surface definitions might be modified, the eye or look positions may be slightly changed, or the intensity of a light source changed. ! This chapter describes the basic operation of \rayshade and some of the options that control that operation. Setting these options properly can greatly reduce rendering time, improve the quality of your images, and make you a better person. ! {\em Rayshade} usually works as a filter, reading a description from the standard input and writing ! an image file to the standard output. As it is working, {\em rayshade} reports on the progress of the rendering by writing messages to the standard error. \section{The Input File} ! The scene description read by \rayshade consists of a number of keywords, each followed by a set of arguments. These keywords can ! be thought of as commands that direct rayshade to do various things, such as create objects, set the eye's position, and change an object's appearance. --- 14,36 ---- surface definitions might be modified, the eye or look positions may be slightly changed, or the intensity of a light source changed. ! This chapter describes the basic operation of {\rayshade} and some of the options that control that operation. Setting these options properly can greatly reduce rendering time, improve the quality of your images, and make you a better person. ! {\Rayshade} usually works as a filter, reading a description from the standard input and writing ! an image file to the standard output. As it is working, {\rayshade} reports on the progress of the rendering by writing messages to the standard error. \section{The Input File} ! The scene description read by {\rayshade} consists of a number of keywords, each followed by a set of arguments. These keywords can ! be thought of as commands that direct {\rayshade} to do various things, such as create objects, set the eye's position, and change an object's appearance. *************** *** 38,52 **** These options override the values given in the input file, and are explained in detail in Appendix A. ! Rayshade is ``case sensitive,'' which means that typing {\tt SPHERE} or {\tt Sphere} instead of {\tt sphere} won't work. ! {\em Rayshade} keywords are all lower-case. Many people choose to capitalize the first letter of names that they give to objects or surfaces in order to make then ``stand out'' in an input file. Keywords, numbers and strings in the input file are separated by spaces, tabs, or new lines (carriage returns). These ``whitespace'' characters ! are handled identically by {\em rayshade}, which means that you can separate keywords from keywords, key words from arguments, and arguments from arguments using any combination of whitespace characters that you choose. --- 39,53 ---- These options override the values given in the input file, and are explained in detail in Appendix A. ! {\Rayshade} is ``case sensitive,'' which means that typing {\tt SPHERE} or {\tt Sphere} instead of {\tt sphere} won't work. ! {\Rayshade} keywords are all lower-case. Many people choose to capitalize the first letter of names that they give to objects or surfaces in order to make then ``stand out'' in an input file. Keywords, numbers and strings in the input file are separated by spaces, tabs, or new lines (carriage returns). These ``whitespace'' characters ! are handled identically by {\rayshade}, which means that you can separate keywords from keywords, key words from arguments, and arguments from arguments using any combination of whitespace characters that you choose. *************** *** 75,93 **** available for use in expressions, in order of decreasing precedence. The upshot of all this is that the strings ! {\tt $42$}, {\tt $42.$}, ! {\tt $(20 + 22)$}, and {\tt $(7^2 - 7)$} mean the same thing ! to {\em rayshade}. Variables may also be defined and used in expressions. Several ! built-in functions are also provided. See appendix B for further details. ! \Rayshade will automatically run the input it receives through the C preprocessor if it is available. This allows you to use C preprocessor directives, such as {\tt \#include}, {\tt \#define}, and {\tt \#ifdef} when designing your input files. ! Comments may be included in \rayshade input files by enclosing text between the strings \verb!/*! and \verb!*/!, as in the C programming language. --- 76,94 ---- available for use in expressions, in order of decreasing precedence. The upshot of all this is that the strings ! {\tt 42}, {\tt 42.}, ! {\tt (20 + 22)}, and {\tt (7\verb!^!2 - 7)} mean the same thing ! to {\rayshade}. Variables may also be defined and used in expressions. Several ! built-in functions are also provided. See Appendix B for further details. ! {\Rayshade} will automatically run the input it receives through the C preprocessor if it is available. This allows you to use C preprocessor directives, such as {\tt \#include}, {\tt \#define}, and {\tt \#ifdef} when designing your input files. ! Comments may be included in {\rayshade} input files by enclosing text between the strings \verb!/*! and \verb!*/!, as in the C programming language. *************** *** 94,101 **** \section{Images} ! The end result of running \rayshade is an image file. Depending upon ! how it was installed, \rayshade writes images in either the Utah Raster {\em RLE} format or a generic but easily-manipulated {\em mtv} format used by Mark VandeWettering in his {\em mtv} ray tracer. The {\em mtv} format consists of a header giving the resolution of the image followed --- 95,102 ---- \section{Images} ! The end result of running {\rayshade} is an image file. Depending upon ! how it was installed, {\rayshade} writes images in either the Utah Raster {\em RLE} format or a generic but easily-manipulated {\em mtv} format used by Mark VandeWettering in his {\em mtv} ray tracer. The {\em mtv} format consists of a header giving the resolution of the image followed *************** *** 103,109 **** supports an arbitrary number of color channels, an alpha channel, comments, a history field, and the ability to treat images as windows into a larger image. As a result of this ! flexibility, a number of {\em rayshade}'s features are not supported if the {\em mtv} format is being used. You are thus strongly encouraged to obtain a copy of the Utah Raster Toolkit. --- 104,110 ---- supports an arbitrary number of color channels, an alpha channel, comments, a history field, and the ability to treat images as windows into a larger image. As a result of this ! flexibility, a number of {\rayshade}'s features are not supported if the {\em mtv} format is being used. You are thus strongly encouraged to obtain a copy of the Utah Raster Toolkit. *************** *** 112,118 **** format is used, the image will (and must) consist of three eight-bit color channels. If the {\em RLE} format is used, the image file consists of three ! eight-bit color channels plus an eight-bit alpha channel. \Rayshade also documents in the {\em RLE} header the command line and {\em gamma} value used in creating the image. --- 113,119 ---- format is used, the image will (and must) consist of three eight-bit color channels. If the {\em RLE} format is used, the image file consists of three ! eight-bit color channels plus an eight-bit alpha channel. {\Rayshade} also documents in the {\em RLE} header the command line and {\em gamma} value used in creating the image. *************** *** 122,131 **** Utah Raster Toolkit can be used to manipulate the resulting ``movie'' files. If the Toolkit is not being used, you will probably need to write ! utility programs to handle the decidedly non-standard mult-image ``mtv'' format files. ! By default, \rayshade writes the computed image to the standard output. The image file may be written to a file instead by specifying a file name in the input stream. --- 123,132 ---- Utah Raster Toolkit can be used to manipulate the resulting ``movie'' files. If the Toolkit is not being used, you will probably need to write ! utility programs to handle the decidedly non-standard multi-image {\em mtv} format files. ! By default, {\rayshade} writes the computed image to the standard output. The image file may be written to a file instead by specifying a file name in the input stream. *************** *** 137,143 **** The size of the output image is measured in pixels. The {\em x} size is the number of pixels left-to-right, while the {\em y} size is ! the number of pixels top-to-bottom. \begin{defkey}{screen}{{\em xsize ysize}} Use a screen {\em xsize} pixels wide by {\em ysize} pixels high. --- 138,144 ---- The size of the output image is measured in pixels. The {\em x} size is the number of pixels left-to-right, while the {\em y} size is ! the number of pixels bottom-to-top. \begin{defkey}{screen}{{\em xsize ysize}} Use a screen {\em xsize} pixels wide by {\em ysize} pixels high. *************** *** 185,191 **** \section{Statistics Reporting} ! As it is working, \rayshade informs you of its progress by writing messages to a ``report file''. By default, the report file is the standard error. The report itself consists of a number of progress report lines consisting of the number of eye rays traced, --- 186,192 ---- \section{Statistics Reporting} ! As it is working, {\rayshade} informs you of its progress by writing messages to a ``report file''. By default, the report file is the standard error. The report itself consists of a number of progress report lines consisting of the number of eye rays traced, *************** *** 221,235 **** If a pixel is not sampled at the proper rate, aliasing will result. Aliasing usually appears as ``jaggies'' or ``stair steps'' in the image. ! In order to reduce these and other artifacts, \rayshade provides an adaptive jittered antialiasing scheme that attempts to detect where increased sampling rates are needed. In jittered sampling, the location at which a sample is taken is perturbed by a random amount. This perturbation reduces aliasing but adds noise to the image. Appendix B describes how jittered ! time sampling is implemented in {\em rayshade}. ! The adaptive sampling scheme implemented in \rayshade begins by sampling each pixel on the current scanline once. For each pixel on the scanline, the contrast between it and its four immediate neighbors is computed. If this contrast is greater --- 222,236 ---- If a pixel is not sampled at the proper rate, aliasing will result. Aliasing usually appears as ``jaggies'' or ``stair steps'' in the image. ! In order to reduce these and other artifacts, {\rayshade} provides an adaptive jittered antialiasing scheme that attempts to detect where increased sampling rates are needed. In jittered sampling, the location at which a sample is taken is perturbed by a random amount. This perturbation reduces aliasing but adds noise to the image. Appendix B describes how jittered ! time sampling is implemented in {\rayshade}. ! The adaptive sampling scheme implemented in {\rayshade} begins by sampling each pixel on the current scanline once. For each pixel on the scanline, the contrast between it and its four immediate neighbors is computed. If this contrast is greater *************** *** 263,269 **** assign a color to a pixel. Ideally, when performing filtering for a specific pixel, the filter will consider samples from neighboring regions. In ! {\em rayshade}, the filtering applied to a pixel makes use of samples taken for that pixel alone. However, one may increase the size of the filter that is applied in order to approximate the results a more robust filtering scheme. --- 264,270 ---- assign a color to a pixel. Ideally, when performing filtering for a specific pixel, the filter will consider samples from neighboring regions. In ! {\rayshade}, the filtering applied to a pixel makes use of samples taken for that pixel alone. However, one may increase the size of the filter that is applied in order to approximate the results a more robust filtering scheme. *************** *** 271,286 **** \begin{defkey}{filter}{{\em type} [{\em width}]} Use the indicated filter type with the given width, in pixels. ! Supported filter types are {\tt gauss} (gaussian) and {\tt box} (the default). \end{defkey} ! The default filter width is 1.0 for a box filter, 1.8 for a gaussian filter. The filter and pixel centers always coincide. When sampling a pixel, samples are taken over the area of the pixel filter, which is not necessarily the same as the area of the pixel itself. ! Jittered sampling is used in \rayshade to sample extended light sources as well. A total of $samples^2$ samples are taken of each extended light source in order to determine the extent of shadowing. --- 272,287 ---- \begin{defkey}{filter}{{\em type} [{\em width}]} Use the indicated filter type with the given width, in pixels. ! Supported filter types are {\tt gauss} (Gaussian) and {\tt box} (the default). \end{defkey} ! The default filter width is 1.0 for a box filter, 1.8 for a Gaussian filter. The filter and pixel centers always coincide. When sampling a pixel, samples are taken over the area of the pixel filter, which is not necessarily the same as the area of the pixel itself. ! Jittered sampling is used in {\rayshade} to sample extended light sources as well. A total of $samples^2$ samples are taken of each extended light source in order to determine the extent of shadowing. *************** *** 295,301 **** to the final picture; if it is not allowed to grow far enough, this premature tree pruning may be evident in the image. ! {\em Rayshade} provides two complimentary methods for controlling the depth of the ray tree. One method sets an absolute maximum for the tree. The other allows one to adaptively prune a tree as it grows so that ``unimportant'' rays are not spawned. --- 296,302 ---- to the final picture; if it is not allowed to grow far enough, this premature tree pruning may be evident in the image. ! {\Rayshade} provides two complementary methods for controlling the depth of the ray tree. One method sets an absolute maximum for the tree. The other allows one to adaptively prune a tree as it grows so that ``unimportant'' rays are not spawned. Index: Doc/Guide/objects.tex *** old/Doc/Guide/objects.tex Mon Feb 3 12:49:56 1992 --- new/Doc/Guide/objects.tex Fri Jan 17 10:29:15 1992 *************** *** 1,6 **** \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, --- 1,6 ---- \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, *************** *** 15,21 **** 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 --- 15,21 ---- 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 *************** *** 25,33 **** \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. --- 25,33 ---- \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. *************** *** 67,73 **** group of one or more metaballs. Each metaball is defined by its position \evec{p}, radius {\em r}, and strength {\em st}. \end{defprim} ! For now, see the source code for more explicit documentation. There is no inverse mapping method for blobs. \begin{defprim}{box}{\evec{corner1} \evec{corner2}} --- 67,77 ---- 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}} *************** *** 132,143 **** \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}{heightfield}{{\em file}} --- 136,147 ---- \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}} *************** *** 254,269 **** 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 --- 258,273 ---- 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 *************** *** 309,318 **** \subsection{Potential CSG Problems} A consistent CSG model is one which is made ! up of solid objects with no dangling surfaces. In {\em rayshade}, it is quite easy to construct inconsistent models, which will usually appear incorrect in the final images. ! In {\em 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 --- 313,322 ---- \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 *************** *** 358,364 **** Such problems are often caused by polygons with incorrectly specified normals, or by surfaces that exactly coincide (which ! appear as partial ``swissh-cheese'' objects). The following example illustrates an attempt to subtract a sphere from a pyramid defined using an incorrectly facing triangle. Note --- 362,368 ---- 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 *************** *** 387,393 **** \section {Named Objects} ! A name may be associated with any primitive, aggregate, or CS object through the use of the {\tt name} keyword: --- 391,397 ---- \section {Named Objects} ! A name may be associated with any primitive, aggregate, or CSG object through the use of the {\tt name} keyword: Index: Doc/Guide/surfaces.tex *** old/Doc/Guide/surfaces.tex Mon Feb 3 12:50:02 1992 --- new/Doc/Guide/surfaces.tex Fri Jan 17 10:29:14 1992 *************** *** 8,17 **** the ``interior'' of an object is the ``other side'' of the object's surface relative to the origin of a ray. ! Rayshade usually ensures that a primitive's surface normal is pointing towards the origin of the incident ray when performing shading calculations. Exceptions to this rule are transparent primitives, for ! which rayshade uses the direction of the surface normal to determine if the incident ray is entering or exiting the object. All non-transparent primitives will, in effect, be double-sided. --- 8,17 ---- the ``interior'' of an object is the ``other side'' of the object's surface relative to the origin of a ray. ! {\Rayshade} usually ensures that a primitive's surface normal is pointing towards the origin of the incident ray when performing shading calculations. Exceptions to this rule are transparent primitives, for ! which {\rayshade} uses the direction of the surface normal to determine if the incident ray is entering or exiting the object. All non-transparent primitives will, in effect, be double-sided. *************** *** 26,32 **** with the exception of the index of refraction, which is assigned the default index of refraction (normally 1.0). ! Surface descriptions are used in rayshade to compute the color of a ray that strikes the surface at a point \evec{P}. The normal to the surface at \evec{P}, \evec{N}, is also computed. --- 26,32 ---- with the exception of the index of refraction, which is assigned the default index of refraction (normally 1.0). ! Surface descriptions are used in {\rayshade} to compute the color of a ray that strikes the surface at a point \evec{P}. The normal to the surface at \evec{P}, \evec{N}, is also computed. *************** *** 55,61 **** \end{defkey} \begin{defkey}{specpow}{{\em exponent}} ! Specifies the specular highlight) exponent. \end{defkey} The intensity of specular highlights from light sources are scaled by the specular color of the surface. --- 55,62 ---- \end{defkey} \begin{defkey}{specpow}{{\em exponent}} ! Controls the size of the specular highlight. The larger ! the {\em exponent}, the smoother the apparent finish. \end{defkey} The intensity of specular highlights from light sources are scaled by the specular color of the surface. *************** *** 106,115 **** \section{Atmospheric Effects} ! Any number of atmospheric effects may also be associated with a surface. ! These effects will be applied to those rays that are transmitted through ! the surface. Applying atmospheric effects to opaque objects is a waste ! of input file. \begin{defkey}{fog}{\evec{color} \evec{thinness}} Add exponential fog with the specified {\em thinness} and {\em color}. --- 107,114 ---- \section{Atmospheric Effects} ! Any number of atmospheric effects may be associated with the default ! medium (``air''). \begin{defkey}{fog}{\evec{color} \evec{thinness}} Add exponential fog with the specified {\em thinness} and {\em color}. *************** *** 125,131 **** \begin{defkey}{mist}{\evec{color} \evec{thinness} {\em zero scale}} Add global low-altitude mist of the specified color. The color of a ray is modulated by a fog with density that varies linearly with ! the difference in $z$ coordinate (altitude) between the ray origin and the point of intersection. The thinness values specify the transmissivity of the fog for each color channel. The base altitude of the --- 124,132 ---- \begin{defkey}{mist}{\evec{color} \evec{thinness} {\em zero scale}} Add global low-altitude mist of the specified color. The color of a ray is modulated by a fog with density that varies linearly with ! the difference in $z$ coordinate\footnote{This all but assumes that ! the default up vector (0, 0, 1) is being used.} ! between the ray origin and the point of intersection. The thinness values specify the transmissivity of the fog for each color channel. The base altitude of the *************** *** 134,139 **** --- 135,146 ---- altitude used to compute the fog. \end{defkey} + \begin{defkey}{fogdeck}{{\em altitude} {\em offset} \evec{scale} {\em chaoscale} + \evec{color} \evec{thinness}} + Add low-altitude fog, with transmissivity modulated by + a chaotic function. + \end{defkey} + \section {The Default Medium} The default medium is the medium which surrounds and encompasses *************** *** 161,167 **** \section {Surface Specification} ! {\em Rayshade} provides a number of ways to define surfaces and to bind these surfaces to objects. The most straight-forward method of surface specification is to simply list the surface properties to be used. --- 168,174 ---- \section {Surface Specification} ! {\Rayshade} provides a number of ways to define surfaces and to bind these surfaces to objects. The most straight-forward method of surface specification is to simply list the surface properties to be used. *************** *** 179,190 **** is used to give the primitive its appearance. An object that has no surface bound to it is assigned a default surface ! that give an object the appearance of white plastic. ! The first ! and most direct way to bind a surface to a primitive ! is by specifying the surface to be bound to ! the primitive when it is instantiated. This is accomplished by inserting a list of surface attributes or a surface name after the primitive's type keyword and before the actual primitive data. --- 186,197 ---- is used to give the primitive its appearance. An object that has no surface bound to it is assigned a default surface ! that gives the appearance of white plastic. ! The ! most direct way to bind a surface to a primitive ! is to specify the surface when the ! the primitive instantiated. This is accomplished by inserting a list of surface attributes or a surface name after the primitive's type keyword and before the actual primitive data. *************** *** 205,211 **** a sphere, which has a diffuse white surface bound to it. The next line instantiates a sphere with the defined ``mud'' surface bound to it. The last line instantiates a sphere with no surface bound to it; ! it is assigned the default surface by {\em rayshade}. The {\tt applysurf} keyword may be used to set the default surface characteristics for the aggregate object currently being defined. --- 212,218 ---- a sphere, which has a diffuse white surface bound to it. The next line instantiates a sphere with the defined ``mud'' surface bound to it. The last line instantiates a sphere with no surface bound to it; ! it is assigned the default surface by {\rayshade}. The {\tt applysurf} keyword may be used to set the default surface characteristics for the aggregate object currently being defined. Index: Doc/Guide/preface.tex *** old/Doc/Guide/preface.tex Mon Feb 3 12:42:37 1992 --- new/Doc/Guide/preface.tex Fri Jan 17 10:29:12 1992 *************** *** 1,20 **** \chapter*{Preface} \addcontentsline{toc}{chapter}{Preface} ! {\em Rayshade} is a program for creating ray-traced images. It reads a description of a scene to be rendered and produces a color image corresponding to the description. ! {\em Rayshade} was designed to make it easy to create nice pictures. It was also meant to be flexible, easy to modify, and relatively fast. ! The first version of \rayshade was written in 1987-1998 at Princeton University with help and encouragement from David Dobkin and David Hoffman. That version was heavily based on a public-domain ``introductory'' ray tracer written by Roman Kuchkuda. ! Changes to \rayshade from that point until version 4.0 were evolutionary in nature. The current version is to a large extent a re-write, and an attempt has been made to remove some of the fundamental --- 1,20 ---- \chapter*{Preface} \addcontentsline{toc}{chapter}{Preface} ! {\Rayshade} is a program for creating ray-traced images. It reads a description of a scene to be rendered and produces a color image corresponding to the description. ! {\Rayshade} was designed to make it easy to create nice pictures. It was also meant to be flexible, easy to modify, and relatively fast. ! The first version of {\rayshade} was written in 1987-1988 at Princeton University with help and encouragement from David Dobkin and David Hoffman. That version was heavily based on a public-domain ``introductory'' ray tracer written by Roman Kuchkuda. ! Changes to {\rayshade} from that point until version 4.0 were evolutionary in nature. The current version is to a large extent a re-write, and an attempt has been made to remove some of the fundamental *************** *** 21,56 **** problems present in previous incarnations. I wish to thank the many people who have made ! contributions to the development of {\em rayshade} during the past four years. Thanks to Marc Andreessen, Ray Bellis, Dominique Boisvert, William Bouma, Allen Braunsdorf, Jeff Butterworth, Nick Carriero, Nancy Everson, Tom Friedel, Robert Funchess, David Gelernter, Mike Gigante, Ed Herderick, John Knuston, Raphael Manfredi, Lee Moore, Dietmar Saupe, Brian Wyvill, ! and everybody else for their bug-fixes, suggestions, input files, encouragement, support, and other feedback. David Dobkin first suggested that an extensible ray tracer would be a worthwhile project. Gavin Bell, David Hoffman, Lefteris Koutsofios, and Steven North ! were the first users of the original \rayshade, and their feedback showed that the project might indeed have a future. In the Fall of 1988, Przemyslaw Prusinkiewicz encouraged me ! to develop \rayshade further, and was, as always, full of ``insanely ! great'' ideas. The resulting version of \rayshade was released ! on UseNet in 1989. Allan Snider was particularly helpful in finding bugs in version 3.0 and in making valuable suggestions as to how the program might be improved. ! {\em Rashade} version 4.0 was written by Craig Kolb and Rod Bogart during 1990-1991, with contributions of ideas and code made by many others. Pat Hanrahan's {\em OOGL} provided the spirit, if not the letter, of the modularity of the version 4.0. Thanks to Pat and to Mark VandeWettering for the ``net tracer'' conversations and for the inspiration to do something ! to clean up {\em rayshade}. Eric Haines saved the day on more than one occasion by suggesting ! improvements, finding bugs, and saying nice things about \rayshade when I was all but ready to throw in the towel. Robert Skinner was kind enough to provide the {\em Noise()}, {\em DNoise()}, and other texturing functions and to allow them to be redistributed. --- 21,57 ---- problems present in previous incarnations. I wish to thank the many people who have made ! contributions to the development of {\rayshade} during the past four years. Thanks to Marc Andreessen, Ray Bellis, Dominique Boisvert, William Bouma, Allen Braunsdorf, Jeff Butterworth, Nick Carriero, Nancy Everson, Tom Friedel, Robert Funchess, David Gelernter, Mike Gigante, Ed Herderick, John Knuston, Raphael Manfredi, Lee Moore, Dietmar Saupe, Brian Wyvill, ! and the hundreds of others who have provided ! bug-fixes, suggestions, input files, encouragement, support, and other feedback. David Dobkin first suggested that an extensible ray tracer would be a worthwhile project. Gavin Bell, David Hoffman, Lefteris Koutsofios, and Steven North ! were the first users of the original {\rayshade}, and their feedback showed that the project might indeed have a future. In the Fall of 1988, Przemyslaw Prusinkiewicz encouraged me ! to develop {\rayshade} further, and was, as always, full of ``insanely ! great'' ideas. The resulting version of {\rayshade} was released ! on Usenet in 1989. Allan Snider was particularly helpful in finding bugs in version 3.0 and in making valuable suggestions as to how the program might be improved. ! {\Rayshade} version 4.0 was written by Craig Kolb and Rod Bogart during 1990-1991, with contributions of ideas and code made by many others. Pat Hanrahan's {\em OOGL} provided the spirit, if not the letter, of the modularity of the version 4.0. Thanks to Pat and to Mark VandeWettering for the ``net tracer'' conversations and for the inspiration to do something ! to clean up {\rayshade}. Eric Haines saved the day on more than one occasion by suggesting ! improvements, finding bugs, and saying nice things about {\rayshade} when I was all but ready to throw in the towel. Robert Skinner was kind enough to provide the {\em Noise()}, {\em DNoise()}, and other texturing functions and to allow them to be redistributed. *************** *** 58,69 **** Jochen Schwarze's cubic and quartic root-finding functions. Major Thanks to Rod Bogart for being willing to take the plunge and play such a large role in the development of version 4.0. ! I am most grateful to Benoit Mandelbrot for his ! continued support and inspiration. \begin{flushright} \parbox[t]{1.5in}{ C. Kolb \\ ! February 13, 1991 } \end{flushright} --- 59,70 ---- Jochen Schwarze's cubic and quartic root-finding functions. Major Thanks to Rod Bogart for being willing to take the plunge and play such a large role in the development of version 4.0. ! I am most grateful to Benoit Mandelbrot for his support of this ! project and the inspiration he provided. \begin{flushright} \parbox[t]{1.5in}{ C. Kolb \\ ! January 10, 1992 } \end{flushright} Index: Doc/Guide/camera.tex *** old/Doc/Guide/camera.tex Mon Feb 3 12:42:51 1992 --- new/Doc/Guide/camera.tex Fri Jan 17 10:29:12 1992 *************** *** 1,6 **** \chapter{Specifying a View} ! When designing a \rayshade input file, there are two main issues that must be considered. The first and more complex is the selection of the objects to be rendered and the appearances they should be assigned. The second and usually easier issue is --- 1,6 ---- \chapter{Specifying a View} ! When designing a {\rayshade} input file, there are two main issues that must be considered. The first and more complex is the selection of the objects to be rendered and the appearances they should be assigned. The second and usually easier issue is *************** *** 8,14 **** latter problem; the majority of the following chapters discuss aspects of objects and their appearances. ! {\em Rayshade} uses a camera model to describe the geometric relationship between the objects to be rendered and the image that is produced. This relationship describes a perspective projection from world space onto the image plane. --- 8,14 ---- latter problem; the majority of the following chapters discuss aspects of objects and their appearances. ! {\Rayshade} uses a camera model to describe the geometric relationship between the objects to be rendered and the image that is produced. This relationship describes a perspective projection from world space onto the image plane. *************** *** 23,29 **** reference ``up'' vector from the camera's position. The image ! ultimately produced by rayshade may then be thought of as the projection of the objects closest to the eye onto a rectangular screen formed by the intersection of the pyramid with a plane orthogonal to the pyramid's axis. The overall shape --- 23,29 ---- reference ``up'' vector from the camera's position. The image ! ultimately produced by {\rayshade} may then be thought of as the projection of the objects closest to the eye onto a rectangular screen formed by the intersection of the pyramid with a plane orthogonal to the pyramid's axis. The overall shape *************** *** 38,44 **** in which it is pointing, and its orientation. The keywords for specifying these values are described below. The default values ! are designed to provide a reasonable view of a sphere or radius 2 located at origin. If these default values are used, the origin is projected onto the center of the image plane, with the world $x$ axis running left-to-right, the $z$ axis bottom-to-top, --- 38,44 ---- in which it is pointing, and its orientation. The keywords for specifying these values are described below. The default values ! are designed to provide a reasonable view of a sphere of radius 2 located at origin. If these default values are used, the origin is projected onto the center of the image plane, with the world $x$ axis running left-to-right, the $z$ axis bottom-to-top, *************** *** 131,140 **** may then be viewed on a stereo monitor, in a stereo slide viewer, or by using colored glasses and an appropriate display filter. ! Rayshade facilitates the rendering of stereo pairs by allowing you to specify the distance between the camera positions used in creating the two images. The camera position given in the ! \rayshade input file defines the midpoint between the two camera positions used to generate the images. --- 131,140 ---- may then be viewed on a stereo monitor, in a stereo slide viewer, or by using colored glasses and an appropriate display filter. ! {\Rayshade} facilitates the rendering of stereo pairs by allowing you to specify the distance between the camera positions used in creating the two images. The camera position given in the ! {\rayshade} input file defines the midpoint between the two camera positions used to generate the images. *** End of Patch 3 ***