Project 2 : Trace
Assigned: Thursday, October 15th, 3:00pm
Due: Friday, October 30th, 4:00pm
Artifact Due: Monday, November 2nd, 11:59pm
Assigned: Thursday, October 15th, 3:00pm
Due: Friday, October 30th, 4:00pm
Artifact Due: Monday, November 2nd, 11:59pm
Trace is a program that constructs recursively ray-traced images of fairly simple scenes.
It is similar in functionality to the POV-Ray raytracer. You may
want to browse around the POV-Ray web site for artifact and extra credit inspiration. POV-Ray is
free, so if you want a taste of what a really powerful raytracer can do, go check it out!
To get started, checkout the skeleton code from your SVN repository (details below). Compare its functionality with the sample solution (link above). You'll also find a "scenes" subdirectory which contain sample scene files (all the files with the .ray extension). These are text files that describe some geometry and the material that should be applied to them. Refer to this page for a brief explanation. Load a scene and press Render in the UI to see the rendering.
The Trace project is a very large collection of files and object-oriented C++ code. Fortunately, you only need to work directly with a subset of it. However, you will probably want to spend a bit of time getting familiar with the layout and class hierarchy at first, so that when you code, you know what classes and methods are available for your use.
The starting point for where ray tracing begins, and where you will be needing to add a lot of functionality, is in the RayTracer.cpp file. This is a good file to start studying and exploring what methods get called and what they do. In addition, the raytracer features a debugging window that allows you to see individual rays bouncing around the scene. This window provides a lot of visual feedback that can be enormously useful when debugging your application. Look at this web page for a detailed explanation of how to use the debugging window.
In order to get the source code, follow the directions below:
Graphics Lab:
$ git clone git@gitlab.cs.washington.edu:cse557-15au-trace/YOUR-REPO.git trace
Working from Home:
If you plan to work from home, you will either need to use the FLTK Installer or point Visual Studio to the correct include and library directories for the FLTK that came in your repository (since normally it points to the local one on each lab machine). Instructions for how to do this.
Before you begin coding, you should run the sample solution; it is linked to above. It has all of the requirements implemented, along with some extra features. Definitely check out the helpful debug mode!
As you get into the project, you'll probably want to use some scenes of your own invention. There is a help page available about the file format. This file also describes the specifications of all the primitives you are required to implement. To create realistic refractive objects, you'll need their Indices of Refraction.
Once you implement the requirements listed below, you'll be able to test it with this automated tool. This tool compares your program's output against the sample solution's. A README is included to help you use the tool.
NOTE: It is in your best interest to test your ray tracer against the sample solution in a pixel level. We provide a comparison tool in the skeleton code for Windows users. This is what the TAs will be using to grade the correctness and functionality of your ray tracer. Mac and Linux users please download ImageMagick and use its "compare" executable.
Don't worry if your solution doesn't give exactly the same output (rounding errors, among other things, are a fact of life). This tool is only to get an idea of where to look for problems. Note that your bells and whistles must be disabled for the tool to accurately check against the sample.NOTE: Memory Leaks: It is strongly advised your program does not have any memory leaks! For more information check out this summary. To check if you have a memory leak in ray.exe, render dragon full depth, antialiasing, max size, etc. Do a ctrl+shift+Esc and watch ray.exe's memory consumption. If it is increasing to no end you probably have a leak. It is likely the program will crash out after some point. Why we care?! It is extremely frustrating for your render to stop 91% complete night of Artifact turn in!
After running the sample solution, you should build the skeleton code and see how it compares. You will probably notice that there is a significant difference in the quality of images rendered with the two versions. This suggests what parts of the raytracer have been written and what parts are left undone.
If you compare the outputs of the skeleton and solution, you will see that most of the basic geometry-handling code is done. The skeleton code is able to cast rays into an image and draw color on the screen, resulting in some flat-shaded polygonal shapes. The skeleton code is doing ray-casting and nothing more. Furthermore, the triangle and sphere primitives will not appear. While all the code to cast a ray exists, not all of the object intersections code is there. You need to implement sphere and triangle intersections and expand ray-casting into ray-tracing by adding support for reflected and refracted rays. You also must implement the Blinn-Phong specular-reflection model and include support for color-filtered shadows cast through transparent objects.
Specifically, each group must implement recursive ray tracing as described in class. This entails making the extensions to the program listed below. Your ray tracer should recursively trace rays to account for these. Recursion should proceed to a maximum depth as set by the user.
| Extension | Shirley's book |
|---|---|
| Triangle Intersection | 4.4.2 (Also see lecture notes) |
| Sphere Intersection | 4.4.1 |
| Blinn-Phong specular-reflection model | 4.5.2 (Also see lecture notes. Important: clamp N dot H) |
Barycentric Interpolation
|
2.7 and 10.2.2 (And see lecture notes) |
|
Contribution from: multiple light sources, distance attenuation, and these additional types of lights:
|
4.5.4 (Also see lecture notes) |
Shadow Attenuation
|
10.7
(Implement filtered transparency as discussed in class) |
| Reflection | 13.1 |
| Refraction |
13.1
(Ignore Fresnel term and Beer's Law, which are whistles) |
Accelerations
|
Chapter 12 |
| Anti-aliasing | 13.4.1 (regular sampling approach, and see lecture notes) |
NOTE: You may assume that objects are not nested inside other objects. If a refracted ray enters a solid object, it will pass completely through the object and back outside before refracting into another object. Improving your refraction code to handle more general cases such as a refractive sphere contained inside another refractive sphere is an extra credit option as described below. In addition, you may assume that the camera itself is not placed inside an object. The initial rays that are sent out through the projection plane will always be moving through air.
NOTE:
When calculating the intersection for triangles, you may have 3 values for the normal and the material (one for each vertex). You will have to interpolate these values in order to get the proper value. Don't forget to renormalize the interpreted normal!
If the normal is not available, you may assume that it is just the normal used in the intersection
calculation, i.e., the normal to the plane that the triangle lies in. dragon.ray, shell.ray,
sierpinski.ray, house.ray, and trimesh2.ray all require material interpolation support in order to
appear as they are rendered by the sample solution.
NOTE:
Some of the provided scenes need features that are not required in order to render correctly.
shell.ray, sierpinski.ray, and z-polytest.ray
all require material interpolation support (which is extra credit) in order to appear as they are
rendered by the sample solution. And, texture_glass_ball.ray, texture_mapping.ray, and
texture_reflection.ray use texture mapping (also extra credit). So, if you are testing
with these scenes, do not worry if your results are different (and other scenes appear fine).
For this project, you are not required to implement any bells or whistles. At this time, we hope that you are already in the habit of thinking about extra features when you start the project. Even the simple bells and whistles can make significant changes in your ray traced scenes.
Most of your effort should be spent on approach 2, i.e. reducing the number of ray-object intersection tests. You are free to experiment with any of the acceleration schemes described in Chapter 6, ''A Survey of Ray Tracing Acceleration Techniques,'' of Glassner's book. Of course, you are also free to invent new acceleration methods.
Make sure that you design your acceleration module so that it is able to handle the current set of geometric primitives - that is, triangles spheres, squares, boxes, and cones.
The sample scenes include several simple scenes and three complex test scenes: trimesh1, trimesh2, and trimesh3. You will notice that trimesh1 has per-vertex normals and materials, and trimesh2 has per-vertex materials but not normals. Per-vertex normals and materials imply interpolation of these quantities at the current ray-triangle intersection point (using barycentric coordinates).
The test scenes each contain up to thousands of triangles. A portion of your grade for this assignment will be based on the speed of your ray tracer running on these scenes. The faster you can render a picture, the higher your grade.
For grading on the rendering speed, the scenes will be traced at the specific size with one ray traced per pixel, and the rays should be traced with 5 levels of recursion, i.e. each ray should bounce 5 times. If during these bounces you strike surfaces with a zero specular reflectance and zero refraction, stop there. At each bounce, rays should be traced to all light sources, including shadow testing. Execution will be forced to single threading. The command for testing rendering speed looks like:
ray -b -w 400 -r 5 -t 1 in.ray out.bmp[For fairness, don't include other stop criteria (except for the one mentioned above) for -b option.]
You are welcome to precompute scene-specific (but not viewpoint-specific) acceleration data structures and make other time-memory tradeoffs, but your precomputation time and memory use should be reasonable. Don't try to customize your ray tracer for the test scenes; we will also use other scenes during grading. If you have any questions about what constitutes a fair acceleration technique, ask us. Coding your inner loops in machine language is unfair. Using multiple processors is unfair. Compiling with optimization enabled is fair. In general, don't go overboard tuning aspects of your system that aren't related to tracing rays.
Each team is required to submit one artifact per person. Name the file <your-cse-netid>.jpg or <your-cse-netid>.png. The scene traced cannot be one of the provided .ray files but must at least be modified in some way (or a completely new scene). With each artifact, you may also submit some brief comments -- this can be as simple as two sentences describing the placement of the objects and lights to get the desired effect or a detailed description of the bells and whistles used to create the scene. The comments will be posted with your artifact on the webpage for voting.
NOTE: Originality There is much room to create something really cool for your artifact, and we encourage you to spend a little time on it (at least more than 10 minutes!). In particular, your Trace artifact should not be too similar to one of the sample scenes. If your rendering is simply based on a tweaked version of a sample scene (e.g., you just rotated the camera X degrees in two axes, or changed the color of an object) then you will lose some (easy) points on turn in.
Same turn in procedure as other projects. In project directory, put source code in turnin/source folder and an executable in turnin/binary folder.
Submit source and binary per team here
Submit one artifact per student here
NOTE: Compile executable in Release Mode! There is a drastic increase in performance by compiling and executable in release mode vs compiling in debug mode. Also ensure that the code compiles on Windows, to aid in the comparison grading.
NOTE: If you implement any bells or whistles you need to provide examples of these features in effect. You should present your extra credit features at grading time either by rendering scenes that demonstrate the features during the grading session or by showing images you rendered in advance. You might need to pre-render images if they take a while to compute (longer than 30 seconds). These pre-rendered examples, if needed, must be included in your turnin directory on the project due date. The scenes you use for demonstrating features can be different from what you end up submitting as an artifact.
Both Shirley's book and Foley, et al., are reasonable resources for implementing bells and whistles. In addition, Glassner's book on ray tracing is a very comprehensive exposition of a whole bunch of ways ray tracing can be expanded or optimized (and it's really well written). If you're planning on implementing any of these bells and whistles, you are encouraged to read the relevant sections in these books as well.
Remember that you'll need to establish to our satisfaction that you've implemented the extension! You should have test cases that clearly demonstrate the effect of the code you've added to the ray tracer. Sometimes different extensions can interact, making it hard to tell how each contributed to the final image, so it's also helpful to add controls to selectively enable and disable your extensions. In fact, we require that all extensions be disabled by default, with controls to turn them on one by one.
Here are some examples of effects you can get with ray tracing. Currently none of these were created from past students' ray tracers.
Implement an adaptive termination criterion for tracing rays, based on ray contribution.
Control the adaptation threshold with a slider.
Modify your antialiasing to implement the first stage of distribution ray tracing
by jittering the sub-pixel samples. The noise introduced by jittering should be evident
when casting 1 ray per pixel.
Modify shadow attenuation to use Beer's law, so that the thicker objects cast darker
shadows than thinner ones with the same transparency constant. (See Shirley p. 214.)
Include a Fresnel term so that the amount of reflected and refracted light at a
transparent surface depend on the angle of incidence and index of refraction. (See Shirley p. 214.)
Implement spot lights (described in the shading lecture). You'll have to extend the parser to
handle spot lights but don't worry, this is low-hanging fruit.
Improve your refraction code to allow rays to refract correctly through objects that
are contained inside other objects. You must put together a .ray file to demonstrate this effect.
Add a menu option that lets you specify a background image to replace the environment's
ambient color during the rendering. That is, any ray that goes off into infinity behind the scene
should return a color from the loaded image, instead of just black. The background should appear
as the backplane of the rendered image with suitable reflections and refractions to it. This
is also called environment mapping. Click here
for some examples.
Find a good way to accelerate shadow attenuation. Do you need to check against every
object when casting the shadow ray? This one is hard to demonstrate directly, so be prepared to
explain in detail how you pulled it off.
Deal with overlapping objects intelligently. While the skeleton code handles materials
with arbitrary indices of refraction, it assumes that objects don't intersect one another.
It breaks down when objects intersect or are wholly contained inside other objects. Add support
to the refraction code for detecting this and handling it in a more realistic fashion.
Note, however, that in the real world, objects can't coexist in the same place at the same time.
You will have to make assumptions as to how to choose the index of refraction in the overlapping space.
Make those assumptions clear when demonstrating the results.
Implement antialiasing by adaptive supersampling, as described in Foley, et al., 15.10.4.
For full credit, you must show some sort of visualization of the sampling pattern that results.
For example, you could create another image where each pixel is given an intensity proportional
to the number of rays used to calculate the color of the corresponding pixel in the ray traced image.
Implementing this bell/whistle is a big win -- nice antialiasing at low cost.
Implement more versatile lighting controls, such as the Warn model described in Foley 16.1.5.
This allows you to do things like control the shape of the projected light.
Implement support for multithreaded anti-aliasing . This means splitting up the anti-aliasing amongst multiple processess.
You'll definitely need to make use of the ThreadPool.cpp class.
This is probably not too difficult if you have taken Operating Systems.
If not, check out some info on Pthreads and threading
here.
We need to see some code and/or a convincing performance demonstration for credit.
Add texture mapping support to the program. To get full credit for this, you must add uv coordinate mapping
to all the built-in primitives (sphere, box, cylinder, cone) except trimeshes. The square object already has
coordinate mapping implemented for your reference. The most basic kind of texture mapping is to apply the map
to the diffuse color of a surface. But many other parameters can be mapped. Reflected color can be mapped to create
the sense of a surrounding environment. Transparency can be mapped to create holes in objects. Additional (variable)
extra credit will be given for such additional mappings. The basis for this bell is built into the skeleton, and the
parser already handles the types of mapping mentioned above. Additional credit will be awarded for quality implementation
of texture mapping on general trimeshes.
Implement bump mapping (Watt 8.4; Foley, et al. 16.3.3).
Check this out!
Implement solid textures or some other form of procedural texture mapping,
as described in Foley, et al., 20.1.2 and 20.8.3. Solid textures are a way to easily generate
a semi-random texture like wood grain or marble. Click here
for a tutorial on making realistic looking marble using Ken Perlin's noise function.
Add some new types of geometry to the ray tracer. Consider implementing torii or general quadrics.
Many other objects are possible here.
Add support for height-fields.
Click here
for a discussion on what they are and how they can be generated.
Extend the ray-tracer to create Single Image Random Dot Stereograms (SIRDS).
Click here to read a paper on how to make them.
Or, create 3D images like this one, for viewing with red-blue glasses.
for first,
for each additional
Implement distribution ray tracing to produce one or more or the following effects:
depth of field, soft shadows, motion blur, or glossy reflection
(See Shirley 10.11, Watt 10.6, Glassner, chapter 5, or Foley, et al., 16.12.4).
Add some higher-level geometry to the ray tracer, such as surfaces of revolution, extrusions,
metaballs, swept surfaces, or blend surfaces. You may have implemented one or more of these as a
polygonal object in the modeler project. For the Raytracer, be sure you are actually raytracing
the surface as a mathematical construct, not just creating a polygonal representation of the
object and tracing that. Yes, this requires lots of complicated math, but the final results are
definitely worth it (see Transparent Metaballs). Here is
a really good tutorial on raytracing
metaballs. For an additional bell, add texture mapping to your higher-level geometry. The texture
mapping must look good in order to get credit for it!
Implement ray-intersection optimization by either significantly
extending the BSP Tree implemented in the skeleton or by implementing a different
optimization method, such as hierarchical bounding volumes (See Glassner 6.4 and 6.5, Foley, et al., 15.10.2).
Implement 3D fractals and extend the .ray file format
to provide support for these objects. Note that you are not allowed to "fake" this by
just drawing a plain old 2D fractal image, such as the usual Mandelbrot Set. Similarly, you
are not allowed to cheat by making a .ray file that arranges objects in a fractal pattern,
like the sierpinski.ray test file. You must raytrace an actual 3D fractal, and your extension
to the .ray file format must allow you to control the resulting object in some interesting
way, such as choosing different fractal algorithms or modifying the base pattern used to produce the fractal.
Here are two really good examples of raytraced fractals that were produced by students during a previous quarter:
Example 1,
Example 2
And here are a couple more interesting fractal objects:
Example 3,
Example 4
Implement 4D quaternion fractals and extend the .ray file format
to provide support for these objects. These types of fractals are generated by using a generalization
of complex numbers called quaternions. What makes the fractal really interesting is that it is actually
a 4D object. This is a problem because we can only perceive three spatial dimensions, not four. In order
to render a 3D image on the computer screen, one must "slice" the 4D object with a three dimensional
hyperplane. Then the points plotted on the screen are all the points that are in the intersection of
the hyperplane and the fractal. Your extension to the .ray file format must allow you to control the
resulting object in some interesting way, such as choosing different generating equations, changing
the slicing plane, or modifying the surface attributes of the fractal.
Here are a few examples, which were created using the POV-Ray raytracer
(yes, POV-Ray has quaternion fractals built in!):
Example 1,
Example 2,
Example 3,
Example 4.
To get started, visit this web page to brush up on your
quaternion math. Then go to this site
to learn about the theory behind these fractals. Then, you can take a look at this page
for a discussion of how a raytracer can perform intersection calculations.
Implement a more realistic shading model. Credit will vary depending on the sophistication of the model.
A simple model factors in the Fresnel term to compute the amount of light reflected and transmitted at a perfect
dielectric (e.g., glass). A more complex model incorporates the notion of a microfacet distribution to broaden
the specular highlight. Accounting for the color dependence in the Fresnel term permits a more metallic appearance.
Even better, include anisotropic reflections for a plane with parallel grains or a sphere with grains that follow
the lines of latitude or longitude. Sources: Shirley, Chapter 24, Watt, Chapter 7, Foley et al, Section 16.7;
Glassner, Chapter 4, Section 4; Ward's SIGGRAPH '92 paper; Schlick's Eurographics Rendering Workshop '93 paper.
This all sounds kind of complex, and the physics behind it is. But the coding doesn't have to be. It can be worthwhile to look up one of these alternate models, since they do a much better job at surface shading. Be sure to demo the results in a way that makes the value added clear.
Theoretically, you could also invent new shading models. For instance, you could implement a less realistic model! Could you implement a shading model that produces something that looks like cel animation? Variable extra credit will be given for these "alternate" shading models. Note that you must still implement the Blinn-Phong model.
Implement CSG, constructive solid geometry. This extension allows you to create very interesting models.
See page 108 of Glassner for some implementation suggestions. An excellent example of CSG
was built by a grad student here in the grad graphics course.
Add a particle systems simulation and renderer (Foley 20.5, Watt 17.7, or see instructor for more pointers).
Implement caustics by tracing rays from the light source and depositing energy in texture maps
(a.k.a., illumination maps, in this case). Caustics are variations in light intensity caused by refractive
focusing--everything from simple magnifying-glass points to the shifting patterns on the bottom of a swimming pool.
Here is a paper discussing some methods. 2 bells each for refractive and reflective caustics.
(Note: caustics can be modeled without illumination maps by doing "photon mapping", a monster bell described below.)
There are innumerable ways to extend a ray tracer. Think about all the visual phenomena in the real world. The look and shape of cloth. The texture of hair. The look of frost on a window. Dappled sunlight seen through the leaves of a tree. Fire. Rain. The look of things underwater. Prisms. Do you have an idea of how to simulate this phenomenon? Better yet, how can you fake it but get something that looks just as good? You are encouraged to dream up other features you'd like to add to the base ray tracer. Obviously, any such extensions will receive variable extra credit depending on merit (that is, coolness!). Feel free to discuss ideas with the course staff before (and while) proceeding!
The trace program assigns colors to pixels by simulating a ray of light that travels, hits a surface, and then leaves the surface at the same position. This is good when it comes to modeling a material that is metallic or mirror-like, but fails for translucent materials, or materials where light is scattered beneath the surface (such as skin, milk, plants... ). Check this paper out to learn more.
Not all rays are created equal. Some light rays contribute more to the image than others, depending on what they reflect off of or pass through on the route to the eye. Ideally, we'd like to trace the rays that have the largest effect on the image, and ignore the others. The problem is: how do you know which rays contribute most? Metropolis light transport solves this problem by randomly searching for "good" rays. Once those rays are found, they are mutated to produce others that are similar in the hope that they will also be good. The approach uses statistical sampling techniques to make this work. Here's some information on it, and a neat picture.
Photon mapping is a powerful variation of ray tracing that adds speed, accuracy and versatility. It's a two-pass method: in the first pass photon maps are created by emitting packets of energy photons) from the light sources and storing these as they hit surfaces within the scene. The scene is then rendered using a distribution ray tracing algorithm optimized by using the information in the photon maps. It produces some amazing pictures. Here's some information on it.
Also, if you want to implement photon mapping, we suggest you look at the SIGGRAPH 2004 course 20 notes (accessible from any UW machine or off-campus through the UW library proxy server).
