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

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


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

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

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

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

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

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

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

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

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