I went back to my simple walkchurch demo to see what I could do to to get finally to some point where I can have some good lighting.
Because the church has no roof, and because the main problem with Radiosity is to get sharp shadows, I decided that the main light source for the time being will be the Sun. Or, generally, a directional light source. A light source so far away that can be considered as coming from infinite and thus casting hard shadows without penumbra.
Since the original light source is really just one and it’s a point, it would be a waste to go and do the full Radiosity hemicube calculation on the receiving triangles. It’s best to have a special case, where I avoid the hemicube calculation process (where for every triangle one has to render the whole scene 5 times (a whole hemisphere), just to, at most, spot the well known and unique light source).
The quick solution is to simply copy the light source energy into those triangles that are visible by the light source. To do that properly while using 3D acceleration, I decided to render the scene from the light source point of view, with triangle writing out unique IDs as their color. I will then read the frame buffer and see which triangles are actually visible (can tell by their IDs !). Because the point of view is the one form the light source, visible triangles are actually visible to the light source.

This thing is nothing really new, it’s a cheap mix between the Shadows Z-Buffer technique (the idea of rendering form the light source) and some accelerated Radiosity hemicube rendering implementations (the idea of assigning a triangle ID as a color).
I’m currently rendering the image from the light source point of view. I could read it already with glReadPixels(), but I decided that I want also to make a step further and take the time to implement the ARB_frame_buffer_object extension to get acquainted with the useful extension that allows to render offscreen and re-use that buffer for texturing.

The problems with this technique are however already evident. It doesn’t tell me if a triangle is completely in light or only partially (partially lit triangles will need special shadow casting to give the shadow edges).
The problem of aliasing also arises: when rendered, triangles could end up being as small as 0 pixels ! This means that if the resolution is relatively low, I may miss some triangles, which will be considered as not receiving any energy, while actually they are receiving some.
This is a signal theory issue.. it’s the price that one has to pay when dealing with discrete values, as opposed to geometrical ones.. which make for very accurate solutions but don’t map well to 3D hardware accelerators.

Posted by Davide Pasca in 3D Graphics