POV-Ray : Newsgroups : povray.binaries.scene-files : eval_pigment() and trace() HowTo Server Time
28 Mar 2024 14:21:15 EDT (-0400)
  eval_pigment() and trace() HowTo (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: Thomas de Groot
Subject: Re: eval_pigment() and trace() HowTo
Date: 9 Jul 2016 02:52:42
Message: <57809f3a@news.povray.org>
On 7-7-2016 16:02, Bald Eagle wrote:
> I see:
> #declare WriteStrands = off; //set to 'on' for the first pass.
>
> Isn't there a way to just check if the file exists, and if not, create it?
> I looked - but it's not clear that this is possible.
> Seemed like a useful and desirable feature to be added, if that's the case.
>

In fact, there is a simple reason why I did not use the file_exists(S) 
function, now that I think about it. It is that you may want to test 
different settings before choosing the final ones (at least that is how 
I work) and so - except for the very first time - there is always a file 
present.

-- 
Thomas


Post a reply to this message

From: clipka
Subject: Re: eval_pigment() and trace() HowTo
Date: 9 Jul 2016 06:38:34
Message: <5780d42a@news.povray.org>
Am 09.07.2016 um 08:52 schrieb Thomas de Groot:
> On 7-7-2016 16:02, Bald Eagle wrote:
>> I see:
>> #declare WriteStrands = off; //set to 'on' for the first pass.
>>
>> Isn't there a way to just check if the file exists, and if not, create
>> it?
>> I looked - but it's not clear that this is possible.
>> Seemed like a useful and desirable feature to be added, if that's the
>> case.
>>
> 
> In fact, there is a simple reason why I did not use the file_exists(S)
> function, now that I think about it. It is that you may want to test
> different settings before choosing the final ones (at least that is how
> I work) and so - except for the very first time - there is always a file
> present.

You could use something like:

    #declare WriteStrands = off; // set to 'on' to force re-writing
    ...
    #if (!file_exists(...)) #declare WriteStrands = on; #end


Post a reply to this message

From: Thomas de Groot
Subject: Re: eval_pigment() and trace() HowTo
Date: 9 Jul 2016 07:17:16
Message: <5780dd3c$1@news.povray.org>
On 9-7-2016 12:38, clipka wrote:
> Am 09.07.2016 um 08:52 schrieb Thomas de Groot:
>> On 7-7-2016 16:02, Bald Eagle wrote:
>>> I see:
>>> #declare WriteStrands = off; //set to 'on' for the first pass.
>>>
>>> Isn't there a way to just check if the file exists, and if not, create
>>> it?
>>> I looked - but it's not clear that this is possible.
>>> Seemed like a useful and desirable feature to be added, if that's the
>>> case.
>>>
>>
>> In fact, there is a simple reason why I did not use the file_exists(S)
>> function, now that I think about it. It is that you may want to test
>> different settings before choosing the final ones (at least that is how
>> I work) and so - except for the very first time - there is always a file
>> present.
>
> You could use something like:
>
>     #declare WriteStrands = off; // set to 'on' to force re-writing
>     ...
>     #if (!file_exists(...)) #declare WriteStrands = on; #end
>

But, that would always set it to on, even when you want it to be off, or 
do I misunderstand this?

-- 
Thomas


Post a reply to this message

From: clipka
Subject: Re: eval_pigment() and trace() HowTo
Date: 9 Jul 2016 07:42:44
Message: <5780e334@news.povray.org>
Am 09.07.2016 um 13:17 schrieb Thomas de Groot:
> On 9-7-2016 12:38, clipka wrote:
>> Am 09.07.2016 um 08:52 schrieb Thomas de Groot:
>>> On 7-7-2016 16:02, Bald Eagle wrote:
>>>> I see:
>>>> #declare WriteStrands = off; //set to 'on' for the first pass.
>>>>
>>>> Isn't there a way to just check if the file exists, and if not, create
>>>> it?
>>>> I looked - but it's not clear that this is possible.
>>>> Seemed like a useful and desirable feature to be added, if that's the
>>>> case.
>>>>
>>>
>>> In fact, there is a simple reason why I did not use the file_exists(S)
>>> function, now that I think about it. It is that you may want to test
>>> different settings before choosing the final ones (at least that is how
>>> I work) and so - except for the very first time - there is always a file
>>> present.
>>
>> You could use something like:
>>
>>     #declare WriteStrands = off; // set to 'on' to force re-writing
>>     ...
>>     #if (!file_exists(...)) #declare WriteStrands = on; #end
>>
> 
> But, that would always set it to on, even when you want it to be off, or
> do I misunderstand this?

It would always set it to on _if_ the file does not already exist, so
you don't need to manually set it to on for the first run.

Of course if there are any use cases where you might want to have _no_
file at all, then this is of no use.


Post a reply to this message

From: Thomas de Groot
Subject: Re: eval_pigment() and trace() HowTo
Date: 10 Jul 2016 03:00:47
Message: <5781f29f$1@news.povray.org>
On 9-7-2016 13:42, clipka wrote:
> Am 09.07.2016 um 13:17 schrieb Thomas de Groot:
>> On 9-7-2016 12:38, clipka wrote:
>>> Am 09.07.2016 um 08:52 schrieb Thomas de Groot:
>>>> On 7-7-2016 16:02, Bald Eagle wrote:
>>>>> I see:
>>>>> #declare WriteStrands = off; //set to 'on' for the first pass.
>>>>>
>>>>> Isn't there a way to just check if the file exists, and if not, create
>>>>> it?
>>>>> I looked - but it's not clear that this is possible.
>>>>> Seemed like a useful and desirable feature to be added, if that's the
>>>>> case.
>>>>>
>>>>
>>>> In fact, there is a simple reason why I did not use the file_exists(S)
>>>> function, now that I think about it. It is that you may want to test
>>>> different settings before choosing the final ones (at least that is how
>>>> I work) and so - except for the very first time - there is always a file
>>>> present.
>>>
>>> You could use something like:
>>>
>>>     #declare WriteStrands = off; // set to 'on' to force re-writing
>>>     ...
>>>     #if (!file_exists(...)) #declare WriteStrands = on; #end
>>>
>>
>> But, that would always set it to on, even when you want it to be off, or
>> do I misunderstand this?
>
> It would always set it to on _if_ the file does not already exist, so
> you don't need to manually set it to on for the first run.
>
> Of course if there are any use cases where you might want to have _no_
> file at all, then this is of no use.
>

I think you misunderstand my use of the on/off switch. The writing away 
of data is only meant as time saving later on when reading the data 
(always faster than having to do the complete calculations for each 
run). So, the switching off of the writing section (once you are 
satisfied with the written data) is essential. A file_exist switch can 
only make sense to check the existence of a file in the "Read" section 
of the macro.

-- 
Thomas


Post a reply to this message

From: clipka
Subject: Re: eval_pigment() and trace() HowTo
Date: 10 Jul 2016 09:29:00
Message: <57824d9c$1@news.povray.org>
Am 10.07.2016 um 09:00 schrieb Thomas de Groot:
> On 9-7-2016 13:42, clipka wrote:
>> Am 09.07.2016 um 13:17 schrieb Thomas de Groot:
>>> On 9-7-2016 12:38, clipka wrote:
>>>> Am 09.07.2016 um 08:52 schrieb Thomas de Groot:
>>>>> On 7-7-2016 16:02, Bald Eagle wrote:
>>>>>> I see:
>>>>>> #declare WriteStrands = off; //set to 'on' for the first pass.
>>>>>>
>>>>>> Isn't there a way to just check if the file exists, and if not,
>>>>>> create
>>>>>> it?
>>>>>> I looked - but it's not clear that this is possible.
>>>>>> Seemed like a useful and desirable feature to be added, if that's the
>>>>>> case.
>>>>>>
>>>>>
>>>>> In fact, there is a simple reason why I did not use the file_exists(S)
>>>>> function, now that I think about it. It is that you may want to test
>>>>> different settings before choosing the final ones (at least that is
>>>>> how
>>>>> I work) and so - except for the very first time - there is always a
>>>>> file
>>>>> present.
>>>>
>>>> You could use something like:
>>>>
>>>>     #declare WriteStrands = off; // set to 'on' to force re-writing
>>>>     ...
>>>>     #if (!file_exists(...)) #declare WriteStrands = on; #end
>>>>
>>>
>>> But, that would always set it to on, even when you want it to be off, or
>>> do I misunderstand this?
>>
>> It would always set it to on _if_ the file does not already exist, so
>> you don't need to manually set it to on for the first run.
>>
>> Of course if there are any use cases where you might want to have _no_
>> file at all, then this is of no use.
> 
> I think you misunderstand my use of the on/off switch.

Not at all. But you apparently misunderstand my use of `file_exists()` ;)

> The writing away
> of data is only meant as time saving later on when reading the data
> (always faster than having to do the complete calculations for each
> run). So, the switching off of the writing section (once you are
> satisfied with the written data) is essential. A file_exist switch can
> only make sense to check the existence of a file in the "Read" section
> of the macro.

No, the `file_exists()` test makes perfect sense before the file
generation. It's pretty simple:

- You use `#declare WriteStrands = on;` while experimenting, forcing a
(re-)write on every run.

- You use `#declare WriteStrands = off;` once you're ok, suppressing a
re-write.

- In case the file does not yet exist, the `#if (!file_exists(...))
#declare WriteStrands = on; #end` overrides your choice and forces a
write, thus making sure that the finished scene can be rendered as-is,
with no tampering necessary even if the data file happens to be missing
for some reason.


Post a reply to this message

From: Thomas de Groot
Subject: Re: eval_pigment() and trace() HowTo
Date: 11 Jul 2016 02:40:23
Message: <57833f57@news.povray.org>
On 10-7-2016 15:28, clipka wrote:
> Am 10.07.2016 um 09:00 schrieb Thomas de Groot:
>> On 9-7-2016 13:42, clipka wrote:
>>> Am 09.07.2016 um 13:17 schrieb Thomas de Groot:
>>>> On 9-7-2016 12:38, clipka wrote:
>>>>> Am 09.07.2016 um 08:52 schrieb Thomas de Groot:
>>>>>> On 7-7-2016 16:02, Bald Eagle wrote:
>>>>>>> I see:
>>>>>>> #declare WriteStrands = off; //set to 'on' for the first pass.
>>>>>>>
>>>>>>> Isn't there a way to just check if the file exists, and if not,
>>>>>>> create
>>>>>>> it?
>>>>>>> I looked - but it's not clear that this is possible.
>>>>>>> Seemed like a useful and desirable feature to be added, if that's the
>>>>>>> case.
>>>>>>>
>>>>>>
>>>>>> In fact, there is a simple reason why I did not use the file_exists(S)
>>>>>> function, now that I think about it. It is that you may want to test
>>>>>> different settings before choosing the final ones (at least that is
>>>>>> how
>>>>>> I work) and so - except for the very first time - there is always a
>>>>>> file
>>>>>> present.
>>>>>
>>>>> You could use something like:
>>>>>
>>>>>     #declare WriteStrands = off; // set to 'on' to force re-writing
>>>>>     ...
>>>>>     #if (!file_exists(...)) #declare WriteStrands = on; #end
>>>>>
>>>>
>>>> But, that would always set it to on, even when you want it to be off, or
>>>> do I misunderstand this?
>>>
>>> It would always set it to on _if_ the file does not already exist, so
>>> you don't need to manually set it to on for the first run.
>>>
>>> Of course if there are any use cases where you might want to have _no_
>>> file at all, then this is of no use.
>>
>> I think you misunderstand my use of the on/off switch.
>
> Not at all. But you apparently misunderstand my use of `file_exists()` ;)

That was a hypothesis I had not considered of course. ;-)

>
>> The writing away
>> of data is only meant as time saving later on when reading the data
>> (always faster than having to do the complete calculations for each
>> run). So, the switching off of the writing section (once you are
>> satisfied with the written data) is essential. A file_exist switch can
>> only make sense to check the existence of a file in the "Read" section
>> of the macro.
>
> No, the `file_exists()` test makes perfect sense before the file
> generation. It's pretty simple:
>
> - You use `#declare WriteStrands = on;` while experimenting, forcing a
> (re-)write on every run.
>
> - You use `#declare WriteStrands = off;` once you're ok, suppressing a
> re-write.
>
> - In case the file does not yet exist, the `#if (!file_exists(...))
> #declare WriteStrands = on; #end` overrides your choice and forces a
> write, thus making sure that the finished scene can be rendered as-is,
> with no tampering necessary even if the data file happens to be missing
> for some reason.
>

I see. Not sure if I want to do it that way though. I keep this in mind 
for when I 'really' need it :-)

-- 
Thomas


Post a reply to this message

From: Kenneth
Subject: Re: eval_pigment() and trace() HowTo
Date: 12 Jul 2016 01:25:00
Message: <web.57847dd1734cd25733c457550@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> For general information purposes,
> eval_pigment is a macro that is defined in functions.inc as shown below.
>
> -----------------------------------------------
> #macro eval_pigment(pigm, vec)
>     #local fn = function { pigment { pigm } }
>     #local result = (fn(vec.x, vec.y, vec.z));
>     result
> #end
> -----------------------------------------------

It's always been interesting to me that the macro was designed to work only with
the r-g-b color components, and not with the f and t components as well. I
assume there's a reason for that (a technical one?); but evaluating a color like
rgb <.3,.5,.7,.4,.2> will return just the 'opague' colors, not the "colors +
f-and-t mix."

Or maybe my own logic about 'color mixing' is in error, when it comes to
*translucent* color shades (?). I admit that the effects of f and t on a color
are not the same as, say, adding *white* to get a pastel tint. But eval_pigment,
as-is, gives a kind of false result when working with translucency-- or so it
seems.


Post a reply to this message

From: clipka
Subject: Re: eval_pigment() and trace() HowTo
Date: 12 Jul 2016 02:00:27
Message: <5784877b$1@news.povray.org>
Am 12.07.2016 um 07:20 schrieb Kenneth:

>> For general information purposes,
>> eval_pigment is a macro that is defined in functions.inc as shown below.
>>
>> -----------------------------------------------
>> #macro eval_pigment(pigm, vec)
>>     #local fn = function { pigment { pigm } }
>>     #local result = (fn(vec.x, vec.y, vec.z));
>>     result
>> #end
>> -----------------------------------------------
> 
> It's always been interesting to me that the macro was designed to work only with
> the r-g-b color components, and not with the f and t components as well. I
> assume there's a reason for that (a technical one?); but evaluating a color like
> rgb <.3,.5,.7,.4,.2> will return just the 'opague' colors, not the "colors +
> f-and-t mix."

And what exactly would make you think so?

If you try it out, you'll find that eval_pigment() works perfectly fine
with full-fledged rgbft colours.

Maybe you somehow got the impression that the `.x`, `.y` and `.z`
referred to the pigment colour's components? They don't. They instead
refer to the input point, passing the individual coordinates as separate
parameters to the pigment function.


Post a reply to this message

From: Thomas de Groot
Subject: Re: eval_pigment() and trace() HowTo
Date: 12 Jul 2016 03:06:01
Message: <578496d9$1@news.povray.org>
On 12-7-2016 8:00, clipka wrote:
> If you try it out, you'll find that eval_pigment() works perfectly fine
> with full-fledged rgbft colours.
>
> Maybe you somehow got the impression that the `.x`, `.y` and `.z`
> referred to the pigment colour's components? They don't. They instead
> refer to the input point, passing the individual coordinates as separate
> parameters to the pigment function.
>

That is interesting! I did not know that but it makes sense indeed. Good 
to know.

-- 
Thomas


Post a reply to this message

<<< Previous 5 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.