Op 03/05/2021 om 19:21 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> For your judgment again.
> 
> This is pretty spectacular, as was the prior ovus example.
> 
> I think what Maurice is trying to point out is the "frosted" look of the blurred
> pattern.
> I think the earlier prototype StepNoise example was more impressive than the
> current iteration.
Both are necessary. The blended version is the weathered granite look, 
the crisp version is the fresh granite look.

> And I'm not sure why you chose to do several experiments with start and end both
> equal to 0.5 - as that is just the cells pattern.
> 
No secret there: just for convenience while testing the omega, lambda 
and octaves. The top row of the experiment shows start and end 
variations both. I guess that more differences would be shown with a 
"simpler" colour_map? Not sure about this. I want to investigate a bit 
further.

> But I must say that I really like this frosted look for an outdoor, weathered
> piece of natural stone, as this is really what it looks like, with dust, and
> evaporated rain, and pollen, etc.  Adding that displacement or normal really
> gives it that natural look as well.
> 
I guess this is almost as close as you can get to a believable granite.

> I think Maurice is looking for that lack of micro-surface texture that leads to
> a lot of air - which has a different ior than the minerals and leads to that dry
> paper / freshly applied transparent tape look.  Polishing, wetting, and waxing
> gives it that sharp, crisp, high-contrast look with more saturated colors and
> clearer delineations between the grains.
> 
> At least that's what I'm speculating.
> 
Maybe. I am not sure yet about what he means.

> However, all in all, this is very pleasing, and extremely encouraging progress!
> 
Absolutely.

-- 
Thomas

Post a reply to this message

A 2048x2048px render.

StepNoise settings: Start=0.2; End=0.8; Turbulence=0.325; and octaves=2; 
lambda=1; omega=2;

-- 
Thomas

Post a reply to this message

Attachments:
Download 'dakotagrains_testbig.jpg' (685 KB)

Preview of image 'dakotagrains_testbig.jpg'

Op 3-5-2021 om 19:21 schreef Bald Eagle:
> However, all in all, this is very pleasing, and extremely encouraging progress!
> 

As an alternative, I am examining the use of another pattern: crackle solid.

It might be an interesting option...

-- 
Thomas

Post a reply to this message

I think this is a perfect alternative to all the preceding!

The basic pigment_pattern used for the mineral grains as well as for the 
mask controlling the size distribution through the rock, is crackle 
solid. It has the advantage to well-discriminate between the different 
minerals, better than all the previous experiments. I found this out by 
examining a couple of traditional POV-Ray stone textures, more 
especially T_Stone_28.inc, and tweak from there before substituting the 
results here.

I think that the "blurry" aspect that Mr was complaining about, came in 
fact from the size distribution within the mask pattern. It may still 
exist a bit, but I developed a mask with less diffuse transitions.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'dakotagrains_testbig3.jpg' (237 KB)

Preview of image 'dakotagrains_testbig3.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:
> I think this is a perfect alternative to all the preceding!
>
> The basic pigment_pattern used for the mineral grains as well as for the
> mask controlling the size distribution through the rock, is crackle
> solid. It has the advantage to well-discriminate between the different
> minerals, better than all the previous experiments. I found this out by
> examining a couple of traditional POV-Ray stone textures, more
> especially T_Stone_28.inc, and tweak from there before substituting the
> results here.
>
> I think that the "blurry" aspect that Mr was complaining about, came in
> fact from the size distribution within the mask pattern. It may still
> exist a bit, but I developed a mask with less diffuse transitions.
>
> --
> Thomas

This sure looks good. I guess my trouble with this scale and contrast/definition
is that I must be loosing track of what context the current image you show is
made for, and thus probably do not have in mind the proper type of real photo
referenced granite occurence. Once we can play with parameters and get these
various photo references side by side with the renders thing will certainly look
fine and more versatile than if made with just one average reference.

If will it or does it already have configuration presets? something along : 1
Raw outside (worn out with slightly blurry patches) 2 raw inside (same pigment,
neater, and with normal bump) 3 polished: same as before without bump and with
slight mirror reflection?

What troubles me, with the scale is that initial picture I saw ad red flakes
around 1cm size while this frosted has rather 1mm... can the first one still be
made easily?

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I think this is a perfect alternative to all the preceding!
>
> The basic pigment_pattern used for the mineral grains as well as for the
> mask controlling the size distribution through the rock, is crackle
> solid.

That's working out just as nicely.
IIRC, crackle solid has different "metrics" and you can get the adjacent cell
effect like you're showing, but also a sort of pavers-and-mortar effect.

These are all looking good, and it will be really nice if there's a way to mix /
blend some of the different patterns and texture_maps, or even the same pattern
at different scales.

Post a reply to this message

Op 5-5-2021 om 18:12 schreef Mr:
> This sure looks good. I guess my trouble with this scale and contrast/definition
> is that I must be loosing track of what context the current image you show is
> made for, and thus probably do not have in mind the proper type of real photo
> referenced granite occurence. Once we can play with parameters and get these
> various photo references side by side with the renders thing will certainly look
> fine and more versatile than if made with just one average reference.
> 
The whole thing is a mess at the moment of course ;-) I need to assess 
now /how/ and /what/ I want to make controls for. A macro architecture 
of course and enough parameters to play with.

> If will it or does it already have configuration presets? something along : 1
> Raw outside (worn out with slightly blurry patches) 2 raw inside (same pigment,
> neater, and with normal bump) 3 polished: same as before without bump and with
> slight mirror reflection?
> 
No yet totally present as such but to be part of that macro I mentioned. 
I hope to start with the cleaning-up now as I guess I have ironed out 
all the problems at this moment.

> What troubles me, with the scale is that initial picture I saw ad red flakes
> around 1cm size while this frosted has rather 1mm... can the first one still be
> made easily?
> 
No idea to be frank. But I keep it in my mind as one of the options.

-- 
Thomas

Post a reply to this message

Op 5-5-2021 om 19:50 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I think this is a perfect alternative to all the preceding!
>>
>> The basic pigment_pattern used for the mineral grains as well as for the
>> mask controlling the size distribution through the rock, is crackle
>> solid.
> 
> That's working out just as nicely.
> IIRC, crackle solid has different "metrics" and you can get the adjacent cell
> effect like you're showing, but also a sort of pavers-and-mortar effect.
> 
I believe so, but I prefer not to use the pavers-and-mortar effect. Less 
natural feeling.

> These are all looking good, and it will be really nice if there's a way to mix /
> blend some of the different patterns and texture_maps, or even the same pattern
> at different scales.
> 
Indeed. Part of the work in progress. ;-)

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...
> The whole thing is a mess at the moment of course ;-) I need to assess
> now /how/ and /what/ I want to make controls for. A macro architecture
> of course and enough parameters to play with.

with the many posts I read, (sorry) I seem to have lost track of 'why'.  whether
it is "simply" a general modernisation, or bringing the code[*] up-to-date for
3.8 and the shiny, new (SDL) toys.  if the latter, then you're spoilt for
choice.  :-)

[*] much of new, I assume.


regards, jr.

Post a reply to this message

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

> I believe so, but I prefer not to use the pavers-and-mortar effect. Less
> natural feeling.

I only mention it because the opening image of this thread has the natural
examples which have quartz veining that is suggestive of this type of
patterning.

Post a reply to this message

Op 6-5-2021 om 11:08 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> ...
>> The whole thing is a mess at the moment of course ;-) I need to assess
>> now /how/ and /what/ I want to make controls for. A macro architecture
>> of course and enough parameters to play with.
> 
> with the many posts I read, (sorry) I seem to have lost track of 'why'.  whether
> it is "simply" a general modernisation, or bringing the code[*] up-to-date for
> 3.8 and the shiny, new (SDL) toys.  if the latter, then you're spoilt for
> choice.  :-)
> 
> [*] much of new, I assume.
> 
The latter, I am afraid. The whole project has taken a life of is own. :-)

-- 
Thomas

Post a reply to this message

Op 6-5-2021 om 12:21 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> I believe so, but I prefer not to use the pavers-and-mortar effect. Less
>> natural feeling.
> 
> I only mention it because the opening image of this thread has the natural
> examples which have quartz veining that is suggestive of this type of
> patterning.
> 
No, that is different. Veins can run randomly through the rock and are 
of another order. We are coming to that later on.

-- 
Thomas

Post a reply to this message

Op 29/04/2021 om 17:56 schreef jr:
> (am interested to see it being used other than in a demo/reference image)

Thomas de Groot <tho### [at] degrootorg> wrote:
> I certainly agree with that. something is planned in that way.

I will gladly volunteer the stone crosses in my current animation project as a
showcase for this astounding texture! (Currently using T_Stone20.)

If you're not ready to release the final code yet then feel free to send the
prototype code to isn### [at] domainch where the domain is protonmail.

I feel compelled to admit that I'm so entranced by this texture that I don't
want to wait! I also understand if you prefer not to release a WIP out into the
world.

Kind regards,
Dave Blandston

Post a reply to this message

Op 08/05/2021 om 07:37 schreef Dave Blandston:
> Op 29/04/2021 om 17:56 schreef jr:
>> (am interested to see it being used other than in a demo/reference image)
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> I certainly agree with that. something is planned in that way.
> 
> I will gladly volunteer the stone crosses in my current animation project as a
> showcase for this astounding texture! (Currently using T_Stone20.)
> 
> If you're not ready to release the final code yet then feel free to send the
> prototype code to isn### [at] domainch where the domain is protonmail.
> 
> I feel compelled to admit that I'm so entranced by this texture that I don't
> want to wait! I also understand if you prefer not to release a WIP out into the
> world.
> 
> Kind regards,
> Dave Blandston
> 

Done! I sent you the prototype code.

I do not take responsibility for PC's taking fire, earthquakes, and 
crumbling crosses under excessive granite weight. :-)

-- 
Thomas

Post a reply to this message

Op 08/05/2021 om 08:46 schreef Thomas de Groot:
> Done! I sent you the prototype code.
> 

Oho... bounced back with following message:

  Message not delivered
Your message couldn't be delivered to isn### [at] domainch because the 
remote server is misconfigured. See the technical details below for more 
information.

The response from the remote server was:

550 relay not permitted

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Oho... bounced back with following message:

It looks like part of the address may have been obscured and/or scrambled
somewhere along the way. I'll break it up to stymie the system. The first part
should be isnomore then the circled a symbol then the domain which is protonmail
then a dot then the letters ch. I also just took the opportunity to update my
profile with the e-mail address so hopefully that will help.

Kind regards,
Dave Blandston
POV-Ray rebel: proudly using gamma 2.2 since POV-Ray had gamma

Post a reply to this message

Op 08/05/2021 om 23:19 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Oho... bounced back with following message:
> 
> It looks like part of the address may have been obscured and/or scrambled
> somewhere along the way. I'll break it up to stymie the system. The first part
> should be isnomore then the circled a symbol then the domain which is protonmail
> then a dot then the letters ch. I also just took the opportunity to update my
> profile with the e-mail address so hopefully that will help.
> 
> Kind regards,
> Dave Blandston
> POV-Ray rebel: proudly using gamma 2.2 since POV-Ray had gamma
> 

OK. I sent the code again and this time correctly it seems. Your initial 
mail address was indeed different from this one. You got also the latest 
version, on its way to the macro structure I have in mind. Easier to use 
and: many more options to select from!

Warning: A couple of things do not work (correctly) as yet. The polished 
version of the granite (Pol=on), and the veined version (Typ=2). Neither 
does the subsurface light transport. And finally, the colour space 
switch (SCS) is not implemented either.

Good luck, and let me know your thoughts about the code.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Good luck, and let me know your thoughts about the code.

Got it!


Kind regards,
Dave Blandston
POV-Ray rebel: proudly using gamma 2.2 since POV-Ray had gamma

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...on its way to the macro structure I have in mind. Easier to use and: many more
options to select from!

Based on your demo images I was expecting the StepNoise version to look best but
the crackle solid version seemed slightly more realistic in this particular
scene. The option to select which function to use is very useful.

LIGHTSYS is a much better lighting method than I've been able to achieve so some
realism was lost in my scene but I think you and your collaborators have created
an awesome material. Maybe LIGHTSYS can be applied to this scene in order to
take full advantage of the subtle nuances of your granite but that will have to
be a project for another day...

The attached image shows how great the new granite looks in spite of my poor
scene lighting ability. This type of granite turned out to be a little too
"busy" for this scene but I think the Flanders Gray will be perfect. (Just as
you described in your posting!) The coloration of the Flanders Gray sample is
spectacular in my opinion and I hope that variation makes it into the final
product.

Thanks for letting me beta test your granite!

Kind regards,
Dave Blandston
POV-Ray rebel: proudly using gamma 2.2 since POV-Ray had gamma

Post a reply to this message

Attachments:
Download 'dakotagrainshighlight.jpg' (147 KB)

Preview of image 'dakotagrainshighlight.jpg'

Op 10/05/2021 om 01:05 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> ...on its way to the macro structure I have in mind. Easier to use and: many more
options to select from!
> 
> Based on your demo images I was expecting the StepNoise version to look best but
> the crackle solid version seemed slightly more realistic in this particular
> scene. The option to select which function to use is very useful.
> 
Good.

> LIGHTSYS is a much better lighting method than I've been able to achieve so some
> realism was lost in my scene but I think you and your collaborators have created
> an awesome material. Maybe LIGHTSYS can be applied to this scene in order to
> take full advantage of the subtle nuances of your granite but that will have to
> be a project for another day...
> 
Sure, especially for landscapes.

> The attached image shows how great the new granite looks in spite of my poor
> scene lighting ability. This type of granite turned out to be a little too
> "busy" for this scene but I think the Flanders Gray will be perfect. (Just as
> you described in your posting!) The coloration of the Flanders Gray sample is
> spectacular in my opinion and I hope that variation makes it into the final
> product.
> 
You could try the 'blend' option here and see if it looks better. The 
template of the Dakota Red will be used for the other granites too later 
on, with the necessary adaptations of course to those particular granites.

> Thanks for letting me beta test your granite!
> 
And thanks for testing! In the meantime, I have finished a preliminary 
macro architecture including also the polished version and the veins. 
Very soon now, I shall post a beta for everybody to shoot at. Stay attuned!

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> ...
> Very soon now, I shall post a beta for everybody to shoot at. Stay attuned!

super, thanks.  looking forward to it.


regards, jr.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> And thanks for testing! In the meantime, I have finished a preliminary
> macro architecture including also the polished version and the veins.
> Very soon now, I shall post a beta for everybody to shoot at. Stay attuned!

I do have one suggestion, which is to replace "#declare" with "#local" for
everything except the finished materials. I ran into one conflict. (It was a
function denoted by the single letter "K.")

I am very excited about this project! After experimenting a little more I'm
convinced this is a major development and will certainly be replacing the old
granite in my project with this wonderful new concoction.

By the way, what is the meaning of "Granites Intermezzo?"

Have an awesome day!

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

Post a reply to this message

Op 11-5-2021 om 09:50 schreef Dave Blandston:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> And thanks for testing! In the meantime, I have finished a preliminary
>> macro architecture including also the polished version and the veins.
>> Very soon now, I shall post a beta for everybody to shoot at. Stay attuned!
> 
> I do have one suggestion, which is to replace "#declare" with "#local" for
> everything except the finished materials. I ran into one conflict. (It was a
> function denoted by the single letter "K.")
> 
Which is/will be done indeed in the upcoming macro version.

"K" would point to the Bald Eagle Step Noise contribution. It is not yet 
entirely well-integrated. However, I never had conflicts with it, so 
maybe you got a special case?

> I am very excited about this project! After experimenting a little more I'm
> convinced this is a major development and will certainly be replacing the old
> granite in my project with this wonderful new concoction.
> 
Thanks indeed. I am certainly satisfied with the results too. Still a 
couple of things to take care of, but nothing really serious at this stage.

> By the way, what is the meaning of "Granites Intermezzo?"
> 
I consider this series of posts as 'intermediary' between the original 
exchange, starting with the Daniel Mecklenburg code upgrade, and the 
upcoming beta version of a first granite set. More will follow after 
that one.

> Have an awesome day!
> 
<grin>

-- 
Thomas

Post a reply to this message

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

> > I do have one suggestion, which is to replace "#declare" with "#local" for
> > everything except the finished materials. I ran into one conflict. (It was a
> > function denoted by the single letter "K.")

Mmm, yes.  I suppose that anything that could be released upon exit from the
include file ought to be declared locally, if for no other reason that to
practice good form going forward from this point.

> "K" would point to the Bald Eagle Step Noise contribution. It is not yet
> entirely well-integrated. However, I never had conflicts with it, so
> maybe you got a special case?

K is pretty much just a straight copy-paste from from Wikipedia / Inigo Quilez /
ShaderToy / The Art of Code / GLSL ...  I just used the same variable names to
make reading and potential debugging easier upon a first read-through.

Ken Perlin has suggested an improved version, no idea how that would affect the
appearance of the texture.

I suppose there are a lot of variations that would be nice to look at, exploring
different interpolation formulas and splines.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Mmm, yes.  I suppose that anything that could be released upon exit from the
> include file ought to be declared locally, if for no other reason that to
> practice good form going forward from this point.

Yep, that would be good - keep everything local that can possibly be kept local.
There is at least one other single-letter function designator ("N") so the
chance of a conflict with other variables in a scene definitely exists. The
reason I had a collision with "K" is because I use the letter "I" to control
loops (short for "Index") then for nested loops I just keep going with "J," then
"K," et cetera. "N" is probably popular because it's the first letter of
"Number." There is no downside to using "#local" wherever possible, but there is
a benefit.



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

Post a reply to this message

Op 11-5-2021 om 13:27 schreef Dave Blandston:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> Mmm, yes.  I suppose that anything that could be released upon exit from the
>> include file ought to be declared locally, if for no other reason that to
>> practice good form going forward from this point.
> 
> Yep, that would be good - keep everything local that can possibly be kept local.
> There is at least one other single-letter function designator ("N") so the
> chance of a conflict with other variables in a scene definitely exists. The
> reason I had a collision with "K" is because I use the letter "I" to control
> loops (short for "Index") then for nested loops I just keep going with "J," then
> "K," et cetera. "N" is probably popular because it's the first letter of
> "Number." There is no downside to using "#local" wherever possible, but there is
> a benefit.
> 
I am presently looking at Bald Eagle's code with the intention to 
implement it inside the granite macro. In that case, all declares will 
become locals obviously and stop giving problems like you encountered.

Another consequence will be that I shall need to define at least three 
additional parameters for the granite macro: Start, End, Turbulence.

@Bald Eagle: in your original code you also defined a parameter "Scale" 
which subsequently was not used. Where did you want to place it? It 
might be an interesting fourth addition.

My reworking of the code would look like this:

//---start code---
#ifndef (SN_Start) #local SN_Start = 0.2; #end
#ifndef (SN_End)   #local SN_End   = 0.8; #end
#ifndef (SN_Turb)  #local SN_Turb  = 0.325; #end
#ifndef (SN_Scale) #local SN_Scale = 0.25; #end

// smoothstep function
#local K = function (t1, t2, T) {max (0, min(1, (T-t1)/(t2-t1) ) )}
#local Smoothstep = function (t1, t2, T) {pow (K(t1, t2, T), 2) * 
(3-2*K(t1, t2, T))}

// mod function that plays nice when crossing 0
#local Mod = function (T) {select (T,  1-mod (abs(T), 1),  mod (abs(T), 
1) )}

// smooth step function
//#local N = function (NN) {floor (NN-0.5) + Smoothstep (SN_Start, 
SN_End, abs(Mod(NN-0.5)-0.5) )}
#local N = function (NN) {floor (NN) + Smoothstep (SN_Start, SN_End, 
Mod(NN) )}

/* usage
#declare StepNoise =
pigment {
   function {f_noise3d (N(x), N(y), N(z))}
   turbulence SN_Turb
}
*/
//---end code---


-- 
Thomas

Post a reply to this message

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

> I am presently looking at Bald Eagle's code with the intention to
> implement it inside the granite macro. In that case, all declares will
> become locals obviously and stop giving problems like you encountered.

I personally might try to rename the parameters to make them unique to the
include file.  GranInc_K or something like that.  1000 times less likely that
someone will try to use that compared to N, NN or K.

> Another consequence will be that I shall need to define at least three
> additional parameters for the granite macro: Start, End, Turbulence.
>
> @Bald Eagle: in your original code you also defined a parameter "Scale"
> which subsequently was not used. Where did you want to place it? It
> might be an interesting fourth addition.

I defined that in order to scale all of the textures at once when I was
comparing f_noise3D, StepNoise, and cells.
If you see a place where you'd like to scale the function independently of where
things might all be scaled together with the scale keyword, then it would get
placed inside the N parts of the StepNoise function like: N(x/Scale).

> My reworking of the code would look like this:
>
> //---start code---
> #ifndef (SN_Start) #local SN_Start = 0.2; #end
> #ifndef (SN_End)   #local SN_End   = 0.8; #end
> #ifndef (SN_Turb)  #local SN_Turb  = 0.325; #end
> #ifndef (SN_Scale) #local SN_Scale = 0.25; #end
>
> // smoothstep function
> #local K = function (t1, t2, T) {max (0, min(1, (T-t1)/(t2-t1) ) )}
> #local Smoothstep = function (t1, t2, T) {pow (K(t1, t2, T), 2) *
> (3-2*K(t1, t2, T))}
>
> // mod function that plays nice when crossing 0
> #local Mod = function (T) {select (T,  1-mod (abs(T), 1),  mod (abs(T),
> 1) )}
>
> // smooth step function
> //#local N = function (NN) {floor (NN-0.5) + Smoothstep (SN_Start,
> SN_End, abs(Mod(NN-0.5)-0.5) )}
> #local N = function (NN) {floor (NN) + Smoothstep (SN_Start, SN_End,
> Mod(NN) )}
>
> /* usage
> #declare StepNoise =
> pigment {
>    function {f_noise3d (N(x), N(y), N(z))}
>    turbulence SN_Turb
> }
> */
> //---end code---
>
>
> --
> Thomas

Maybe rename/preface Mod and SmoothStep.
Also, to remove the dependency on functions.inc, f_noise3D id defined as
function {internal(76)}.
So maybe do:  #declare GraniteNoise = function {internal(76)}

But I think that until you release a test version "into the wild", we won't be
able to predict where some tricky problems may be hiding.

Post a reply to this message

Op 11-5-2021 om 19:44 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> I am presently looking at Bald Eagle's code with the intention to
>> implement it inside the granite macro. In that case, all declares will
>> become locals obviously and stop giving problems like you encountered.
> 
> I personally might try to rename the parameters to make them unique to the
> include file.  GranInc_K or something like that.  1000 times less likely that
> someone will try to use that compared to N, NN or K.
> 
Done.

>> Another consequence will be that I shall need to define at least three
>> additional parameters for the granite macro: Start, End, Turbulence.
>>
>> @Bald Eagle: in your original code you also defined a parameter "Scale"
>> which subsequently was not used. Where did you want to place it? It
>> might be an interesting fourth addition.
> 
> I defined that in order to scale all of the textures at once when I was
> comparing f_noise3D, StepNoise, and cells.
> If you see a place where you'd like to scale the function independently of where
> things might all be scaled together with the scale keyword, then it would get
> placed inside the N parts of the StepNoise function like: N(x/Scale).
> 
Ok. I shall not use it as it appears to be redundant with other scales.

>> My reworking of the code would look like this:
>>
>> [snip]
> 
> Maybe rename/preface Mod and SmoothStep.

Done.

> Also, to remove the dependency on functions.inc, f_noise3D id defined as
> function {internal(76)}.
> So maybe do:  #declare GraniteNoise = function {internal(76)}
> 
Hmm. Not sure yet if I want to do that. Not change for the time being.

> But I think that until you release a test version "into the wild", we won't be
> able to predict where some tricky problems may be hiding.
> 
Sure.

-- 
Thomas

Post a reply to this message

All right! This is going to be the *last* test image of the pre-macro 
Dakota Red Granite, closing also this Intermezzo.

Shown here, is the current implementation of the quartz veins through 
the granite, using the marble pattern. Please note that this feature 
will remain /experimental/ in the upcoming beta macro which I shall 
provide tomorrow.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'dakotagrains_test_veins.jpg' (93 KB)

Preview of image 'dakotagrains_test_veins.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:
> All right! This is going to be the *last* test image of the pre-macro
> Dakota Red Granite, closing also this Intermezzo.
>
> Shown here, is the current implementation of the quartz veins through
> the granite, using the marble pattern. Please note that this feature
> will remain /experimental/ in the upcoming beta macro which I shall
> provide tomorrow.
>
> --
> Thomas

Artistically , I love it !  And if the geologist validates it, that's even
greater !

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> All right! This is going to be the *last* test image of the pre-macro
> Dakota Red Granite, closing also this Intermezzo.
>
> Shown here, is the current implementation of the quartz veins through
> the granite, using the marble pattern. Please note that this feature
> will remain /experimental/ in the upcoming beta macro which I shall
> provide tomorrow.

This is looking very nice!  :)

Just going to jot down some observations and thoughts, some which we may
address, and some we might not.

I think the pattern we have is better that the previous stock pattern.  The
grain size is still too uniform, but maybe if several adjacent grains were
textured identically, using the hexagon/bricks trick, then we could get a less
homogeneous size distribution.

Next I guess would be crafting the textures of the individual minerals composing
the grains.

Aside:
I took the boy outside last weekend - the oxygen and sunlight surely burned his
lungs and skin - and we explored the retaining wall of the local dam
https://www.nae.usace.army.mil/Missions/Civil-Works/Flood-Risk-Management/New-Hampshire/Hop-Ev/
Lots of granite, big chunks of quartz, and other things yet to be identified "Is
that andesite?" (smart kid - or maybe it's Minecraft...)
I noticed that the quartz, while appearing translucent white in small samples,
took on an agate gray/purple cast as the veins or chunks got larger and deeper
and Beer's law started to really kick in.  There were also striations
perpendicular to the vein line, and some of the quartz was bordered by a
different mineral that was more chalky / portland cement solid white, whatever
that might be.

There were also "rust spots" in some of the rocks, as well as plates of of mica.
 And mixed in with the granites were a few very smooth fine-grained/grainless
stones that had a dark grey transitioning to red color, such that they almost
looked like they were rusting.

I can return and take samples, photos, closeups if we think such would assist.

I would imagine that the quartz veins will be the most challenging to implement,
as there will be the issue of presence, thickness, number of veins, orientation,
amount of turbulence, etc.  Maybe that's best handled by an optional array that
the macro checks to see if present.

Post a reply to this message

Op 13-5-2021 om 17:27 schreef Mr:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> All right! This is going to be the *last* test image of the pre-macro
>> Dakota Red Granite, closing also this Intermezzo.
>>
>> Shown here, is the current implementation of the quartz veins through
>> the granite, using the marble pattern. Please note that this feature
>> will remain /experimental/ in the upcoming beta macro which I shall
>> provide tomorrow.
>>
>> --
>> Thomas
> 
> Artistically , I love it !  And if the geologist validates it, that's even
> greater !
> 
Thanks. Validating... it depends on how deep you want to go into the 
Uncanny Valley, or beyond into a complete and exact copy of reality. The 
second, is imo, hardly possible (and certainly not recommended in terms 
of workload and ultimate usage); the first would need a lot more 
detailed work including close-up comparisons with real samples, but 
would not be justified by the average intentions of individual users. I 
doubt if even professionals would want it: they probably would opt for a 
high-resolution image_map.

So, I do validate this version of the Dakota Red granite, perhaps not as 
a true /Dakota Red/, but as a type of red granite. In a later stage we 
shall tackle the /Canadian Pink/ and the /North American Pink/. Will 
they be different from the present one? We shall see.

-- 
Thomas

Post a reply to this message

Op 13-5-2021 om 20:40 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> All right! This is going to be the *last* test image of the pre-macro
>> Dakota Red Granite, closing also this Intermezzo.
>>
>> Shown here, is the current implementation of the quartz veins through
>> the granite, using the marble pattern. Please note that this feature
>> will remain /experimental/ in the upcoming beta macro which I shall
>> provide tomorrow.
> 
> This is looking very nice!  :)
> 
I had been writing an answer to this post, and then it was lost... drat! 
Have to do it again. :-/

> Just going to jot down some observations and thoughts, some which we may
> address, and some we might not.
> 
> I think the pattern we have is better that the previous stock pattern.  The
> grain size is still too uniform, but maybe if several adjacent grains were
> textured identically, using the hexagon/bricks trick, then we could get a less
> homogeneous size distribution.
> 
You have to realise that granites in general /are/ rather uniform in 
grain size, only a certain class of rocks show marked size differences 
('phenocrysts', 'porphyritic') where the large crystals are represented 
by feldspars rather than quartz. So, the size distribution in the 
present concept is about right.

> Next I guess would be crafting the textures of the individual minerals composing
> the grains.
> 
No, I would advise against doing that, for the simple reason that it 
would be overkill for most of the uses of the material. Additionally it 
would burden memory and parser/render time to unacceptable levels. Much 
better would be to find a 'fast' way to add a believable sslt 
(conundrum, I know).

> Aside:
> I took the boy outside last weekend - the oxygen and sunlight surely burned his
> lungs and skin - and we explored the retaining wall of the local dam
>
https://www.nae.usace.army.mil/Missions/Civil-Works/Flood-Risk-Management/New-Hampshire/Hop-Ev/
> Lots of granite, big chunks of quartz, and other things yet to be identified "Is
> that andesite?" (smart kid - or maybe it's Minecraft...)

Excellent exercise! To be recommended for everybody in 'rocky' country. 
Beautiful landscape btw. I like it.
As said above, the big chunks are probably feldspars rather quartz, and 
no, no 'andesite', which would be a fine-grained, dark, extrusive rock 
and no granite. However, a smart suggestion indeed. The big chunks may 
point to a porphyry or a gabbro instead of a true granite.

> I noticed that the quartz, while appearing translucent white in small samples,
> took on an agate gray/purple cast as the veins or chunks got larger and deeper
> and Beer's law started to really kick in.  There were also striations
> perpendicular to the vein line, and some of the quartz was bordered by a
> different mineral that was more chalky / portland cement solid white, whatever
> that might be.
> 
Yes, those characteristics seem to point to feldspars. the 'chalky' 
colour might point to 'weathering' of the minerals.

> There were also "rust spots" in some of the rocks, as well as plates of of mica.
>   And mixed in with the granites were a few very smooth fine-grained/grainless
> stones that had a dark grey transitioning to red color, such that they almost
> looked like they were rusting.
> 
Hmmm... inclusions of stones... maybe we are not dealing with a true 
granite here. Granites do not have such inclusions.

> I can return and take samples, photos, closeups if we think such would assist.
> 
Well, a few photos would do no harm indeed. Remember however, that we 
are dealing here with /Dakota/ granites! If taking photos, remember to 
put in a coin or something recognisable for size. Good practice for such 
things!

> I would imagine that the quartz veins will be the most challenging to implement,
> as there will be the issue of presence, thickness, number of veins, orientation,
> amount of turbulence, etc.  Maybe that's best handled by an optional array that
> the macro checks to see if present.
> 
Yes, the veins are a problem. I was wondering if we should not need some 
kind of function to do this well. Not sure how to do this correctly.

-- 
Thomas

Post a reply to this message

Le 2021-05-14 à 04:24, Thomas de Groot a écrit :
> Op 13-5-2021 om 17:27 schreef Mr:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> All right! This is going to be the *last* test image of the pre-macro
>>> Dakota Red Granite, closing also this Intermezzo.
>>>
>>> Shown here, is the current implementation of the quartz veins through
>>> the granite, using the marble pattern. Please note that this feature
>>> will remain /experimental/ in the upcoming beta macro which I shall
>>> provide tomorrow.
>>>
>>> -- 
>>> Thomas
>>
>> Artistically , I love it !  And if the geologist validates it, that's 
>> even
>> greater !
>>
> Thanks. Validating... it depends on how deep you want to go into the 
> Uncanny Valley, or beyond into a complete and exact copy of reality. The 
> second, is imo, hardly possible (and certainly not recommended in terms 
> of workload and ultimate usage); the first would need a lot more 
> detailed work including close-up comparisons with real samples, but 
> would not be justified by the average intentions of individual users. I 
> doubt if even professionals would want it: they probably would opt for a 
> high-resolution image_map.
> 
> So, I do validate this version of the Dakota Red granite, perhaps not as 
> a true /Dakota Red/, but as a type of red granite. In a later stage we 
> shall tackle the /Canadian Pink/ and the /North American Pink/. Will 
> they be different from the present one? We shall see.
> 

The uncanny Valley is rather shallow when it comes to things like the 
pattern of rocks.

Post a reply to this message

Op 14-5-2021 om 16:48 schreef Alain Martel:
> Le 2021-05-14 à 04:24, Thomas de Groot a écrit :
>> Op 13-5-2021 om 17:27 schreef Mr:
>>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>> All right! This is going to be the *last* test image of the pre-macro
>>>> Dakota Red Granite, closing also this Intermezzo.
>>>>
>>>> Shown here, is the current implementation of the quartz veins through
>>>> the granite, using the marble pattern. Please note that this feature
>>>> will remain /experimental/ in the upcoming beta macro which I shall
>>>> provide tomorrow.
>>>>
>>>> -- 
>>>> Thomas
>>>
>>> Artistically , I love it !  And if the geologist validates it, that's 
>>> even
>>> greater !
>>>
>> Thanks. Validating... it depends on how deep you want to go into the 
>> Uncanny Valley, or beyond into a complete and exact copy of reality. 
>> The second, is imo, hardly possible (and certainly not recommended in 
>> terms of workload and ultimate usage); the first would need a lot more 
>> detailed work including close-up comparisons with real samples, but 
>> would not be justified by the average intentions of individual users. 
>> I doubt if even professionals would want it: they probably would opt 
>> for a high-resolution image_map.
>>
>> So, I do validate this version of the Dakota Red granite, perhaps not 
>> as a true /Dakota Red/, but as a type of red granite. In a later stage 
>> we shall tackle the /Canadian Pink/ and the /North American Pink/. 
>> Will they be different from the present one? We shall see.
>>
> 
> The uncanny Valley is rather shallow when it comes to things like the 
> pattern of rocks.

Yes, that is certainly true indeed, but you get my meaning.

-- 
Thomas

Post a reply to this message

Thomas de Groot wrote on 13/05/2021 17:02:
> All right! This is going to be the *last* test image of the pre-macro 
> Dakota Red Granite, closing also this Intermezzo.
> 
> Shown here, is the current implementation of the quartz veins through 
> the granite, using the marble pattern. Please note that this feature 
> will remain /experimental/ in the upcoming beta macro which I shall 
> provide tomorrow.
> 

It looks great!

Paolo

Post a reply to this message