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

Rather than think of it from the narrow perspective of what _you_ might do to
the color, think about what might happen to the color once the object pigmented
with it is placed into a scene, in proximity to another object that _does_ have
a red color, or is lit with a light source that has a red component.   Then
POV-Ray (or any other graphics software) would calculate what color the camera
would see by multiplying the base color by some fraction of the lighting or
radiosity, etc.

And THAT's the take-away message I got from following along in a few tutorials
and live coding sessions.

I mean, we can always ADD <r, 0, 0> to a color to give it some red first, and
THEN multiply it, but the idea is always have that little bit in there that can
be operated upon by all the complexities of the scene and lighting interactions,
so that we don't have to think about it every time, and make it even more
difficult for newbies to debug "Why do my scene objects look so _______ ?"

I hope that clears it up a little bit.

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)

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.

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

(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?
What about sslt and interior {ior} ?


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.


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?


Thanks!   :)

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