In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> I can't agree, in same way we can say that sphere,box,etc are redunant 
> versions of i.e. isosurface.

No, you can't...the isosurface object uses a completely different way to 
solve for the shape, takes a different kind of input, etc. A color map 
is a linear spline with some limitations...it can only take color 
values, and can only have 256 elements. Instead of removing the 
limitations and adding features, my suggestion is to replace it with the 
existing spline feature and add features to *that*. Instead of a color 
map with options for things like cubic blending, just have a color 
spline with the same syntax as any other spline.

The other stuff, the color space functions and pigment-as-function, were 
just a much more flexible and more consistent way of accomplishing the 
same result, interpolating in a different color space, as well as much, 
much more.


> I alsow realy like SDL, but if we will continue to implement everything 
> possible in SDL istead of C we will end with parse-times longer then 
> renders ;-/ and with straaange syntax.

This wouldn't have any impact on parse time. It might slightly slow 
render time, but it would be more capable than a vast array of 
hard-coded features.


> pigment {
>   bozo
>   color_map { 
>     [0 rgb x]  // #1 blend to next entry using global blend type
>     [0.1 rgb y blend_rgb] // #2 blend to next entry  RGB
>     [0.2 rgb z] // #3 blend to next entry using global blend type 
>     [1 rgb x+y] // #4 blend to next entry using global blend type
>     blend_hsv // set global entry (used for 1,3,4)
>     precalc {4096} // precaluate 4096 RGB values to optimize speed
>   }
> }

This is really crying for the old (and currently deprecated) blend 
syntax, which gave each end of a range as well as the color of each end:
pigment {bozo
  color_map {
    blend_hsv
    [0.0, 0.1 rgb x, rgb y]
    [0.1, 0.2 rgb y, rgb z blend_rgb]
    [0.2, 1.0 rgb z, rgb x+y]
    precalc 4096
  }
}

But I still don't think this syntax is necessary...that function syntax 
I proposed would handle it just fine for those cases where it is needed.
That precalc idea...I don't think I like it. For one thing, it would 
only help a few cases, and would hurt a lot of others. It would be 
required so rarely that it could easily be coded as a loop instead. And 
the differences between per-range and per-map blending modes would 
complicate things unnecessarily and cause confusion, its main advantage 
would be reducing typing.

-- 
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