Sectionable instance for SegTree is not a linear reparameterization.

[fryguybob]

The Sectionable instance for SegTree does not result in a split with a linear reparameterization. This is assumed, however, in at least the default definition of section. Original issue was found here. Given:

s1 :: Located (Trail R2)
s1 = section origS 0 0.25
s2 :: Located (Trail R2)
s2 = section origS 0.25 0.75
s3 :: Located (Trail R2)
s3 = section origS 0.75 1

origS :: Located (Trail R2)
origS = cubicSpline False [origin, 0 ^& 2, 2 ^& 1, 1 ^& 0]

We have s2 located at a point that is not atparam origS 0.25:

ghci> s2
Loc {loc = P (0.0 ^& 2.0), ...
ghci> atParam origS 0.25
P ((-0.240625) ^& 1.7625)

[banx]

Maybe it will make more sense for segTree to redefine parameters according to their lengths. The current model makes little sense of the parameter t in contrast with normal Bezier:

split1 :: Located (Trail R2)
split1 = fst . splitAtParam origS $ 0.75

We can verify that, unlogically, the params for both origS and split1 remain the same:

ghci> split1 `atParam ` 0.25
P ((-0.240625) ^& 1.7625)
ghci> origS `atParam ` 0.25
P ((-0.240625) ^& 1.7625)

In my opinion if the parameter represent the portion of the length, it would be a more logical approach, but on the expense of performance.

[fryguybob]

Unfortunately there is no closed form for converting from a bezier
parameter to a length along the curve. Parameterizing by length or
fraction of length has clear benefits and it would be nice to live in that
world, but I don't think it is a viable one to live in by default. I have
a couple of solutions that I'm working on as I have time, but I think we
can choose to either change the way that trails are parameterized to make
the parameter linear in subdivision or we can just fix the section
function only (a fix with somewhat less complexity).

On Fri, Oct 10, 2014 at 8:58 AM, banx notifications@github.com wrote:

Maybe it will make more sense for segTree to redefine parameters according
to their lengths. The current model makes little sense of the parameter t
in contrast with normal Bezier:

split1 :: Located (Trail R2)split1 = fst . splitAtParam origS $ 0.75

We can verify that, unlogically, the params for both origS and split1
remain the same:

ghci> split1 atParam 0.25
P ((-0.240625) ^& 1.7625)
ghci> origS atParam 0.25
P ((-0.240625) ^& 1.7625)

In my opinion if the parameter represent the portion of the length, it
would be a more logical approach, but on the expense of performance.

—
Reply to this email directly or view it on GitHub
#217 (comment)
.

[banx]

I agree with you, it is a simple math to construct a linear mathematical mapping between segtree and parameters conserving linearly the parameters for the beziers within. However, my concerns regard the meaning of such parameters, and how developers would understand their use. Mathematical existence, while easy, is not always sensical in practical world.