In article <chrishuff-DDBC53.06140904112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

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

I found the problem, a rather nasty bug in Copy_Spline(). It allocates 
room for the spline data, but doesn't copy the old data to the new 
spline. I have no idea how this wasn't noticed before...the fixed 
version is below(all that was needed was the addition of one line, the 
call to memcpy()). I am still not sure it is right, I have never used 
memcpy() before, but it works. :-)

SPLINE2 * Copy_Spline(SPLINE2 * se)
{
    SPLINE2 * New;
    New = (SPLINE2 *)POV_MALLOC(sizeof(SPLINE2), "spline");
    
    New->SplineEntries = 
POV_MALLOC(se->Number_Of_Entries*sizeof(SPLINE_ENTRY), "spline entry");
    memcpy(New->SplineEntries, se->SplineEntries, 
se->Number_Of_Entries*sizeof(SPLINE_ENTRY));
    
    New->Number_Of_Entries = se->Number_Of_Entries;
    New->Type = se->Type;
    return New;
}

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

Chris Huff wrote in message ...
>I found the problem, a rather nasty bug in Copy_Spline(). It allocates
>room for the spline data, but doesn't copy the old data to the new
>spline. I have no idea how this wasn't noticed before...the fixed
>version is below(all that was needed was the addition of one line, the
>call to memcpy()). I am still not sure it is right, I have never used
>memcpy() before, but it works. :-)


Thanks!

--
Mark

Post a reply to this message

Chris Huff wrote in message ...
>In article <3a03ab54$1@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>
>(got a better name for the last one? "all"?)


"all" makes more sense than "grey".

>
>> I'm going to be removing the limit on the number of points in a spline,
>
>There is a limit? I hadn't noticed...


The limit is 256 points -- enough for most uses, but why have a limit when
there doesn't need to be one?

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


This might be very difficult to implement -- there are enough problems with
the spline syntax as it is.

--
Mark

Post a reply to this message

That worked much better. Thanks for the assist.

Mark Wagner wrote:
> 
> Try the links from my POV-Ray downloads page to see if they work for you.
> 
> http://www.geocities.com/rengaw03/povray.html
> 
> --
> Mark

Post a reply to this message

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

> "all" makes more sense than "grey".

That is what I finally implemented it as. It took me a while to figure 
out how to allow rgb, red, green, and blue to be used, though.


> The limit is 256 points -- enough for most uses, but why have a limit 
> when there doesn't need to be one?

It looks to me like that was just a stopgap measure...it looks like you 
could implement it mostly by adding code to the Insert_Spline_Entry() 
function.
I don't have any experience with growing dynamically allocated 
arrays...I tend to use linked lists for everything.


> >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.
> This might be very difficult to implement -- there are enough 
> problems with the spline syntax as it is.

I think could get it working with functions, but I have no idea how to 
do the array like syntax...
INT spline_points(SPLINE_IDENT) Retrieves the number of points in the 
spline.
EXPRESS get_spline_point(INT_INDEX) Returns the corresponding point on 
the spline.

BTW, I implemented the SPLINE_IDENT(T, TYPE) syntax. You can now do 
something like this:
#declare Spl = spline {linear_spline ...}

#declare Val1 = Spl(T);
#declare Val2 = Spl(T, cubic_spline);
#declare Val3 = Spl(T, quadratic_spline);

I will send you the code soon.

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

In article <chrishuff-AE6B1C.09490803112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

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

I've found a couple more bugs, for example, Insert_Spline_Entry() took a 
vector and tried to pass 5 float values through it. I changed that to an 
expression... However, it might be a good idea to have separate 
Insert_Spline_Vector_Entry() and maybe Insert_Spline_Float_Entry() 
functions for ease of use in other code.
I also cleaned up a lot of the code, mostly just reformatting it, but 
partly rewriting some functions. And I fixed some typos in the 
comments...:-)
I plan on doing more, but I thought you would like to have what I have 
done so far. I hope this is helpful in the work you are doing.
The spline code changes are here:
http://homepage.mac.com/chrishuff/mpovplus/splines.zip

I will upload the curves post_process patch soon.

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

Mark Wagner wrote:
> 
> Chris Huff wrote in message ...
> >In article <3a03ab54$1@news.povray.org>, "Mark Wagner"
> ><mar### [at] gtenet> wrote:
> >
> >(got a better name for the last one? "all"?)
> 
> "all" makes more sense than "grey".
> 
	I think it depends on what the spline does exactly: is it the same as:
rgb SPLINE, SPLINE, SPLINE

	Or does it only change the brightness? A good thing to add too:
spline-based manipulations on hue and saturation...


-- 

* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy.    * http://www.enst.fr/~jberger
*********************************

Post a reply to this message

<Jer### [at] enstfr> wrote:

> > "all" makes more sense than "grey".
> 	I think it depends on what the spline does exactly: is it the same as:
> rgb SPLINE, SPLINE, SPLINE
> 	Or does it only change the brightness?

It uses the same spline to adjust each channel. The current value of the 
channel is taken as the "t" value of the spline, and the result of the 
spline is used as the new value for the channel.


> A good thing to add too: spline-based manipulations on hue and 
> saturation...

Not as a special feature of the spline patch...just use a rgb_to_hsl 
filter, then use the ordinary curves filter to adjust hue or saturation, 
then use hsl_to_rgb to get the corrected image back. More flexible, less 
complicated, and you can combine it with other things to get special 
effects. And I *am* planning to write these conversion filters...as soon 
as I figure out the math. I've found lots of information about 
converting between color spaces, but little or nothing about the actual 
equations used to convert between rgb and hsl. That, or I'm just not 
recognizing it when I see it...

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

In article <chrishuff-2DD880.12353405112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> ...as soon as I figure out the math. I've found lots of information 
> about converting between color spaces, but little or nothing about 
> the actual equations used to convert between rgb and hsl. That, or 
> I'm just not recognizing it when I see it...

Never mind, I just came across a couple files Nathan sent me which 
should do everything that I need. I had set them aside and completely 
forgotten about them...

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

Chris Huff wrote in message ...
>In article <3a04ed21@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>> The limit is 256 points -- enough for most uses, but why have a limit
>> when there doesn't need to be one?
>
>It looks to me like that was just a stopgap measure...it looks like you
>could implement it mostly by adding code to the Insert_Spline_Entry()
>function.
>I don't have any experience with growing dynamically allocated
>arrays...I tend to use linked lists for everything.


I've already got the code for this written -- it's just a matter of copying
it from my personal version to SkyPOV.

>> >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.
>> This might be very difficult to implement -- there are enough
>> problems with the spline syntax as it is.
>
>I think could get it working with functions, but I have no idea how to
>do the array like syntax...
>INT spline_points(SPLINE_IDENT) Retrieves the number of points in the
>spline.
>EXPRESS get_spline_point(INT_INDEX) Returns the corresponding point on
>the spline.


I think that, usage-wise, it would be better to use the array syntax.  This
would allow points to be changed and read using a single syntax.

>BTW, I implemented the SPLINE_IDENT(T, TYPE) syntax. You can now do
>something like this:
>#declare Spl = spline {linear_spline ...}
>
>#declare Val1 = Spl(T);
>#declare Val2 = Spl(T, cubic_spline);
>#declare Val3 = Spl(T, quadratic_spline);
>
>I will send you the code soon.


Thanks!

Post a reply to this message