In article <3a025559$1@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> >I am going to make a post_process filter which uses a spline to adjust
> >color values...is this what you are talking about?
> Yes.

I will send you the code as soon as it is tested.


> >You mean it picks a random pixel each time? Another thing that might be
> >nice: some kind of "progressive" antialiasing, that renders the image
> >without antialiasing and then makes several "refinement" passes.
> That's going to be part of the system, since I can't do antialiasing with
> just one pixel.

Good. :-)


> I don't have it implemented yet, but this will be for the "poly" 
> object type.  It's much easier to enter a formula for a 7th-order 
> polynomial as a formula than as a string of a hundred coefficients.

Oh, I thought this was for something else...this seems rather redundant, 
since you can just use isosurfaces to do the same thing, and 
often(usually?) with faster rendering.


> >I would suggest using one of the spline patches...less duplicate code,
> >more standardized, etc...
> 
> This is going to be an improvement on the spline{} syntax.

Oh...
Ok, what improvements are you thinking of? More spline types, the 
ability to choose what kind of spline to use at evaluation time?

By the second, I mean something like this:
#declare Spline = spline {...the usual spline stuff...}

#declare Val1 = Spline(XVal);
#declare Val2 = Spline(XVal, cubic_spline);
#declare Val3 = Spline(XVal, linear_spline);

Another wild idea that might be useful: allow splines to be used as 
color maps. :-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message