First of all, thanks for reading my post! I was worried it would be buried.
Not necessarily. Tangents could be set manually via a pop-up much as the TCB parameters can be set currently. Of course, once boundary conditions are implemented as I propose above, it becomes trivial to add handles. (“Trivial” I say, still not a programmer, not the person who would have to go through the process of creating the damn thing.)
In my pseudocode above, adding parabolic waypoints is not substantially more difficult than any other changes. Also, a lot of my own uses of Synfig use parabolic splines, so maybe I’m a little biased. Of course, if for whatever reason they’re difficult to implement, the user can manually calculate the desired tangent.
I don’t have anything specific in mind, but I thought of it when thinking about the boundary conditions associated with linear waypoints. There is no constraint on linear waypoints-- currently or in my proposal-- that forces the derivative to agree on either side of the function. This means that linear waypoints introduce corners, which to me sounds rather “not-so-linear”. I wanted to propose something that would straighten them out so the derivatives agree on either side. Unfortunately, I think this makes the problem significantly more difficult and I can’t match up the number of boundary conditions with the number of variables, so I’m inclined to file it away as a fanciful idea that isn’t worth implementing. The user could still use a “tangent” waypoint and manually set the tangents equal on either side. The downside to this is that the second derivative would likely not vanish in the vicinity of the waypoint, which is what the linear waypoint is supposed to accomplish.
I am familiar with cubic Hermite splines and they are currently used in Synfig. Check back to the first post of this topic. Cubic Hermite splines are, as you say, great for setting the values and first derivatives of arbitrary splines. They are ill-suited, however, for specifying second or third derivatives, both of which I’ve done above.
Let’s work with a concrete example. Suppose we have a spline defined over normalized time (0<t<1) that takes the value 0 at the left end and 1 at the right end. Let’s say we also want the derivative to be zero at the right end and the second derivative to be zero at the left end. This last condition, concerning the second derivative, is one that can’t be handled easily by cubic Hermite splines. The boundary conditions with respect to the derivatives I’ve set correspond to a linear waypoint at the left end and an ease in/out waypoint at the right end, so this isn’t some abstract exercise.
We first have to take two derivatives of all our Hermite splines:
H0’’ = 12t - 6
H1’’ = 6t - 4
H2’’ = -12t + 6
H3’’ = 6t - 2
(I did those in my head. They might be wrong.)
We can still use H0, H2, and H3 to satisfy three of the boundary conditions, but H1’s coefficient remains unknown. In equation form, this is P(t) = 0*H0 + A*H1 + 1*H2 + 0*H3, where A is our unknown coefficient. The second derivative condition is then:
P’‘(0) = 0 = A*H1’’ + H2’’
0 = -4A + 6
A = 3/2
Notice how the algebra is more extensive than usual for cubic Hermite splines. We can scale up or down this result for free, which is nice, but that amounts to programming in several different cases (i.e., how to handle tangent-tangent splines, tangent-linear splines, tangent-parabola splines, ease-parabola splines, etc…). All of this is equivalent to the same amount of work as is required to invert the matrix, as I’ve done in the pseudocode.
If you’d like, I can adjust my pseudocode to output coefficients of cubic Hermite splines. I promise it won’t really offer any advantages.