COMP 557 - Fall 2009 - Assignment 4 (now combined with A5)
Ray Tracing

Milestone Due 23:59 pm Monday 16 November

Complete Assignment Due 23:59 pm Monday 30 November

New Details (November 13)

This assignment has been combined with assignment 5 and it will be worth double a normal assignment, that is, 16% of the final grade. Rather than giving an extension you must still make a submission of a milestone for the original deadline, with the complete assignment to be submitted by the end of Monday November 30.

The Milestone requirement is that you must have completed the first 3 steps of the original assignment. There will be a penalty of 20% for milestones which are incomplete or not submitted. Submit the following three things: a snapshot of your code along with a scene xml file and resulting image which demonstrates the requirement.

The new requirements for the complete assignment is that you must implement the following extensions:

  1. Jittered Super Sampling

    This need not be adaptive, but you should consider each of jittering and super sampling separately by adding additional tags to your scene file to enable or disable them independently.

    For super sampling, you will want to sample the image at regular locations within each pixel, as if you were building an image at twice the resolution (or some other resolution). But you should also observe how some high frequency aliasing problems can still exist.

    Observe how adding a small random perturbation to the direction of each ray fixes the aliasing problem. The amount of random perturbation should be configured in your xml scene file.

    Note that you naturally have high frequency details in your scenes, such as edges. Likewise if you implement textures (optional) then the aliasing problems should be even more evident. You should also try putting high frequency details in your background colour computation as an easy test, for instance, choosing a colour modulated by cos(k*(x^2+y^2)) would give low frequency when looking down the negative z axis, but will have higher frequency as you cast rays away from this axis (adjust k so you can observe the aliasing effect). Again, you might want to make this an option so that you are not stuck with the same background in all your test images!

  2. Simple Acceleration for Meshes

    Compute an axis aligned bounding box for each mesh in your scene. Test first ray intersection with the box before testing all triangles in the mesh. Make sure that you can turn on or off your acceleration method. Measure the improvement for your sample scene and report on the improvement in your readme and on your submitted web page (see below).

  3. Area Lights and Soft Shadows

    Define a new tag for an area light where you specify its position and shape as a quadrilateral in world coordinates. Cast several shadow rays to random positions on the area to compute a weighted lighting computation. Note that the number of rays you cast should be configurable in the lamp definition, but you could optionally optimize the number of rays you cast depending on the distance between the light and the surface being lit.

Note that the bonus items listed below have been adjusted slightly, and you can still implement extra features for extra credit.

Final Submission Format

You should create and submit a web page (that is the files, not just a link!) along with your assignment submission which contains images that demonstrate each requirement of the assignment, along with demonstrating the extra features you implemented.

While you could probably create one image to show all of your features at once, it is suggested that you take some time to create a variety of nice test scenes and render several images. Some images should be plain and simple to demonstrate individual features. Other images should be more complex and demonstrate a creative use of your software to generate interesting images.

Each image on your submitted web page should include a caption that gives the name of the xml scene file you used to generate the image, the computation time to generate the image, a list of features demonstrated in the image, and any additional comments. You may also want to list your hardware and operating system to help give meaning to the timings for each image. Note that the images should be a reasonable size, for instance, 640x480 is sufficient for showing many of the features, but you may optionally want to compute higher resolution images for your final scene, but do not go higher than 1920x1200.

Note that we may also run your code, but largely evaluation of your assignment will be done by inspecting the web page and your submitted code. Submitting an image that was not generated by your code is considered cheating. Because raytracers may take a long time to generate a given image the TAs may only selectively run specific examples, and it is largely on your honor that the images you show are yours (do not violate this trust).

Optional Competition

There will be optional competition for images created with your raytracer. You do not submit an image if you do not want to participate. To participate, you should submit a representative image, and a short description describing the technical achievements and or artist statement for your submission. Submit the image and statement to the competition assignment box by the end of Monday 30 November. A small jury will judge submissions based on aesthetics, creativity, and technical merit. Winners will be announced in class on Tuesday 1 December.

Getting Started

In this assignment, you will write a raytracer. Note that there is no written part to this assignment. The sample code will get you started with an XML scene file parser and code to write PPM image file. The XML scene format is very very loosely based off of the Yafaray format, but is simplified and modified for the purpose of this assignment. You are free to make additional modifications and extensions as you please to both the XML format and the code, but your code should still work with the simple examples provided, and likewise, any changes you make must be well documented in your readme file.

XML scene description

The XML file is organized as sequence of named materials, lights, cameras, nodes, and renders. The main scene is defined in the node with the name "root". In general you will only need to have one node defined, and it must have the name "root", but nodes can also be referred to within the scene graph hierarchy as an instance (i.e., to help you reuse parts of the scene hierarchy multiple times).

The scene nodes each have an associated transformation. The node definition can contains a list of transformations (translation, rotx, roty, rotz, and scale (and others if you choose to add them)). These transformations are applied in order to build the node transformation. The node can also list a number of different kinds of geometry (sphere, cube, mesh, instance). Finally, the node can also contain a list of child nodes, allowing a hierarchy of transformations and geometry to be built.

Look at the two examples provided to get a better idea of how the scene description files are organized. Please share your test scenes on WebCT. Note that you may also implement additional tags and attributes as you proceed through the objectives, so this may complicate sharing.

Provided Code

A4App opens an xml document and calls the Scene constructor to load the scene definition from the xml file. It then calls the scene render method to produce an image file. This render method is a good place to start making changes to the code, but you will need to make lots of changes to many classes, and make new classes on your own. You've been provided with basic classes for defining a materials, lights, and nodes, but they do nothing but hold loaded data. A Ray class and an intersection result have been defined for your convenience, but you may wish to change them. They are defined to allow the Intersectable interface to be defined. The sphere, cube, plane, mesh, or any other geometry (or node) that can be intersected will implement this interface.

Steps and Objectives

  1. Generate Rays

    The sample takes you up to the point where you need to compute the rays to intersect with the scene. Use the camera definition to build the rays you need to cast into the scene. You should have a default background for when rays do not intersect objects, and this should not be a solid colour. Choose some pleasing background colour based on your ray direction or pixel coordinate.

  2. Sphere Intersection

    The simplest scene includes a single sphere at the origin. Write the code to perform the sphere intersection and set the colour to be either black or white depending on the result (i.e., don't worry about lighting in this first step). Implement an additional position attribute for the sphere tag so that you can create a scene with several spheres at different positions without using the transformation tags (see step 7). For instance, <sphere radius="0.5" position="0 0 0" material="red"/>.

  3. Lighting

    Modify your code so that you're always keeping track of the closest intersection, and the material, and the normal. Use this information to compute the colour of each pixel by summing the contribution of each of the lights in the xml file.

  4. Shadows

    Modify your lighting code to compute a shadow ray, and test that the light is not occluded before applying computing and adding the light contribution in the previous step.

  5. Cube

    Add code to create an intersectable Cube object. The cube should be axis aligned, centered at the origin, and with edges of length specified in the XML file, i.e., <cube size="1" material="red">.

  6. Triangle Meshes

    The provided code include the polygon soup loader from the previous assignment. You can use this loader, or extend it, or write something new to load the obj file specified in the mesh XML nodes. Note that you do not have vertex normals by default, so flat shaded triangles are fine (though Phong shading would be nice).

  7. Hierarchy and Instances

    Use the transformations defined in the scene nodes to transform the rays before intersecting the geometry and child nodes. Be sure to also transform the normals of the intersection result that you return to the caller. Implement the instance tag to reuse named subtrees of the hierarchy. Do something reasonable with the material definition of an instance (i.e., replace the material of the intersection, or modulate the colours).

  8. Create a Novel Scene

    Create a unique scene of your own. Be creative. Try to have some amount of complexity to make it interesting (i.e., different shapes and different materials). Your scene should demonstrate all features of your ray tracer. Note that there will be a separate submission for the ray tracing competition later in the term.

  9. Bonus

    Implement some extra feature (or features) in your ray tracer, and make sure that it is something of some minimum difficulty if you want to receive full bonus marks. Here is a list of thing you might consider, but note that the items have been adjusted from the original posting of this assignment to account for the new requirements of the combined fourth and fifth assignments

    • Adaptive per pixel jittered super sampling
    • Fresnel Reflection
    • Refraction and Fresnel term
    • Motion blur
    • Depth of field, or real lenses
    • Spot lights
    • Procedural volume textures
    • Environment maps
    • Textured mapped meshes (adaptive sampling or even mipmaps would be useful here)
    • Bump maps
    • transparency and compositing
    • Programmable shading
    • Acceleration techniques (hierarchical bounding volumes, parallelization).
    • Quadrics
    • Other implicit surfaces (e.g., metaballs)
    • Subdivision surfaces
    • Bezier surfaces
    • Constructive Solid Geometry
    • Something awesome

    Be sure to document your extra feature or features in your readme!

Finished?

Great! Be sure your name and student number is in the window title, and in the comments of the code. Submit your source code as a zip file via webCT. Include a readme.txt file with your comments. DOUBLE CHECK your submitted files by downloading them from WebCT. You can not recieve any marks for assignments with missing or corrupt files!

Note that you are encouraged to discuss assignments with your classmates, but not to the point of sharing code and answers. All code must be your own.