POV-Ray : Newsgroups : povray.binaries.images : Granites Intermezzo Server Time
23 Jun 2021 13:56:53 EDT (-0400)
  Granites Intermezzo (Message 72 to 81 of 86)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>
From: Dave Blandston
Subject: Re: Granites Intermezzo
Date: 11 May 2021 03:55:00
Message: <web.609a36f4cfb077e479416a1f607c1b34@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Granites Intermezzo
Date: 11 May 2021 04:23:31
Message: <609a3f03$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: Granites Intermezzo
Date: 11 May 2021 06:20:00
Message: <web.609a59ffcfb077e41f9dae3025979125@news.povray.org>
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

From: Dave Blandston
Subject: Re: Granites Intermezzo
Date: 11 May 2021 07:30:00
Message: <web.609a6a17cfb077e479416a1f607c1b34@news.povray.org>
"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

From: Thomas de Groot
Subject: Re: Granites Intermezzo
Date: 11 May 2021 08:05:03
Message: <609a72ef@news.povray.org>
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

From: Bald Eagle
Subject: Re: Granites Intermezzo
Date: 11 May 2021 13:45:00
Message: <web.609ac27dcfb077e41f9dae3025979125@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Granites Intermezzo
Date: 12 May 2021 08:35:42
Message: <609bcb9e$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: Granites Intermezzo - last test image!
Date: 13 May 2021 11:02:41
Message: <609d3f91@news.povray.org>
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'
dakotagrains_test_veins.jpg


 

From: Mr
Subject: Re: Granites Intermezzo - last test image!
Date: 13 May 2021 11:30:00
Message: <web.609d454c21b6342116086ed03f378f2@news.povray.org>
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

From: Bald Eagle
Subject: Re: Granites Intermezzo - last test image!
Date: 13 May 2021 14:45:00
Message: <web.609d72a921b634211f9dae3025979125@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.