Checkpoint 4 Completed

Click here to view a youtube video of the new effects for Checkpoint 4.

Main Image: Procedural checkerboard floor


Extra: Images from a file as textures, with bilinear filtering



Extra: Proceedural Julia-set fractal as a texture, animated over time


View a closeup of another animated fractal I created.

Checkpoint 3 Completed

Checkpoint 3 involoved adding Phong shading and shadows to the raytracer.

Main image of phong shading:

Single light - note that this scene runs at real-time speeds




Extra: Multiple lights

Watch: Youtube video of the above scene with moving lights


Extra: Blinn-Phong specular calculation

This uses the 'halfway' vector to compute the specular strength
(exponent = 100)



Other interesting visuals produced:
"Beer-googles mode" Click here for video
"Artistic noisy image mode" Click here for video

Project Proposal: Radiosity

( click here to download the PDF of this proposal)

Title: Pre-computing Radiosity with OpenGL for Realtime Applications

Student: Robert Gustafson

Class: Computer Graphics II; 4003-571

Professor: Bailey

Project Web Site: http://gustafsonprojects.blogspot.com/search/label/radiosity

Summary:
Implement a system for lighting static scenes with radiosity calculations, with a goal of reproducing the classic radiosity image, the Cornell Box. (see suggested project guidelines at http://www.cs.rit.edu/~rjb/RITcourses/20082/Computer Graphics 2/public/CG2ProjectRadiosity.htm )
Radiosity will be implemented as a preprocessing step, and the results will be passed intro a normal OpenGL rendering pipeline. The preprocessing can be done as a series of passes using OpenGL to quickly solve visibility queries.

Project Objectives:
Implement a radiosity application for producing scenes with realistic reflected light and soft shadows.
Demonstrate the use of OpenGL to accelerate visibility calculations for radiosity
Demonstrate the use the above to pre-compute lighting for a static OpenGL 3d environment.

System and Software:

Platform: OSX
Hardware: MacBook with Intel Core 2 duo processor with 4 gigabytes of ram.
Libraries: OpenGL & GLUT for real-time displays and visibility determination.
Language: C++
IDE: Eclipse
Compiler: g++

Project components:

File Parser: Read the supplied input files into program. This provides camera position, window size, and scene patches.

Environment Visualization: Using OpenGL, the environment will be rendered with patches given the shades determined by the radiosity solver.

User Interface:
-Because the radiosity data is not view-dependent, after computing the lighting, the user will be able to change the camera's position in real-time in the scene to inspect the results.
-User input will determine which testing scene to work with, via keyboard
-User input will determine how many iterations to complete, via keyboard.
-User story:
- launches application by double-clicking on executable
- answers prompt for which scene to test (ex: CornellBox_Fine.txt)
- answers prompt for number of interactions to compute (ex: 4)
- waits for radiosity to compute
- user is shown a default view of the completed scene
- user can then manipulate camera to view scene from other angles
- user presses Escape to quit



Visibility Solver: Using OpenGL, create localized hemicube views to determine a patch's form factors, or visibility of other patches.

Iterative Radiosity Solver: Given information about a patch's form factors, distribute reflected diffuse lighting

Tone reproduction: Remap computed lighting to produce varied effects.

Project Responsibilities: All tasks will be completed by Robert Gustafson



Project Timeline:

Mon, week 4:
Complete parser & main opengl rendering component, so provided worlds can be visualized freely or from the perspective of a particular patch.

Mon, week 5:
Have hemicube views from perspective of a patch

Mon, week 6:
Be able to read back what patches at patch can see in its hemicube
Have mid-project review completed

Mon, week 7:
Be able to solve for 1 iteration of light propagation
Have created own other scenes to test

Mon, week 8:
Be able to solve for arbitrary numbers of iterations, have implement tone mapping

Mon, week 9:
Presentation & Report prepared and functional polishing completed

Mon, week 10:
Code cleanup completed

Mon, week 11:
Code submitted & Report updated if needed and submitted


Final Presentation -
1) Overview of Goals (slides)
2) Show Cornell Box scene without lighting information
3) A live demonstration of computing a number of iterations should be possible. If producing the lighting data takes too long for a live demo, one will be staged in which the data has already been produced
4) Slides about how I used OpenGL as the visibility solver

Checkpoint 2 Completed

Checkpoint 2 status: Complete + 2 extras
Tech: C++, OpenGL/GLUT for pixel buffer placement.

Supports: Spheres, Infinite Planes, Quads, Triangles, Supersampling, .obj 3d models

Extra: Supersampling

Here you can see the addition of supersampling and an attempt at drawing the checkerboard pattern on the floor polygon.

Click here for a close-up comparison

Extra: Triangles!

I added the ability to do intersection tests against triangles. The obvious thing to do with this functionality was to try raytracing a large triangle mesh loaded from a file. The teapot shown here is made from over 6 thousand triangles. I perform a bounding-sphere test first to see if a ray is near the model before actually doing an intersection test on the triangles. Also, backface culling is used because the object is perfectly opaque.

Testing with such a large model really helped me to find issues inside my code that I would not usually have noticed: It was leaking memory at a huge rate, and would run out of memory by hitting the 2gb limit for 32 bit applications!

Now, I can trace the scene using only about 16mb of ram.

General Benchmark: the screenshot above, 400x400, 6320 triangles, with 4x supersampling enabled, took about 20 seconds on a MacBook.

First result of raytracer!

Yes, its pretty bad! The only calculations done are ray directions and determining the number of roots in a ray-sphere intersection formula. No actual intersection points are solved for yet. The blocky look is because i'm tracing 100x100 pixels and blowing the result up to 400x400.

Raytracer Checkpoint 1: Scene Layout

I designed a scene layout to match Whitted's original rendering. This image was simply drawn with OpenGL to get the general geometry of the scene. The spheres are near each other but not quite touching.

The settings are as follows:

Foreground sphere: at [0,0,-2.6] radius = 1.0
Background sphere: at [-1.2,-1.0,-3.7] radius = 0.9


Floor plane corners:

• (-8,-2,0)
• (2.7,-2,0)
• (2.7,-2,-15)
• (-8,-2,-15)

Light source

• Location: (2.0, 5.0, 0.0)
• Diffuse: (0.7, 0.7, 0.7)
• Ambient: (0.4, 0.4, 0.4)

Camera

• Position: (0,0,1)
• Lookat: (0,0,0)
• Up: (0,1,0)
• Field of view = 60.0 degrees
• Aspect ratio = 1.3 (640/480)