readme.txt

The goal of this project is to explore the idea of point-based radiosity, which is a shooting radio

Ben Landon
CSCI E-235
Semester Project
Point-based radiosity

Preamble
--------

Set your expectations appropriately low for these results.  

On the plus side: The renderings exist.

On the minus side: They're mighty bad and the radiosity procedure
doesn't always converge.

The files HemiCube.cpp, HemiCube.hpp, Scene.cpp, and Scene.hpp
are probably the most interesting files in the source code.
These four files contain the code that represents the core of
the point-based radiosity algorithm.  The rest of the code
is essentially support code.  WinMain.cpp contains the calls
that manipulate the HemiCube and the Scene objects. 


Introduction
------------

The goal of this project is to explore the idea of point-based
radiosity, which is a shooting radiosity technique suggested by Mark
Harris at UNC.  The primary idea is that features available in
graphics hardware can be utilized to perform radiosity calculations.
Facilities such as flat shading, diffuse lighting, projective
textures, and mipmapping can be used to replace traditional numerical
solutions for radiosity.  

The background material presented in this readme.txt is paraphrased
from Harris's Point-based radiosity web page (see References).

Caveats
-------

As far as I know, this idea was never fully explored, and it doesn't
appear that Harris has worked on it since early 2001, perhaps earlier.
Furthermore, it was never clear that this idea would work at all,
since I am not aware of any publication or working system that
implements point-based radiosity.  As you will undoubtedly see in my
project submission, it is still unclear if this is a feasible approach
to radiosity.

A Note on using the software
----------------------------

Run the program and hit 's' a couple of times.  Hitting 's' does one
step in the radiosity algorithm.

Hitting 'g' is equivalent to hitting 's' 100 times.  

If you want to see the reprojected points, press 'd' to toggle
this. ('d' stands for "debug").  

If you want to use OpenGL points to accumulate reprojected points,
press 'p' to toggle this on and off.  The default is to accumulate the
reprojected points in software.

The magenta spot is the brightest spot in the scene.  

When you run the program, the scene is drawn as a wireframe, and the
triangles are drawn using their accumulation textures.  Pressing 's'
does one iteration of the point-based radiosity procedure.  Pressing
'g' does 100 steps.


The Idea
--------

The principal idea behind point-based radiosity is that diffuse
lighting in conjunction with a projective texture looks a lot like
form factor calculation in the traditional hemicube approach to
radiosity.  Two renderings of the scene for each face of the hemicube
are used to figure out where to shoot point samples.  These point
samples are then accumulated by objects in the scene.

The Recipe
----------

The recipe for point-based radiosity is:

1.) Load a scene, where each triangle in the scene has two textures
associated with it.  These are the accumulation and emissive textures.
The accumulation texture is the sum of all light incident on the
triangle, and the emissive texture is the same as the accumulation
texture minus emitted light.

2.) There has to be at least one light source, so populate the
accumulation and emissive textures on the light source with nonzero
texels.  All other textures (for non-light sources) should be set to
zero.

3.) Find the brightest texel in the scene, and place a hemicube over
it.  Place the camera at the center of the hemicube, and turn on a
diffuse light source, also at the center of the hemicube.  The light
source's diffuse component should be the same as the brightest texel's
color.  Set the diffuse material color for each triangle, and render
the scene with smooth shading and depth testing.  This rendering also
has to be multiplied by an itensity factor that is essentially the 
cosine of the angle between the hemicube normal and the ray going
from the hemicube center through the hemicube pixel.  I've been
using the term "cosine map" to refer to this set of factors.  

Note: Ideally projective texture mapping can be used with the cosine
map as a texture.  The projective cosine texture is centered about the
hemicube.  I couldn't get this to work, so I use mipmaps to get the
cosine texture sampled to the resolution that I need, and then I do
the multiply in software.

Save the five renderings (one for each side of the hemicube), using
something like glReadPixels.  Also save the depth buffer for each of
the five renderings.  I've been refering to the color buffer for this
rendering as the "RC texture", where RC stands for rendering times
cosine.  

The projection and modelview matrices are saved at this step for use
later.  They're needed for the point shooting phase.

4.) Turn off the light source, disable lighting, and set the shading
mode to flat shading.  Depth testing should still be on.  Render the
scene where the color for each triangle is some sort of identifier.
It is important that we be able to uniquely identify a color in the
rendering with a triangle in the scene.  Save these five renderings
using glReadPixels.  Don't use GL_FLOAT to extract this buffer since
we won't be able to identify triangles due to floating point precision
issues.  I've been calling this set of renderings the "item buffer",
although there is some question about wheter this is technically
correct.

5.) Shoot Point Samples 
Now we have 5 sets of item, depth and RC buffers.  Go through the item
buffer, and for each pixel identify which scene triangle that pixel's
color corresponds to.  Now look up the depth and color in the
corresponding depth and RC buffer.  Use gluUnProject to go to a point
in the scene.  Add this point and color to a list of the triangle
identified by the item buffer.  I've been using the term "splat" or
"point sample" for the point/color object, although I'm not confident
that these are the correct terms.  The set of point samples associated
with each triangle has to be cleared in each iteration.

6.) Reconstruction Phase 
Now go through each triangle in the scene.  Set up the camera so that
it is looking straight at the triangle, and there is an orthographic
projection set.  The view volume should be the bounding box around the
triangle.  Make sure that the point with texture coordinate (0.0, 0.0)
(for the triangle's accumulation and emissive texture) is at the lower
left corner of the ortho near plane.

Render the triangle using the accumulation texture to color it. 

Now turn on additive blending (glEnable(GL_BLEND), glBlendFunc(GL_ONE,
GL_ONE)), and turn off depth testing.  

For each point sample collected by this triangle in step 5.) use
GL_POINTS to draw a point of that color.  When all of the point
samples have been shot with GL_POINTS, the color frame buffer should
contain the triangle with its accumulation texture with the point
samples added.  Read back the frame buffer and set this to be 
the next accumulation texture and emissive texture.  

Alternatively, the reprojected points (splats) can be accumulated in
to software.  Once all points are accumulated they can be added to the
accumulation texture.  The advantage to doing the accumulation in
software instead of by using GL_POINTS is that more than 8 bits of
precision is needed sometimes.

Now subtract the brightest texel (see Step 3.) from the emissive
texture.

Now repeat!

Problems, Next Steps, Known Bugs
--------------------------------

1.) The diffuse lighting step is supposed to use a quadratic
attenuation coefficient of pi. Pi is a fairly large value for this
coefficient, so often the color value for a sample is below 1/256 per
channel.  This is effectively zero since 32 bit color is the best that
my current graphics environment can do.  I don't know whether this is
a fuction of the graphics hardware (Radeon 7500), the drivers, the
operating system, or my wgl libraries.  Getting access to hardware
with 64 color bits would help.

2.) It is unclear if using gluUnProject is the best way of figuring
    out where a point sample is supposed to go.  There may be some clever
    way of using OpenGL to do this more efficiently.

3.) The scenes produced by my current implementation of point-based
    radiosity are pretty bad looking.  Something has to be done to improve
    these. Maybe I should start with a different shooting technique that
    is known to work.

4.) The cosine map multiplication is currently done in software
    because I couldn't get projective texture mapping to work when
    rendering to an offscreen bitmap.  This is now a moot point since I'm
    no longer rendering to a bitmap (DIB), but I didn't have time to try
    projective texture mapping again.

5.) I'm not convinced that point based radiosity is yet on firm
    logical foundations. I should study shooting radiosity techniques to
    have more confidence that point-based radiosity can work.

6.) Sometimes, an accumulation texture develops a black hemicube
    shaped hole in it.  I'm reasonably sure that this is a hemicube
    shadow when a surface is closer to the hemicube center than the
    near clipping plane.


Acknowledgements and References
-------------------------------

Point-based radiosity was introduced by Mark Harris, who is currently
a Ph.D. student in CS department at the University of North Carolina.
The web page http://www.cs.unc.edu/~harrism/pbrad/pbrad.html is the
only material on point-based radiosity that I am aware of.

I also used the cosine texture from Mark Harris's web site.

Barycentric coordinates formulae are from Graphics Gems IV.  Graphics
Gems IV, Paul S. Heckbert, Ed. Academic Press/Morgan Kaufman, 1994.

Hanspeter Pfister helped me substantially with several conversations
about the point-based radiosity approach.

There were several useful papers on projective texture mapping on the
developer section of Nvidia's web site.

Some background material on radiosity was taken from "Radiosity and
Global Illumination" by Francois Sillion and Claude Puech. Morgan
Kaufman Publishers, 1994.