"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