The granite macro has been overhauled once again. Please find (and play 
with) the latest beta version (1.4) and the first granite include file 
(DakotaRedGranite.inc) which is also the default if you do not use the 
file including parameter.

Put it through its paces!

-- 
Thomas

Post a reply to this message

Attachments:
Download 'granite_21_beta_1.4.mcr.txt' (20 KB) Download 'dakotaredgranite.inc.txt' (3 KB)

Op 28-5-2021 om 17:11 schreef Thomas de Groot:
> The granite macro has been overhauled once again. Please find (and play 
> with) the latest beta version (1.4) and the first granite include file 
> (DakotaRedGranite.inc) which is also the default if you do not use the 
> file including parameter.
> 
> Put it through its paces!
> 
I forgot to mention an important info:

To load an external granite file, you need to put the following two 
lines in your scene before calling the macro:

#declare Granite_file = "DakotaRedGranite.inc"
#include Granite_file

"Granite_file" is an imperative name for the macro to read/test. 
Otherwise, you can call any file you want ("MyOwnBackyardGranite.inc") 
provided that you use exactly the same array names as in the default 
("DakotaRedGranite.inc") and adapt the number of entries, where 
necessary, for each array.

-- 
Thomas

Post a reply to this message

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

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.

This is as far as I have presently got in my quest for the Granite 
Grail, today, Anno Domini 2021, on the 30th day of the month of May.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'dakotaredgranite.inc.txt' (3 KB) Download 'granite_21_beta_1.5.mcr.txt' (21 KB)

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.

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

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

I will look, at fiddling with the inc file - as this is likely to drive the
creation of all of the previous items.



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.

I will get 2nd coffee and begin reading...

Post a reply to this message

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

?

Post a reply to this message

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.

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

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.

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?

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.

Post a reply to this message

Attachments:
Download 'graniteeditor.png' (223 KB)

Preview of image 'graniteeditor.png'

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.

In the meantime, I have explored the world of the Saint-André Green 
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 
through the Saint-André Green info yesterday, I came across the list of 
quarries in Québec supplying granite and I was struck by the number of 
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 
Saint-André-du-Lac-Saint-Jean.

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

Op 1-6-2021 om 08:59 schreef Thomas de Groot:
>> 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....
>>
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

Op 01/06/2021 om 23:40 schreef Bald Eagle:
> "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.   :)
> 
Just got a bootlegged batch of fresh Dried Frog Pills (pale yellow, not 
green) which does seem to do me a lot of good... [kwark!] sorry  ;-)

You know how it works: somebody in some scene uses a "smart" trick, 
which seems to work fine, and you mindlessly copy that into your own 
scenes, and it does seem to work... somehow, and then you tweak that 
"smart" trick to cover another need (close, but different) and lo! it 
just refuses to do what you expected. That is what happened to me. It 
took me an unusual long time to discover that it didn't work because I 
had been so clever as to cover up my tracks in such a way that it always 
"seemed" to work. I was sorely mislead by my tricky mind! One always 
needs a critical mind close by to get you back on the right track. 
Thanks Bill!

-- 
Thomas

Post a reply to this message

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

> You know how it works: somebody in some scene uses a "smart" trick,
> which seems to work fine, and you mindlessly copy that into your own
> scenes, and it does seem to work... somehow, and then you tweak that
> "smart" trick to cover another need (close, but different) and lo! it
> just refuses to do what you expected.

Yes, I have been there on many occasions.  But let's be honest, I've also been
thwarted from time to time by the simplest of stock SDL commands.  :D

> One always
> needs a critical mind close by to get you back on the right track.
> Thanks Bill!
>
> --
> Thomas

Hey - if it somehow "worked", I would have let it slip by for a while too.   I
only noticed it because POV-Ray was squawking about all of that undeclared
identifier stuff.  Damned parser.

Glad you're feeling better.  How many fingers am I holding up?

Post a reply to this message

Op 2-6-2021 om 12:23 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> You know how it works: somebody in some scene uses a "smart" trick,
>> which seems to work fine, and you mindlessly copy that into your own
>> scenes, and it does seem to work... somehow, and then you tweak that
>> "smart" trick to cover another need (close, but different) and lo! it
>> just refuses to do what you expected.
> 
> Yes, I have been there on many occasions.  But let's be honest, I've also been
> thwarted from time to time by the simplest of stock SDL commands.  :D
> 
It is also when you are bending too long over the same bunch of code 
that you get blind to the most obvious things.

>> One always
>> needs a critical mind close by to get you back on the right track.
>> Thanks Bill!
>>
>> --
>> Thomas
> 
> Hey - if it somehow "worked", I would have let it slip by for a while too.   I
> only noticed it because POV-Ray was squawking about all of that undeclared
> identifier stuff.  Damned parser.
> 
> Glad you're feeling better.  How many fingers am I holding up?
> 
hmmm.... fingers...? What do you mean by "fingers"...?

-- 
Thomas

Post a reply to this message

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

> hmmm.... fingers...? What do you mean by "fingers"...?

You are a rather naughty old man.
Clearly I mean the measure of the quantity of tincture of bufo terrestris
americanus in a whiskey glass.  :P


I came across this in my notifications - it's rather old, and sparse, but it has
a list of references that might be of more utility, and act as handles for
searching for newer developments.

https://www.academia.edu/993480/Modeling_Ore_Textures_and_Mineral_Liberation_Using_3D_Voronoi_Diagrams?email_work_card=
view-paper

Post a reply to this message

Op 03/06/2021 om 01:30 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> hmmm.... fingers...? What do you mean by "fingers"...?
> 
> You are a rather naughty old man.
> Clearly I mean the measure of the quantity of tincture of bufo terrestris
> americanus in a whiskey glass.  :P
> 
Why didn't you say so in the first place? Filled my whiskey glass with 
other stuff I am afraid... :-)

> 
> I came across this in my notifications - it's rather old, and sparse, but it has
> a list of references that might be of more utility, and act as handles for
> searching for newer developments.
> 
>
https://www.academia.edu/993480/Modeling_Ore_Textures_and_Mineral_Liberation_Using_3D_Voronoi_Diagrams?email_work_card=
> view-paper
>
Interesting! The use of voronoi diagrams had crossed my mind as an 
alternative. However, I have not the slightest idea how to do that; a 
bit beyond my capacities I am afraid. Still, good to know it has been 
done. Another fork to the exploration rig. Thanks!

-- 
Thomas

Post a reply to this message

Op 03/06/2021 om 08:39 schreef Thomas de Groot:
> Interesting! The use of voronoi diagrams had crossed my mind as an 
> alternative. However, I have not the slightest idea how to do that; a 
> bit beyond my capacities I am afraid. Still, good to know it has been 
> done. Another fork to the exploration rig. Thanks!
> 
Which reminded me of an old program I played with in the past: 
Tesselsphere. On Sourceforge, there are other utilities too using 
voronoi diagrams.

https://sourceforge.net/directory/os:windows/?q=voronoi

-- 
Thomas

Post a reply to this message

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

> Interesting! The use of voronoi diagrams had crossed my mind as an
> alternative. However, I have not the slightest idea how to do that; a
> bit beyond my capacities I am afraid. Still, good to know it has been
> done. Another fork to the exploration rig. Thanks!

Good heavens, lad!  You're already doing it.
Crackle IS Voronoi - and you're using crackle {solid} which is 3D Voronoi.

Stop being so modest.  :)

Post a reply to this message

Op 3-6-2021 om 12:16 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> Interesting! The use of voronoi diagrams had crossed my mind as an
>> alternative. However, I have not the slightest idea how to do that; a
>> bit beyond my capacities I am afraid. Still, good to know it has been
>> done. Another fork to the exploration rig. Thanks!
> 
> Good heavens, lad!  You're already doing it.
> Crackle IS Voronoi - and you're using crackle {solid} which is 3D Voronoi.
> 
> Stop being so modest.  :)
> 
>
LOL! I completely forgot about that aspect of crackle!

There is a 17th century French play by Molière, "Le bourgeois 
Gentilhomme" where de main character, wanting to get access to the upper 
echelons of society, starts to "educate" himself with the help of 
"teachers" (more interested in money) and so is delighted to learn that 
he has been speaking "prose" all his life without knowing it.

https://en.wikipedia.org/wiki/Le_Bourgeois_gentilhomme

[Admire my latest portrait on the site above. I think it is particularly 
well done and life-like] :-)

-- 
Thomas

Post a reply to this message

Op 03/06/2021 om 13:27 schreef Thomas de Groot:
> Op 3-6-2021 om 12:16 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> Interesting! The use of voronoi diagrams had crossed my mind as an
>>> alternative. However, I have not the slightest idea how to do that; a
>>> bit beyond my capacities I am afraid. Still, good to know it has been
>>> done. Another fork to the exploration rig. Thanks!
>>
>> Good heavens, lad!  You're already doing it.
>> Crackle IS Voronoi - and you're using crackle {solid} which is 3D 
>> Voronoi.
>>
>> Stop being so modest.  :)
>>
>>
> LOL! I completely forgot about that aspect of crackle!
> 

...but seriously, I would be interested to know how to use voronoi 
diagrams for this particular project, apart from the crackles pattern. 
Something where the individual cells (and distribution of them) would be 
more "controlled" by the user. Beyond the "using voronoi without knowing 
it", that would completely change the whole granite setup I think. At 
this moment, beyond the beta and beyond the final version.

-- 
Thomas

Post a reply to this message

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

> ...but seriously, I would be interested to know how to use voronoi
> diagrams for this particular project, apart from the crackles pattern.
> Something where the individual cells (and distribution of them) would be
> more "controlled" by the user. Beyond the "using voronoi without knowing
> it", that would completely change the whole granite setup I think.

Correct, and there has been some interest in exactly that for quite some time.

I have 2 or 3 implementations of Voronoi algorithms coded in GLSL/Shadertoy that
I've been meaning to start converting to SDL, in the hopes that I could get
something reasonably functional.



I didn't get to spend ANY POV-time yesterday, but I was thinking about exactly
what you're talking about, and it occurred to me that one thing we could
probably do is plug crackle into a function and then operate on the function
coordinates - like I did with the vortex.  That would give spatial control.

Then the whole bricks pattern trick would give further control over the
coloring.

And, of course Jerome Grimbert has already addressed this in hgpovray38
https://wiki.povray.org/content/User:Le_Forgeron#voronoi

I mean, even for now, we could probably just add some gentle black hole warps or
other warps to the basic granite pattern and introduce a little bit of
variation.  I'm bad at implementing warps, but maybe the quartz veins could
benefit from some clever application of them.

> At
> this moment, beyond the beta and beyond the final version.

Yes, just looking at the POV-Ray source code for the crackle and other
voronoi-based pattern shows it to be a little complex, and IIRC, the problem was
really that it's one of those things that you can do fairly straightforwardly
with an algorithm when directly shading pixels, but would be difficult or
impossible to do with straight SDL functions.

https://thebookofshaders.com/12/
https://iquilezles.org/www/articles/voronoilines/voronoilines.htm
https://iquilezles.org/www/articles/smoothvoronoi/smoothvoronoi.htm
https://iquilezles.org/www/articles/voronoise/voronoise.htm

Post a reply to this message

Op 4-6-2021 om 12:20 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> ...but seriously, I would be interested to know how to use voronoi
>> diagrams for this particular project, apart from the crackles pattern.
>> Something where the individual cells (and distribution of them) would be
>> more "controlled" by the user. Beyond the "using voronoi without knowing
>> it", that would completely change the whole granite setup I think.
> 
> Correct, and there has been some interest in exactly that for quite some time.
> 
> I have 2 or 3 implementations of Voronoi algorithms coded in GLSL/Shadertoy that
> I've been meaning to start converting to SDL, in the hopes that I could get
> something reasonably functional.
> 
I did a bit of browsing about voronoi diagrams, in particular MathWorks, 
and it occurred to me (just thinking aloud here) that if we could 
generate a 3d voronoi volume based on a random set of points in an 
array, that volume - intersected by the object we want to texture with 
granite - would give a 2d voronoi granite pattern. At least, that was 
how I interpreted the info given in MathWorks, which somehow seemed to 
click right away with those papers you directed me to.

Perhaps, we do not even need a 3d volume at all, but it seems to me that 
it would be a better, or more "natural", approach to the problem.

> 
> 
> I didn't get to spend ANY POV-time yesterday, but I was thinking about exactly
> what you're talking about, and it occurred to me that one thing we could
> probably do is plug crackle into a function and then operate on the function
> coordinates - like I did with the vortex.  That would give spatial control.
> 
> Then the whole bricks pattern trick would give further control over the
> coloring.
> 
That is an interesting idea... we should certainly follow up that line 
to see where it would get us.

> And, of course Jerome Grimbert has already addressed this in hgpovray38
> https://wiki.povray.org/content/User:Le_Forgeron#voronoi
> 
Ok. I need to look at that.

> I mean, even for now, we could probably just add some gentle black hole warps or
> other warps to the basic granite pattern and introduce a little bit of
> variation.  I'm bad at implementing warps, but maybe the quartz veins could
> benefit from some clever application of them.
> 
Maybe. I am not sure what the black hole warp would really add to the 
turbulence warp already in place. Granites are not very turbulent by 
themselves and rather monotonous in fact.

>> At
>> this moment, beyond the beta and beyond the final version.
> 
> Yes, just looking at the POV-Ray source code for the crackle and other
> voronoi-based pattern shows it to be a little complex, and IIRC, the problem was
> really that it's one of those things that you can do fairly straightforwardly
> with an algorithm when directly shading pixels, but would be difficult or
> impossible to do with straight SDL functions.
> 
> https://thebookofshaders.com/12/
> https://iquilezles.org/www/articles/voronoilines/voronoilines.htm
> https://iquilezles.org/www/articles/smoothvoronoi/smoothvoronoi.htm
> https://iquilezles.org/www/articles/voronoise/voronoise.htm
> 
Well, it appears we shall not have time to get bored or idle. ;-)

In the meantime, I have started to write that piece of documentation you 
asked about. Steadily growing.

-- 
Thomas

Post a reply to this message

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

> That is an interesting idea... we should certainly follow up that line
> to see where it would get us.

We should - but I never really dug into that really great project deeply enough
to understand exactly how it all works.  Maybe it's time.


> > I mean, even for now, we could probably just add some gentle black hole warps or
> > other warps to the basic granite pattern and introduce a little bit of
> > variation.  I'm bad at implementing warps, but maybe the quartz veins could
> > benefit from some clever application of them.
> >
> Maybe. I am not sure what the black hole warp would really add to the
> turbulence warp already in place. Granites are not very turbulent by
> themselves and rather monotonous in fact.

They are, but you have those other patterns which have some size variation.  It
might be nice to have some of that in the pattern as an option.  I'm only
throwing it out there so we can play with it and either decide it has promise -
or discard it as "nope - not a good idea".

> Well, it appears we shall not have time to get bored or idle. ;-)

Always so much to do.   Never enough time, energy, or opportunity.   Better that
than being idle and boring.


> In the meantime, I have started to write that piece of documentation you
> asked about. Steadily growing.

Thanks  :)


Find attached a quick exploratory crackle experiment.  The sum of 2 crackle
patterns of different scales, one with turbulence, then the whole thing with
some turbulence.

Post a reply to this message

Attachments:
Download 'cracklefunction.png' (877 KB)

Preview of image 'cracklefunction.png'

Op 04/06/2021 om 22:08 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> That is an interesting idea... we should certainly follow up that line
>> to see where it would get us.
> 
> We should - but I never really dug into that really great project deeply enough
> to understand exactly how it all works.  Maybe it's time.
> 
I have to dig up my old Geomorph code (2004-2005) in which I used 
patterns (including crackle) in different functions to build isosurface 
landscapes. It might inspire...

> 
>>> I mean, even for now, we could probably just add some gentle black hole warps or
>>> other warps to the basic granite pattern and introduce a little bit of
>>> variation.  I'm bad at implementing warps, but maybe the quartz veins could
>>> benefit from some clever application of them.
>>>
>> Maybe. I am not sure what the black hole warp would really add to the
>> turbulence warp already in place. Granites are not very turbulent by
>> themselves and rather monotonous in fact.
> 
> They are, but you have those other patterns which have some size variation.  It
> might be nice to have some of that in the pattern as an option.  I'm only
> throwing it out there so we can play with it and either decide it has promise -
> or discard it as "nope - not a good idea".
> 
I fully agree.

>> Well, it appears we shall not have time to get bored or idle. ;-)
> 
> Always so much to do.   Never enough time, energy, or opportunity.   Better that
> than being idle and boring.
> 
> 
>> In the meantime, I have started to write that piece of documentation you
>> asked about. Steadily growing.
> 
> Thanks  :)
> 
> 
> Find attached a quick exploratory crackle experiment.  The sum of 2 crackle
> patterns of different scales, one with turbulence, then the whole thing with
> some turbulence.
> 
Interesting result indeed. The "cells" are not looking "natural" enough 
to my taste, but with enough tweaking...

It shows, imo, how we have to be careful with the amount of turbulence.


-- 
Thomas

Post a reply to this message

Le 2021-06-05 à 02:39, Thomas de Groot a écrit :
> Op 04/06/2021 om 22:08 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> That is an interesting idea... we should certainly follow up that line
>>> to see where it would get us.
>>
>> We should - but I never really dug into that really great project 
>> deeply enough
>> to understand exactly how it all works.  Maybe it's time.
>>
> I have to dig up my old Geomorph code (2004-2005) in which I used 
> patterns (including crackle) in different functions to build isosurface 
> landscapes. It might inspire...
> 
>>
>>>> I mean, even for now, we could probably just add some gentle black 
>>>> hole warps or
>>>> other warps to the basic granite pattern and introduce a little bit of
>>>> variation.  I'm bad at implementing warps, but maybe the quartz 
>>>> veins could
>>>> benefit from some clever application of them.
>>>>
>>> Maybe. I am not sure what the black hole warp would really add to the
>>> turbulence warp already in place. Granites are not very turbulent by
>>> themselves and rather monotonous in fact.
>>
>> They are, but you have those other patterns which have some size 
>> variation.  It
>> might be nice to have some of that in the pattern as an option.  I'm only
>> throwing it out there so we can play with it and either decide it has 
>> promise -
>> or discard it as "nope - not a good idea".
>>
> I fully agree.
> 
>>> Well, it appears we shall not have time to get bored or idle. ;-)
>>
>> Always so much to do.   Never enough time, energy, or opportunity.   
>> Better that
>> than being idle and boring.
>>
>>
>>> In the meantime, I have started to write that piece of documentation you
>>> asked about. Steadily growing.
>>
>> Thanks  :)
>>
>>
>> Find attached a quick exploratory crackle experiment.  The sum of 2 
>> crackle
>> patterns of different scales, one with turbulence, then the whole 
>> thing with
>> some turbulence.
>>
> Interesting result indeed. The "cells" are not looking "natural" enough 
> to my taste, but with enough tweaking...
> 
> It shows, imo, how we have to be careful with the amount of turbulence.
> 
> 
To make your turbulence smoother, reducing the octave parameter could 
help. It default at 6. So, maybe try with octave 3.

Next, you can also reduce the lambda. Default of 2. Make it closer to 1.

Finally, the omega could also get adjusted down from the default of 0.5.

A proposition :
octave 3
lambda 1.4
omega 0.25

This should make the turbulence much more wavy and smoother.

Post a reply to this message

Op 05/06/2021 om 16:55 schreef Alain Martel:
> To make your turbulence smoother, reducing the octave parameter could 
> help. It default at 6. So, maybe try with octave 3.
> 
> Next, you can also reduce the lambda. Default of 2. Make it closer to 1.
> 
> Finally, the omega could also get adjusted down from the default of 0.5.
> 
> A proposition :
> octave 3
> lambda 1.4
> omega 0.25
> 
> This should make the turbulence much more wavy and smoother.

Yes indeed, and thanks for the reminder. Presently I have no time to 
deal too much with this, but Bald Eagle will take that up quite probably :-)

For now, I need to concentrate on that part of the docs I mentioned 
earlier, and deal with a couple of little thorns in the macro code which 
have not been dealt with fully to my satisfaction.

-- 
Thomas

Post a reply to this message

Op 01/06/2021 om 14:49 schreef Thomas de Groot:
> 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.
> 
Now, with POV-Ray development started in earness again, the use of the 
'optional' parameter may become interesting again. I have to delve into 
its use because I do not entirely understand /how/ it works, but with a 
couple of test scenes I shall get the hang of it I expect.

>> 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.
> 
No change here at the moment.

>> 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....
> 
Slow work somehow, but it is growing. I hope it will meet your 
expectations ;-)

>> 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.
> 
That "Granite Editor" of yours, Can you post me a copy? It looks like an 
interesting tool to use in the approach to re-defining the color_maps, 
and I do it intuitively by hand now. Thanks.


-- 
Thomas

Post a reply to this message