In article <fgucqu4mhn13aldspfkk016iom072qtuf3@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Why ? If it is easy possible with macro (already included in official package)
> then no need to waste time for coding. There will be no difference between
> macro and builded feature. It have to be always converted to rgb internally.

I think he is talking about different blending methods...currently, 
color_maps do a linear interpolation of RGB colors, and will return < 
0.5, 0.5, 0> with a pattern value of 0.5 with that color map, the user 
might have expected < 1, 1, 0>. Doing a linear interpolation in HSV 
space would give a very different blend...it would make it possible to 
specify two colors with maximum brightness and saturation and get a 
rainbow of hues all of the same brightness.

However, it would be slower. Not by a lot, the conversion of the color 
entries could be done at parse time (assuming you will never want to 
access the color entries directly, with something like an array syntax), 
but it still has to convert back to RGB space. It may be faster to just 
use an RGB map with more entries.

I have considered doing something related to this, along with different 
interpolation types like cosine and cubic interpolation. Color maps are 
very similar to splines in some ways, I've been thinking it might be 
better to merge them into the spline feature.
Basically, all the *_map keywords would be replaced with "blend", the 
parser would be smart enough to figure out what kind of blend is needed. 
The color_map feature would be replaced with the spline feature. 
Pigments would be vector functions. Something like that code could be 
written as:

#declare colorSpline =
spline {
    [0, rgb2hsv(< 1, 0, 0>)]
    [1, rgb2hsv(< 1, 1, 0>)]
}

#declare theTexture =
texture {
    pigment hsv2rgb(colorSpline(bozo(x, y, z)))
}

Maybe an in-line syntax for splines too:
texture {
    pigment hsv2rgb(
        spline {//linear would be default
            [0, rgb2hsv(< 1, 0, 0>)]
            [1, rgb2hsv(< 0, 1, 0>)]
        }(bozo(x, y, z))
    )
}

Ok, that looks a bit wierd, but is much more flexible and could be 
backwards compatible, it doesn't have to replace the existing syntax.
One thing I don't like, you have to watch for the differences between 
code run at parse/scene setup time and code run at render time, but the 
same problem exists now and it doesn't cause much trouble.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message