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

Post a reply to this message

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.

Post a reply to this 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:
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5e9608782b8cb206fb0b41570%40news.povray.org%3E/

Post a reply to this 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.

Post a reply to this message

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.

Post a reply to this message