Originally posted by JustHanging:
My first concern is, that when the light source gets further from the hemicube’s center, it’s projection on the hemicube gets smaller. Does this correctly account for attenuation, or should I do something about it?
As long as you apply the proper compensation for the hemicube shape (its difference to the hemisphere shape), and Lambert’s cosine law (attenuation caused by light dir vs normal angle), you are set. See this exellent page for more information: http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm
Second, what is the mimimum acceptable hemicube resolution?
That one is not very easy to answer. I think it depends very much on how small details you need to catch. A rule of thumb is that the smallest light source visible to a patch on a surface should be at least a few pixels in size in the hemicube rendering. If not, you may get irregular lighting across a surface due to the poor hemicube resolution. One way to solve this is to avoid small light sources (e.g. approximations of point lights). Another way is to calculate point lights separately from the hemicube rendering. I.e. use some technique similar to raytracing, but ONLY for the point light sources, and sum up the results from all light sources and the hemicube rendering.
And how many hemicubes can you draw per second with a relatively simple scene, say 1000 faces?
That depends on what technique you use. I have experimented with it a bit, and I used 256x256 hemicube maps (I think) and a VERY simple scene (~10 surfaces). I also applied the “multiplier map” (hemicube compensation * Lamberts cosine law) in hardware using blending. Finally, I used a custom floating point format (alpha channel = exponent) - be careful, as this requires some thinking to get it right. All in all, the only post-processing that had to be done was the custom floating point => IEEE floating point conversion and the sum of all pixels. Everything else was done in hardware using OpenGL.
So, what speed did I get? About 100-200 patches per second (on a Ti4200 + Athlon 700 MHz). A major bottleneck was glReadPixels and the sum-loop performed by the CPU. I also rendered all five sides of the hemicube in “one go”, by using scissor tests to place them all in one frame buffer before reading back the pixels (five rendering passes, but only one glReadPixel call).
Last, has anyone tried any alternatives to hemicubes? Like paraboloid projection, which would allow to draw your scene only once per sampling point as opposed to the five times required by a hemicube. Or at least using the top of a tethraedr instead of a cube, that would be three faces.
No, but it should be possible for sure. You just have to figure out the compensation map.