diff --git a/cs658/html/class-diagram.png b/cs658/html/class-diagram.png new file mode 100644 index 0000000..7fd7640 Binary files /dev/null and b/cs658/html/class-diagram.png differ diff --git a/cs658/html/csg.png b/cs658/html/csg.png new file mode 100644 index 0000000..6b1dc6a Binary files /dev/null and b/cs658/html/csg.png differ diff --git a/cs658/html/design.html b/cs658/html/design.html new file mode 100644 index 0000000..ec03e29 --- /dev/null +++ b/cs658/html/design.html @@ -0,0 +1,106 @@ + + +
+ ++ FART is my semester project for the Computer Science 658 class at Grand Valley State University. My goal is for FART to be a distributed, object-oriented ray-tracer. The name is a recursive acronym similar to "GNU" or "LAME." +
+ ++ FART will take in a scene-description file in a text-based input file format. After the scene file is parsed, it will be raytraced (rendered) according to the render options. Some of these options can be specified on the command line and others can be specified in the scene description file. When a given option can be specified both places, the command-line options will override what is in the scene file. +
+ ++ Rendering can be done using a built-in distributed algorithm. Command-line options will be utilized to specify a "host file" which can contain a list of hosts to use while rendering the scene. The algorithm will be fault-tolerant so that if one of the worker nodes goes down the work can be reorganized to complete that section of the image. +
+ ++ The instance of the program which is directly invoked by the user will be the "master" process. If a host file is specified as an argument to the program, then the master process will read a list of hosts to use as worker nodes. It will spawn an instance of the program on each worker node, and dole out chunks of the image to each worker node in a master/slave, client/server manner. + +
+ Since the amount of time to render a given chunk of the image can vary tremendously depending on the number of objects in the scene, the maximum recursion depth, and the antialiasing level, the master process does not know how long it should wait to expect a reply from the worker nodes. Therefore, a thread on the master node will be dedicated to polling all the worker nodes at an interval of some number of seconds. The worker nodes should respond to this polling message with a "still working" message to indicate that they are still up and are processing data. If a given worker node does not reply to the polling message, it will be considered "down" and the work it was processing will be doled out to another node. +
+ ++ In this way, the raytracer program will be fault-tolerant. It can tolerate each of the worker nodes going down and still produce the final image. +
+ ++ The follows the object-oriented design paradigm. It is made up of a collection of modules, which are organized into functional groupings. Each module implements one or more classes of objects for the system. The groupings of modules are utility modules, scene description file parsing modules, shape modules, program distribution modules, and main program modules. +
+ +
+
+
+ The actual scene will be rendered by tracing rays from the virtual camera's position in space through a virtual plane perpendicular to the view direction which represents the image being rendered. For each pixel, a total of m2 rays will be launched, where m is the multi-sample level set by the user. Setting a multi-sample level greater than 1 effectively produces an anti-aliased image. +
+ ++ Rays are collided with objects in the scene, and the closest object to the viewer that is hit by the ray is recorded. When this object has been found, its material properties are examined for lighting information, reflection levels, and transparency levels. Unless the object is completely transparent or reflective, for each light in the scene, a ray is launched from the contact point on the surface of the closest object to the light source. If the ray hits the light source then the Phong lighting model is computed to calculate the color for that point on the surface. If the ray instead hits another object instead of the light source, then that light source does not add to the color at that point, effectively producing a shadow. +
+ ++ After calculating the light source's contributions to the color, the algorithm will recurse if the surface has non-zero reflectivity or transparency. This allows the scene to accurately be drawn from a reflected point of view from a particular surface. This is one of the major strengths of the ray-tracing algorithm. +
+ ++ When the scene attempts to determine if a given ray collides with a shape, it calls the virtual function intersect() on the shape. This function is overridden in all shape objects. It returns a list of (shape, point) intersection pairs telling which shape was hit and which point it was hit at. The reason it returns the shape hit is because the shape object inquired may be a composite object of some sort (such as an intersection, union, or subtraction of sub-shapes). Thus, the caller knows which actual shape object was hit and can thus use this shape object to determine material properties and the surface normal at the intersection point. +
++ FART is my semester project for the Computer Science 658 class + at Grand Valley State University. + My goal is for FART to be a distributed, object-oriented raytracer. + The name is a + recursive acronym similar to GNU or LAME. +
++ FART will take in a scene-description file in some sort of + ASCII-based input file format. + After the scene file is parsed, it will be raytraced (rendered) + according to the render options. + Some of these options can be specified on the command line and + others can be specified in the scene description file. + When a given option can be specified both places, the command-line + options will override what is in the scene file. +
++ Rendering can be done using the built-in distributed algorithm. + Command-line options will be utilized to specify a "host file" + which can contain a list of hosts to use while rendering the scene. + The algorithm will be fault-tolerant so that if one of the worker + nodes goes down the work can be reorganized to complete that + section of the image. +
+ ++ You can retrieve a copy of FART from my Subversion repository + using the command + svn co svn://holtrop.homelinux.com/fart/trunk fart + Build using make + and run with something like + ./fart scenes/infinity.fart +
+ +
+
+
+ Revision 25 - I can write .bmp files but I'm not doing
+ anything with scene data yet.
+
+
+
+ Revision 43 - FART can intersect a ray with a sphere
+ but doesn't have lighting/shading/material colors yet...
+
+
+
+ Revision 45 - cheap lighting based on implicit light source
+ at the viewpoint
+
+
+
+ Revision 46 - multisampling is working (back to a flatly-shaded
+ sphere to show the anti-aliasing effect on the edges)
+
+
+
+ Revision 62 - added a Plane shape type, I really need to
+ get some better lighting working
+
+
+
+ Revision 76 - Phong shading model working with
+ ambient, diffuse, and specular light components
+
+
+
+ Revision 121 - Added a Box object. No, it didn't take 45 revisions
+ just for that. I've been working on the parser for the scene input
+ files a lot as well.
+
+
+
+ Revision 134 - Added a Cyl object.
+ Cyl objects can be cones or cylinders - they have a bottom
+ radius, a top radius, and a height.
+
+
+
+ Revision 155 - Boolean intersections working.
+ I had to rework the way I was returning intersections to also
+ return a reference to the actual shape that was intersected with
+ so that Intersect shapes would really return the child shape that
+ produced the point.
+
+
+
+ Revision 162 - a few bug fixes, and added Union and Subtract
+ shape types.
+
+
+
+ Revision 176 - More bug fixes, and reading the scene description
+ from a file is finally working!
+
+
+
+ Revision 180 - Material definitions working
+
+
+
+ Revision 187 - Recursion working for transparent objects.
+ Rays sent from surface point to each light source now intersect
+ with other objects to produce shadows depending on the transparency
+ of the objects between the surface point and the light source.
+
+
+
+ Revision 196 - Added scenes/csg.fart as an example of doing
+ CSG.
+ Also fixed a bug in the loading of boolean objects.
+
+
+
+ Revision 202 - Changed intersection method to also return surface
+ normals (instead of accessing them through a separate function,
+ getNormalAt()).
+ This allowed Subtract objects to invert the normals obtained by
+ the sub-object being subtracted out.
+ This, in turn, allowed subtractions of subtractions to re-invert
+ them, and so on and so forth...
+