POV-Ray : Newsgroups : povray.beta-test : cubic spline bug Server Time
29 Jul 2024 18:16:24 EDT (-0400)
  cubic spline bug (Message 1 to 7 of 7)  
From:
Subject: cubic spline bug
Date: 16 Apr 2002 07:01:29
Message: <4j0obu8bqevuf7spm93rlj2nl7rp8tlkb7@4ax.com>
POV 3.5 RC1 icl on WinNT Sp 6 PII 233 with 128 MB

According to documentation "Val_1, Val_2, etc, are the value of the spline
parameter at each specific point. " (6.1.9). So when there is different point
for t=0 and t=1 than I expect that Spline(0) is different than Spline(1).
Below example shows that for cubic spline it is not true. When I parse below
script as is then it stops at last macro call and tells that both points are
the same. When I comment last line it parses ok. When prepare spline first,
and convert later (at macro call) there is everything ok as first part shows.

// START

#macro List() 0 <1,1,0> 1 <3,8,0> 2 <7,7,0> 3 <7,3,0> #end
#macro Test(S) cylinder{ S(0) S(1) 1 } #end

#local Spline = spline { List() };

Test( spline{ Spline linear_spline    } ) 
Test( spline{ Spline quadratic_spline } )
Test( spline{ Spline natural_spline   } )
Test( spline{ Spline cubic_spline     } )

Test( spline{ linear_spline    List() } ) 
Test( spline{ quadratic_spline List() } )
Test( spline{ natural_spline   List() } )
Test( spline{ cubic_spline     List() } )

// END

ABX


Post a reply to this message

From:
Subject: Re: cubic spline bug
Date: 16 Apr 2002 07:08:30
Message: <c91obucinpo98opr6qqbineln3kiof8pr0@4ax.com>

wrote:
> When prepare spline first,
> and convert later (at macro call) there is everything ok

There is becouse new type is ignored and spline is still linear
(I forgot in last known bug list my report
http://news.povray.org/m7fq3u41ctia9e6i3tbnlstn6ek739vpke%404ax.com
is part of "Problems still being worked on")

ABX


Post a reply to this message

From:
Subject: Re: cubic spline bug
Date: 16 Apr 2002 07:32:22
Message: <nm2obuk1qt6vee0i0v356fk0clph21a32c@4ax.com>

wrote:

> Below example shows that for cubic spline it is not true.

Moreover when I tried forcing type conversion at evaluation time with:

  #macro Test(S) cylinder{ S(0,cubic_spline) S(1,cubic_spline) 1 } #end

I have got strange error:

  cylinder{ S(0,cubic_spline <----ERROR
  Parse Error: linear_spline, quadratic_spline, natural_spline,
  or cubic_spline expected.

ABX


Post a reply to this message

From:
Subject: Re: cubic spline bug
Date: 16 Apr 2002 08:26:07
Message: <706obu0m93oirddgqevd0p2a3bovfaqd6g@4ax.com>

wrote:
> Below example shows that for cubic spline it is not true. 

Perhaps something related:
http://news.povray.org/povray.beta-test/22758/

ABX


Post a reply to this message

From: Mark Wagner
Subject: Re: cubic spline bug
Date: 17 Apr 2002 01:00:33
Message: <3cbd0171@news.povray.org>

<4j0obu8bqevuf7spm93rlj2nl7rp8tlkb7@4ax.com>...
>POV 3.5 RC1 icl on WinNT Sp 6 PII 233 with 128 MB
>
>According to documentation "Val_1, Val_2, etc, are the value of the spline
>parameter at each specific point. " (6.1.9). So when there is different
point
>for t=0 and t=1 than I expect that Spline(0) is different than Spline(1).
>Below example shows that for cubic spline it is not true.
>// START
>
>#macro List() 0 <1,1,0> 1 <3,8,0> 2 <7,7,0> 3 <7,3,0> #end
>#macro Test(S) cylinder{ S(0) S(1) 1 } #end
>
>#local Spline = spline { List() };


>Test( spline{ Spline cubic_spline     } )


>Test( spline{ cubic_spline     List() } )
>
>// END

This is because of the way cubic_splines (aka Catmull-Rom splines) are
defined: the first and last points are tangents, rather than points on the
spline.  As a result, cubic_spline interpolation is only valid between the
second and next-to-last points.  For all other spline types, interpolation
is valid from the first point to the last point.  For t-values outside the
valid range, POV-Ray returns the value of the nearest valid point.  As a
result,

>Test( spline{ cubic_spline     0 <1,1,0> 1 <3,8,0> 2 <7,7,0> 3 <7,3,0> } )

uses the points S(0) = <3,8,0> and S(1) = <3,8,0>, since the first valid
point on a cubic_spline is the second one in the list.

Whoever's maintaining the relevant part of the documentation should make a
note of this.


--
Mark

The Universe is expanding.
The budget for its exploration is shrinking.


Post a reply to this message

From: ingo
Subject: Re: cubic spline bug
Date: 17 Apr 2002 03:44:56
Message: <Xns91F3639B2C106seed7@povray.org>
in news:3cbd0171@news.povray.org Mark Wagner wrote:

> Whoever's maintaining the relevant part of the documentation should
> make a note of this.

Will be added.

Ingo


Post a reply to this message

From: David Wallace
Subject: Re: cubic spline bug
Date: 19 Apr 2002 18:26:13
Message: <3cc09985@news.povray.org>
"Mark Wagner" <mar### [at] gtenet> wrote in message
news:3cbd0171@news.povray.org...

> <4j0obu8bqevuf7spm93rlj2nl7rp8tlkb7@4ax.com>...
> >POV 3.5 RC1 icl on WinNT Sp 6 PII 233 with 128 MB
> >
> >According to documentation "Val_1, Val_2, etc, are the value of the
spline
> >parameter at each specific point. " (6.1.9). So when there is different
> point
> >for t=0 and t=1 than I expect that Spline(0) is different than Spline(1).
> >Below example shows that for cubic spline it is not true.
> >// START
> >
> >#macro List() 0 <1,1,0> 1 <3,8,0> 2 <7,7,0> 3 <7,3,0> #end
> >#macro Test(S) cylinder{ S(0) S(1) 1 } #end
> >
> >#local Spline = spline { List() };
>
>
> >Test( spline{ Spline cubic_spline     } )
>
>
> >Test( spline{ cubic_spline     List() } )
> >
> >// END
>
> This is because of the way cubic_splines (aka Catmull-Rom splines) are
> defined: the first and last points are tangents, rather than points on the
> spline.  As a result, cubic_spline interpolation is only valid between the
> second and next-to-last points.  For all other spline types, interpolation
> is valid from the first point to the last point.  For t-values outside the
> valid range, POV-Ray returns the value of the nearest valid point.  As a
> result,
>
> >Test( spline{ cubic_spline     0 <1,1,0> 1 <3,8,0> 2 <7,7,0> 3
<7,3,0> } )
>
> uses the points S(0) = <3,8,0> and S(1) = <3,8,0>, since the first valid
> point on a cubic_spline is the second one in the list.

Yep, I ran into a problem on the other end.  This spline,

#declare splArm = spline {
 cubic_spline
 -1, <-1, 1, 0>
 0, <0, 0, 0>
 0.3, <1, -.5, -1>
 1.0, <1.3, 1.0, 1.5>
 //1.1, <1.1, 1.2, 1.7>
 1.2, <1, 0.5, 2.0>
}

gave me a lot of headaches with the following macro:

#macro splDir(spl, ps) vnormalize(spl(ps+1e-4)-spl(ps-1e-4)) #end

splDir(splArm, 1.02) gives a <0,0,0> result which caused a error further
afield.  When I added the line which I have commented out here, the problem
went away.

>
> Whoever's maintaining the relevant part of the documentation should make a
> note of this.
>
>
> --
> Mark
>
> The Universe is expanding.
> The budget for its exploration is shrinking.
>
>
>


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.