 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Setting this to `off` (=0) will cause POV-Ray to revert to the default
behaviour.
The parameter can also be set to an intermediate value, in order to
allow for the (approximate) modelling of anti-rective coatings.
_Interaction with Albedo_:
The `diffuse albedo DIFFUSE`, `phong albedo PHONG` and `specular albedo
SPECULAR` syntax, which is normally used to specify the effective
_bihemispherical albedo_ of that respective component, does not work as
advertised when finish-level `fresnel` is set to non-zero. Instead,
`diffuse albedo DIFFUSE` will specify the albedo the object would
exhibit if it had a refractive index of 1, while `phong albedo PHONG`
and `specular albedo SPECULAR` will specify the albedo the object would
exhibit if it had an infinitely large refractive index.
As a result, while you would normally want to choose paramaters such
that DIFFUSE + PHONG + SPECULAR <= 1, with finish-level `fresnel` set to
a non-zero value you would want to choose parameters such that DIFFUSE
<= 1 and PHONG + SPECULAR <= 1.
For optimal realism, you should specify `diffuse albedo 1 phong albedo 0
specular albedo 1`, and control the brightness of the diffuse component
via the layer pigment.
_Interaction with Reflection_:
Setting finish-level `fresnel` will automatically activate (if set to a
non-zero value) or de-activate (if set to zero) the reflection-level
`fresnel` parameter. This can be overridden by specifying the reflection
parameters _after_ the finish-level `fresnel` parameter.
For optimal realism, the maximum reflection should be set equal to the
finish-level `fresnel` parameter, while the minimum reflection should be
set to zero.
_Interaction with Subsurface Light Transport_:
When subsurface light transport is enabled, the finish-level `fresnel`
parameter will have no effect on the diffuse feature; instead, the
feature will always act as if the parameter had been set to 1.
_Interaction with Radiosity_:
Radiosity-based illumination currently does not account for the Fresnel
effect on incoming light, regardless of the finish-level `fresnel`
parameter.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.12.2016 um 09:55 schrieb clipka:
> I'm changing the way the `finish` keyword will act when specified right
> inside the `finish` block.
Just posted a pair of sample images to povray.binaries.images.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.12.2016 um 09:55 schrieb clipka:
> The `diffuse albedo DIFFUSE`, `phong albedo PHONG` and `specular albedo
> SPECULAR` syntax, which is normally used to specify the effective
> _bihemispherical albedo_ of that respective component, does not work as
Make that "bihemispheric albedo".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
testing allows:
finish {
fresnel on
specular S_Value fresnel off
}
does that mean /all/ applicable attributes get fresnel treatment
/except/ specular
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>
> lol ... how am i supposed to get caught up if you keep changing/adding
You should control the release to the main program when you are happy
with the documentation.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2016 6:49 AM, Stephen wrote:
> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>
>> lol ... how am i supposed to get caught up if you keep changing/adding
>
> You should control the release to the main program when you are happy
> with the documentation.
>
if it /were/ only true!!! lately i've been practicing /going with the
flow/ so i guess the only thing to do is run faster ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2016 12:10 PM, Jim Holsenback wrote:
> On 12/21/2016 6:49 AM, Stephen wrote:
>> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>>
>>> lol ... how am i supposed to get caught up if you keep changing/adding
>>
>> You should control the release to the main program when you are happy
>> with the documentation.
>>
>
> if it /were/ only true!!! lately i've been practicing /going with the
> flow/ so i guess the only thing to do is run faster ;-)
Watch you don't get the sidewalk coded away from under you. :)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.12.2016 um 13:10 schrieb Jim Holsenback:
> On 12/21/2016 6:49 AM, Stephen wrote:
>> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>>
>>> lol ... how am i supposed to get caught up if you keep changing/adding
>>
>> You should control the release to the main program when you are happy
>> with the documentation.
>>
>
> if it /were/ only true!!! lately i've been practicing /going with the
> flow/ so i guess the only thing to do is run faster ;-)
That's the spirit!
Here, let me dangle this carrot before your nose... ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.12.2016 um 13:41 schrieb Stephen:
> On 12/21/2016 12:10 PM, Jim Holsenback wrote:
>> On 12/21/2016 6:49 AM, Stephen wrote:
>>> On 12/21/2016 11:33 AM, Jim Holsenback wrote:
>>>>
>>>> lol ... how am i supposed to get caught up if you keep changing/adding
>>>
>>> You should control the release to the main program when you are happy
>>> with the documentation.
>>>
>>
>> if it /were/ only true!!! lately i've been practicing /going with the
>> flow/ so i guess the only thing to do is run faster ;-)
>
> Watch you don't get the sidewalk coded away from under you. :)
When I'm done coding, he'll be able to render his own perfectly
realistic sidewalk ;)
Now off with you -- let the man do his job...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
