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

Op 1-6-2021 om 08:59 schreef Thomas de Groot:


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

>> frog
>> pills....
>>
Well... it appears I am in serious need of a fresh batch of the "Super 
Strong Extra" frog pills myself. :-/

Don't ask me how or why I completely messed up here, that will be food 
for the psychiatrist; I have an inkling but that is for another time.

Your bewilderment was completely right and I got the full bucket of cold 
water on my head the moment when I /really/ tested with a new granite 
include file. As you can guess ("I told you so") it did not work.

So, after having flogged myself almost senseless, I guess the following 
lines should replace the offensive ones in the macro:

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

Also, to make successive calls of the macro more comprehensive (for 
now), add the following line in section 7:

#undef Granite_file

This seems to work correctly, at least for me. Hope it does for you too 
of course.

>> You certainly have your own tricks up your sleeves that keep me on mine!!
>>
> Glad to be of help :-)
> 
Yeah... my sleeves are full of holes and I often get pretty blind to 
them... ;-[

-- 
Thomas

Post a reply to this message

Op 31-5-2021 om 03:41 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> - A comprehensive demo scene file
> 
>> - 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
> 
> So I was playing with a scene for editing the material's color_map, and in
> addition to the inc file stuff, I noticed that you had removed all of the macro
> parameters.
> 
> I think that works really nicely, so far.
> 
> On the one hand, I like the #undef stuff at the end, but with what I'm doing
> with variations on the same theme, I noticed that that causes me to have to
> redeclare any macro parameters before each call.  No big deal - I can work with
> that.
> 
Yes, but it might not be the best solution...

> But I'm thinking if it doesn't change anything, maybe have it work like
> 
> Granite_21 (optional parameters_persist)
> (default is no)
> and then #if (parameters_persist) would govern macro section 7
> 
Problem is that the 'optional' parameter is still only version 3.8 of 
POV. Not desirable for now I am afraid.

> I have some things laid out with to-scale rulers, and with respect to the SSLT
> I'm wondering what I should do to indicate the - depth - of the translucency
> effect.  I'm not sure that I know of an equation / documentation / diagram for
> calculating / estimating the effect given an rgb 1 light_source and material
> thickness.
> 
After all the commotion about the Granite_file, I still have to plunge 
into this.

> I'm going to try to figure out a way to get as much useful visual info into the
> scene, but minimize the long render time effect of the SSLT.
> 
> Perhaps as a lead-in to the documentation, you could just briefly comment on the
> layout and purpose of the macro parts - the masks and such?
> 
I shall see what I can do on short term....

> Thanks,
> 
> - Bill
> 
> Attached is highlighting 2 color_map entries in green, and then replacing them
> with black.  Just a little macro to make it easier to do from within the scene
> file.
> 
That could be nice indeed... The original color_maps will need a serious 
overhaul I am afraid.

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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...?
>

This is a lifting of a "protection" mechanism from the C language (at least
that's where I first encountered it).

The basic form is in your main .c file is:
#include <somefile.h>
#include <someotherfile.h>

Assume that somefile.h also includes other files, and those include others.
Further assume that someotherfile.h also includes other files.  If it ends up
that some set of includes is /duplicated/ then you run into problems.

So, to avoid that, in C somefile.h will contain something like this:
/* file: somefile.h */
/* defines some stuff */
ifndef(_SOMEFILE_H_)
 #define _SOMEFILE_H_
 #declare bob=1
 #declare ted=2
#end

The idea is that each include file defines the variable name associated with
that file, so that if that include file is hit /again/ when resolving includes
the first ifndef line will discover that, the include file contents will be
'skipped', and nothing /more/ will happen.

I'm not aware of any 'magic' that happens in povscript WRT defining a
_filename_INC_ variable, but there could be such.

(hope this helps clear up the concept)

Post a reply to this message

"jamesf" <nomail@nomail> wrote:

> This is a lifting of a "protection" mechanism from the C language (at least
> that's where I first encountered it).

.....

Thanks, James - I have seen that type of thing in the various POV-Ray include
files, and probably in some source and arduino code.  I thought that's what was
getting done, but at present it seems that TdG was trying to invoke some kind of
POV "woo".

> I'm not aware of any 'magic' that happens in povscript WRT defining a
> _filename_INC_ variable, but there could be such.

Yeah - I was stunned that there was some such thing that I had never heard of or
seen.  On the other hand, it's an interesting concept - maybe a clever macro
could "search" for all variants of a particular filename...

> (hope this helps clear up the concept)

So do I.  The world just keeps getting cloudier, murkier, more opaque, and more
obscure as time goes on it seems...

I'm going to sacrifice another lime and offer up a supplication that Thomas gets
the rest, therapy, - and medication - that he so desperately needs to find
clarity of mind and inner peace.  We love you, Thomas.   Help is always just a
forum-post away.   :)

Post a reply to this message