Jerome <ber### [at] inamecom> wrote:
: 	Well, suppose you want to make an object with a bozo
: pigment that goes from red to green to blue, you would
: naturally tend to use a color_map like this:
: {
:   [ 0.0 color Red ]
:   [ 0.5 color Green ]
:   [ 1.0 color Blue ]
: }

: 	With standard pov (or my patch), it gives what you expect,
: but in megapov 0.5 the result is mostly green.

  But the latter _is_ the correct behaviour.
  Think about the color map:
  From 0 to 0.25 the red component is predominant (ie. it's larger than the
other components), from 0.25 to 0.75 the green component is predominant and
from 0.75 to 1 the blue is predominant.
  This means that 50% of the pigment should be predominatly green, 25% red
and 25% blue.
  Thus, having the result mostly green is the correct behaviour and should
be expected. This should happen with every pattern that has even distribution.

  If you want each color component to cover the same percentage of the pigment,
you'll have to set it up so that each of them gets 33.33% of it. For example:

  [ 0/3 rgb Red ]
  [ 1/3 rgb Green ]
  [ 2/3 rgb Blue ]
  [ 3/3 rgb Red ]

  Now you have an equal amount of each color (ie. 33.33% of each). This should
work with every pattern which has even distribution.

  This also means that your pattern does NOT have even distribution, but
prefers some values more than others.

: 	He did exactly the same thing I did: he took the result
: from the old function before it is truncated and applied a
: transformation to it (other than truncating) to force the
: result to be between 0 and 1. The only differece between his
: patch and mine is that he applied a linear transform and I
: applied a non-linear one.

  Multiplying the function with a scalar only changes its amplitude, not
its shape. Your non-linear transformation makes it a completely different
function.

: 	Regular and smooth? Mine is as regular and smooth as the
: old one and has as much variation as the old one

  Nope. The curvature of the surface in some places is higher in your
function than in the old one (if we don't count the plateaus produced by
the clamping). This makes it less smooth.
  A sphere is smoother than an ellipsoid.

, whereas
: Nathan's has less and therefore is more different from the
: old one than mine...

  Nathan's function is _exactly_ the same as the old one. Only the amplitude
has changed.
  A sine wave does not stop being a sine wave if we multiply it by a scalar.
However if we make a non-uniform transform to it, then it stops being a
sine wave.

: 	The statistical distribution is very much in favor of the
: middle-range values

  As I said that happened only because your color_map was in favor of the
green value (50%) and not the others (25% each).

:>   I still think that your function should be renamed if included.
: 	I disagree, mine has no more reason to be renamed then
: Nathan's.

  Wrong. Nathan's fix did not change the function. Yours did. Your function
is thus a different one.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message