Radiosity - video of progress

This video shows where I am currently with the radiosity project. It still is only a single bounce of light, but the calculations used for that bounce are now much more accurate. The initial calculation of the lighting takes about 9 seconds, then the scene runs at 200 fps.

Ray Tracer Checkpoint 5: Reflection

All of these scenarios run at around 24 fps on a MacBook. In my realtime demo, the light moves and the foreground ball bounces

Main Image:

Single reflective sphere over checkerboard

Bonus images: (Just for fun!)

Recursive reflections- look close at the reflection on the silver ball.



Reflections + Bumpmapping = distorted reflections!



Reflections + textures

Radiosity midway checkpoint

The progress report for the radiosity project is available here.
Executive Summary: Project is on schedule, no changes need to be made to the deliverables.


Raw, unlit scene



Scene with simplified 1-bounce lighting
(hemicube is not calibrated yet)


With lighting interpolated across patches

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.