In article <38D### [at] aolcom>, Lummox JR <Lum### [at] aolcom> wrote:

> Personally, I'd like to see a sort of function-aware color map that can
> do the work. For example, imagine if you could code a pigment as such:
> 
> pigment {
> 	function rgb
> 	function {x-floor(x)}
> 	function {y-floor(y)}
> 	function {z-floor(z)}
> 	}
> 
> In other words, you could tell the pigment that it expects to see three
> functions, representing red, green, and blue, respectively. I would
> expect a similar syntax could handle rgbt, rgbf, etc.

I suppose this is probably the only feasible way to go...one alternative 
would be to have vector_function, float_function, color_function, etc as 
separate kinds of functions. There is just something I don't like about 
the multiple-function method, but it would be the easiest and simplest 
way of implementing this feature.


> clip() would have been my first choice, but the token wasn't available.
> I suppose if I'm changing bozo() to rnoise() then I could just add
> "clip" anyway, but it seems a shame to waste a perfectly viable token
> that's more or less clear enough for the purpose.

Well, what if that function gets added to the list of functions useable 
outside of isosurface functions?(I think everything available in 
isofunctions(?) should be available outside them as well, and most of 
what is available outside should be available inside them.)
Since the range keyword is already in use(I know it is used for photons, 
maybe also for other things), you would have the same function with 
different names depending on where it is used(it would be clamp or clip 
outside isofunctions, and range inside them). Bad idea.


> Anyway, more on this in povray.programming, since this has become more
> of a programming discussion.

Ok. I will look at the programming issues in .programming...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message