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

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

"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

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

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