|
|
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
|
|