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

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