Am 30.04.2017 um 17:42 schrieb Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>> I tried all sorts of tricks to try and eliminate the problem, but no luck...
>>
> 
> I ran the scene in the latest(?) 3.7.1 beta 5, as well as in my original 3.70
> install; same problems in both.
> 
> IIRC, sphere_sweeps using a cubic spline have been problematic for a *long*
> time. If it were possible to do, I would suggest adding the 'natural_spline'
> type to the sphere_sweep code. I don't know the math differences between natural
> and cubic splines (or if one is mathematically 'simpler' than the other) but it
> might give us at least one way to make curvy sphere_sweeps that can be
> CSG-differenced from another object.

Mathematically, "natural splines" are only marginally different from
what POV-Ray calls "cubic splines": Both are 3rd order polynomial
splines, i.e. piecewise defined functions mapping a single scalar
parameter to a point in N-dimensional space, with each piece having the form

    F(t) = A[3] * t^3 + A[2] * t^2 + A[1] * t + A[0]

with A[i] being N-dimensional constants (N=3 in the case of POV-Ray's
splines).

I would therefore not expect "natural splines" to have any advantage
over the so-called "cubic splines" (except possibly being more intuitive
to control, depending on user and use case). To the contrary, "natural
splines" have fewer degrees of freedom, allowing less control over the
direction and curvature at the start and end of the spline.

Technically speaking, all 3rd order polynomial splines are cubic
splines. This also includes POV-Ray's "bezier splines", which behind the
scenes differ from the other types only in that they provide even more
degrees of freedom, allowing for sudden changes in both direction and
curvature between the pieces of the spline.

Post a reply to this message