Here's an idea for a (simple, I think) texturing feature.  It would
give the ability to adjust resulting rgb values where they are
produced (essentially in pigments and textures).  Example :
 
 I need to repeat several wooden planks, and want to change
slightly their brightness, randomly.  Usually, I would do
that using ambient, but it is unpractical, and has annoying
consequences (if I use radiosity, etc..).  My idea is to do it 
that way : 

  pigment {wood color_map {WoodMap} 
           rgb_adjust <r,g,b>*(1+rand(r1)*.1) 
          }

Other formulaes could be used to adjust contrast, hue, apply
some color filter... without messing with other settings which
are not designed to do that.  Much easier than messing with 
the color_map, especially if it was generated externally.
And it would also work with any complex texture :

 texture {VeryComplexTexture scale.. rotate .. rgb_adjust <r*.5,g,b>}

...which would dim the Red channel at each point of the texture.

Fabien.

Post a reply to this message

Fabien Mosen wrote:

> Here's an idea for a (simple, I think) texturing feature.  It would
> give the ability to adjust resulting rgb values where they are
> produced (essentially in pigments and textures).  Example :

Note that it's already possible to obtain some of these effects
using the average pattern (which doesn't mean that the rgb_adjust feature
wouldn't be interesting) :

#declare pig1=pigment{bozo color_map{[0 Green][1 Red]}}
plane { y, 0
    pigment {
        average
        pigment_map{
            [1 pig1]
            [0.1 color Cyan]
        }
    }
}

G.

Post a reply to this message

I think this would be an excellent addition to POV. I often need random or
slightly changing values for objects and colors and it ain't always easy to
do.

Mick

"Fabien Mosen" <fab### [at] skynetbe> wrote in message
news:39D4BF73.3A275524@skynet.be...
> Here's an idea for a (simple, I think) texturing feature.  It would
> give the ability to adjust resulting rgb values where they are
> produced (essentially in pigments and textures).  Example :
>
>  I need to repeat several wooden planks, and want to change
> slightly their brightness, randomly.  Usually, I would do
> that using ambient, but it is unpractical, and has annoying
> consequences (if I use radiosity, etc..).  My idea is to do it
> that way :
>
>   pigment {wood color_map {WoodMap}
>            rgb_adjust <r,g,b>*(1+rand(r1)*.1)
>           }
>
> Other formulaes could be used to adjust contrast, hue, apply
> some color filter... without messing with other settings which
> are not designed to do that.  Much easier than messing with
> the color_map, especially if it was generated externally.
> And it would also work with any complex texture :
>
>  texture {VeryComplexTexture scale.. rotate .. rgb_adjust <r*.5,g,b>}
>
> ...which would dim the Red channel at each point of the texture.
>
> Fabien.

Post a reply to this message

In article <39D4BF73.3A275524@skynet.be>, Fabien Mosen 
<fab### [at] skynetbe> wrote:

> Here's an idea for a (simple, I think) texturing feature.  It would
> give the ability to adjust resulting rgb values where they are
> produced (essentially in pigments and textures).  Example :

I have thought of making a variation of the color_matrix filter that 
would work on pigments...but I wasn't sure if it would be useful enough 
for the effort. Other filters could be done too...blurring, color space 
conversions, etc...much of the same stuff available in post_process 
filters. Kind of like an enhanced waveform applied to colors instead of 
pattern values...

BTW, another thing in the same interesting-but-maybe-not-useful 
category: waveform lists for patterns. Basically, it would allow you to 
specify a sequence of waveform transformations instead of a single 
one...it would be implemented as just another waveform type.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> BTW, another thing in the same interesting-but-maybe-not-useful
> category: waveform lists for patterns. Basically, it would allow you to
> specify a sequence of waveform transformations instead of a single
> one...it would be implemented as just another waveform type.

? I don't get it... please reprocess and repeat...

Post a reply to this message

I would have thought you gurus would have stated (already) that this is
possible now? I have already done it (wasn't tidy), so I know it can be
done. I just thought there was someone out there already working on it? Oh,
wait a minute, that was me! heh

Grim

Post a reply to this message

In article <39d54f3b@news.povray.org>, "Tony[B]" 
<ben### [at] panamac-comnet> wrote:

> > BTW, another thing in the same interesting-but-maybe-not-useful
> > category: waveform lists for patterns. Basically, it would allow you to
> > specify a sequence of waveform transformations instead of a single
> > one...it would be implemented as just another waveform type.
> 
> ? I don't get it... please reprocess and repeat...

Ok...
Take "gradient y" for example. It makes a linear ramp-wave, the value of 
the pattern increases from 0 to 1 and then drops sharply back to 0. If 
you specify "sine_wave", this value is fed through a "filter" which 
transforms the ramp wave to a sine wave before the color_map is read.
What I am proposing is a new waveform which allows you to specify a list 
of waveform filters.

waveform_list {
    sine_wave|scallop_wave|ramp_wave|spline_wave
    add|subtract|multiply|divide|function|etc...
}

As an example:
pigment {bozo
    waveform_list {
        multiply 2
        ramp_wave
        sine_wave
        poly_wave 2
    }
    color_map {...}
}

This would make a bozo pattern with twice the frequency, and a sine wave 
falloff with sharper peaks due to the poly_wave. This isn't impossible 
to do now...but you would have to feed a bozo pattern into a function 
pattern and do the waveform stuff in the function...more flexible, but 
harder to read, less obvious and slower.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Fri, 29 Sep 2000 19:11:06 +0100, "Mick Hazelgrove"
<mic### [at] mhazelgrovefsnetcouk> wrote:

>I think this would be an excellent addition to POV. I often need random or
>slightly changing values for objects and colors and it ain't always easy to
>do.
>
>Mick

One way of thinking of this, is to specify a "tolerance" value in
addition to the actual parameter. Then the actual parameter would be
randomly modified by an amount within the tolerance you have
specified. If no tolerance is specified, then there would be no
modification of the parameter value.

Does anyone like this idea?

Later,
Glen

Post a reply to this message