Closed ecurtiss closed 1 month ago
Closing because the stated motivation for this proposal is flawed—merely setting the knot vector to be the keyframes does not fix the issue that we cannot interpolate adjacent points that are equal.
There are two ways we could approach assigning keyframes to control points that do permit equal adjacent points:
This feature is a larger effort than just assigning the knot vector.
I wrote a proof of concept of option 2: https://github.com/ecurtiss/CatRom/tree/keyframes
I modified SegmentFactory
to allow us to supply the distances between points while constructing the segments. This allowed me to a create a separate $n$-dimensional positional spline and 1-dimensional time spline using the distances between the $(n+1)$-dimensional points. Then, each 1-dimensional segment is written in the Chebyshev basis and inverted, allowing us to reparametrize the positional spline by the time coordinate.
It works, but some of the methods act poorly given duplicate points, in particular the SolveCFrame
methods. Also, since the position and time coordinates are linked, the positional spline is different from what you would get with a regular $n$-dimensional spline between the same control points. I still think option 1 is better.
Today, the knots in the knot vector are always proportional to the arc lengths of the segments. However, number-type splines are not often used in this way. For example, one could use a number-type spline to interpolate a scalar value in an animation. In this case, the knots would need to correspond to keyframe times, which is something that the user must supply. In fact, this is precisely what I want to do in the internals of CatRom--use a CatRom to animate a roll angle along the spline. In this case, the knot vector would need to be the knot vector of the original spline.
This improvement would imply having 5 arguments for the constructor (points, alpha, tension, loops, knots), so I propose that the constructor now accept a table.