radiosity

Name: Radiosity
Language: C/C++
API: OpenGL
Platform: Linux
Authors: Auger, Corey and Wecker, Lakin

1. Project Goal

We plan on creating computer generated images of the best quality through a synthesis of Radiosity and Ray Tracing. This combination will allow us to simulate the diffuse, and specular interactions in complex environments. Because both methods are time consuming we will be using acceleration techniques in both.

These techniques include:

• Octree generation for fast spatial determination.

• Using graphics hardware Z-buffer for visibility determination in radiosity solution.

• Saving information into texture memory.

• Mini-mapping hemi-cube information for form factor calculations.

• Distributed Ray Tracing techniques to simulate imperfect reflections.

2. Motivation

Computer generated images typically concentrate on one portion of the lighting equation: either diffuse or specular lighting. Recently, new algorithms, new data structures and concepts have been researched to represent a more complete view of the lighting in increasingly complex environments. The radiosity approach stems from the want to simulate indoor environments where diffuse lighting is the primary mode of heat transfer. Ray tracing surfaced to simulate the way rays interact with reflective and specular surfaces. These two approaches are typically separated, however by combining the two one can look at both parts of the lighting equation. This is extremely useful in indoor environments with shiny reflective objects.

3. Key Technical Challenges

Radiosity

With regards to radiosity the key challenges lie in the speed and accuracy of the solution. We plan to exploit modern graphics hardware to aid in the visibility and form factor calculations. The main challenges will be with regard to the accuracy of the solution. We plan on having a very adaptive solution to allow us to experiment with different thresholds.

Additional challenges for the radiosity section is going to come from 'tight' geometry. We would like our solution to be able to handle models of any shape and complexity. With a hemi-cube approach this will pose problems in tight corners where the hemi-cube protrudes into geometry, or sees right through a faces in the geometry. In this case we are going to have to test the area around the hemi-cube and do some work to not allow the hemi-cube to pierce the geometry.

Ray Tracer

The Key technical challenge for the ray tracer will be the lighting model to use when combining the final information into a pixel color to display on the screen. There will be texture mapping details, the light map representing the diffuse and ambient lighting for the triangle, as well as the specular information gathered by the ray tracer. We plan to use Cook-Torrance lighting to achieve a more realistic colors and images.

4. Approach

4.1 Overview

Radiosity

Dividing each face of our scene into light-map texel regions, we are going to perform a gathering type of radiosity solution. First by using GL to render the scene from the perspective of a texel into a hemi-cubed texture map, we solve the visibility problem. After applying a lambertian mask over the pixels and perspective correction we then evaluate the hemi-cube as a 1x1 mini-map. This will be our form-factor calculation. This value gets stored in the light-map location that was being evaluated. This continues until we have converged on a solution. To further speed this process up we would only calculate (in between) pixels if they did not meet an interpolation threshold. This will allow for adaptive sampling at shadow boundaries. Additionally our scene is in an Octree format, so we will perform frustum culling and only pass vertices's to the renderer that the point can see. This should yield an acceptable upper limit on the complexity of most complex scenes.

Ray Tracer

The geometry will be loaded into an Octree to accelerate the intersection routines. The ray tracer will use the typical Ray Tracing technique by shooting rays from the eye, through the screen pixels and into the scene. The Octree will provide a quick intersection with surfaces in the scene. Then the ray tracer will analyze the properties of the intersection object. Based on this information it will ascertain whether it's necessary to recurse to obtain the reflected light. This will automatically be cutoff at a specified recursion level. The reflection rays will be shot in varying ways. We will store a reflection index which indicates how "perfect" the patch reflects light. We will always shoot 16 rays, but the angle from the perfect reflection ray to the actual rays shot will be determined by the index. The greater the angle, the less perfect of a reflection is shot. Once all of the specular data has been obtained at a particular intersection, it will be combined with the diffuse information stored from the radiosity solution.

5 Results

Radiosity

( missing octree graphic )
This is the only scene we currently have that shows off the ray tracing algorithm. It shows an opengl rendering of the axis-aligned bounding boxes that form the octree for a spider mesh. This really shows off the adaptive nature of an octree, as the space where geometry is really crowded, are subdivided even further and low polygon areas.

As you can see our engine is not yet complete. We will tweaking the radiosity algorithm to remove the artifacts and merging the ray-tracing algorithm with the radiosity solution, in the next few days and expect to have this fully working by our demo on friday.

6 Conclusion

Radiosity

Implementing radiosity in hardware using OpenGL has turned out to be much harder than originally anticipated. OpenGL is not well suited to the algorithm, and much care must be taken to use it correctly. It does lend itself well to generating the hemicube from points on the triangles, however this information cannot be read directly from the texture memory. To solve this we had to render the hemicube to the screen and read the frame buffer memory. However this clamps all values to 0.0-1.0. This does not allow really bright lights to be used, and care must be taken to use the correct model when dealing with this.

Once the hemicube is generated this information is combined into a single pixel value in the lightmap which pertains to the current point on the triangle. The only problem encountered in this was the alias problem where the middle of a lightmap pixel related to a point in object space that did not receive any light. However part of that lightmap pixel is included in the triangle's u-v texture mapping space. This create artifacts along edges of walls and and in corners. Care was then taken to correctly sample these edges in the lightmaps to generate the correct light at that position.

Performance

Our program operates at an efficiency that is dependent on the area of the scene that requires sampling. In this manor we can operate somewhat independent of the triangle complexity of the scene. If we had time to integrate the octree into the radiosity solution, we could then only pass visible geometry to the hemicube renderer. In this manor we would more be affected by the additional lightmaps that needed to be sampled and not by the complexity of the scene.

The advantage of our stratagy is that it allows you to adaptively choose heuristics. These include:

• Size of the hemicube.

• Triangle Area to lightmap ratio.

To further improve the performance we only sample points that will be in the triangle. The algorithm to determine this relationship can be done in 2D texture space and is thus way faster then the inner angle theorem in 3D. We had planned a further improvement but failed in the time we have left to implement it. This improvement would allow you to sample every N number of pixels on the grid in your first pass through the map. You then look at the bilinear difference in the samples that you have taken. If they are within a threshold then you take simply interpolate. If they are not then you sample again in between these points. Full details on this can be found on Hugo Elias website.

Another advantage is that after every pass you can walk your camera around the room in real time and check for an problems thus far in the solution. If you are happy with the current solution you can save the lightmaps out to disk and begin the program on another pass.

Edge Artifacts.

Sampling the pixel at position A yields a result that is inside the triangle and looking at the light. Sampling at position B gives us in many occasions a sample from inside the wall ( or totally black ). Once we interpolate the result we have an edge that fades to black. The solution to this is to detect the boundary cases and sample for point B a sample from right on the triangles edge.

This problem should be fixed by Friday :)

Ray-Tracing

Unfortunately the ray-tracing part of the system has not yet produced any usable results. The geometry is loaded into an octree, and the intersection tests for the octree have been perfected which yields reasonably fast times on models of medium size. However the light model to combine the specular and diffuse lighting from the radiosity has not yet been implemented to a usable state. We have included a picture of an OpenGL rendering of the Axis-Aligned Bounding Boxes for the octree which was created for a 21,000 face mesh. The mesh is not rendered to show you how the geometry is centered.

7. List of References

• Hugo Elias
  http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm

• Radiosity on Graphics Hardware
  Greb Coombe, Mark J. Harris, Anselme Lastra
  Department of Computer Science, University of North Carolina, Chapel Hill, North Carolina, USA

• A progressive refinement approach to fast radiosity image generation
  Michael F. Cohen, Shenchang Eric Chen, John R. Wallace, Donald P. Greenberg
  SIGGRAPH '88, Pages: 75 - 84

• Wallace, John R., Michael F. Cohen, Donald P. Greenberg
  A Two-Pass Solution to the Rendering Equation: A Synthesis of Ray Tracing and Radiosity Methods
  Proceedings of SIGGRAPH'87, In Computer Graphics, Vol. 21, No. 4, July 1987, pp. 311-320

• Cook, Robert L., Porter, Thomas, Carpenter Loren
  Distributed Ray Tracing
  In Computer Graphics, Vol. 18, No. 3, July 1984, pp. 137-145