granites.inc from 1996 is not officially part of the POV-Ray set of 
include files but I believe it should be part of a larger collection of 
essential include files developed over the years by the users community.

The original code, which I have been able to trace back to 1996, I have 
upgraded to version 3.7+ standards. The result is made available in 
p.b.s-f. The collection set contains:

1. the original granites.inc file (comments included);
2. the upgraded granites21.inc file which provides three versions for 
each granite type (comments included);
3. example scene files for each granite type;
4. a set of rendered images of each granite type. Two of those are shown 
here.

Comments welcome of course.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'napfro0.jpg' (73 KB) Download 'nappol0-1.jpg' (74 KB)

Preview of image 'napfro0.jpg'

Preview of image 'nappol0-1.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:
> granites.inc from 1996 is not officially part of the POV-Ray set of
> include files but I believe it should be part of a larger collection of
> essential include files developed over the years by the users community.
>
> The original code, which I have been able to trace back to 1996, I have
> upgraded to version 3.7+ standards. The result is made available in
> p.b.s-f. The collection set contains:
>
> 1. the original granites.inc file (comments included);
> 2. the upgraded granites21.inc file which provides three versions for
> each granite type (comments included);
> 3. example scene files for each granite type;
> 4. a set of rendered images of each granite type. Two of those are shown
> here.
>
> Comments welcome of course.
>
> --
> Thomas

Hello, only looking at the images so far, and sorry to be nitpicking, but it is
only with hope it would really be a benefit of such discussions? Here is the
thing: I adore the first rawest granite, while i abhore the second :-D ... Let
me quickly add why of course; The rawest one has nice roughness, brilliance
curve / Oren nayar sigma, corresponding to realistic behavior that I intuit
would be consistent in a radiosity scene and to represent what it is meant for.
The polished one however really shows the repetition of procedural texturing too
visibly, to the point that it breaks everything else, which would otherwise of
course work fine for a polished material... Fist thing I would try, to see if it
solves the problem would be to give a bigger scale to the pattern; Or combine
two variants of that pattern with both scales using a third masking /warping
pattern, so that variation seems less homogenous. May be tweaking its color map
to closer match what is found in some photographic reference and have less
contrast in the smaller scale end to cheat that. I assume both version are
supposed to be somewhat matching patterns? the suggested change would not harm
the first image if propagated.

Finally it's not included? I believe some of the current official included
textures are not up to even the one I like less, so is there a legal reason for
not including? otherwise I would still vote for inclusion of both, even as they
are now.


Thanks for asking feedback and sorry to be that pronounced, it's easier to
comment than to do.

Post a reply to this message

"Mr" <nomail@nomail> wrote:

> The polished one however really shows the repetition of procedural texturing too
> visibly, to the point that it breaks everything else, which would otherwise of
> course work fine for a polished material...

You have better eyes than I do ;-) I am not yet seeing the repetition of the
pattern in the polished version. If there, I would guess that it would go
unnoticed in most rendered scenes. I actually like that one better than the
unpolished/raw example.

But I see tiny dark specks in the raw version, which seem to be missing from the
polished one's appearance. I assume that they both use the identical granite
pattern? Or perhaps not.

Post a reply to this message

Op 11-4-2021 om 14:48 schreef Mr:
> Thanks for asking feedback and sorry to be that pronounced, it's easier to
> comment than to do.
> 

You are very welcome indeed to comment in any way :-)

My initial - and still main - purpose is to provide an /ancient/ code in 
more /modern/ context. I think that granites.inc (1996) merits to be 
considered. I am sure that your objections are valid. However, the code 
needs to be given as it was written 25 years ago (with some minor 
changes by me, I confess) and not as one written today, with all the 
knowledge accumulated since then. This is a piece of POV-Ray archeology 
as it were...

-- 
Thomas

Post a reply to this message

Op 11-4-2021 om 15:26 schreef Kenneth:
> "Mr" <nomail@nomail> wrote:
> 
>> The polished one however really shows the repetition of procedural texturing too
>> visibly, to the point that it breaks everything else, which would otherwise of
>> course work fine for a polished material...
> 
> You have better eyes than I do ;-) I am not yet seeing the repetition of the
> pattern in the polished version. If there, I would guess that it would go
> unnoticed in most rendered scenes. I actually like that one better than the
> unpolished/raw example.

I didn't see them either.

> 
> But I see tiny dark specks in the raw version, which seem to be missing from the
> polished one's appearance. I assume that they both use the identical granite
> pattern? Or perhaps not.
> 
They do (mostly) but not always indeed.

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 11-4-2021 om 14:48 schreef Mr:
> > Thanks for asking feedback and sorry to be that pronounced, it's easier to
> > comment than to do.
>
> You are very welcome indeed to comment in any way :-)
>
> My initial - and still main - purpose is to provide an /ancient/ code in
> more /modern/ context. I think that granites.inc (1996) merits to be
> considered. I am sure that your objections are valid. However, the code
> needs to be given as it was written 25 years ago (with some minor
> changes by me, I confess) and not as one written today, with all the
> knowledge accumulated since then. This is a piece of POV-Ray archeology
> as it were...

I like the idea of archiving and maintaining, etc.  however, access to the
information too has to be considered.  when I unzipped the archives I got that
... sinking feeling, you know, dozens of files but not even a README
(equivalent).  so I suggest providing an additional document in some format
(PDF, html, or txt), that gives context and perhaps has a "manifest".

anyway, mindful of Mr's closing comment, I've thrown together an example html
page with sections for three of the granites -- literally a cut and paste job,
so layout (and <style>) are not right; it looks for the images in a 'img'
sub-directory.


regards, jr.

Post a reply to this message

Attachments:
Download 'granites21.html.txt.htm' (3 KB)

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

> My initial - and still main - purpose is to provide an /ancient/ code in
> more /modern/ context.

Than you, Thomas - I'm sure it's a LOT of tedious editing to get these things
into shape.  I have not looked over your code or image zips yet - but since
these are old, historic scene codes, perhaps consider including the
"deprecate(d)" keyword to show the "new" way of writing "old" code.

The discussion so far highlights some interesting things.
_I_ thought the second image was better - probably because I'm used to seeing
more polished granite in such shapes, whereas the first might be ok for curbs
and dry loose rock here in The Granite State.  The second also has more contrast
and a pleasing color map than the first.  So interesting to see what some people
find "better".

It also suggests that here, at the outset, we should start to compile a list of
"all those things we've learned in the past 20 years..." and then apply them to
the same classes of texture to see what improvements we can make.

srgb
radiosity
layering fractal noise
different noise generator functions
ways of incorporating and balancing diffuse, specular, metallic, ior,
subsurface, fresnel, ...  and a lot of other things that I'm missing.


One thing we might try is - rather than having static definitions of the
textures where the include file has to be hunted down and edited - what if we
wrote them as macros that generated the texture?

You could have a default, a little #debug blurb that summarizes the parameters
and usage syntax, and maybe an index macro that summarizes all of the available
texture macros in the include file.  ("Is it granite_03, or Granite03, or....?")
Perhaps think of naming the macros to indicate how many [optional] parameters
there are, or have a default texture macro call the "real" texture macro with
the proper number of parameters.  If any argument is suplied to the default
macro, it will trigger a verbose help mode for the real texture macro that barfs
out a bunch of stuff to #default text stream.

Then we could have boilerplate texture structure that would incorporate all of
the important points that have been addressed over the years, and the user could
adapt the texture from within the scene file, leaving the core macro code
untouched.
Something akin to quality levels could be integrated into the texture itself,
shutting off very slow features like subsurface, reflection, etc during scene
development, but making them instantly available for a final render.

I also have come across old examples of people writing .map files for color
maps.  I think this would be incredibly useful in the present context, and
something I have not seen done in a long time.  The .map could be a macro
parameter, allowing the user to use the "defaults" in the include directory, or
employing a color map written in the scene code. (#declare Granite08_map =
color_map {...})

In this way, we could choose one texture type - granite, metal, wood, glass, etc
- and write a prototype macro and texture, then have the experts on implementing
such textures chime in on what features to include and what values to select,
perhaps with #warning notes about certain feature and value combinations.  This
would provide a solid basis for people learning to write their own, more
involved and complicated textures of the same type.

Again - thanks for diving into this, I'm sure it's been needed for a long time.

Post a reply to this message

Op 11/04/2021 om 14:48 schreef Mr:
> The polished one however really shows the repetition of procedural texturing too
> visibly, to the point that it breaks everything else, which would otherwise of
> course work fine for a polished material... 

I have a nagging question: Is the granite pattern a /repetitive/ pattern?

Because I do not understand your comment about procedural texturing 
here. In addition, I checked the result against a Real World example and 
they are close. You will read in the header of granites21.inc that these 
granites are based on Real World examples by the original author, and so 
they are.

-- 
Thomas

Post a reply to this message

Op 11/04/2021 om 17:55 schreef jr:
> 
> I like the idea of archiving and maintaining, etc.  however, access to the
> information too has to be considered.  when I unzipped the archives I got that
> ... sinking feeling, you know, dozens of files but not even a README
> (equivalent).  so I suggest providing an additional document in some format
> (PDF, html, or txt), that gives context and perhaps has a "manifest".
> 

I have hesitated about a README, and opted, for the time being, to give 
the info in the headers of the include files. Maybe not the smartest way 
to do this indeed. As you can guess, this version of the package is open 
to improvements...

> anyway, mindful of Mr's closing comment, I've thrown together an example html
> page with sections for three of the granites -- literally a cut and paste job,
> so layout (and <style>) are not right; it looks for the images in a 'img'
> sub-directory.
> 

Thank you. I shall delve into it.

-- 
Thomas

Post a reply to this message

Op 11/04/2021 om 18:47 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> My initial - and still main - purpose is to provide an /ancient/ code in
>> more /modern/ context.
> 
> Than you, Thomas - I'm sure it's a LOT of tedious editing to get these things
> into shape.  I have not looked over your code or image zips yet - but since
> these are old, historic scene codes, perhaps consider including the
> "deprecate(d)" keyword to show the "new" way of writing "old" code.

It /was/ tedious, and a lot of "goose chasing" in the Cousin Ricky 
meaning of the term :-)

I need to look up (again) the "deprecated" keyword. I think you have a 
point here indeed.

> 
> The discussion so far highlights some interesting things.
> _I_ thought the second image was better - probably because I'm used to seeing
> more polished granite in such shapes, whereas the first might be ok for curbs
> and dry loose rock here in The Granite State.  The second also has more contrast
> and a pleasing color map than the first.  So interesting to see what some people
> find "better".

Absolutely.

> 
> It also suggests that here, at the outset, we should start to compile a list of
> "all those things we've learned in the past 20 years..." and then apply them to
> the same classes of texture to see what improvements we can make.
> 
> srgb
> radiosity
> layering fractal noise
> different noise generator functions
> ways of incorporating and balancing diffuse, specular, metallic, ior,
> subsurface, fresnel, ...  and a lot of other things that I'm missing.
> 

Agreed.

> 
> One thing we might try is - rather than having static definitions of the
> textures where the include file has to be hunted down and edited - what if we
> wrote them as macros that generated the texture?
> 
> You could have a default, a little #debug blurb that summarizes the parameters
> and usage syntax, and maybe an index macro that summarizes all of the available
> texture macros in the include file.  ("Is it granite_03, or Granite03, or....?")
> Perhaps think of naming the macros to indicate how many [optional] parameters
> there are, or have a default texture macro call the "real" texture macro with
> the proper number of parameters.  If any argument is suplied to the default
> macro, it will trigger a verbose help mode for the real texture macro that barfs
> out a bunch of stuff to #default text stream.
> 
> Then we could have boilerplate texture structure that would incorporate all of
> the important points that have been addressed over the years, and the user could
> adapt the texture from within the scene file, leaving the core macro code
> untouched.
> Something akin to quality levels could be integrated into the texture itself,
> shutting off very slow features like subsurface, reflection, etc during scene
> development, but making them instantly available for a final render.
> 

I have to think about this. I believe you are right but I need to let it 
percolate through my thick braincase.

> I also have come across old examples of people writing .map files for color
> maps.  I think this would be incredibly useful in the present context, and
> something I have not seen done in a long time.  The .map could be a macro
> parameter, allowing the user to use the "defaults" in the include directory, or
> employing a color map written in the scene code. (#declare Granite08_map =
> color_map {...})
> 
> In this way, we could choose one texture type - granite, metal, wood, glass, etc
> - and write a prototype macro and texture, then have the experts on implementing
> such textures chime in on what features to include and what values to select,
> perhaps with #warning notes about certain feature and value combinations.  This
> would provide a solid basis for people learning to write their own, more
> involved and complicated textures of the same type.
> 

Yes. More to think about...

> Again - thanks for diving into this, I'm sure it's been needed for a long time.
> 

You are welcome. I believe we are at a stage where something like this - 
POV-Ray wide - is needed. I shall try to improve the granites package 
first of all.

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 11/04/2021 om 17:55 schreef jr:
> > ... so I suggest providing an additional document in some format
> > (PDF, html, or txt), that gives context and perhaps has a "manifest".
>
> I have hesitated about a README, and opted, for the time being, to give
> the info in the headers of the include files. Maybe not the smartest way
> to do this indeed. As you can guess, this version of the package is open
> to improvements...

looks like all the hard work's done anyway.  thinking that since size + cost of
storage do not really matter anymore (alas), the document [cw]ould mostly be
straight duplication of the stuff in the headers, "pretty" presentation just an
extra bonus.  :-)


regards, jr.

Post a reply to this message

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

> > srgb
> > radiosity
> > layering fractal noise
> > different noise generator functions
> > ways of incorporating and balancing diffuse, specular, metallic, ior,
> > subsurface, fresnel, ...  and a lot of other things that I'm missing.
> >
>
> Agreed.

One other important thing that I had never thought of, but the ShaderToy folks
have brought up:
No values in the (s)rgb triplets should ever be zero.
First, because there are almost never absolutely black objects in real life
("vanta black")
and second, because there is no way to modify it with a multiplier.
If you had a red value of one millionth, you could multiply that by a million to
get 1.   But anything multiplied by zero is always zero.
So maybe we can set some min() threshold value that doesn't really register on a
monitor (1/256).


> > One thing we might try is - rather than having static definitions of the
> > textures where the include file has to be hunted down and edited - what if we
> > wrote them as macros that generated the texture?...

> I have to think about this. I believe you are right but I need to let it
> percolate through my thick braincase.

I think if we bounce it back and forth a few times, we can get the important
points hammered out for a prototype texture.

Post a reply to this message

Op 12-4-2021 om 12:48 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>> srgb
>>> radiosity
>>> layering fractal noise
>>> different noise generator functions
>>> ways of incorporating and balancing diffuse, specular, metallic, ior,
>>> subsurface, fresnel, ...  and a lot of other things that I'm missing.
>>>
>>
>> Agreed.
> 
> One other important thing that I had never thought of, but the ShaderToy folks
> have brought up:
> No values in the (s)rgb triplets should ever be zero.
> First, because there are almost never absolutely black objects in real life
> ("vanta black")
> and second, because there is no way to modify it with a multiplier.
> If you had a red value of one millionth, you could multiply that by a million to
> get 1.   But anything multiplied by zero is always zero.
> So maybe we can set some min() threshold value that doesn't really register on a
> monitor (1/256).
> 
Yes indeed; something I had not been aware of. Shall correct this in 
granites21.inc

> 
>>> One thing we might try is - rather than having static definitions of the
>>> textures where the include file has to be hunted down and edited - what if we
>>> wrote them as macros that generated the texture?...
> 
>> I have to think about this. I believe you are right but I need to let it
>> percolate through my thick braincase.
> 
> I think if we bounce it back and forth a few times, we can get the important
> points hammered out for a prototype texture.
> 
Absolutely.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 11/04/2021 om 14:48 schreef Mr:
> > The polished one however really shows the repetition of procedural texturing too
> > visibly, to the point that it breaks everything else, which would otherwise of
> > course work fine for a polished material...
>
> I have a nagging question: Is the granite pattern a /repetitive/ pattern?
>
> Because I do not understand your comment about procedural texturing
> here. In addition, I checked the result against a Real World example and
> they are close. You will read in the header of granites21.inc that these
> granites are based on Real World examples by the original author, and so
> they are.
>
> --
> Thomas

Since I'm invited to develop, I will, but please bear with some convoluted
stream of gut feeling rather than thought process:

Is the pattern really mathematically repetitive? What matters more is, does it
just even vaguely look like it is?

One of the key to overcome the "repetitive look" could be to break the scale
invariance. what I call scale invariance would be a strong inherent component of
computer generated fractal imagery: what is bigger looks quite like what is
smaller. so we add a depth pass to refine detail adding say one voronoi cell
inside another voronoi cell now it has depth of 2. this may look fascinating as
it reminds the way nature does (a tree has branches over branches). It is even
more so (fascinating) thanks to the computers ability to randomize that cell big
or small, say with a rotation or whatever (e.g. tree's species branching could
be described as generally between this and that angle for generation of branches
out of trunk and these other angles for generation 2 of branches out of branches
1) so let's have the computer pick randomly a rotation value between these max
and min and even state that it should never pick twice exactly the same
number... sounds good,

BUT

Nature has kind of two margins for this randomness... The one that makes one
recognize the represented object's characteristics, here they are perfect.
AND the one that is over these boundaries but still occurs from times to times.
The important thing is to really allow the additional level of detail (big or
small) to go there, but still control this probability to a small amount and not
have it constantly embedded in occurring variations, even if it's
programmatically made to mathematically never be that exact one. Or else, a) it
would look like repetition and b)more importantly,  it would break resemblance
to the represented object, since we're not talking of the characteristic
frequent values but rather the extremes.

What the **** am I talking about HERE ? :-)

For this granite, here is a CC0 image that could come out as a pretty standard
search result, rather consistent across the four or five first results:

https://en.wikipedia.org/wiki/Granite#/media/File:Fj%C3%A6regranitt3.JPG

If this was taken from say 1m away from surface with a 50/80mm focal length. And
we tried to roughly approach the pov scene to cover the same field of view.
Then if both in the photograph and rendered image one circled the salmon colored
areas. One difference I would expect in resulting circle clouds to weight for my
point in the balance: the radius would be almost constant in the pov result
while the photograph shows isolated much bigger circles sometimes occurring. My
gut feeling was just that the lack of these extreme occurrences gives the image
the look of a fractal image from the nineties. Now that was a nice period, and I
do value data preservation and archeology, I only fear the newer looking results
are currently just not included along at all with POV package despite its being
perfectly capable of it, as great images in these newsgroups frequently prove.
I fear people tend to shy away from pov these days because of somewhat hidden
modernity.

Maybe the first image looks much more natural to me because the additional black
dimples and accurate roughness provide enough additional detail and variation
especially at a lower frequency concerning the roughness because its shading is
graded over all of the object.

Post a reply to this message

OK, thanks for your detailed comments! I shall answer tomorrow as I am a 
bit short on time at this moment. However 1, I see your meaning and I 
certainly agree with you. However 2, as I wrote earlier, the granites in 
granites21.inc are /history/. What you propose is something for a 
completely new set.

Op 12-4-2021 om 16:06 schreef Mr:
> Since I'm invited to develop, I will, but please bear with some convoluted
> stream of gut feeling rather than thought process:
> 
> Is the pattern really mathematically repetitive? What matters more is, does it
> just even vaguely look like it is?
> 
> One of the key to overcome the "repetitive look" could be to break the scale
> invariance. what I call scale invariance would be a strong inherent component of
> computer generated fractal imagery: what is bigger looks quite like what is
> smaller. so we add a depth pass to refine detail adding say one voronoi cell
> inside another voronoi cell now it has depth of 2. this may look fascinating as
> it reminds the way nature does (a tree has branches over branches). It is even
> more so (fascinating) thanks to the computers ability to randomize that cell big
> or small, say with a rotation or whatever (e.g. tree's species branching could
> be described as generally between this and that angle for generation of branches
> out of trunk and these other angles for generation 2 of branches out of branches
> 1) so let's have the computer pick randomly a rotation value between these max
> and min and even state that it should never pick twice exactly the same
> number... sounds good,
> 
> BUT
> 
> Nature has kind of two margins for this randomness... The one that makes one
> recognize the represented object's characteristics, here they are perfect.
> AND the one that is over these boundaries but still occurs from times to times.
> The important thing is to really allow the additional level of detail (big or
> small) to go there, but still control this probability to a small amount and not
> have it constantly embedded in occurring variations, even if it's
> programmatically made to mathematically never be that exact one. Or else, a) it
> would look like repetition and b)more importantly,  it would break resemblance
> to the represented object, since we're not talking of the characteristic
> frequent values but rather the extremes.
> 
> What the **** am I talking about HERE ? :-)
> 
> For this granite, here is a CC0 image that could come out as a pretty standard
> search result, rather consistent across the four or five first results:
> 
> https://en.wikipedia.org/wiki/Granite#/media/File:Fj%C3%A6regranitt3.JPG
> 
> If this was taken from say 1m away from surface with a 50/80mm focal length. And
> we tried to roughly approach the pov scene to cover the same field of view.
> Then if both in the photograph and rendered image one circled the salmon colored
> areas. One difference I would expect in resulting circle clouds to weight for my
> point in the balance: the radius would be almost constant in the pov result
> while the photograph shows isolated much bigger circles sometimes occurring. My
> gut feeling was just that the lack of these extreme occurrences gives the image
> the look of a fractal image from the nineties. Now that was a nice period, and I
> do value data preservation and archeology, I only fear the newer looking results
> are currently just not included along at all with POV package despite its being
> perfectly capable of it, as great images in these newsgroups frequently prove.
> I fear people tend to shy away from pov these days because of somewhat hidden
> modernity.
> 
> Maybe the first image looks much more natural to me because the additional black
> dimples and accurate roughness provide enough additional detail and variation
> especially at a lower frequency concerning the roughness because its shading is
> graded over all of the object.
> 
> 


-- 
Thomas

Post a reply to this message

Op 12/04/2021 om 12:48 schreef Bald Eagle:
> One other important thing that I had never thought of, but the ShaderToy folks
> have brought up:
> No values in the (s)rgb triplets should ever be zero.
> First, because there are almost never absolutely black objects in real life
> ("vanta black")
> and second, because there is no way to modify it with a multiplier.
> If you had a red value of one millionth, you could multiply that by a million to
> get 1.   But anything multiplied by zero is always zero.
> So maybe we can set some min() threshold value that doesn't really register on a
> monitor (1/256).
> 

Done.

I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which 
corresponds to 1/256)


-- 
Thomas

Post a reply to this message

Op 12-4-2021 om 16:06 schreef Mr:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 11/04/2021 om 14:48 schreef Mr:
>>> The polished one however really shows the repetition of procedural texturing too
>>> visibly, to the point that it breaks everything else, which would otherwise of
>>> course work fine for a polished material...
>>
>> I have a nagging question: Is the granite pattern a /repetitive/ pattern?
>>
>> Because I do not understand your comment about procedural texturing
>> here. In addition, I checked the result against a Real World example and
>> they are close. You will read in the header of granites21.inc that these
>> granites are based on Real World examples by the original author, and so
>> they are.
>>
>> --
>> Thomas
> 
> Since I'm invited to develop, I will, but please bear with some convoluted
> stream of gut feeling rather than thought process:
> 
> Is the pattern really mathematically repetitive? What matters more is, does it
> just even vaguely look like it is?
> 
> One of the key to overcome the "repetitive look" could be to break the scale
> invariance. what I call scale invariance would be a strong inherent component of
> computer generated fractal imagery: what is bigger looks quite like what is
> smaller. so we add a depth pass to refine detail adding say one voronoi cell
> inside another voronoi cell now it has depth of 2. this may look fascinating as
> it reminds the way nature does (a tree has branches over branches). It is even
> more so (fascinating) thanks to the computers ability to randomize that cell big
> or small, say with a rotation or whatever (e.g. tree's species branching could
> be described as generally between this and that angle for generation of branches
> out of trunk and these other angles for generation 2 of branches out of branches
> 1) so let's have the computer pick randomly a rotation value between these max
> and min and even state that it should never pick twice exactly the same
> number... sounds good,
> 

Ok. I follow you.

> BUT
> 
> Nature has kind of two margins for this randomness... The one that makes one
> recognize the represented object's characteristics, here they are perfect.
> AND the one that is over these boundaries but still occurs from times to times.
> The important thing is to really allow the additional level of detail (big or
> small) to go there, but still control this probability to a small amount and not
> have it constantly embedded in occurring variations, even if it's
> programmatically made to mathematically never be that exact one. Or else, a) it
> would look like repetition and b)more importantly,  it would break resemblance
> to the represented object, since we're not talking of the characteristic
> frequent values but rather the extremes.
> 

Understood.

> What the **** am I talking about HERE ? :-)
> 
> For this granite, here is a CC0 image that could come out as a pretty standard
> search result, rather consistent across the four or five first results:
> 
> https://en.wikipedia.org/wiki/Granite#/media/File:Fj%C3%A6regranitt3.JPG
> 

Yes, this is a typical granite. What we should understand however, is 
that granites can show a wide variety of grain-size differences, from 
fine-grained to rather coarse-grained and within this range, with fairly 
equal grain-sizes to more different grain-sizes either of the feldspars 
(like the image shown above) or the quartz grains (the white/translucent 
grains).

> If this was taken from say 1m away from surface with a 50/80mm focal length. And
> we tried to roughly approach the pov scene to cover the same field of view.
> Then if both in the photograph and rendered image one circled the salmon colored
> areas. One difference I would expect in resulting circle clouds to weight for my
> point in the balance: the radius would be almost constant in the pov result
> while the photograph shows isolated much bigger circles sometimes occurring. My
> gut feeling was just that the lack of these extreme occurrences gives the image
> the look of a fractal image from the nineties. Now that was a nice period, and I
> do value data preservation and archeology, I only fear the newer looking results
> are currently just not included along at all with POV package despite its being
> perfectly capable of it, as great images in these newsgroups frequently prove.
> I fear people tend to shy away from pov these days because of somewhat hidden
> modernity.
> 
I agree with you. In more "interesting" granite textures some random 
grain-size differences should be provided. Not yet sure how to do this 
presently, but I can imagine a couple of solutions. Something to 
investigate indeed and make available within future versions of 
granites, maybe through the macro structure proposed by Bald Eagle above.

> Maybe the first image looks much more natural to me because the additional black
> dimples and accurate roughness provide enough additional detail and variation
> especially at a lower frequency concerning the roughness because its shading is
> graded over all of the object.
> 

Quite probable indeed. :-)

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> One other important thing that I had never thought of, but the ShaderToy folks
> have brought up:
> No values in the (s)rgb triplets should ever be zero.
> First, because there are almost never absolutely black objects in real life
> ("vanta black")
> and second, because there is no way to modify it with a multiplier.
> If you had a red value of one millionth, you could multiply that by a million to
> get 1.   But anything multiplied by zero is always zero.
> So maybe we can set some min() threshold value that doesn't really register
> on a monitor (1/256).
>

Thomas wrote:
> Done.

> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
> corresponds to 1/256)

Those are interesting points from Bald Eagle, and I sense the logic behind them.
I agree with the first statement, that pure black is never seen in real life.
I'm guilty of that too when specifying something like rgb 0.0 for an object, so
I need to remember to change such colors to be more realistic-- like to at least
0.004 as Thomas mentions.

But here's a little monkey wrench that I'll throw into the second point ;-)
(because I'm honestly puzzled regarding the ShaderToy logic):

If I use a color in a scene like <0,.7,.7>, whether as rgb or srgb, it has no
'red' color at all (disregarding the unrealistic nature of such a color, except
perhaps in a scientific setting using purely-generated monochromatic colors.) By
multiplying or dividing that <0,.7,.7> by whatever value, the 'red' should still
be 0.0-- in other words, there's no red to begin with, so any increase or
decrease of the color vector should still have no red-- either mathematically
*or* visually. Whether of not that's a 'realistic' color is a different matter,
of course; but the total lack of red seems to be the logical outcome...with no
..004 'red' addition required (for example).

Or perhaps I'm misunderstanding what the ShaderToy reference means, and why it
cautions against a 0.0 value in a color vector being multiplied.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Or perhaps I'm misunderstanding what the ShaderToy reference means, and why it
> cautions against a 0.0 value in a color vector being multiplied.

Yes, it is a bit hard, if not impossible to grasp the "why" without a greater
overview of the context.

Rather than think of it from the narrow perspective of what _you_ might do to
the color, think about what might happen to the color once the object pigmented
with it is placed into a scene, in proximity to another object that _does_ have
a red color, or is lit with a light source that has a red component.   Then
POV-Ray (or any other graphics software) would calculate what color the camera
would see by multiplying the base color by some fraction of the lighting or
radiosity, etc.

And THAT's the take-away message I got from following along in a few tutorials
and live coding sessions.

I mean, we can always ADD <r, 0, 0> to a color to give it some red first, and
THEN multiply it, but the idea is always have that little bit in there that can
be operated upon by all the complexities of the scene and lighting interactions,
so that we don't have to think about it every time, and make it even more
difficult for newbies to debug "Why do my scene objects look so _______ ?"

I hope that clears it up a little bit.

Post a reply to this message

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

> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
> corresponds to 1/256)

Thank you, Sir.

I am playing a bit with the macro thing and a simple demo scene, and I will post
both as soon as it's far enough along to warrant some code pong.

Perhaps you can guide me a bit in crafting a prototype texture since you're
likely better/more knowledgeable than I.  After briefly going through your code,
I like what I see so far.
Some small observations:
You have some #declares in your macros where you should probably use #locals.
Maybe use some underscores or GraniteInc_ prefixes to construct a unique
namespace that won't potentially clash with a user's scene file declares.





I'm using the "Mahogany (sp) granite - polished surface" as a starting point,
and I'm noticing a few things:

we have       diffuse 0.6      specular 0.9
Which adds up to over 1.0   Is this proper?   Should the sum never exceed unity?

(it would be nice if we had some dot-notation type stuff to work with, but it
would be a CSG-tree type nightmare)

This is a layered texture, but both texture have finish blocks.  Should there
only be a single finish block for the whole object?
What about sslt and interior {ior} ?


There is also the issue of scale.
"The granite patterns have been scaled in such a way that, when applied to a
unit-sized POV-Ray object, they correspond most closely to the real world
examples from which they have been modeled. (sp)"

and for sslt we have:
"The mm_per_unit algorithm is designed to give realistic results at a scale of
10 mm per POV-Ray unit by default"

So we may have some things to think about there, so that everything is playing
together in harmony, without too much mucking about by inexperienced users.


With more complex textures using ior, sslt, and layered textures, should we have
a full texture_map mechanism, or material_map rather than color_map?


Thanks!   :)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Or perhaps I'm misunderstanding what the ShaderToy reference means, and why it
> > cautions against a 0.0 value in a color vector being multiplied.
>
> Yes, it is a bit hard, if not impossible to grasp the "why" without a greater
> overview of the context.
>

Ah yes, I see the reasoning now, particularly as concerns lighting and
radiosity: For example, a 0.0 in an object's color vector is like a 'black hole'
that absorbs any and all 'incoming' color for that color channel, no matter what
the incoming intensities are. Like a hypothetical 'super-black', which is
certainly not a realistic situation, and which was probably not intended anyway.

That's an interesting little problem that I had not considered before! I've
probably had a weirdly mistaken notion that a 'black object' in POV-ray like rgb
<0,0,0> would somehow show itself as 'dark gray' if a powerful-enough light was
shined on it, ha-- like a typical real-world black color. But I didn't think
through the details. :-<

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Or perhaps I'm misunderstanding what the ShaderToy reference means, and why it
> > cautions against a 0.0 value in a color vector being multiplied.

For instance:

"Pigments having any zero color components currently doesn't play nice with
SSLT. For example use rgb <1,0.01,0.01> instead of rgb <1,0,0> as color literals
or when declaring pigment identifiers."

https://wiki.povray.org/content/Reference:Finish#Subsurface_Light_Transport

Post a reply to this message

Hi Thomas,

thanks for the effort, and bringing this into the 21st century.

Here is a little piece of software to set the type and SCS (or any other
variable) in a Povray file from the command line. You don't have to change the
source then to render another texture.

On the command line give
declare=TYP=1

In the Povray file add
#ifdef (TYP)
    #declare Typ = TYP;
#else
    #declare Typ = 1;
#end

// Check whether the correct value is given.
#if ((Typ < 1) | (Typ > 2)
// Give a #warning and set Typ to 1, or give an #error
#end

I use this idea to set radiosity (with a #switch) and I can choose between
several camera positions.

Cheers
Ton

Post a reply to this message

So just as a quick initial proposal, see attached.


with regard to:
veins and inclusions
I clearly recall a thread where someone had a pattern of some sort that looked
like
one texture visible in wavy "cracks" in another - any ideas where that is?
Not "recently, but not that long ago, either.
Had something to do with wavy fire...?

The layered texture is tricky, esp when trying to incorporate sslt.
sslt requires an ior, which requires that it be in a material {} wrapper
using sslt has prerequisites that might warrant a #warning

I had a real problem at the very end trying to declare a name for the layered
texture, and gave up.  No idea what the problem was.

I just left it in the raw development state, mostly just to get the macro idea
across as clearly as I could, and then we can edit things as seems best.

Post a reply to this message

Attachments:
Download 'granitetexturemacro_v0.1.0.zip' (157 KB)

"Ton" <ton### [at] gmailcom> wrote:

> On the command line give
> declare=TYP=1

Ah yes, jr has promoted this method as well.
Also coupled with .ini files

The thing that always begins nagging at the back of my mind is that anything
typed on the command line is _gone_.

having the same mechanism in the .pov file with #declare typ = 1; works just as
well (?)


I played a bit with some command-line file conversions, and you can convert a
..pov file to .pdf with 'soffice --convert-to pdf MyScene.pov'

with graphicsmagick, .png can be converted to .jpg with 'gm convert MyScene.png
MyScene.jpg'

and then by simply doing 'cat MyScene.jpg MyScene.pdf > DualFile.jpg'

you get a file that you can either view as an image, or as a PDF.

I think if we had a tidy way to do a post-render command script to do all 3
tasks, (and maybe increment a counter) then you could have the scene code saved
_inside_ of your image, never to be lost, or separated from the image, since
it's the same file.

Rename the attached to .pdf and see if it works for you.   :)

Post a reply to this message

Attachments:
Download 'letter2.jpg' (174 KB)

Preview of image 'letter2.jpg'

Op 13/04/2021 om 21:00 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
>> corresponds to 1/256)
> 
> Thank you, Sir.
> 
> I am playing a bit with the macro thing and a simple demo scene, and I will post
> both as soon as it's far enough along to warrant some code pong.
> 

Good! I think the macro suggestion is the way to go. Might become quite 
complex...

> Perhaps you can guide me a bit in crafting a prototype texture since you're
> likely better/more knowledgeable than I.  After briefly going through your code,
> I like what I see so far.
> Some small observations:
> You have some #declares in your macros where you should probably use #locals.
> Maybe use some underscores or GraniteInc_ prefixes to construct a unique
> namespace that won't potentially clash with a user's scene file declares.
> 

I shall look into that.


> I'm using the "Mahogany (sp) granite - polished surface" as a starting point,
> and I'm noticing a few things:
> 
> we have       diffuse 0.6      specular 0.9
> Which adds up to over 1.0   Is this proper?   Should the sum never exceed unity?
> 
I did not go too deep into the original code, but you are right I think; 
I need to look up my notes on this. There is also a comment in one of 
the Clipka Voodoo's which talks about diffuse values in a srgb 
environment...

> (it would be nice if we had some dot-notation type stuff to work with, but it
> would be a CSG-tree type nightmare)
> 
> This is a layered texture, but both texture have finish blocks.  Should there
> only be a single finish block for the whole object?

Something I wondered about too. My gut feeling is that only one finish 
should be used.

> What about sslt and interior {ior} ?

I don't think that those are to be used with granites. It would not add 
anything imo.


> There is also the issue of scale.
> "The granite patterns have been scaled in such a way that, when applied to a
> unit-sized POV-Ray object, they correspond most closely to the real world
> examples from which they have been modeled. (sp)"
> 
> and for sslt we have:
> "The mm_per_unit algorithm is designed to give realistic results at a scale of
> 10 mm per POV-Ray unit by default"
> 
> So we may have some things to think about there, so that everything is playing
> together in harmony, without too much mucking about by inexperienced users.
> 

Indeed. Note however that the scale of the texture is rather arbitrary 
and open to change by the user. I felt I had to provide something at 
least visually "correct".

> 
> With more complex textures using ior, sslt, and layered textures, should we have
> a full texture_map mechanism, or material_map rather than color_map?
> 
Maybe, and depending on "complexity". Personally, I would prefer the 
texture_map/material_map structure indeed.

> 
> Thanks!   :)
> 

<grin>

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 13/04/2021 om 21:00 schreef Bald Eagle:
> > Thomas de Groot <tho### [at] degrootorg> wrote:
> > ...
> > You have some #declares in your macros where you should probably use #locals.
> > Maybe use some underscores or GraniteInc_ prefixes to construct a unique
> > namespace that won't potentially clash with a user's scene file declares.
> >
>
> I shall look into that.

if you'd like, simply do the 'granites21.inc', may I suggest a 'g21_' prefix?
when done send me (or here) a zip and I shall update the .pov files to
correspond (ideally for the weekend :-))


regards, jr.

Post a reply to this message

Op 13-4-2021 om 23:31 schreef Bald Eagle:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>>> Or perhaps I'm misunderstanding what the ShaderToy reference means, and why it
>>> cautions against a 0.0 value in a color vector being multiplied.
> 
> For instance:
> 
> "Pigments having any zero color components currently doesn't play nice with
> SSLT. For example use rgb <1,0.01,0.01> instead of rgb <1,0,0> as color literals
> or when declaring pigment identifiers."
> 
> https://wiki.povray.org/content/Reference:Finish#Subsurface_Light_Transport
> 

So, to be correct, I should also change all the single 0.000 components 
of colour triplets to 0.004.

I remember in the past to have avoided 0.0 in pigment triplets, only to 
forget about it subsequently of course. :-)

-- 
Thomas

Post a reply to this message

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

> So, to be correct, I should also change all the single 0.000 components
> of colour triplets to 0.004.

That's how I understand it.  Never any absolute zeroes anywhere.
And for realism, always some small amount of reflection in every finish (but
maybe our radiosity covers that already)
I usually use an E = 0.000001 to avoid coincident surface type stuff
For the granites I used #declare _not0 = 1/256; // a small non-zero value since
it was the same character length as 0.000 and fit nicely into the color maps  ;)


With regard to the duplicate finish blocks, there was certainly a difference
when I rendered the base texture vs the full layered texture.

Post a reply to this message

Op 14-4-2021 om 12:22 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> So, to be correct, I should also change all the single 0.000 components
>> of colour triplets to 0.004.
> 
> That's how I understand it.  Never any absolute zeroes anywhere.
> And for realism, always some small amount of reflection in every finish (but
> maybe our radiosity covers that already)
> I usually use an E = 0.000001 to avoid coincident surface type stuff
> For the granites I used #declare _not0 = 1/256; // a small non-zero value since
> it was the same character length as 0.000 and fit nicely into the color maps  ;)
> 
Smart! ;-)

> 
> With regard to the duplicate finish blocks, there was certainly a difference
> when I rendered the base texture vs the full layered texture.
> 
Yes, there is a difference. I need to test this more thoroughly though 
to see what the different finishes do to the final render because I am 
not entirely sure about the transparant parts of the second layer.

Shall report back later.

-- 
Thomas

Post a reply to this message

Op 14-4-2021 om 09:42 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 13/04/2021 om 21:00 schreef Bald Eagle:
>>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> ...
>>> You have some #declares in your macros where you should probably use #locals.
>>> Maybe use some underscores or GraniteInc_ prefixes to construct a unique
>>> namespace that won't potentially clash with a user's scene file declares.
>>>
>>
>> I shall look into that.
> 
> if you'd like, simply do the 'granites21.inc', may I suggest a 'g21_' prefix?
> when done send me (or here) a zip and I shall update the .pov files to
> correspond (ideally for the weekend :-))
> 
Thanks, but no problem for me; takes about 15 minutes to change them all 
(copy/paste). In fact, I am thinking about (1) wrapping the repetitive 
parts into a macro and (2) writing a single execute file for the whole 
thing replacing all the pov's. Would make things much easier. ;-)

-- 
Thomas

Post a reply to this message

Some initial thoughts and actions involving the below.

Op 14-4-2021 om 08:40 schreef Thomas de Groot:
> Op 13/04/2021 om 21:00 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
>>> corresponds to 1/256)
>>
>> Thank you, Sir.

Also changed the remaining 0.000 values (only a few left) to 0.004.

>>
>> I am playing a bit with the macro thing and a simple demo scene, and I 
>> will post
>> both as soon as it's far enough along to warrant some code pong.
>>
> 
> Good! I think the macro suggestion is the way to go. Might become quite 
> complex...
> 
>> Perhaps you can guide me a bit in crafting a prototype texture since 
>> you're
>> likely better/more knowledgeable than I.  After briefly going through 
>> your code,
>> I like what I see so far.
>> Some small observations:
>> You have some #declares in your macros where you should probably use 
>> #locals.
>> Maybe use some underscores or GraniteInc_ prefixes to construct a unique
>> namespace that won't potentially clash with a user's scene file declares.
>>
> 
> I shall look into that.
> 
So I wrapped the environment code to be used in each pov-file into a 
macro, where the parameters start with a g21_ prefix (thanks jr!).

The next step I intend to do is try to formulate a single pov file from 
where each and all the granites can be rendered, name and all.

> 
>> I'm using the "Mahogany (sp) granite - polished surface" as a starting 
>> point,
>> and I'm noticing a few things:
>>
>> we have       diffuse 0.6      specular 0.9
>> Which adds up to over 1.0   Is this proper?   Should the sum never 
>> exceed unity?
>>
> I did not go too deep into the original code, but you are right I think; 
> I need to look up my notes on this. There is also a comment in one of 
> the Clipka Voodoo's which talks about diffuse values in a srgb 
> environment...
>
In my notes I found the 'rule' for realistic finish should be:
   "diffuse albedo" + "reflection {Value fresnel} < 1
and:
   "specular albedo" + "phong albedo" < Value in the finish block;
   with the mention that a good use would be specular + phong = Value/2

I have still to browse the Clipka grimoire though...

>> (it would be nice if we had some dot-notation type stuff to work with, 
>> but it
>> would be a CSG-tree type nightmare)
>>
>> This is a layered texture, but both texture have finish blocks.  
>> Should there
>> only be a single finish block for the whole object?
> 
> Something I wondered about too. My gut feeling is that only one finish 
> should be used.
> 
I tested this and indeed a single finish in the top texture seems to be 
enough.

>> What about sslt and interior {ior} ?
> 
> I don't think that those are to be used with granites. It would not add 
> anything imo.
> 
Well... I retract my words. At least, this should be tested more fully.

Fwiw, https://pixelandpoly.com/ior.html is a list of ior's that could be 
useful.

> 
>> There is also the issue of scale.
>> "The granite patterns have been scaled in such a way that, when 
>> applied to a
>> unit-sized POV-Ray object, they correspond most closely to the real world
>> examples from which they have been modeled. (sp)"
>>
>> and for sslt we have:
>> "The mm_per_unit algorithm is designed to give realistic results at a 
>> scale of
>> 10 mm per POV-Ray unit by default"
>>
>> So we may have some things to think about there, so that everything is 
>> playing
>> together in harmony, without too much mucking about by inexperienced 
>> users.
>>
> 
> Indeed. Note however that the scale of the texture is rather arbitrary 
> and open to change by the user. I felt I had to provide something at 
> least visually "correct".
> 
>>
>> With more complex textures using ior, sslt, and layered textures, 
>> should we have
>> a full texture_map mechanism, or material_map rather than color_map?
>>
> Maybe, and depending on "complexity". Personally, I would prefer the 
> texture_map/material_map structure indeed.
> 
>>
>> Thanks!   :)
>>
> 
> <grin>
> 

back to the drawing board...

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 14-4-2021 om 09:42 schreef jr:
> > if you'd like, ...
> Thanks, but no problem for me; takes about 15 minutes to change them all
> (copy/paste). In fact, I am thinking about (1) wrapping the repetitive
> parts into a macro and (2) writing a single execute file for the whole
> thing replacing all the pov's. Would make things much easier. ;-)

re the second point - or one .ini file.  allows non-GUI users to execute as
easily as "right-clicking" in the Windows UI.


regards, jr.

Post a reply to this message

Op 14-4-2021 om 16:39 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 14-4-2021 om 09:42 schreef jr:
>>> if you'd like, ...
>> Thanks, but no problem for me; takes about 15 minutes to change them all
>> (copy/paste). In fact, I am thinking about (1) wrapping the repetitive
>> parts into a macro and (2) writing a single execute file for the whole
>> thing replacing all the pov's. Would make things much easier. ;-)
> 
> re the second point - or one .ini file.  allows non-GUI users to execute as
> easily as "right-clicking" in the Windows UI.
> 
> 
> regards, jr.
> 

Yes. I have to delve into ini-writing as I am not a frequent user.

-- 
Thomas

Post a reply to this message

Le 2021-04-13 à 22:16, Bald Eagle a écrit :
> "Ton" <ton### [at] gmailcom> wrote:
> 
>> On the command line give
>> declare=TYP=1
> 
> Ah yes, jr has promoted this method as well.
> Also coupled with .ini files
> 
> The thing that always begins nagging at the back of my mind is that anything
> typed on the command line is _gone_.
> 
> having the same mechanism in the .pov file with #declare typ = 1; works just as
> well (?)
> 
> 
> I played a bit with some command-line file conversions, and you can convert a
> ..pov file to .pdf with 'soffice --convert-to pdf MyScene.pov'
> 
> with graphicsmagick, .png can be converted to .jpg with 'gm convert MyScene.png
> MyScene.jpg'
> 
> and then by simply doing 'cat MyScene.jpg MyScene.pdf > DualFile.jpg'
> 
> you get a file that you can either view as an image, or as a PDF.
> 
> I think if we had a tidy way to do a post-render command script to do all 3
> tasks, (and maybe increment a counter) then you could have the scene code saved
> _inside_ of your image, never to be lost, or separated from the image, since
> it's the same file.
> 
> Rename the attached to .pdf and see if it works for you.   :)
> 
> 
> 
> 
> 
Works well. My PDF reader opens it flawlessly and IrfanView show it as 
an image after asking me if it should change the extension to .JPG.

Post a reply to this message

Le 2021-04-14 à 07:13, Thomas de Groot a écrit :
> Op 14-4-2021 om 12:22 schreef Bald Eagle:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>> So, to be correct, I should also change all the single 0.000 components
>>> of colour triplets to 0.004.
>>
>> That's how I understand it.  Never any absolute zeroes anywhere.
>> And for realism, always some small amount of reflection in every 
>> finish (but
>> maybe our radiosity covers that already)
>> I usually use an E = 0.000001 to avoid coincident surface type stuff
>> For the granites I used #declare _not0 = 1/256; // a small non-zero 
>> value since
>> it was the same character length as 0.000 and fit nicely into the 
>> color maps  ;)
>>
> Smart! ;-)
> 
>>
>> With regard to the duplicate finish blocks, there was certainly a 
>> difference
>> when I rendered the base texture vs the full layered texture.
>>
> Yes, there is a difference. I need to test this more thoroughly though 
> to see what the different finishes do to the final render because I am 
> not entirely sure about the transparant parts of the second layer.
> 
> Shall report back later.
> 
One thing that can be done with layered textures with a finish in more 
than one is to simulate varnished metals.

Have the base texture with metallic highlights and reflection, while the 
top texture is transparent with fresnel highlights and reflection. Just 
need to add an interior for the ior.

The rendered image is quite similar to actual varnished metal.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> >>
> >>> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
> >>> corresponds to 1/256)
>
> Also changed the remaining 0.000 values (only a few left) to 0.004.
>

It just occurred to me that a small explanatory note-- about the 'why' of this
addition-- might be useful, somewhere in your package. So that future users
don't scratch their heads and flood the newsgroups with questions like, "WHY are
these values not 0.0??! What's this crazy .004 addition for??" Maybe for users
like...me, ha. When I've long since forgotten the details of this discussion :-P

Perhaps a modified form of Bald Eagle's explanation(s) would suffice.

And I neglected to mention what a nice job you did with collating and updating
these granite textures. Your hard work is appreciated. I especially like the
three-way 'switch' for each texture, a great addition.

Thank you!

Post a reply to this message

Op 14/04/2021 om 19:11 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>>
>>>>> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
>>>>> corresponds to 1/256)
>>
>> Also changed the remaining 0.000 values (only a few left) to 0.004.
>>
> 
> It just occurred to me that a small explanatory note-- about the 'why' of this
> addition-- might be useful, somewhere in your package. So that future users
> don't scratch their heads and flood the newsgroups with questions like, "WHY are
> these values not 0.0??! What's this crazy .004 addition for??" Maybe for users
> like...me, ha. When I've long since forgotten the details of this discussion :-P
> 
> Perhaps a modified form of Bald Eagle's explanation(s) would suffice.

That is certainly important to mention indeed. I make a note, and it 
will find its place in the explanatory part of the include, or better, 
in the html document to be still done.

> 
> And I neglected to mention what a nice job you did with collating and updating
> these granite textures. Your hard work is appreciated. I especially like the
> three-way 'switch' for each texture, a great addition.
> 
> Thank you!
> 

Thank you indeed, sir :-) I thought these granites would be a nice test 
case to see how we can upgrade and go forward. Although I probably found 
the earliest mention of the code back in 1996, I fail to remember /when/ 
and /where/ those granites appeared in the POV-Ray n.g. proper. I 
mention them in a post back in 2014, but earlier...?

Still a lot to do of course.

============================================================

Maybe this would be the right place and time to make a suggestion about 
the "real" upgrade.

Using the draft comments from Bald Eagle as well as from Maurice (Mr), 
to only mention two of the contributors, I would like to suggest to keep 
the first two SCS switches (0 and 1) for the "original" code, and use 
switch (2) for a real upgrade and overhaul towards a full-fledged 
material implementation, including all the sophisticated possibilities 
like sslt. Or, should this be implemented in a to be created switch (3)? 
Or even as a separated include file?

How do you all feel about this? My personal preference would be to use 
switch (2).

-- 
Thomas

Post a reply to this message

Op 14/04/2021 om 18:00 schreef Alain Martel:
> Le 2021-04-14 à 07:13, Thomas de Groot a écrit :
>> Op 14-4-2021 om 12:22 schreef Bald Eagle:
>>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>>
>>>> So, to be correct, I should also change all the single 0.000 components
>>>> of colour triplets to 0.004.
>>>
>>> That's how I understand it.  Never any absolute zeroes anywhere.
>>> And for realism, always some small amount of reflection in every 
>>> finish (but
>>> maybe our radiosity covers that already)
>>> I usually use an E = 0.000001 to avoid coincident surface type stuff
>>> For the granites I used #declare _not0 = 1/256; // a small non-zero 
>>> value since
>>> it was the same character length as 0.000 and fit nicely into the 
>>> color maps  ;)
>>>
>> Smart! ;-)
>>
>>>
>>> With regard to the duplicate finish blocks, there was certainly a 
>>> difference
>>> when I rendered the base texture vs the full layered texture.
>>>
>> Yes, there is a difference. I need to test this more thoroughly though 
>> to see what the different finishes do to the final render because I am 
>> not entirely sure about the transparant parts of the second layer.
>>
>> Shall report back later.
>>
> One thing that can be done with layered textures with a finish in more 
> than one is to simulate varnished metals.
> 
> Have the base texture with metallic highlights and reflection, while the 
> top texture is transparent with fresnel highlights and reflection. Just 
> need to add an interior for the ior.
> 
> The rendered image is quite similar to actual varnished metal.

Ah! That is an idea! Thank you Alain; I certainly want to play with this.

-- 
Thomas

Post a reply to this message

Am 4/11/2021 um 14:06 schrieb Thomas de Groot:
> granites.inc from 1996 is not officially part of the POV-Ray set of 
> include files but I believe it should be part of a larger collection of 
> essential include files developed over the years by the users community.
> 
> The original code, which I have been able to trace back to 1996, I have 
> upgraded to version 3.7+ standards. The result is made available in 
> p.b.s-f. The collection set contains:
> 
> 1. the original granites.inc file (comments included);
> 2. the upgraded granites21.inc file which provides three versions for 
> each granite type (comments included);
> 3. example scene files for each granite type;
> 4. a set of rendered images of each granite type. Two of those are shown 
> here.
> 
> Comments welcome of course.
> 

Comments, well, truth is my first reaction was just to demand that you 
remove my nom du guerre from this include file as I consider it an 
personal insult to appear within some context that is not even wrong.
To quote W. Pauli in his native language "Das ist noch nicht einmal 
falsch."  Pronounced in his dialect from Vienna.

I also need to step in for Daniel Meklenburg (aka Code Warrior) the 
original author of the granites who's intention was to provide some 
realistic colored granites for POV-Ray. And he did it very well for the 
time, and yes I did check it out by installing POV-Ray version 3.0 and 
did render it there.
None of your 3 versions does even remotely look like the original granites.
And no, providing 3 versions has nothing to do with artistic freedem
or freedom of choice when all 3 versions look completely dull compared 
to the original.

Well, for old times sake, I did create a scene file that shows a 
framework how this has to be done, added numerous notes and comments as 
to how and why.

And for artistic freedom, I'm all for it and might add a small addition 
to this framework that will allow you to change a dark green granite to 
some bright pink marble - and in addition will do some *really* useful 
thing called blackpoint compensation, addressing the issue that (most) 
contemporary monitors are unable to display *black* while good old CRT's
had no problem with this.

Attached is the scene file and two example render showing Code Warrior's
North American Pink granite polished and frozen.

Post a reply to this message

Attachments:
Download 'nap.pov.txt' (20 KB) Download 'nap_frozen.png' (446 KB) Download 'nap_polished.png' (448 KB)

Preview of image 'nap_frozen.png'

Preview of image 'nap_polished.png'

Op 15-4-2021 om 16:27 schreef Ive:
[snip]

> Attached is the scene file and two example render showing Code Warrior's
> North American Pink granite polished and frozen.
> 

Thanks Ive. I shall comment on your mail more in detail later. Just one 
remark: The "original" granites (and your images are examples) do /not/ 
show granites in their /original/ scaling! I should know, as I am a 
geologist. Which is why I changed the scaling to - at least - something 
representing a granite as seen in nature. I have a couple of examples in 
my backyard, graciously transported here by the penultimate ice age. :-)

-- 
Thomas

Post a reply to this message

Just some general comments at this stage.

Op 15-4-2021 om 16:27 schreef Ive:
> Comments, well, truth is my first reaction was just to demand that you 
> remove my nom du guerre from this include file as I consider it an 
> personal insult to appear within some context that is not even wrong.
> To quote W. Pauli in his native language "Das ist noch nicht einmal 
> falsch."  Pronounced in his dialect from Vienna.
> 
I would sincerely regret such a move. I do not really understand a rigid 
orthodox stand about this matter, from a user's point of view. I have 
always assumed that providing some liberty of choice should be given; 
what does it matter which version a user chooses for his scene because 
he/she finds it more appealing or "correct" for his/her personal context?

However, these are my personal views, whatever they are worth. I am also 
interested in the comments on this by others beside myself.

> I also need to step in for Daniel Meklenburg (aka Code Warrior) the 
> original author of the granites who's intention was to provide some 
> realistic colored granites for POV-Ray. And he did it very well for the 
> time, and yes I did check it out by installing POV-Ray version 3.0 and 
> did render it there.
> None of your 3 versions does even remotely look like the original granites.

See my rapid comment in my earlier post.

> And no, providing 3 versions has nothing to do with artistic freedem
> or freedom of choice when all 3 versions look completely dull compared 
> to the original.

Dull... in what manner? I fail to understand.

> 
> Well, for old times sake, I did create a scene file that shows a 
> framework how this has to be done, added numerous notes and comments as 
> to how and why.
> 

My sincere thanks for providing the scene file in particular. I have not 
looked at it in detail yet, but I shall return to it and comment where 
necessary later on.

> And for artistic freedom, I'm all for it and might add a small addition 
> to this framework that will allow you to change a dark green granite to 
> some bright pink marble - and in addition will do some *really* useful 
> thing called blackpoint compensation, addressing the issue that (most) 
> contemporary monitors are unable to display *black* while good old CRT's
> had no problem with this.
> 
All right.

> Attached is the scene file and two example render showing Code Warrior's
> North American Pink granite polished and frozen.
> 
Thank you indeed! Much appreciated. I am all for a good discussion even 
if we do not necessarily agree on all points.

Cheers!

-- 
Thomas

Post a reply to this message

The radical visual differences between the granites of Thomas vs. Ive reminded
me of something I used to do years ago in older versions of POV-ray: running my
scenes in a gamma 2.2 environment (instead of the always-recommended 1.0)--
simply as a way to get 'rgb colors' to appear the way that I thought they
should. This was before I understood the technical details of 'linear' lighting
and rendering (which is another topic, of course.)

So, using the two *original* 1996 Daniel Mecklenburg textures from the
"granites_original.inc" file that Thomas included in his zip files, I decided to
run  them in v3.7-- while *switching* between assumed_gamma 1.0 and
assumed_gamma 2.2. [To be specific, I'm running a v3.8xx 'experimental build' in
Windows, that piggybacks on v3.7, but  using "#version 3.7" in my test scene.]
Disregarding my own scene's lack of radiosity and a different light_source
setup... not to mention the vast differences that have accrued in POV-ray itself
since 1996...the respective gamma results are quite interesting!

At the time of Daniel's code creation, there was no 'assumed_gamma' keyword,
AFAIU-- just something like Display_Gamma or File_Gamma in an .INI file. (That's
probably what I used-- and with a 2.2 value instead of 1.0.)

The results of my test here indicate that the Thomas/Ive visual differences
might simply be the result of the gamma environment Daniel M was using at the
time.  If it was indeed a 2.2-gamma environment-- possibly like my own old way
of doing things-- then Ive's version would seem to be more 'correct' (as regards
Daniel's original intent?); if Daniel used a gamma of 1.0 instead, then Thomas's
looks correct.

Just some food for thought.

I make no judgement as to which of the versions of 'North American Pink granite'
has the correct 'visual' look-- I'll leave that to the granite experts ;-)

-------- Kenneth test code ------
global_settings{assumed_gamma 1.0} // change to 2.2

#default{finish{ambient .07 emission 0 diffuse .8}}

camera {
  perspective
  location  <0, 2.1, -6.9>
  look_at   <0, 1,  0>
  right     x*image_width/image_height
   angle 58
}

light_source {
  0*x
  color rgb .3
  translate <-20, 40, -20>
}

light_source {
  0*x
  color rgb .7
  translate <-20, 40, -20>
}

// NAPPol : North American Pink polished
// NAPFro : North American Pink frosted

//----ORIGINAL texture code from Daniel Mecklenberg, used below
#declare PolishFinish =
finish { ambient 0.5 phong 0.9 phong_size 80 brilliance 1.5 }

//----ORIGINAL texture code from Daniel Mecklenberg ----
// [KENNETH note: a material wrapper is apparently not
// needed for this 2-part texture]
#declare NAPPol =
texture {
pigment {
granite
turbulence 0.8
color_map {
[ 0.000, 0.500 color rgb < 97/255, 51/255, 63/255 >
color rgb < 178/255, 118/255, 86/255 > ]
[ 0.500, 1.000 color rgb < 172/255, 129/255, 116/255 >
color rgb < 235/255, 215/255, 205/255 > ]
}
}
finish { PolishFinish }
}
texture {
pigment {
granite
turbulence 0.8
color_map {
[ 0.000, 0.600 color rgbf < 1.00, 1.00, 1.00, 1.00 >
color rgbf < 1.00, 1.00, 1.00, 1.00 > ]
[ 0.600, 1.000 color rgbf < 0.10, 0.08, 0.08, 0.50 >
color rgbf < 0.05, 0.04, 0.04, 0.00 > ]
}
scale 0.5
translate < 20, 20, 20 >
rotate < 30, 30, 30 >
}
finish { PolishFinish }
}

//-----------
//----ORIGINAL texture code from Daniel Mecklenberg ----
#declare NAPFro =
texture {
pigment {
granite
turbulence 0.8
color_map {
[ 0.000, 0.500 color rgb < 147/255, 111/255, 123/255 >
color rgb < 162/255, 129/255, 116/255 > ]
[ 0.500, 0.720 color rgb < 172/255, 129/255, 116/255 >
color rgb < 245/255, 220/255, 215/255 > ]
[ 0.720, 1.000 color rgb < 70/255, 70/255, 70/255 >
color rgb < 50/255, 50/255, 50/255 > ]
}
}
finish { diffuse 1.0 crand 0.25 ambient 0.5 }
normal { bumps 0.1 scale 0.2 }
}
//------------------
background{srgb .7}

union{
superellipsoid{<.1,.1> rotate 35*y}
sphere{0,1 scale <1,1.3,1> translate 2.2*y}
texture{NAPPol scale .3} //---  OR use NapFro ---
}

Post a reply to this message

Attachments:
Download 'granite gamma comparisons.jpg' (144 KB)

Preview of image 'granite gamma comparisons.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> So, using the two *original* 1996 Daniel Mecklenburg textures from the
> "granites_original.inc" file that Thomas included in his zip files, I
> decided to run  them in v3.7 ...

I forgot to mention that the *only* minor change I made to those original
textures was to scale them smaller-- to look more like Thomas's granite.

Post a reply to this message

Maybe we should implement the Cornell Box as a standard way of posting images
for comparison - to remove all of the other variables that affect the look of an
object and texture.

http://news.povray.org/povray.unofficial.patches/thread/%3C39380E82.5F30%40wanadoo.fr%3E/

(Isn't there an include file for this?)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Maybe we should implement the Cornell Box as a standard way of posting images
> for comparison - to remove all of the other variables that affect the look of an
> object and texture.
>
> (Isn't there an include file for this?)

Yes, the 'Cornell box' scene is in SCENES/RADIOSITY (I had to hunt for it.)

I think its particular box environment might not be the best for showing the
true colors of a textured object placed inside it, only because it has
red/green/yellow walls (and the only lighting comes from the small ceiling
'radiosity' panel.) But your idea sounds useful-- perhaps a gray sphere for the
environment? Plus at least one white light_source for phong/specular highlights?

Post a reply to this message

Just noticed that my test scene code's two light_sources are in identical
positions-- they should be...

light_source {
  0*x
  color rgb .3
  translate <20, 40, -20>
}

light_source {
  0*x
  color rgb .7
  translate <-20, 40, -20>
}

My apologies for the error. I don't think it affects the results of the overall
experiment though. (I was curious as to why my renders showed only ONE highlight
on the objects.)

Post a reply to this message

Op 15/04/2021 om 22:03 schreef Kenneth:
[snip]>
> I make no judgement as to which of the versions of 'North American Pink granite'
> has the correct 'visual' look-- I'll leave that to the granite experts ;-)
> 

It the case of the granites I sincerely wonder if the gamma issue is an 
issue at all (not to be discarded like that of course but...).

Attached is a Real World photograph of North American Pink. No scale is 
provided but, in general, the largest grains in granites do not exceed 
10-15mm [Bates & Jackson (1987): Glossary of Geology, 3rd Ed.].

Imo, this granite hue closely resembles the assume_gamma 1.0 render and 
much less the assumed_gamma 2.2 one. However, there are innumerable 
variations in hue and sizes, so who can say he is in the right and who 
in the wrong? It becomes almost trivial. Except for the /scale/ of the 
texture, where I strongly feel that a 'Real World correct' render should 
be provided to the users.

I have come to the conclusion that granites21.inc is /based on/ 
granites.inc by Daniel Mecklenberg and not an exact reproduction of his 
code. If we want those, we need to render the original file separately, 
  with the initial conditions like Ive and you have done.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'north american pink.jpg' (49 KB)

Preview of image 'north american pink.jpg'

Op 16/04/2021 om 08:24 schreef Kenneth:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> Maybe we should implement the Cornell Box as a standard way of posting images
>> for comparison - to remove all of the other variables that affect the look of an
>> object and texture.
>>
>> (Isn't there an include file for this?)
> 
> Yes, the 'Cornell box' scene is in SCENES/RADIOSITY (I had to hunt for it.)
> 
> I think its particular box environment might not be the best for showing the
> true colors of a textured object placed inside it, only because it has
> red/green/yellow walls (and the only lighting comes from the small ceiling
> 'radiosity' panel.) But your idea sounds useful-- perhaps a gray sphere for the
> environment? Plus at least one white light_source for phong/specular highlights?
> 

I agree with you. My 'environment' could serve but needs adjustments in 
that case.


-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> I have come to the conclusion that granites21.inc is /based on/
> granites.inc by Daniel Mecklenberg and not an exact reproduction of his
> code. If we want those, we need to render the original file separately,
>   with the initial conditions like Ive and you have done.
>
Yes, I agree. And in my personal opinion, the gamma 1.0 'look' is most likely
what was intended, more or less-- based on my trust of your own knowledge of
granites, and also the original comments by Daniel M, who seemed to know about
the subject himself. It would surprise me if he did run his textures with a
2.2-gamma and accepted the result-- because I would assume that "North American
Pink granite" is a well-known and 'standard' type of rock, agreed on by
geologists.  Not like 'political viewpoints', ha.

Post a reply to this message