Am 21.12.2016 um 12:33 schrieb Jim Holsenback:
> On 12/21/2016 3:55 AM, clipka wrote:
>> I'm changing the way the `finish` keyword will act when specified right
>> inside the `finish` block.
>>
>> The future syntax will be as follows:
>>
>>     FINISH:
>>       finish { [FINISH_IDENTIFIER] [FINISH_ITEMS...] }
>>     FINISH_ITEMS:
>>       ... | fresnel FLOAT | ...
>>
>>
>> Setting this to `on` (=1) will cause POV-Ray to realistically account
>> for the Fresnel effect in all of the following features:
>>
>>   - ambient
>>   - diffuse
>>   - emission
>>   - phong
>>   - specular
> 
> lol ... how am i supposed to get caught up if you keep changing/adding

Sorry. Call it necessary cleanup (adding ambient and emission to the
mix), plus a minor improvement while I was on it (making it a float
setting rather than a bool).

Smile and be glad, for things could be worse -- I'm currently already
restraining myself when it comes to entirely /new/ features ;)

(*tries to wriggle out of straightjacket*)


> testing allows:
> 
> finish {
>   fresnel on
>   specular S_Value fresnel off
>   }
> 
> does that mean /all/ applicable attributes get fresnel treatment
> /except/ specular

No, it means that /no/ attribute gets fresnel treatment, because the
setting /always/ applies to /all/ elements, and the later "fresnel off"
supersedes the earlier "fresnel on".

This is similar how the "metallic" setting at the finish level works:
While it is perfectly legal to write

    finish {
      phong 1 metallic on
      specular 1 metallic off
      }

this is misleading style, since "metallic" always applies to both phong
and specular. You might just as well write

    finish {
      phong 1
      specular 1
      metallic on metallic off
      }

with the later "metallic" statement winning over the earlier one. Which
in turn is just like

    finish {
      specular 1
      specular 0
      }

is also perfectly legal but only the second "specular" wins.


This is a side effect of (A) allowing users to specify the finish
parameters in arbitrary order, (B) allowing users to specify a
"template" finish at the beginning of the finish block and then override
individual parameters from that template, and (C) still keeping the
parser reasonably simple (well, maybe more like "not _batshit_ crazy
convoluted").

Post a reply to this message