cs6620 Project 2

Abe Stephens

Required Images


Lambertian Shading.

View from the bottom.


Creative Images

This is the same scene rendered with 64 samples per pixel rather then just one. It took 81 times as long. (13.8 seconds)

This image was rendered using an ambient occlusion shader. I used 8 samples per pixel and 500 rays per point for the ambient occlusion shader. (330.779 seconds with one thread.)

This image was rendered using the ambient occlusion shader for two of the spheres and the plane, but using a lambertian shader for the two other spheres. Again 8 samples per pixel, and 500 rays per point for the ambient occlusion shader. This looks a little strange since the point light source only applies to the Lambertian materials.  (388.013 seconds with one thread.)
The ambient occlusion shader was very expensive. I think using a better sampling algorithm for the secondary rays would allow for fewer samples.

Extra Images




Another scene with Lambertian shading.



Same scene with orthographic camera.



Scene with a direction light.

Same scene with a point light.


Screenshot of Fox frontend with mouse interaction. The mouse interaction is still rough and my trackball is not great and could use more work.

The front end consists of a main window containing the configuration menus (the pin hole camera dialog is pictured on the left) as well as a number of message handlers for manipulating the renderer. The two most important handlers are begin render and abort render. These are called by the image panel when the user engages the mouse. If the "Mouse interaction" option is enabled every time the user releases the mouse button, the renderer will be invoked and the frame will be refreshed. The image pictured was generated using one thread with multisampling and was not interactive. (~2.6 seconds per frame)  If the "Show progress" option is enabled, the image will refresh once per second. The renderer runs in a different thread from the user interface, if the user wishes to stop the rendering, the ui notifies the renderer to abort, and the renderer stops after the current pixel.

Description

The performance template for the first required image is here.

The renderer is implemented in several static libraries, the gui library contains all of the fox code, the renderer library contains the basic renderers, (i.e. SingleThreadRenderer), the scene library contains cameras, lights, and other scene objects. The renderer and scene libraries may be invoked from both fox code as well as command line frontends.

Base class interfaces:
FrameBuffer 		Provides access to individual pixels on either an onscreen window or a file buffer that will be written to disk.
Methods: write( ... ), commit( ... )
GenericRenderer		Provides access to a renderer implementation. Responsible for managing all threads etc.
Methods: render_to( ... ), stop_render( ... )
Background		Special object which is queried in the case that no other objects are intersected by a ray.
Methods: shade( ... )
Camera			Cameras map framebuffer pixels to coordinates normalized in (0,1)x(0,1).
Methods: compute_ray( ... ) translate_position( ... )
Light			Used by certain shaders for lighting calculations.
Methods: get_light( ... )
Material		Encapsulates shader for a certain material.
Methods: shade( ... )
Object			Base class for any container:
Methods: intersect_point( ... )
Primitive		Base class for any geometry.  Primitives are objects.
Methods: compute_normal( ... ). (Contains pointer to a Material)

SceneGroup Special object which holds Camera, Lights, and a root Object.

Additionally many objects have a preprocess method which is invoked by the preprocess method in SceneGroup.

The design of the renderer closely followed the notes. For the Lambertian shadow test, I moved the shadow ray start point a small distance along the normal at the intersection point. As a result the plane in the second required image exhibits the ABS behavior.

In the very near future I plan to add a MultiThreadRenderer class.

Total time: ~3 days.
Difficulty:   The material in this assignment wasn't difficult, but there was a lot of debugging.