Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
60F### [at] netplexaussieorg

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

Hmm ok... but I don't understand, how can I use this spline to get HSV 
blend beetwen :
  [0  rgb <1,1,0>]
  [.5 rgb <1,0,0>]
  [1  rgb <.3,1,.3>]
?

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

I was talking in generaly about Your's approach "why hard code while we can 
do it in SDL"
 
> 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 

You realy doesn't like changes ;) IMHO :
a) users that don't use it - will not notice it
b) users with do use it - will appriciate this possibility.

Btw. it can be used along with Yours spline idea (if I understand it 
correctly).

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

only if we add function color_map_value_at(float,COLOR_MAP)
but hmm I do agree :) maybe just code this function instead.
Hmm in fact this is where I woulud agree alsow that using SDL is good.

#macro color_map_at_value(_v,_cmap) - make function i.e. gradient x at 
return it's color at <_v,0,0> 
hmm what was full syntax for it ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message