





 
 




 
 


I'm using SphereSweep_Approx (SSWP_QUADRATIC_SPLINE ....)
to draw some SVG data, and I noticed that the control point is intersected by
the curve, whereas in SVG, they show the curve being inside of the convex hull
of control points.
Is this intentional behaviour of the macros?
Am I doing something wrong, using it improperly?
Would it be possible to have an additional, alternative quadratic spline added?
https://developer.mozilla.org/enUS/docs/Web/SVG/Tutorial/Paths
Thanks! :)
#version 3.8;
global_settings {assumed_gamma 1.0}
camera {
location <0.5, 0.5, 1.25>
right x*image_width/image_height
up y
look_at <0.5, 0.5, 0>
}
light_source {<3, 2, 10> rgb 1}
sky_sphere {pigment {rgb <0.3, 0.3, 0.75>}}
#include "BezierInclude.inc"
#include "spheresweep.inc"
#declare P1 = <0, 0, 0>;
#declare P2 = <0.5, 1.0, 0>;
#declare P3 = <1, 0, 0>;
object {
SphereSweep_Approx (SSWP_QUADRATIC_SPLINE, array {P1, P2, P3}, array {Line,
Line, Line}, 100, 0)
pigment {rgb <0, 0, 0>}
}
Point (P1, 2, texture {pigment {rgb <1, 0, 0>}})
Point (P2, 2, texture {pigment {rgb <1, 0, 0>}})
Point (P3, 2, texture {pigment {rgb <1, 0, 0>}})
cylinder { P1, P2, Line pigment {rgb <1, 0, 0>}}
cylinder { P2, P3, Line pigment {rgb <1, 0, 0>}}
Post a reply to this message


 
 




 
 


On 20200830 8:04 PM (4), Bald Eagle wrote:
> I'm using SphereSweep_Approx (SSWP_QUADRATIC_SPLINE ....)
> to draw some SVG data, and I noticed that the control point is intersected by
> the curve, whereas in SVG, they show the curve being inside of the convex hull
> of control points.
> Is this intentional behaviour of the macros?
> Am I doing something wrong, using it improperly?
SVG's quadratic curve uses 2nd order Bézier splines, while
SSWP_QUADRATIC_SPLINE uses POVRay's builtin quadratic spline type,
which connects the control points with parabolic curves. They are two
different spline types.
To get an SVG style quadratic curve, you would need to use
SSWP_BEZIER_SPLINE, and clone the middle control point:
SphereSweep_Approx
( SSWP_BEZIER_SPLINE,
array { P1, P2, P2, P3 },
array { Line, Line, Line, Line}, 100, 0
)
Unfortunately, the Bézier algorithm in SphereSweep 1.2 does not handle
such cloning properly. You'll need to replace macro SSwp__Bezier_calc()
in spheresweep.inc with the following:
[BEGIN CODE]
#macro SSwp__Bezier_calc (T, pv_Points, Radii, s_Macro)
#local sswp_NPts = dimension_size (pv_Points, 1);
#local sswp_Pt0 = floor (T / 4) * 4; // index of 1st point in segment
#local sswp_T0 = (T  sswp_Pt0) / 3; // t, within segment
#local sswp_T1 = 1  sswp_T0; // 1  t, within segment
#if (sswp_T0 > 1  T < 0  T >= sswp_NPts)
SSwp__Report
( s_Macro,
concat
( "SSwp__Bezier_calc() was called with T = ", str (T, 0, 1),
" for ", str (sswp_NPts, 0, 0), " points."
)
)
#end
#local sswp_MaxR = dimension_size (Radii, 1)  1;
#local sswp_Pt = <0,0,0>
+ pow (sswp_T1, 3) * pv_Points [sswp_Pt0]
+ 3 * pow (sswp_T1, 2) * sswp_T0 * pv_Points [sswp_Pt0+1]
+ 3 * sswp_T1 * pow (sswp_T0, 2) * pv_Points [sswp_Pt0+2]
+ pow (sswp_T0, 3) * pv_Points [sswp_Pt0+3];
#local sswp_R =
pow (sswp_T1, 3) * Radii [min (sswp_Pt0, sswp_MaxR)]
+ 3 * pow (sswp_T1, 2) * sswp_T0 * Radii [min (sswp_Pt0+1, sswp_MaxR)]
+ 3 * sswp_T1 * pow (sswp_T0, 2) * Radii [min (sswp_Pt0+2, sswp_MaxR)]
+ pow (sswp_T0, 3) * Radii [min (sswp_Pt0+3, sswp_MaxR)];
<sswp_Pt.x, sswp_Pt.y, sswp_Pt.z, sswp_R>
#end
[END CODE]
> Would it be possible to have an additional, alternative quadratic spline added?
It is under consideration. In any case, the Bézier algorithm patch will
definitely be in the next update.
> Thanks! :)
No problem!
Post a reply to this message


 
 




 
 


Cousin Ricky <ric### [at] yahoocom> wrote:
> SVG's quadratic curve uses 2nd order Bézier splines, while
> SSWP_QUADRATIC_SPLINE uses POVRay's builtin quadratic spline type,
> which connects the control points with parabolic curves. They are two
> different spline types.
I /thought/ that might be the case.
> To get an SVG style quadratic curve, you would need to use
> SSWP_BEZIER_SPLINE, and clone the middle control point:
> Unfortunately, the Bézier algorithm in SphereSweep 1.2 does not handle
> such cloning properly. You'll need to replace macro SSwp__Bezier_calc()
> in spheresweep.inc with the following:
Weird, but glad you had a quick fix all ready to plug in. :)
> It is under consideration. In any case, the Bézier algorithm patch will
> definitely be in the next update.
Thanks very much  that fixed the bumpiness of the outlines.
Now I have to figure out why the SVG splines render ohsovery nicely in a
browser, but have all sorts of apparently extraneous lines and scribble when
converted over to sphere sweeps...
Post a reply to this message


 
 




 
 


On 20200831 7:30 PM (4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
>> To get an SVG style quadratic curve, you would need to use
>> SSWP_BEZIER_SPLINE, and clone the middle control point:
>
>> Unfortunately, the Bézier algorithm in SphereSweep 1.2 does not handle
>> such cloning properly. You'll need to replace macro SSwp__Bezier_calc()
>> in spheresweep.inc with the following:
>
> Weird, but glad you had a quick fix all ready to plug in. :)
It's been sitting on the shelf, while I try to figure out how to
reproduce one of Hgpovray's sphere_sweep features using official
POVRay. But now that this graceful degradation failure (that's "bug"
in English) has turned up, I'm moving the patch up in the queue. (An
update to AndroidRobot has priority, though. The Google keeps changing
things.)
> Thanks very much  that fixed the bumpiness of the outlines.
> Now I have to figure out why the SVG splines render ohsovery nicely in a
> browser, but have all sorts of apparently extraneous lines and scribble when
> converted over to sphere sweeps...
Such problems are why I wrote the SphereSweep module in the first place.
Post a reply to this message


 
 


From: Cousin Ricky
Subject: Re: Sphere Sweep 1.2 Quadratic spline question  STOP THE PRESS!
Date: 8 Sep 2020 03:07:11
Message: <5f572d9f$1@news.povray.org>



 
 


On 20200831 1:22 PM (4), Cousin Ricky wrote:
>
> To get an SVG style quadratic curve, you would need to use
> SSWP_BEZIER_SPLINE, and clone the middle control point:
>
> SphereSweep_Approx
> ( SSWP_BEZIER_SPLINE,
> array { P1, P2, P2, P3 },
> array { Line, Line, Line, Line}, 100, 0
> )
That is wrong! Something didn't look right about the curve, so I went
back and doublechecked the Bézier theory. The correct solution is this:
SphereSweep_Approx
( SSWP_BEZIER_SPLINE,
array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 },
array { Line, Line, Line, Line}, 100, 0
)
I will post an example illustration in p.b.i.
Post a reply to this message


 
 




 
 


Cousin Ricky <ric### [at] yahoocom> wrote:
> That is wrong! Something didn't look right about the curve, so I went
> back and doublechecked the Bézier theory. The correct solution is this:
>
> SphereSweep_Approx
> ( SSWP_BEZIER_SPLINE,
> array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 },
> array { Line, Line, Line, Line}, 100, 0
> )
>
> I will post an example illustration in p.b.i.
Without picking through the underlying code of the spheresweep, I'll just say
that the curve indeed looks correct, but (now, to me,)
array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 }
does not.
Since a Bezier spline uses some fraction of all of the control points across the
entire spline (except for the absolute endpoints), shouldn't there be a P3 and a
P1 term in there  or does that somehow get (partially) accounted for under the
hood?
I was too tired to work out the correct derivatives of the Bernstein polynomial
terms the other day, and I have things to do before I will have a chance to look
into this any further.
Just asking to clarify and triple check. ;)
Post a reply to this message


 
 


From: Cousin Ricky
Subject: Re: Sphere Sweep 1.2 Quadratic spline question  STOP THE PRESS!
Date: 8 Sep 2020 14:02:50
Message: <5f57c74a$1@news.povray.org>



 
 


On 20200908 1:36 PM (4), Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
>> That is wrong! Something didn't look right about the curve, so I went
>> back and doublechecked the Bézier theory. The correct solution is this:
>>
>> SphereSweep_Approx
>> ( SSWP_BEZIER_SPLINE,
>> array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 },
>> array { Line, Line, Line, Line}, 100, 0
>> )
>>
>> I will post an example illustration in p.b.i.
>
> Without picking through the underlying code of the spheresweep, I'll just say
> that the curve indeed looks correct, but (now, to me,)
> array { P1, P2 * 2/3 + P1 / 3, P2 * 2/3 + P3 / 3, P3 }
> does not.
>
> Since a Bezier spline uses some fraction of all of the control points across the
> entire spline (except for the absolute endpoints), shouldn't there be a P3 and a
> P1 term in there  or does that somehow get (partially) accounted for under the
> hood?
I don't know what you mean; all 3 terms are in the array. The 2nd term
is 2/3 of the way from P1 to P2, and the 3rd term is 2/3 of the way from
P3 to P2.
Under the hood, the formula draws from all 4 control points, so each of
the 3 quadratic points gets its input.
Post a reply to this message


 
 




 
 


What I mean is:
The "usual" array is {P1, P2, P3, P4}
The initial suggestion was to do:
> > array { P1, P2, P2, P3 },
(seemed totally reasonable to me, and seemed to give good results)
Which is just P3 = P2.
Now you're saying:
> SphereSweep_Approx
> ( SSWP_BEZIER_SPLINE,
array {
P1,
P1 * 1/3 + P2 * 2/3,
P2 * 2/3 + P3 * 1/3,
P3 },
So what I'm asking is: why aren't ALL 3 control points appearing as terms in the
equations for each of the array elements?
I'm not doubting that the correction you're proposing is right, I'd just like
you to articulate, for my own benefit, why, in light of the corrections to the
2nd and 3rd elements, the first and last elements are still solitary control
points, and why the second doesn't have a term for P3, and the third doesn't
have a term for P1.
Post a reply to this message


 
 


From: Cousin Ricky
Subject: Re: Sphere Sweep 1.2 Quadratic spline question  STOP THE PRESS!
Date: 8 Sep 2020 17:09:40
Message: <5f57f314$1@news.povray.org>



 
 


On 20200908 2:32 PM (4), Bald Eagle wrote:
>
> The initial suggestion was to do:
>>> array { P1, P2, P2, P3 },
> (seemed totally reasonable to me, and seemed to give good results)
Seemed totally reasonable to me, too, which is why I made that mistake.
But human brains are notoriously bad at math.
> So what I'm asking is: why aren't ALL 3 control points appearing as terms in the
> equations for each of the array elements?
>
> I'm not doubting that the correction you're proposing is right, I'd just like
> you to articulate, for my own benefit, why, in light of the corrections to the
> 2nd and 3rd elements, the first and last elements are still solitary control
> points, and why the second doesn't have a term for P3, and the third doesn't
> have a term for P1.
The end points are the same for both methods, right? So why would they
need any influence from the other points?
As for the 2nd and 3rd points, I think they are best explained with an
illustration:
https://commons.wikimedia.org/wiki/File:Quadratic_to_cubic_Bezier_curve.svg
P1 and P3 are the gray circles, and P2 is the magenta circle. The 2nd
and 3rd cubic points are the yellow circles, and the quadratic curve is
the yellow curve with the black border. You can see that the 2nd point
is on the line between P1 and P2, which needs no input from P3; and the
3rd point is on the line between P2 and P3, which needs no input from P1.
Each point on the cubic Bézier curve is computed as:
P(t) = (1t)³*P1 + 3*(1t)²*t*P2 + 3*(1t)*t²*P3 + t³*P4
As this one formula includes all 4 control points, all the curve needs
is for each of the quadratic points to be accounted for in _at least_
one cubic point. There is simply no need for each of the cubic points
to include all 3 of the quadratic points.
Post a reply to this message


 
 




 
 


Cousin Ricky <ric### [at] yahoocom> wrote:
> The end points are the same for both methods, right? So why would they
> need any influence from the other points?
See below.
> https://commons.wikimedia.org/wiki/File:Quadratic_to_cubic_Bezier_curve.svg
> You can see that the 2nd point
> is on the line between P1 and P2, which needs no input from P3; and the
> 3rd point is on the line between P2 and P3, which needs no input from P1.
>
> Each point on the cubic Bézier curve is computed as:
> P(t) = (1t)³*P1 + 3*(1t)²*t*P2 + 3*(1t)*t²*P3 + t³*P4
Yeah  I got it now, it "clicked".
The fatigue was like a brick wall and any information was just bouncing off like
ping pong balls.
My tired brain was comingling the Bernstein polynomial terms for the control
points with your calculation of the coordinates OF the control points for the
array.
Thanks, Richard  all is clear now.
It works just fine in the SVG conversion too. Doesn't look materially different
from the wrong way  likely because the control points are all so close together
and there's not much overall "curve" to the spline.
Post a reply to this message


 
 




 

