Am 09.07.2012 15:39, schrieb Zeger Knaepen:
> On 9/07/2012 3:47, clipka wrote:
>> I didn't think about it when I implemented the albedo for diffuse, but
>> it won't play nice with radiosity. Because radiosity actually doesn't
>> support brilliance, and always computes diffuse illumination from other
>> objects as if the surface had brilliance 1.0.
>
> Is there a reason for that, other than speed?

Yes: Algorithm design, and the simple fact that nobody ever seriously 
cared about brilliance in radiosity scenes before.

Radiosity samples only store the level of illumination, but no 
information about the direction(s) from which this illumination comes. 
But this information is vital for the brilliance feature.

Storing detailed information about the individual illumination intensity 
from all the sampled directions is obviously an absolute no-go for 
memory reasons.

The issue could be addressed by taking brilliance into account when 
averaging the individual illumination intensities for one sample, and 
storing the information for which brilliance the sample was taken; the 
sample would then not be taken into account for textures with different 
brilliance values.


Another possible approach would be to store the illumination intensity 
not as a scalar but as spherical harmonics, which is essentially an 
efficient way of storing a blurred "image" of the illumination pattern. 
This could then be used to compute angle-dependent effects when re-using 
a sample rather than at gathering time. As an added benefit this could 
then also be used for handling perturbed normals without significant 
memory & speed penalty (currently extra samples are taken for this), and 
might also significantly improve the quality of cylindrical surfaces at 
little extra cost. It's an idea I've already pondered for future 
versions of POV-Ray, but I'll have to dive deep into spherical harmonics 
math for that.

Post a reply to this message