POV-Ray : Newsgroups : povray.binaries.scene-files : Granite_21 macro - beta #1.4 : Re: Granite_21 macro - beta #1.5 Server Time
20 Apr 2024 07:02:08 EDT (-0400)
  Re: Granite_21 macro - beta #1.5  
From: Thomas de Groot
Date: 1 Jun 2021 02:59:48
Message: <60b5dae4@news.povray.org>
Op 31/05/2021 om 20:06 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> This is an ancient trick I learned decades ago ;-). The form
>> _GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow
>> covers all the possible forms of writing (capitals, dots, etc) of which
>> a file name is composed. And it works perfectly well for me.
> 
> You're killin' me.
> I have never seen this used before, or even mentioned.
> Is this in the documentation?
> 
No idea. I guess I learned it from a 'smart one'. I would not be 
surprised if that was Sam Benge. But others have used the trick too I am 
convinced.

>> And then...!!!! [thunderclap]
>> So I forgot to give you the proper Line 70, which should be of course,
>> after Line 69, as given:
>>
>> #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
>> "DakotaRedGranite.inc"  #end
>> #include Granite_file
> 
> So I guess I will have to play with this...  is the _GRANITE_FILE_INC_
> "operating on" the #local Granite_file declaration ...?  Does it need the _INC_
> part then...?
> 
Now you ask too much ;-) A learned one like William Pokorny may know...

> I'm even more confused by the #local Granite_file = "DakotaRedGranite.inc" when
> the actual file name isn't capitalized.   Maybe I've run out of dried frog
> pills....
> 
This is one of those cases where DFP do not help I am afraid. I do not 
know th mechanism but it works. Same as my laptop: no idea how it 
functions... ;-)

> 
>> The granite include files, as I have defined them, use a 2d array
>> already.
> 
> Well, yes, but what I mean is that instead of:
> 
> array [Map1_entries][4] {
>    {0.00, not_0, not_0, not_0},
> 
> it might be preferable to have:
> array [Map1_entries][2] {
>    {0.00, <not_0, not_0, not_0>},
> 
> or
> 
> array [Map1_entries][2] {
>    {0.00, <not_0, not_0, not_0, not_0, not_0>},
> 
I am not a fan of this... The first would be a possibility... hmm, I 
have to think about this a bit. For instance, Map1 /never/ should have 
any filter or transmit info.

>> As the macro can render veins, where transmit info is supplied
>> by the corresponding array (the map2 one) it is just a matter of reading
>> the proper info in the right place. The macro takes care of that.
> 
> I am riding the struggle bus here.
> Convert () returns a basic rgb, not an rgbft,
> and map2 has transmit, yes, but not filter.
> My thought was that the macro should accommodate full 5D color vectors
> everywhere, because we have the Norbert Kern / Sean Day / Robert McGregor types
> who will squeeze every last bit of artistic flair out this if allowed to.
> 
They are free to try, but have to play by my rules ;-) For different 
reasons, I have restricted the use of transmit to the veins where 
filters are not allowed and imo, are not recommended.

Veins, btw, is still an issue of course.

>> Thanks for your thoughts! It keeps me on my toes. ;-)
> 
> You certainly have your own tricks up your sleeves that keep me on mine!!
> 
Glad to be of help :-)

-- 
Thomas


Post a reply to this message

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