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