 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2016 12:48 PM, clipka wrote:
> 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...
>
I will if you stop moving the goal posts.
Remember I have my beady eye on you.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
