"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

Op 16-4-2021 om 09:36 schreef Kenneth:
> 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.
> 
> 
Lol! My thoughts entirely. I assume that Daniel Mecklenburg intended his 
textures to be used with an added scale closely related to the 
/dimensions/ of the supporting object where a 10cm wide cube in one 
scene would need a different scale than a 10m wide stone wall in another 
scene. Caveat: if used in the same scene, both objects would of course 
need the same scale! I would argue that, by itself, any POV-Ray texture 
is "dimensionless" and needs a known support in order to be scaled 
accordingly.

I assume that the name "North American Pink" is the commercial name. As 
a geologist, I would call it a 'granodiorite' probably. The same goes 
for the other granites textures which I have been able to trace in the 
Real World.

In any case, as 'simple' users, lets be and remain creative! Also in the 
rgb/srgb matter (ouch! I did it again!). We have a saying here: "buiten 
de lijntjes kleuren" which translates as "colouring outside the lines 
(or the boundaries)" and meaning "breaking the rules" in particular 
concerning the creative process, but also applied to scientific 
research. It promotes serendipity without any doubt imo.

-- 
Thomas

Post a reply to this message

Am 4/16/2021 um 10:21 schrieb Thomas de Groot:
> Op 16-4-2021 om 09:36 schreef Kenneth:
>> 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

I'm can assure you that in 1996 absolutely nobody did use assumed_gamma 
1.0 for reasons that are actually quite obvious even if you do not 
understand them.
On the other hand my guess would be them someone with the pseudo "Code 
Warrior" (and its implied reference to Mel Gibson) did not use a toy 
operating system like Windows 95 which means he did use assumed_gamma 
1.8 as a consequence.


>> 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.
>>
>>
> Lol! My thoughts entirely. I assume that Daniel Mecklenburg intended his 
> textures to be used with an added scale closely related to the 
> /dimensions/ of the supporting object where a 10cm wide cube in one 
> scene would need a different scale than a 10m wide stone wall in another 
> scene. Caveat: if used in the same scene, both objects would of course 
> need the same scale! I would argue that, by itself, any POV-Ray texture 
> is "dimensionless" and needs a known support in order to be scaled 
> accordingly.
> 
> I assume that the name "North American Pink" is the commercial name. As 
> a geologist, I would call it a 'granodiorite' probably. The same goes 
> for the other granites textures which I have been able to trace in the 
> Real World.
> 
> In any case, as 'simple' users, lets be and remain creative! Also in the 
> rgb/srgb matter (ouch! I did it again!). We have a saying here: "buiten 
> de lijntjes kleuren" which translates as "colouring outside the lines 
> (or the boundaries)" and meaning "breaking the rules" in particular 
> concerning the creative process, but also applied to scientific 
> research. It promotes serendipity without any doubt imo.
> 

Well, my understanding was that this is not just about this particular 
granite file, but about a correct way to convert in general old textures 
from times were *never* assumed_gamma = 1.0 was used.

Obviously this is not the case, sorry for this misunderstanding on my 
part, but frankly you should have said so in the first place and should 
not have added a bunch of buzz words borrowed from color science into 
your header where these words make no sense at all.

So I did completely waste my time here and it seems you did not even 
bother to look at my code - as all I hear is just about comparing 
images. So here is a final image from me also produced with my code but 
with some more educated "guesses" to tweak one user parameter - based on 
the image you did show.

My conclusion: my first thought was right, so please do not mention me 
in any of your files, seriously I mean it.

No need to bother with a reply I'm outa here

so long - Ive

Post a reply to this message

oops, the image...

Post a reply to this message

Attachments:
Download 'nap.png' (496 KB)

Preview of image 'nap.png'

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

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

I peeked there, but it was the most cursory of late-night scans.  I missed it.
IIRC, it was a complicated scene that had a lot of code that I didn't
understand.

I was not suggesting the idea to show any true colors, but as a means of having
an absolute standard environment in terms of lighting, environment, and scale to
compare "side-by-side" two objects and their textures.

That way any differences are coming from the texture definition and any
quibbling and misunderstandings about lighting, object size, etc can be [mostly]
avoided.

Scene variants can have different light sources for highlighting, etc.
Not sure what a good object would be - a sphere with radial normal map?


And I do wish that kids like you and that DeGroot hoodlum would just GROW UP and
have a little maturity.  You spoiled children clearly flaunt your privilege and
brazenly appropriate the cultural heritage of the POV-Ray late 90's.  It's
shameful - and offensive.  "HOW DARE YOU!"  You're probably even using the wrong
surface modification and not the New Normal!  Rather than demonstrate how we as
a people have evolved and advanced civilization through enlightenment and
diversity, you prattle on in your ego chamber about inconsequential social
constructs that are devoid of relevance to the feelings about someone you've
never met and probably haven't ever heard of before now.  How then can we have
peace?  If you had the least care in the world about notional justice, you'd
burn down the city around you to show it - maybe even plowing through a crowd of
quartz and feldspar lovers with your van in the process.  Allahu Code Warrior!
Perhaps if you two were even woke enough to confront your own [m]in[eral]grained
biases, you'd loot a sto[n]re or two and get a REAL computer with a serious
operating system - like _Apple_.  Then we could take back the means of
production from the Upper Class, smash capitalism, strike a blow for the
underprivileged and oppressed, AND fight Climate Change all in one go!
Then under Full Communism, you could do things with your rightfully
redistributed property the One Right Way and we could - finally - have unity.

(Hey - - - Do you think we could code the granites in Unity and see what they
look like there ... ?)

War is Peace!
Freedom is Slavery!
and Ignorance is Strength.

Contemplate your sins against Big Brother Ive - and _be ashamed_.



Whoops - there goes my alarm - I've [sic] got to go take another Dried Frog Pill
and watch "Beyond Melodrome" ....  Anyone else around here need one?

Post a reply to this message

Op 16-4-2021 om 13:13 schreef Bald Eagle:
> Whoops - there goes my alarm - I've [sic] got to go take another Dried Frog Pill
> and watch "Beyond Melodrome" ....  Anyone else around here need one?
> 
> 

  I thought so this morning. Uncle Bill was looking a little green about 
the eyes and jumping up and down in the backyard mumbling to himself 
about... what was it...? a Cornell Box!? Probably meant the Cornflake 
Box; which is empty by the way. Your turn Ken to go down to the shop 
today. And don't forget the beer! but keep it out of sight of uncle 
Bill; you know what happened last time.

-- 
Thomas

Post a reply to this message

Op 16-4-2021 om 11:28 schreef Ive:
> So I did completely waste my time here and it seems you did not even 
> bother to look at my code - as all I hear is just about comparing 
> images. So here is a final image from me also produced with my code but 
> with some more educated "guesses" to tweak one user parameter - based on 
> the image you did show.

Not even had the time to seriously look at your code, which I said I 
appreciated indeed. I have also a life besides POV-Ray and your comments 
need time to get digested seriously and commented on. Have a little 
patience, please?

> 
> My conclusion: my first thought was right, so please do not mention me 
> in any of your files, seriously I mean it.

Well... as you wish. No need to get angry. Have you never learned to 
take things in a relaxed way? My god, we use POV-Ray for our /pleasure/ 
or don't we? At least that is my philosophy.

> 
> No need to bother with a reply I'm outa here
> 
> so long - Ive
> 

Sorry to see you go...

-- 
Thomas

Post a reply to this message

Op 14-4-2021 om 18:00 schreef Alain Martel:

> 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.

To tell the truth, I do not find this easy. I looked up the rules Clipka 
put forward (see attached pdf) and applied those as well as I was able 
to a granite texture (see attached image and the code below). I find the 
result too reflective and really difficult to manage correctly. The hue 
changes dramatically with changes to the reflection value or the 
specular albedo block. I need some help here. Thanks!

//start code
   #local Fudge = 1.9;
   #declare T1_MohoganyPol =
   texture {
     pigment {
       granite
       //turbulence 0.4
       color_map {
         [0.00 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<not_0, 
not_0, not_0>))]
         [0.25 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<0.059, 
0.059, 0.059>))]
         [0.25 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<0.086, 
0.027, 0.059>))]
         [0.35 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<0.118, 
0.118, 0.078>))]
         [0.35 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<0.200, 
0.137, 0.110>))]
         [1.00 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<0.769, 
0.329, 0.298>))]
       }
       scale 0.1 //0.8
     }
     /*finish {
       diffuse 0.8
       brilliance 1.5
       specular 0.9
       roughness 0.005
     }*/
     finish {
       diffuse albedo 0.01*(1-Fudge) brilliance 1.5
       specular albedo 0.8*Fudge roughness 0.001
       metallic on
       reflection {0.8 metallic on}
     }
   } //texture

   #declare T2_MohoganyPol =
   texture {
     pigment {
       granite
       turbulence 0.2
       color_map {
         [0.00 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<0.200, 
0.200, 0.200>)) transmit 0.149]
         [0.25 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<0.200, 
0.200, 0.200>)) transmit 0.949]
         [0.25 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<1.000, 
1.000, 1.000>)) transmit 1.000]
         [1.00 ColourSat(SatBoost, BrightBoost, scRGB_to_sRGB(<1.000, 
1.000, 1.000>)) transmit 1.000]
       }
       scale 0.3
       translate <20.0, 20.0, 33.0>
       rotate <0.3, 0.2, 0.0>
     }
     /*finish {
       diffuse 0.8
       brilliance 1.5
       specular 0.9
       roughness 0.005
     }*/
     finish {
       diffuse albedo 0.8*(1-Fudge) brilliance 1.5
       specular albedo 0.2*Fudge roughness 0.001
       fresnel on
       reflection {0.2 fresnel on} conserve_energy
     }
   } //texture

   #declare MohoganyPol_1 = texture {T1_MohoganyPol}

   #declare MohoganyPol_2 =
   material {
     interior {ior 1.5}
     texture {T1_MohoganyPol}
     texture {T2_MohoganyPol}
   } //material
//end code

-- 
Thomas

Post a reply to this message

Attachments:
Download 'mohoganypol2-2.jpg' (83 KB) Download 'clipkas finish 1.pdf' (66 KB)

Preview of image 'mohoganypol2-2.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:
I find the
> result too reflective and really difficult to manage correctly. The hue
> changes dramatically with changes to the reflection value or the
> specular albedo block.

Whoa.  That's super shiny.  It looks like polished marble dipped in
polyurethane.

It took me while of looking over the surface to understand that what I thought
might be some weird artefact is actually the reflection of the edge of your
curved plane and the sky_sphere.

This would be a great texture to apply to make wet granite - maybe a bird bath
or a fountain or something.  I'm sure it would look interesting to texture an
isosurface with this and apply a few off-center radial sine-waves.

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:

>
> I'm can assure you that in 1996 absolutely nobody did use assumed_gamma
> 1.0 for reasons that are actually quite obvious even if you do not
> understand them.

Gee, I guess I don't, not being blessed with your obviously superior and
all-seeing knowledge.

>
> Well, my understanding was that this is not just about this particular
> granite file, but about a correct way to convert in general old textures
> from times were *never* assumed_gamma = 1.0 was used.
>
> Obviously this is not the case, sorry for this misunderstanding on my
> part but frankly you should have said so in the first place and should
> not have added a bunch of buzz words borrowed from color science into
> your header where these words make no sense at all.

Gee, an actual half-baked apology? From Your Highness?! (with a dose of further
insults, of course) Wow. I'll bet you choked on it, trying to get it out.
>
> So I did completely waste my time here...

Gee, that's sad.
>
> My conclusion: my first thought was right, so please do not mention me
> in any of your files, seriously I mean it.

Gee, that sounds SERIOUS. You mean it! (...or else?...) Personally, I would pay
no attention to such egotistic claptrap. It actually makes me laugh. And if you
felt insulted and wronged and that your *orders* were not being paid attention
to, you would be welcome to take your case to the International Criminal Court
of Justice to seek redress...if they don't laugh too, and kick you out of the
building.

>
> No need to bother with a reply

Yes Sir, if you say so Sir.

 I'm outa here

Gee, that's sad too. I guess you'll be flying back to Mount Olympus now, to be
among your fellow Gods. Well, don't let the door slam on your way out!
*Somehow*, the rest of us will manage to get along...
>
> so long - Ive

Send us a postcard from On High.

------
But I still like your IC app; I'm not yet going to tear it from my computer and
burn its bytes in a fit of childish temper...like you have displayed.

You may take your toys and go home now.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Yes, the 'Cornell box' scene is in SCENES/RADIOSITY (I had to hunt for it.)
>
> I peeked there, but it was the most cursory of late-night scans...

What?! You only *peeked* at it??  No No No, that is NOT the 'POV-ray way'. The
rules are clearly spelled out in chapters 7,43, and 129 of the 'POV-ray
Behavior' manual. Don't tell me you haven't read them??
>
>
> And I do wish that kids like you and that DeGroot hoodlum would just
> GROW UP and have a little maturity.  You spoiled children clearly flaunt
> your privilege...

SPOILED?! Oh, you mean, because of that $50 million I inherited when I was 2
months old? Naw, I've always been the same lovable, cuddly, ever-so-pleasant
fellow that I was before then. I think.

> ...you'd burn down the city around you to show it - maybe even plowing
> through a crowd of quartz and feldspar lovers with your van in the process.

Personally, I would prefer olivine and soapstone lovers...they always irritate
me...

Post a reply to this message

Op 16/04/2021 om 19:17 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> I find the
>> result too reflective and really difficult to manage correctly. The hue
>> changes dramatically with changes to the reflection value or the
>> specular albedo block.
> 
> Whoa.  That's super shiny.  It looks like polished marble dipped in
> polyurethane.
> 
> It took me while of looking over the surface to understand that what I thought
> might be some weird artefact is actually the reflection of the edge of your
> curved plane and the sky_sphere.
> 
> This would be a great texture to apply to make wet granite - maybe a bird bath
> or a fountain or something.  I'm sure it would look interesting to texture an
> isosurface with this and apply a few off-center radial sine-waves.
> 

See? In another post I've (sic) ;-) mentioned "serendipity" and... there 
we are!

Excellent suggestion! I shall put this in another file for later.

[where are my Round Tuits...? I really, I mean: Really, need more Round 
Tuits...]

-- 
Thomas

Post a reply to this message

Op 17/04/2021 om 05:20 schreef Kenneth:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>>> Yes, the 'Cornell box' scene is in SCENES/RADIOSITY (I had to hunt for it.)
>>
>> I peeked there, but it was the most cursory of late-night scans...
> 
> What?! You only *peeked* at it??  No No No, that is NOT the 'POV-ray way'. The
> rules are clearly spelled out in chapters 7,43, and 129 of the 'POV-ray
> Behavior' manual. Don't tell me you haven't read them??

Well... what did you expect, frankly? Big words and bla-bla imo. 
"late-night scans"...!  Whoaaa-ha-ha!

[have another beer]

>>
>>
>> And I do wish that kids like you and that DeGroot hoodlum would just
>> GROW UP and have a little maturity.  You spoiled children clearly flaunt
>> your privilege...
> 
> SPOILED?! Oh, you mean, because of that $50 million I inherited when I was 2
> months old? Naw, I've always been the same lovable, cuddly, ever-so-pleasant
> fellow that I was before then. I think.

Thanks for the loan, btw!  Whoaa-ha-haaa!

[Have abeer an otter...]

> 
>> ...you'd burn down the city around you to show it - maybe even plowing
>> through a crowd of quartz and feldspar lovers with your van in the process.
> 
> Personally, I would prefer olivine and soapstone lovers...they always irritate
> me...

nah... bunch of creeps... [burp]

-- 
Thomas

Post a reply to this message

Op 11-4-2021 om 14:48 schreef Mr:
> [snip]  Or combine
> two variants of that pattern with both scales using a third masking /warping
> pattern, so that variation seems less homogenous. 

Experimental and with finish commented-out.

Not bad at all!

Thanks for the suggestion. It took some time, but I am getting there.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'layeredtextures_finish_test.jpg' (91 KB)

Preview of image 'layeredtextures_finish_test.jpg'

After reworking the top layer.


-- 
Thomas

Post a reply to this message

Attachments:
Download 'mohoganypol2-2.jpg' (98 KB)

Preview of image 'mohoganypol2-2.jpg'

Op 16/04/2021 om 11:28 schreef Ive:
 > Well, my understanding was that this is not just about this particular
 > granite file, but about a correct way to convert in general old textures
 > from times were *never* assumed_gamma = 1.0 was used.
 >
 > Obviously this is not the case, sorry for this misunderstanding on my
 > part, but frankly you should have said so in the first place and should
 > not have added a bunch of buzz words borrowed from color science into
 > your header where these words make no sense at all.
 >

Yve,

Possibly, you are not going to read this, so I write for my own benefit 
(and for those who might be interested) and because I feel I am entitled 
to give a serious answer (after a bit of charivari to vent frustrations).

Initially, this whole exercise was indeed, about upgrading old files. As 
so often happens in the (creative) process, things evolved quite rapidly 
and soon enough granites21 was about generating a new granites 
construction, */based on the work of Daniel Meklenburg/*, I want to 
stress. I am afraid you missed the (gradual) shift to this new approach; 
I was taken by surprise myself I must confess. So, your contribution is 
/not/ a waste of time. On the contrary, it is invaluable for taking up 
the /original/ granites.inc and provide a comprehensive document 
corrected to the use of POV-Ray 3.7+ in a not too distant future. In 
your file there are many things I did not know/been aware of or had 
forgotten. So, again, thanks indeed for your contribution. You are not 
rid of me: in due time I shall give my comments on your file.

You and me, we are both part of the scientific community at large I 
understand. You are a professional (I guess) of the colour sciences; I 
am a professional of the geological sciences. The fundamental difference 
however between us, as I surmise, is that colour sciences are 
/necessarily/ part of the /exact/ sciences, while geological sciences 
are, for a large part, not. Geology is as much about reconstructing, 
from partly preserved items, environments and life from the past, 
without having enough elements to be able to do so in an /exact/ way. 
Where necessary, we make use of the exact sciences, and increasingly so, 
but we are as much indebted to creativity and leaps of faith in order to 
reach consensus and progress. We are rewarded by the visions and 
reconstructions of the ancient world as they evolve under our hands as 
it were.

This is why we have very different approaches to these matters of colour 
in particular. I certainly expect a rigorous approach from you, and I 
would have been surprised if you were not, in the matters of your 
expertise field. On the other hand, while acknowledging this, I feel 
rather free to use some results from the colour sciences as they are 
made available to the POV-Ray community, in maybe a twisty way but 
important for the creative process where the visible results are 
important. So, if I only talk for myself, I use different rgb and/or 
srgb elements together in the same scene and nobody can pinpoint them 
separately I am sure. I understand your irritation about the use of 
possibly inappropriate terms from the colour sciences and I got rid of 
them in the next version of granites21. Understand that my objective was 
to be as precise as possible, but without your kind of understanding 
this is certainly prone to errors.

A last remark. I take exception to your impatience when you mention that 
"it seems you did not even bother to look at my code" and that *within 
24 hours* of your initial post! I resent this indeed. You have 
absolutely no idea about the frequency and time I spend on POV-Ray, 
including reading and commenting on posts. I mentioned that I have a 
life in the Real World, as you have too I am sure, and that takes 
absolute priority. Well, let me tell you that during each 24 hours I 
spend maybe two hour *maximum* to POV-Ray (including posts), divided 
over several snippets of time during the day. So, gimme a break, OK?

All right. Enough about this. I hope you understand if you read this, 
and let's close the matter definitively. If you want to answer, you are 
welcome indeed, but I consider the war axe to be buried from now on.

Cheers

-- 
Thomas

Post a reply to this message

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

Sarcasm and satire aside,
You need to deal with the fact that there is a large and rapidly increasing
number of people out in the world that suffer from mental illness.  They may
_seem_ normal in certain isolated settings, but it only takes the slightest
nudge to flip things over that threshold.

> I am afraid you missed the (gradual) shift to this new approach;

Nah,  If you pay attention to the "pattern" of posting, one can surmise that
like some other people, there's some type of monitoring software being used, and
after months or years of absence, they suddenly appear from seemingly nowhere to
get offended over something, rave, and generally "stir the pot".


> You and me, we are both part of the scientific community at large I
> understand.

Be careful.  You're projecting.  Soon you will begin to attempt to rationalize
the irrational and get "sucked in".  I can't tell you how many "scientists",
"professors", "grad students", "experts", "professionals", "mathematicians", and
"programmers" - who you'd think would be logical and at least stable - but you
shift to a certain topic, and it all goes straight out the window.
Imprinting, trauma, brainwashing, and Stockholm Syndrome are all very real, very
dangerous things.   Amongst many others.



> I understand your irritation about

.... everything.  It's the way everyone in the world is now.   They do
archaeology to uncover decades old thing to be offended about, and when that's
too much work, they invent fictitious "new" things to take offense at.

> A last remark. I take exception to your impatience when you mention that
> "it seems you did not even bother to look at my code" and that *within
> 24 hours* of your initial post! I resent this indeed. You have
> absolutely no idea about the frequency and time I spend on POV-Ray,
> including reading and commenting on posts. I mentioned that I have a
> life in the Real World, as you have too I am sure, and that takes
> absolute priority. Well, let me tell you that during each 24 hours I
> spend maybe two hour *maximum* to POV-Ray (including posts), divided
> over several snippets of time during the day. So, gimme a break, OK?

I sometimes get impatient for responses, especially when I'm working on
something and need ("want") some assistance to move past some difficulty and
reach a solution or workaround.  But that's not really the case here.
I'm calling "rabid instability".  Maybe he's taken up eating paint.

I have work, home, child, meals, shopping, laundry, garden, relationships,
neighbors, favors, friends, community involvement, and plenty of other things
that take me away from making any "meaningful progress" on any number of _hobby_
projects, let alone starting any new ones.  And my mechanism of making a "to-do
list" is starting a project so that it's physically there to remind me of it.

> All right. Enough about this. I hope you understand if you read this,
> and let's close the matter definitively. If you want to answer, you are
> welcome indeed, but I consider the war axe to be buried from now on.

Toxic people get offended and will try to flip things around and in true Saul
Alinsky fashion, accuse YOU for holding a grudge.  "Nah, little buddy.  That's
called a boundary."

I've been through all of this in a very personal, very real, very consequential
manner.  So I can see what's going on instantly, with pretty good clarity.  And
I know how to follow the breadcrumbs (vide infra).

"The emotional maturity of a typical narcissistic person is akin to a 5-year-old
child who pouts and refuses to play with a friend in the sandbox because the
friend wants to share the pail and shovel. The 5-year-old refuses to talk with
the friend and angrily storms off to play on the jungle gym with someone else."

https://www.goodtherapy.org/blog/silent-treatment-a-narcissistic-persons-preferred-weapon-0602145

view-source:https://

Post a reply to this message

Op 18-4-2021 om 14:58 schreef Bald Eagle:
Thank you Bill, I do really appreciate indeed your comments and I am 
sadly aware of your own experience of this. The thought passed through 
my mind too. However, I wanted to give Yve what in French is called "Le 
bénéfice du doute" (the Benefit Of The Doubt). What I write remains my 
own conviction, whatever he may make of it.

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 18-4-2021 om 14:58 schreef Bald Eagle:
> Thank you Bill, I do really appreciate indeed your comments ...
> my mind too. However, I wanted to give Yve what in French is called "Le

umlauts + accents etc (currently) cause hiccups.


> own conviction, whatever he may make of it.

only two things to .. observe -- why "Yve"?  some Freudian thing?  :-)  concur
with BE, "ingrown toenails", likely.  not your problem.


regards, jr.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 18-4-2021 om 14:58 schreef Bald Eagle:
> Thank you Bill, I do really appreciate indeed your comments and I am
> sadly aware of your own experience of this. The thought passed through
> my mind too. However, I wanted to give Yve what in French is called "Le
>
> own conviction, whatever he may make of it.
>
> --
> Thomas

(I'm guessing something got omitted in there, but I understand where you're
going)

Indeed.  Now, we don't really need to "be fair" or give Ive/Yve a fair hearing -
because he can post [virtually] anything he wants here, any time he wants - and
there's damned little any but a select few can do to stop him.

Perhaps like so many before - artistically brilliant and enviously talented -
but psychologically....  wow.

I certainly give plenty of people a fair chance to present their views and
discuss them and what they believe their reasons for having them are.  Maybe we
agree, maybe we don't.   Sometimes we leave it at that, sometimes it begins a
long and continuing conversation that can last years.

But I'm not getting any younger, and I've learned some hard and painful lessons
from people who have quite frankly surprised me by their sudden and inexplicable
U-turns in thought/belief/behaviour.   So I just add them to the list of people
who are lost, too far gone, or too dangerously damaged for me to consider it
worthwhile bothering with.

As you say, I sadly got put through the wringer, but: I _learned_ a lot - both
about other people and myself, had my eyes opened, my illusions dispelled, and
after 10 years am doing well enough.  Although it no longer hurts, it's the pain
of the burn that keeps the child from grasping the hot handle of the pan on the
stove again.
Having instructed college chemistry, I did my due diligence and asked of the
students on the first day of lab, "Before you go and just thoughtlessly pick up
a beaker - what's the difference in appearance between cold glass and hot
glass?"
<silence>
"There isn't any."

I mean, I'm generally a top-of-the-Nolan-chart Libertarian who will genuinely
defend people's God-given Rights to say, or do, all manner of things.  But I
always admonish them with a reminder that "with great power comes great
responsibility" - and freedom and liberty are the fonts of personal power.  So
just because you CAN do something, doesn't mean you SHOULD.  Just because I'm
not going to stop you, doesn't mean that it isn't still a bad idea, or that I
won't try to dissuade you.  It also doesn't mean that after you do it, I won't
judge you for it, lay the blame and responsibility at your feet, or think that
it's a swell idea to continue my association with you.  I may, at some future
time, even realize and regret that I may have played some part and bore some
responsibility as well.   Stuff happens.  You can either get all hung up on it -
or move past it, grow, mature, and hopefully do better next time.


You were making an honest and wholly innocent effort to freely give of your
time, experience, and expertise to breathe new life into a set of procedural
textures that are decades old - and he decided to pop in out of nowhere,
snarling like a rabid dog, hurling blanket accusations and baseless attributions
of motive, intent, and willful negligence, and then just as abruptly stormed
out.

So, based on past similar behaviour and a peek under the the facade across the
interwebs, I'm making the call that there's a whole lot going on in that can of
worms, such that I don't see any value in getting drawn into it, and [caveat]
depending on the specific details of location, proximity and resources, one can
never really tell what any given individual is apt to do.  As an American, I was
surprised to find that Norway placed top of the list in 2011.  Maybe the
pressure cooker in TX has just been building up to bursting for the last decade.
https://www.youtube.com/watch?v=kJKJM36lMTE

Now, if I'm wrong or there's some underlying heap of stuff but everything gets
aired out and fixed up - fine.  I can be wrong.  I'm wrong a lot.  I prefer to
be "right", and that's why I spend such an inordinate amount of time learning,
and fixing things, and helping other to improve.


So, if people want to be decent and civilized, so be it.
If they want to be an epithet, that's their choice as well.

But at this point, regardless of whether or not it's "their bat and their ball,"
they can go home if they want to.  It's up to them.

Post a reply to this message

Op 18/04/2021 om 18:23 schreef jr:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 18-4-2021 om 14:58 schreef Bald Eagle:
>> Thank you Bill, I do really appreciate indeed your comments ...
>> my mind too. However, I wanted to give Yve what in French is called "Le
> 
> umlauts + accents etc (currently) cause hiccups.

Oops! I had not noticed that, sorry. I mentioned "the benefit of the 
doubt" there.

> 
> 
>> own conviction, whatever he may make of it.
> 
> only two things to .. observe -- why "Yve"?  some Freudian thing?  :-)  concur
> with BE, "ingrown toenails", likely.  not your problem.
> 
> 
> regards, jr.
> 

Right! Freudian, no doubt ;-) I have no idea why I mis-typed....

-- 
Thomas

Post a reply to this message