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

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

I'm having a hard time getting it to work though...I suspect the problem 
is in my parsing code, though I'm not sure why it is misbehaving. 
Anyway, this is the syntax I am planning to use(I am currently working 
on the first form):
curves {rgb RED_SPLINE, GREEN_SPLINE, BLUE_SPLINE}
curves {red RED_SPLINE}
curves {green GREEN_SPLINE}
curves {blue BLUE_SPLINE}
curves {gray GRAY_SPLINE}
(got a better name for the last one? "all"?)

When I add color space conversion filters, you will be able to adjust 
other types with these filters(convert to another color space, modify 
the correct channel, convert back to rgb).


> I'm going to be removing the limit on the number of points in a spline, 

There is a limit? I hadn't noticed...


> and making it possible to use the points from one spline as the basis 
> for another spline, like:
> #declare Spline2 = spline{ Spline 1,<2,2,2> etc.}
> Right now you can't do that.

I noticed the Parse_Spline() function had the ability to take an 
identifier to create a copy of the spline, but also had a bug which made 
that useless when no new points were defined. I think it was intended to 
work the way you describe, allowing new points to be inserted.

Also, it would be useful if you could access the control points, with 
functions that behave similar to the array functions and an array-like 
syntax.

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