This is more a question than a feature request.
Would it possible and/or usefull to ad a (3d) convolution matrix as a warp?

warp {
  convolution {
    divisor
    offset
    (channels rgb)
    <v1>,.....,<v25>
  }
}

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <8EE67CD38seed7@204.213.191.228>, ing### [at] homenl (ingo) 
wrote:

> This is more a question than a feature request.
> Would it possible and/or usefull to ad a (3d) convolution matrix as a 
> warp?
> 
> warp {
>   convolution {
>     divisor
>     offset
>     (channels rgb)
>     <v1>,.....,<v25>
>   }
> }

Hmm, what is a convolution matrix? A way to transform colors as though 
they were points? If so, it wouldn't be a warp, although warps could 
possibly be used in it. Something like:

pigment {
    pattern, color_map, warps and transforms, etc
    convolution {
        convolution stuff...
        warps to be applied to the color
    }
}

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

>Hmm, what is a convolution matrix?

Here is an explaination of what it does:
http://btp1da.phy.uni-bayreuth.de/FreeBSD/gimp/Plugin_generic.html#446972

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <8EE67889Aseed7@204.213.191.228>, ing### [at] homenl (ingo) 
wrote:

> Here is an explaination of what it does:
> http://btp1da.phy.uni-bayreuth.de/FreeBSD/gimp/Plugin_generic.html#446972

Ah, I have used those before(GraphicConverter has them). This sounds 
more like a post_process feature than a texture feature, though...
But it seems odd to be limited to a float value for each pixel-why not 
use a color vector instead? And maybe make the size user defined instead 
of fixed.

The reason it would be a post_process feature and not a pigment warp is 
that it seems to require pixels, or at least color samples in a plane. 
That would be pretty difficult to accomplish without UV coordinates for 
every object, I think. Maybe if there were a way to define it for 
specific objects, so it was only applied in the area of the image 
covered by the object...the code shouldn't be too hard, but what would 
the syntax be?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

>Ah, I have used those before(GraphicConverter has them). This sounds 
>more like a post_process feature than a texture feature, though...
>But it seems odd to be limited to a float value for each pixel-why not 
>use a color vector instead? And maybe make the size user defined instead
>of fixed.
>

From the POV-doc on turbulence:
"It says in effect "Don't give me the color at this spot... take a few 
random steps in different directions and give me that color"."

I know very little of the way graphic software works. I was thinking, 
instead of taking the random steps of turbulence, take "defined" steps as 
in a convolution matrix.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <8EE68726Aseed7@204.213.191.228>, ing### [at] homenl (ingo) 
wrote:

> From the POV-doc on turbulence:
> "It says in effect "Don't give me the color at this spot... take a few 
> random steps in different directions and give me that color"."
> 
> I know very little of the way graphic software works. I was thinking, 
> instead of taking the random steps of turbulence, take "defined" steps as 
> in a convolution matrix.

It might be possible to do that, but you would have to specify the size 
of the sampling rectangle as well. You would also need to orient the 
sampling rectangle to be parallel to the surface, and have the same 
orientation as it's neighboring points. That is the difficult part, and 
I don't know how it would be done.(maybe just by using the angle to the 
xz plane and angle around the y axis?)

Or you could have the matrix always be aligned with the origin(with 
rotations and other transforms, of course). This would be a lot easier 
to implement, but it wouldn't follow the surface of the object. And to 
do it well would probably require a 3D array of values, like 3*3*3.

I will look into this, I think all it would require is multiple calls to 
Compute_Pigment with the evaluation point moved in the right way. And it 
would be restricted to pigment, since it operates on colors instead of 
patterns, like turbulence does. And it probably wouldn't be very fast.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message