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/en-US/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 2020-08-30 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 POV-Ray's built-in 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 POV-Ray's built-in 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 oh-so-very 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 2020-08-31 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 
POV-Ray.  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 oh-so-very 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

On 2020-08-31 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 double-checked 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 double-checked 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

On 2020-09-08 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 double-checked 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

On 2020-09-08 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) = (1-t)³*P1 + 3*(1-t)²*t*P2 + 3*(1-t)*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) = (1-t)³*P1 + 3*(1-t)²*t*P2 + 3*(1-t)*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