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'

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'