Op 19-4-2021 om 11:57 schreef Paolo Gibellini:
> Thomas de Groot wrote on 16/04/2021 08:46:
>> [snip]>
> 
> Regarding marbles, in my area it was often used marble containing 
> ammonites, does this seem an interesting challenge to you?
> See the picture as reference.
> 
> Paolo

A challenge? It would be a very interesting to do indeed. Not 
immediately as I want to complete the granites first, but it is /an 
offer I cannot refuse/ ;-)

-- 
Thomas

Post a reply to this message

I think we are on the verge of version 2.0 of granites21.inc. Thanks to 
your comments important improvements have been made or are pending. So, 
thank you indeed for your comprehensive contributions.

Attached are examples of the latest developments. All the textures have 
been wrapped into material{} with an ior of quartz (1.6) and now include 
a finish with fresnel. The tentative to use the albedo keyword however, 
has been abandoned for the time being as too difficult apparently to use 
in any way. Without being exclusive, thanks to Alain and Maurice, and of 
course the usual suspects Bald Eagle and Kenneth.

In a next stage, the use of more elaborate macros are planned, including 
sslt possibilities for instance. Bald Eagle has proposed a first version 
of such a macro and I am going to study it and see how to integrate 
things. In the same way, Jr proposed a HowTo html file where for 
instance the content of the headers and additional info can be provided. 
Thanks to both of you.

More discussions can and will follow here of course, but a new version 
of the package will be uploaded in a new post in due time.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'mohoganyfro2-1.jpg' (99 KB) Download 'mohoganyfro2-2.jpg' (99 KB) Download 'mohoganypol2-1.jpg' (101 KB) Download 'mohoganypol2-2.jpg' (98 KB)

Preview of image 'mohoganyfro2-1.jpg'

Preview of image 'mohoganyfro2-2.jpg'

Preview of image 'mohoganypol2-1.jpg'

Preview of image 'mohoganypol2-2.jpg'

Op 20-4-2021 om 14:56 schreef Thomas de Groot:
> More discussions can and will follow here of course, but a new version 
> of the package will be uploaded in a new post in due time.
> 

A couple of things I failed to mention but are particularly important:

1. Following Maurice's suggestion to use a pigment_pattern to vary grain 
sizes, there follows that the use of colour /map/ codes becomes 
important. Bald Eagle suggested this also and we need to determine if 
those should go as different files or whatever, then to be addressed by 
macros.

2. Bald Eagle stressed the importance of starting to make list of "all 
those things we've learned in the past 20 years...". This remained 
dormant until now where I am concerned, but I intend to start to 
actively dig around and document.

Later,

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> to use the albedo keyword however,
> has been abandoned for the time being as too difficult apparently to use
> in any way.

Interested in hearing why - it's always good to document perceived failures as
much as successes.

> In a next stage, the use of more elaborate macros are planned, including
> sslt possibilities for instance.

I simply figured that with something that had transparency like quartz, it might
be a good thing to include.

> Bald Eagle has proposed a first version
> of such a macro and I am going to study it and see how to integrate
> things.

As always, let me know if there are any questions.   The code was mostly to
demonstrate the rudimentary principles and stimulate further discussion and
development.

Now that some of this has percolated in my head for a bit, I think I see
Maurice's concern more clearly - the distribution of the texture elements are
too uniform.  Yes, there are different grain sizes and colors, but there is no
layering, veins, or variation of scale throughout the texture.

Should we have a color_map .map file, or should we have a texture or material
map for something as complex as a granite?   Different grains are different
minerals, with different colors, iors, sslt attributes, finishes, etc.  Maybe
make materials for each individual mineral and then combine them into the final
granite.  More than simplistic, less than explosively complex.   Put some
comments in where we're leaving excessively complicated things out of the stock
new granites, and leave those as avenues to pursue for those wishing to craft
more complex materials.
Part of what I'm thinking is to be able to select from a list of "complete"
materials and use them combinatorially, like in Jonathan Hunt's "Pebbles.pov"

Going even further along that line of include file development, it would be
beneficial to create an array of default versions of all the macro textures so
that the user could address and select them _numerically_.  A macro in the
include file could be called to instantiate such an array if desired, so that
it's not generated each time the include file is called.

I'm thinking that the variation of the granite will probably either have to be
controlled / achieved with layering, or by elevating the level of the underlying
"granite" pattern with a pattern map or function or some other approach.  Here
at the outset, it's not so crucial to actually achieve the goal, but to define
it, so that we can see what theoretically should be done, and then decide what
compromises and tricks can be used to approach that without undue complexity.
Set out some must-have attributes for what, geologically, a proper granite
should embody, and then at least we have something to shoot for.

I also think that the white that got added into some of the granite texture
examples seems "off".   Like they are clouds and are floating over and apart
from the underlying stone and are not a part of it.  Not sure what should be
done to address that, or if you see it as a problem.


Anyway, that's what was bouncing around in my head.

Post a reply to this message

Op 20/04/2021 om 20:06 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> to use the albedo keyword however,
>> has been abandoned for the time being as too difficult apparently to use
>> in any way.
> 
> Interested in hearing why - it's always good to document perceived failures as
> much as successes.
> 
In a nutshell (I want to investigate more of course) I fail to tweak the 
different values (following the rules) without drastically changing the 
colour/aspect of the texture too. Something fundamental escapes me.

>> In a next stage, the use of more elaborate macros are planned, including
>> sslt possibilities for instance.
> 
> I simply figured that with something that had transparency like quartz, it might
> be a good thing to include.
> 
Yes, and it certainly needs more work.

>> Bald Eagle has proposed a first version
>> of such a macro and I am going to study it and see how to integrate
>> things.
> 
> As always, let me know if there are any questions.   The code was mostly to
> demonstrate the rudimentary principles and stimulate further discussion and
> development.
> 
Of course.

> Now that some of this has percolated in my head for a bit, I think I see
> Maurice's concern more clearly - the distribution of the texture elements are
> too uniform.  Yes, there are different grain sizes and colors, but there is no
> layering, veins, or variation of scale throughout the texture.
> 
Yes. I tackled the grainsize differences but I am still not happy with 
the aspect overall.

> Should we have a color_map .map file, or should we have a texture or material
> map for something as complex as a granite?   Different grains are different
> minerals, with different colors, iors, sslt attributes, finishes, etc.  Maybe
> make materials for each individual mineral and then combine them into the final
> granite.  More than simplistic, less than explosively complex.   Put some
> comments in where we're leaving excessively complicated things out of the stock
> new granites, and leave those as avenues to pursue for those wishing to craft
> more complex materials.
> Part of what I'm thinking is to be able to select from a list of "complete"
> materials and use them combinatorially, like in Jonathan Hunt's "Pebbles.pov"
> 
Again, yes. I am now exclusively working on the Mohogany granite and I 
want to explore those avenues you suggest. I realise that I have taken 
on a major investigation :-) and that is ok. I am not bound to a 
deadline. I certainly would like to come up with a credible granite 
material and I am beginning to get "obsessed" by it as it were. Slow 
work of trial and error... discussing the issues helps to focus on the 
weak and strong points, and eliminate dead-end issues.

> Going even further along that line of include file development, it would be
> beneficial to create an array of default versions of all the macro textures so
> that the user could address and select them _numerically_.  A macro in the
> include file could be called to instantiate such an array if desired, so that
> it's not generated each time the include file is called.
> 
yes indeed.

> I'm thinking that the variation of the granite will probably either have to be
> controlled / achieved with layering, or by elevating the level of the underlying
> "granite" pattern with a pattern map or function or some other approach.  Here
> at the outset, it's not so crucial to actually achieve the goal, but to define
> it, so that we can see what theoretically should be done, and then decide what
> compromises and tricks can be used to approach that without undue complexity.
> Set out some must-have attributes for what, geologically, a proper granite
> should embody, and then at least we have something to shoot for.
> 
following what was written higher on. The "depth" aspect of the rock is 
crucial but also difficult to achieve.

> I also think that the white that got added into some of the granite texture
> examples seems "off".   Like they are clouds and are floating over and apart
> from the underlying stone and are not a part of it.  Not sure what should be
> done to address that, or if you see it as a problem.
> 
Imo, the white represents the quartz veins that cut through the 
granites. In the original code they came out as mere "clouds" of grey; I 
brought them back at least as something looking like veins (the top 
texture). See the examples I provided.

> 
> Anyway, that's what was bouncing around in my head.
> 
Quite a lot to have bouncing around in there, sir. ;-)

Your comments are much appreciated and keep me on track.

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 20/04/2021 om 20:06 schreef Bald Eagle:
> > ...
> > that the user could address and select them _numerically_.
> yes indeed.

but how will a numpty like self know how to select?  I do hope that there will a
few introductory paragraphs discussing, and a small table laying out, the
principal (POV-Ray) components making "granite"; their role and useful parameter
ranges, etc.


regards, jr.

Post a reply to this message

Bald Eagle wrote on 19/04/2021 12:33:
> Paolo Gibellini <p.g### [at] gmailcom> wrote:
>> Thomas de Groot wrote on 16/04/2021 08:46:
>>> [snip]>
>>
>> Regarding marbles, in my area it was often used marble containing
>> ammonites, does this seem an interesting challenge to you?
>> See the picture as reference.
>>
>> Paolo
> 
> :D   Way to raise the bar, Paolo.
> 
> 
> Maybe something akin to Ingo's blob pattern could be used for the ammonites, and
> then a repeat warp added in...
> 

I agree with Thomas: we could try to do a challenge, and you could make 
these ideas /concrete/...

Paolo

Post a reply to this message

Thomas de Groot wrote on 19/04/2021 13:56:
> Op 19-4-2021 om 11:57 schreef Paolo Gibellini:
>> Thomas de Groot wrote on 16/04/2021 08:46:
>>> [snip]>
>>
>> Regarding marbles, in my area it was often used marble containing 
>> ammonites, does this seem an interesting challenge to you?
>> See the picture as reference.
>>
>> Paolo
> 
> A challenge? It would be a very interesting to do indeed. Not 
> immediately as I want to complete the granites first, but it is /an 
> offer I cannot refuse/ ;-)
> 

Honestly I used the word challenge in a generic way, but a real 
challenge could be interesting, it would add more content to the inc files.

When you are done...

;-)
Paolo

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I realise that I have taken
> on a major investigation :-) and that is ok.

So did I while writing this!


> Imo, the white represents the quartz veins that cut through the
> granites. In the original code they came out as mere "clouds" of grey; I
> brought them back at least as something looking like veins (the top
> texture). See the examples I provided.

IIRC, the marble pattern is just a series of repeating lines that attains a
marble look due to the turbulence.   Maybe make a material_map using turbulated
marble and have the granite and quartz materials be the entries.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> but how will a numpty like self know how to select?

You won't.  It will be one those fun mystery things, like a grab-bag, an egg
hunt, voting.  Or dating.

Actually, part of the idea I had, which is somewhat demonstrated in the stuff I
posted for TdG, is that, while not self-documenting, the code can be made to be
"self-documentable" - in that, the verbose feature embedded into all of the
macros could be turned on by such an array instantiation macro, and then you'd
generate a list of entries upon execution.  Really, the idea was to have them
available for random selection...

> I do hope that there will a
> few introductory paragraphs discussing, and a small table laying out, the
> principal (POV-Ray) components making "granite"; their role and useful parameter
> ranges, etc.

Could do that, or issue a #warning depending on values of macro parameters.
Might just imply correct values by using min/max in macro definition, or
comments.

I agree, but I can see the line between "include file" and "geology textbook"
becoming rapidly blurred.

Post a reply to this message