|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm a modeler person, so this is likely an obvious question - humour me.
I've been fiddling around with clouds, and have been using a turbulated
bozo with a colourmap. Now, I thought that I'd like to get more of the
fractal nature of clouds by using a pseudo-perlin noise pigment. I've
generated this by averaging a number of bozo pigments together, where
each successive pigment is half the size, and half the weight in the
average. The results look good so far.
However, I would like to use this new pigment I created with colour
maps. Since it's average based, I can't apply the colourmaps prior to
averaging.
How can I do this? I'm using the MegaPov [1]
Also, I noticed that in the course of the averaging, the whole pigment
approached a greyish colour, as the white bits became darker, and the
dark bits lighter. Is there an easy way to normalize the pigments
between Black and White again?
Simon
[1] I've looked, hopefully, at "pigment_pattern", but I don't think this
is what I want...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39AB252B.3DE01FB8@istar.ca>, sde### [at] istarca wrote:
> However, I would like to use this new pigment I created with colour
> maps. Since it's average based, I can't apply the colourmaps prior to
> averaging.
This sounds like it would be a lot easier to do with a function. Then
you can just use the function as a pattern in the color pigment...
pigment {
function {
(noise3d(x, y, z) +
noise3d(x*2, y*2, z*2))/2
}
color_map {...}
}
> Also, I noticed that in the course of the averaging, the whole pigment
> approached a greyish colour, as the white bits became darker, and the
> dark bits lighter. Is there an easy way to normalize the pigments
> between Black and White again?
You can use pigment_pattern with a color_map that has solid bands of
color at each end. If you use a function, it is very simple: subtract
the minimum from the value, and multiply by an amount that makes the
maximum equal 1.
But I think your pattern probably has areas with values of 0 and 1(or
very close to these), it might be a better idea to apply some waveform
to amplify differences in the middle of the range so the extremes become
more visible. Maybe something based on the sine function...again, this
would most easily be done with functions.
> [1] I've looked, hopefully, at "pigment_pattern", but I don't think this
> is what I want...
It sounds like it is exactly what you want. Use the grayscale version of
the pigment in pigment_pattern, and add your color_map.
--
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
|
|
| |
| |
|
|
From: Simon de Vet
Subject: Re: Colourmaps, averaging, and custom pigments
Date: 29 Aug 2000 13:37:32
Message: <39ABF537.D50DE3E@istar.ca>
|
|
|
| |
| |
|
|
Chris Huff wrote:
> In article <39AB252B.3DE01FB8@istar.ca>, sde### [at] istarca wrote:
>
> > [1] I've looked, hopefully, at "pigment_pattern", but I don't think this
> > is what I want...
>
> It sounds like it is exactly what you want. Use the grayscale version of
> the pigment in pigment_pattern, and add your color_map.
Actually, I've found an easier (for me) method.
I took my complex Bozo perlin, and converted it into a function with the
function{pigment{...}} command in MegaPov. Now that it's a function, I can use
it like any other pigment type, with pigment{function{...}}. A little
roundabout, but at least I understand how it works.
Looks pretty good too!
Simon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39A### [at] istarca>, sde### [at] istarca wrote:
> Actually, I've found an easier (for me) method.
>
> I took my complex Bozo perlin, and converted it into a function with
> the function{pigment{...}} command in MegaPov. Now that it's a
> function, I can use it like any other pigment type, with
> pigment{function{...}}. A little roundabout, but at least I
> understand how it works.
As I understand it, using a pigment function as a pattern does the exact
same thing as pigment_pattern. The difference is that you have to
declare a separate function and use that as a pattern, but it allows you
to manipulate the pattern in whatever way you want.
Not really pertinent to this problem, but I personally would prefer it
if functions took *patterns*. You could use pigments with
pigment_pattern to get the same results as a pigment function does now,
but could use plain patterns if you wanted, without any computational
overhead of evaluating a pigment. But I doubt this will happen any time
soon, since I don't know how to implement it.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|