Am 25.06.2015 um 20:13 schrieb And:
> clipka <ano### [at] anonymousorg> wrote:
>> - When using "brilliance", always use "brilliance FLOAT, FLOAT" with
>> both parameters set to the same value, and specify "brilliance on" in
>> the radiosity block. (You'll need a POV-Ray 3.7.1-alpha build for these,
>> or UberPOV.)
>>
>
> Would you tell me what the "FLOAT, FLOAT" really mean? You said it ... what it
> is bi-direction ..once to me, but I don't understand that yet.

At the default of "brilliance 1" the brightness of the diffuse component 
depends on the angle of the incoming light, following a cos(theta) law, 
where theta is the angle between the light ray and the surface normal 
(the vector perpendicular to the surface).

Similarly, if we're talking about brightness as the total amount of 
light reaching the observer from any given patch of surface, the 
brightness of the diffuse component also depends on the angle of the 
/outgoing/ light (i.e. the angle at which the surface is seen by an 
observer), following the very same cos(theta) law. However, this is 
already modeled exactly by the patch of surface appearing to get smaller 
as theta increases, while the brightness of any individual pixel remains 
constant.

Using "brilliance N" with any value other than 1 changes the dependency 
between the brightness of the diffuse component and the angle of 
incoming light: Rather than following a cos(theta) law, it now follows a 
cos(theta)^N law.

Now there is some fundamental law known to the contemporary world of 
professional and academic rendering, that any physically realistic 
shading formula must be "bi-directional", i.e. if you exchange the 
incoming and outgoing light rays, the formula must still yield the same 
result.

Thus, when you change the brightness' dependency on the incoming 
direction, you also need to change the dependency on the outgoing 
direction accordingly.

Traditionally however, POV-Ray will fail to do this, always leaving the 
brightness of an individual pixel constant no matter what the 
orientation of the surface towards the observer, which - as mentioned 
before - happens to be a perfect match for "brilliance 1", but breaks 
bi-directionality at any other setting.

Now fixing this behaviour of the "brilliance" keyword would be possible, 
but it would break each and every existing scene that makes use of 
brilliance. Therefore, I introduced an optional second parameter to 
"brilliance" which governs the dependency on the outgoing direction, 
allowing to restore bi-directionality by setting both parameters to the 
same value.

Post a reply to this message