POV-Ray : Newsgroups : povray.advanced-users : Normal pigment not evaluated as a function? Server Time: 28 May 2020 21:16:13 GMT
 Normal pigment not evaluated as a function? (Message 1 to 5 of 5)
 From: Bald Eagle Subject: Normal pigment not evaluated as a function? Date: 12 Apr 2020 03:10:00 Message:
```I'd like to create different functions to control the red, green, and blue
channels of an /average/ pigment pattern.
I figured I could take the three different /slope/ patterns, color map them to
r, g, and b, /average/ them, and then use that pigment to create a pigment
function.

The /average/ pigment works fine on its own, but neither the /slope/ pattern nor
the /average/ pigment pattern gives a function that makes anything show up when
put back into a pigment statement.  Setting [0 ....] to something other than 0
works, which indicates that the function[s] always evaluate to 0.   :|

Yes, that paragraph above is VERY hard to understand, and seems - circular or at
least unproductive.  But that's what I need since POV-Ray doesn't have functions
that operate with vectors as input or output.  Hopefully the code makes more
sense than the description.

The docs on the slope pattern are pretty hard to understand.
http://wiki.povray.org/content/Reference:Slope_Pattern

Maybe someone can see and point out where / what the problem is.

#declare SlopeX =
pigment {
slope x //sine_wave frequency 0.5
color_map{
[0 rgb 0]
[1 rgb <3, 0, 0>]
}
}
#declare SlopeY =
pigment {
slope y //sine_wave frequency 0.5
color_map{
[0 rgb 0]
[1 rgb <0, 3, 0>]
}
}
#declare SlopeZ =
pigment {
slope z //sine_wave frequency 0.5
color_map{
[0 rgb 0]
[1 rgb <0, 0, 3>]
}
}

#declare Normal = pigment {
average
pigment_map {
[1 SlopeX]
[1 SlopeY]
[1 SlopeZ]
}
}

#declare dif = function {pigment {Normal}}

#declare P_Red =
pigment {
function {dif(x,y,z).red}
color_map {
[0 rgb 0]
[1 rgb <3, 0, 0>]
}
}

#declare P_Green =
pigment {
function {dif(x,y,z).green}
color_map{
[0 rgb 0]
[1 rgb <0, 3, 0>]
}
}

#declare P_Blue =
pigment {
function {dif(x,y,z).blue}
color_map{
[0 rgb 0]
[1 rgb <0, 0, 3>]
}
}

#declare col =
texture{
pigment {
average
pigment_map {
[1 P_Red]
[1 P_Green]
[1 P_Blue]
}
}
//finish {ambient 1 diffuse 0 emission 0}
}
```
 From: William F Pokorny Subject: Re: Normal pigment not evaluated as a function? Date: 12 Apr 2020 16:18:48 Message: <5e933f68\$1@news.povray.org>
```On 4/11/20 11:06 PM, Bald Eagle wrote:
>
> I'd like to create different functions to control the red, green, and blue
> channels of an /average/ pigment pattern.
> I figured I could take the three different /slope/ patterns, color map them to
> r, g, and b, /average/ them, and then use that pigment to create a pigment
> function.
>
> The /average/ pigment works fine on its own, but neither the /slope/ pattern nor
> the /average/ pigment pattern gives a function that makes anything show up when
> put back into a pigment statement.  Setting [0 ....] to something other than 0
> works, which indicates that the function[s] always evaluate to 0.   :|
>
> Yes, that paragraph above is VERY hard to understand, and seems - circular or at
> least unproductive.  But that's what I need since POV-Ray doesn't have functions
> that operate with vectors as input or output.  Hopefully the code makes more
> sense than the description.
>
> The docs on the slope pattern are pretty hard to understand.
> http://wiki.povray.org/content/Reference:Slope_Pattern
>
> Maybe someone can see and point out where / what the problem is.
>
...
>

The slope pattern isn't one I've much used and I've not spent time with
the code, but I have it in my head it only works with normals.

It comes to the fact the pattern - like aoi - needs the surface
intersection and associated normal to work. You don't have this - or
have a bogus normal input - when used with functions (or densities). The
evaluations are happening apart from any surface in 3D space.

Where today the documentation says:

It can be used for pigments, normals and textures, but not for media
densities.

It should say:

It can be used for pigments, normals and textures, but not for media
densities or functions.

Bill P.
```
 From: Bald Eagle Subject: Re: Normal pigment not evaluated as a function? Date: 14 Apr 2020 19:10:01 Message:
```William F Pokorny <ano### [at] anonymousorg> wrote:

> It comes to the fact the pattern - like aoi - needs the surface
> intersection and associated normal to work. You don't have this - or
> have a bogus normal input - when used with functions (or densities). The
> evaluations are happening apart from any surface in 3D space.

This makes me wonder if there's a way to chain the object pattern into the
mix...

Anyway, I got it to work - not well, mind you.   I need to hunt down where the
errors in accuracy are coming from where I use the normal values to modulate the
color values of the seams (The coloring is intentional, the banding is not.)

I don't think it's my delta-h in the partial derivatives - I went from 0.01 to
0.000001 / image_width without much improvement.  I'll probably have to start
graphing the gradient as a function of delta-h for x, y, and z to get a better
feel for what's going on.

Anyway, it's good enough to play with for now.   But ... slow.  :O

see:
```
 From: Bald Eagle Subject: Re: Normal pigment not evaluated as a function? Date: 14 Apr 2020 19:30:01 Message:
```One additional thing this did highlight was why is RGB a pigment and emission a
finish.

Granted, there's the whole mechanism of handling all of this that's already
coded up... but:

It would interesting and useful to have rgbfte - or perhaps any channel >1
functioning as an emissive value of (channel-1).
That would allow function-driven pixel-by pixel emission control.

But maybe I can work that into an average statement using a texture with
emission...   hmmm.
```
 From: William F Pokorny Subject: Re: Normal pigment not evaluated as a function? Date: 15 Apr 2020 11:35:09 Message: <5e96f16d\$1@news.povray.org>
```On 4/14/20 3:25 PM, Bald Eagle wrote:
>
> One additional thing this did highlight was why is RGB a pigment and emission a
> finish.
>
> Granted, there's the whole mechanism of handling all of this that's already
> coded up... but:
>
> It would interesting and useful to have rgbfte - or perhaps any channel >1
> functioning as an emissive value of (channel-1).
> That would allow function-driven pixel-by pixel emission control.
>
> But maybe I can work that into an average statement using a texture with
> emission...   hmmm.
>

A little off the top of my head, but IIRC, while you cannot have
multiple finishes in a texture map of defined textures, I believe you
can code up a texture map as:

texture_map {
[0, pigment { pigm00 } finish { FinEmit }]
[1, pigment { pigm01 } finish { FinPlain } ]
}

and get the differing finishes. I've never tried it with emission
though, so if you do, let me know if it works. ;-)

Bill P.
```