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