Op 30/05/2021 om 16:16 schreef Bald Eagle:
> Maybe I'm tired, doing it wrong - or there are errors.
> 
> In line 69 you have a capitalized inc file name, but you provide an
> all-lowercase named file.
> 
> Then in line 70 you include a file - but if Granite_file isn't declared, it
> throws an error - which I thought is what line 69 is for.
> 
> and _GRANITE_FILE_INC_ doesn't even exist until the file actually gets included,
> so aren't you checking the wrong identifier?
> 
> Shouldn't it read something like:
> 
> #ifndef (Granite_file)
>      #declare Granite_file = "dakotaredgranite.inc";
>      #declare FileOK = file_exists (Granite_file);
>      #if (FileOK)
>          #include Granite_file
>      #else error concat ("Material color_map file \"", Granite_file, "\" doesn't
> exist.  Exiting."
>      #end // end if
> #end // end ifndef
> 

There is indeed an error there. Replace the following line:

#ifndef (_GRANITE_FILE_INC_)  #include "DakotaRedGranite.inc"  #end

by:

#ifndef (_GRANITE_FILE_INC_)  #local Granite_file = 
"DakotaRedGranite.inc"  #end

-- 
Thomas

Post a reply to this message

Op 30/05/2021 om 14:51 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> OK. This is a /cleanup/ version of the granite macro, and associated
>> DakotaRedGranite.inc file.
>>
>> The following things need to be addressed (in no particular order):
>>
>> - A comprehensive demo scene file
>> - A comprehensive documentation
>> - An investigation/implementation of Real World dimensions (should have
>> started with that, but you know of it goes...)
>> - Additional xxxGranite.inc files to be fed to the macro
> 
> Excellent.
> 
> I got dragged into the distasteful task of fixing/replacing my old cell phone
> (swapping out the motherboard has got me 99% of the way there) and haven't had a
> chance to delve into this yet.
> 
> Having written all of this, you would be the most knowledgeable about what to
> test / show off in a demo scene.
> 
We shall see how it goes. I have number of test scenes running at the 
moment. Still need some tweaking though.

> Depending on changes, documentation might not be comprehensive until it's all
> real-world tested-broken-fixed in the wild.
> 
I agree.

> My (essentially new) phone with the granite photos is the one that suddenly and
> inexplicably died - I will see if I can still retrieve them.  Maybe the
> dimension should be a parameter...
> 
That would be nice indeed.


granite in Canada (it was the one which most intrigued me) and found 
that it is not a granite as such, but a monzonite (granitoid). Does not 
matter much for our purpose; the mineral composition is different (less 
than 5% quartz compared to granites).

> I will look, at fiddling with the inc file - as this is likely to drive the
> creation of all of the previous items.
> 
Indeed. It is what I am going to do too in the coming days.

> 
> 
> Thanks for all of your expertise and industrious coding in this!
> I think it's pretty nice that we have some new patterns and materials that came
> out of this - relatively quickly - and hopefully a lot of the methods extend
> over to other materials.
> 
Thank you indeed. It became a fascinating project I confess. I certainly 
think it might generate spin-offs, either in the rock domain or in 
others maybe.

> I will get 2nd coffee and begin reading...
> 
...and I go food shopping now ;-)

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Concerning that last point, and with the knowledge that the granite
> /industry/ names /granite/ everything that is hard, grainy, pretty when
> polished, I have started to wonder if /all/ the granite codes provided
> originally by Daniel Mecklenburg (an employee of said industry) /are/
> really granites. There is little doubt imp, about Canadian Pink and
> North American Pink; Southern Gray and Medium Gray also seem to be
> genuine, but I need more info. However, I start to seriously scratch my
> head with the /black/ granites: Impala and India Black; and what to
> think of St. Andre Green? I think those are not granites at all but
> something else, gabbros, gneisses, I don't know what. Again, I need more
> info. What I want to say by all this, is that those rocks potentially
> may need a different approach in comparison to the granites proper.

According to the folks at our local granite supply store, some unique granite
formations turn out to be fairly small and inconsistent over distance. So some
variations of granite have been totally depleted and are no longer commercially
available.

Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"

Post a reply to this message

Op 31/05/2021 om 10:11 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Concerning that last point, and with the knowledge that the granite
>> /industry/ names /granite/ everything that is hard, grainy, pretty when
>> polished, I have started to wonder if /all/ the granite codes provided
>> originally by Daniel Mecklenburg (an employee of said industry) /are/
>> really granites. There is little doubt imp, about Canadian Pink and
>> North American Pink; Southern Gray and Medium Gray also seem to be
>> genuine, but I need more info. However, I start to seriously scratch my
>> head with the /black/ granites: Impala and India Black; and what to
>> think of St. Andre Green? I think those are not granites at all but
>> something else, gabbros, gneisses, I don't know what. Again, I need more
>> info. What I want to say by all this, is that those rocks potentially
>> may need a different approach in comparison to the granites proper.
> 
> According to the folks at our local granite supply store, some unique granite
> formations turn out to be fairly small and inconsistent over distance. So some
> variations of granite have been totally depleted and are no longer commercially
> available.
> 
> Kind regards,
> Dave Blandston
> Suggested motto: "With POV-Ray anything is possible, but nothing is easy"
> 
Interesting you say that and thanks for this info. When I searched 


them that were not operational any more (the majority, but over a long 
time period of a century or so). Looking also at the geological maps, 
depletion is very probable for many of them indeed. The mentioned 
granite is a very local occurrence I guess, only available around 


-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Interesting you say that and thanks for this info. When I searched
> them that were not operational any more (the majority, but over a long
> time period of a century or so). Looking also at the geological maps,
> depletion is very probable for many of them indeed. The mentioned
> granite is a very local occurrence I guess, only available around

The topic arose because I was asking about availability of "Verde Oceano." It
may not be a true granite but it's amazingly beautiful - lots of iridescence. It
looks like an underwater scene complete with brightly colored tropical fish.
Photos are totally insufficient. Adding that to your granite project would be
quite a task (maybe for the next granite update sometime around 2050), but lots
of granites do have iridescence - or at least stones that are being sold as
granite whatever they might actually be...


Kind regards,
Dave Blandston
Suggested motto: "With POV-Ray anything is possible, but nothing is easy"

Post a reply to this message

Attachments:
Download 'verdeoceano.jpg' (219 KB)

Preview of image 'verdeoceano.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:

> There is indeed an error there. Replace the following line:
>
> #ifndef (_GRANITE_FILE_INC_)  #include "DakotaRedGranite.inc"  #end
>
> by:
>
> #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
> "DakotaRedGranite.inc"  #end


So, I guess I'm still not understanding your intent.

Working backwards,

You have :"DakotaRedGranite.inc", so I guess the file you recently supplied
needs to be renamed with capitals.

Before this, You're checking to see if _GRANITE_FILE_INC_ is a declared
identifier.  Where is this identifier supposed to be properly declared?   In the
include file?

I just looked through "dakotaredgranite.inc" and it doesn't get declared in
there.
Also, this implies that _GRANITE_FILE_INC_ is a requisite line in any color_map
include file.  Correct?

Also, the arrays in any include file must have the proper names: A_Granite_map1,
A_Granite_map2, etc.


I see no real problem there at the moment, although it will need to be clear how
to properly implement multiple granite materials in a scene, so a demo ought to
have that feature and some comments.  Just pointing it out, since some people
like to have all of their include stuff at the top of a scene, and then do all
the processing later.

One last thing that occurred to me as I was trying to get to sleep - I decided
that I don't like the way I implemented the array for the color_map:
1. it uses separate entries for the color vector rather than a single vector.
2. That makes it difficult if not impossible to use rgbft colors

a 2d array with color_map location and color vector would likely be better.  The
macro probably has to get tested with an rgbft statement as well to make sure an
vector promotion happens as expected, etc.


- Bill

Post a reply to this message

Op 31-5-2021 om 12:26 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> There is indeed an error there. Replace the following line:
>>
>> #ifndef (_GRANITE_FILE_INC_)  #include "DakotaRedGranite.inc"  #end
>>
>> by:
>>
>> #ifndef (_GRANITE_FILE_INC_)  #local Granite_file =
>> "DakotaRedGranite.inc"  #end
> 
> 
> So, I guess I'm still not understanding your intent.
> 
> Working backwards,
> 
> You have :"DakotaRedGranite.inc", so I guess the file you recently supplied
> needs to be renamed with capitals.
> 
No.

> Before this, You're checking to see if _GRANITE_FILE_INC_ is a declared
> identifier.  Where is this identifier supposed to be properly declared?   In the
> include file?
> 
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.

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

Sometimes I get blind to the most obvious things... :-/

For the proper use, you declare the file you want, /before/ calling the 
macro. Example:

#declare Granite_file = "MyElectricGranite.inc";

Which includes the necessary paths too of course, like:

#declare Granite_file = "FolderA/FolderB/MyElectricGranite.inc";


> I just looked through "dakotaredgranite.inc" and it doesn't get declared in
> there.
> Also, this implies that _GRANITE_FILE_INC_ is a requisite line in any color_map
> include file.  Correct?
> 
No. It should be all controlled by the above.

> Also, the arrays in any include file must have the proper names: A_Granite_map1,
> A_Granite_map2, etc.
> 
Yes indeed. Those names are then used by the macro.

> 
> I see no real problem there at the moment, although it will need to be clear how
> to properly implement multiple granite materials in a scene, so a demo ought to
> have that feature and some comments.  Just pointing it out, since some people
> like to have all of their include stuff at the top of a scene, and then do all
> the processing later.
> 
YEs, that might give some clashes. Nothing very serious but one has to 
be aware of /what/ the macro exactly does.

> One last thing that occurred to me as I was trying to get to sleep - I decided
> that I don't like the way I implemented the array for the color_map:
> 1. it uses separate entries for the color vector rather than a single vector.
> 2. That makes it difficult if not impossible to use rgbft colors
> 
> a 2d array with color_map location and color vector would likely be better.  The
> macro probably has to get tested with an rgbft statement as well to make sure an
> vector promotion happens as expected, etc.
> 
The granite include files, as I have defined them, use a 2d array 
already. 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.

Thanks for your thoughts! It keeps me on my toes. ;-)

-- 
Thomas

Post a reply to this message

Op 31-5-2021 om 11:45 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Interesting you say that and thanks for this info. When I searched
>> them that were not operational any more (the majority, but over a long
>> time period of a century or so). Looking also at the geological maps,
>> depletion is very probable for many of them indeed. The mentioned
>> granite is a very local occurrence I guess, only available around
> 
> The topic arose because I was asking about availability of "Verde Oceano." It
> may not be a true granite but it's amazingly beautiful - lots of iridescence. It
> looks like an underwater scene complete with brightly colored tropical fish.
> Photos are totally insufficient. Adding that to your granite project would be
> quite a task (maybe for the next granite update sometime around 2050), but lots
> of granites do have iridescence - or at least stones that are being sold as
> granite whatever they might actually be...
> 

Aha! a larvikite! also monzonite granitoid, and a beautiful one indeed, 
very often used in the front walls of prestigious shops or offices.

-- 
Thomas

Post a reply to this message

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?

> 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...?

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....


> 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>},

> 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.

> Thanks for your thoughts! It keeps me on my toes. ;-)

You certainly have your own tricks up your sleeves that keep me on mine!!

Post a reply to this message

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