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