Someone once remarked to me that tweening with Bezier curves seemed to have a ‘natural’ easing. In some cases, a sprite moving along the curve might appear to move slowly out of the first control point, noticeably speeding up moving into the last control point.
The issue is not easing, but parameterization. The subject of parameterization has been dealt with in detail in this blog and in TechNotes, although mostly for composite curves. The Singularity Bezier curves now support approximate arc-length parameterization (implemented in the base Parametric class).
A person drawing a quadratic Bezier with curveTo() might be inclined to state that the point corresponding to t=0.5 was exactly halfway along the length of the Bezier curve. If markers were distributed at say t=0, t=0.1, t=0.2 … t=1, one might expect them to be uniformly distributed along the curve.
In fact, the marker distribution depends on the curve’s geometric constraints (control point placement). This is illustrated in the following screen shot,
The blue markers illustrate marker placement at natural (t-parameter) intervals, with a delta of 0.1 . The green markers are placed at uniform normalized arc-length, i.e. s=0, s=0.1, s=0.2 … s=1. Notice that the blue markers are closer together near the left-most part of the curve (knots were placed left-to-right) and farther apart near the right-most part of the curve.
A sprite animated along this curve using the natural parameterization would appear to move faster as it approached the final control point, leading to the impression of implicit easing.
The online demo may be viewed here. I should point out that the algorithm for arc-length parameterization is based on spline interpolation and is only approximate. There are some extreme conditions (highly acute control cage angles) in which the green marker spread is very slightly inconsistent. Recent improvements in the arcLengthAt() estimation have alleviated this issue and the interpolation will be eliminated in an future release of the Singularity package.
Thanks to Zeh Fernando for his help in some initial testing!
The Algorithmist 
Nice topic there! This is a common problem in curves.. My Catmull tween don’t make such curve steps equals.. I’m thinking a way to make it dynamic as the path tween can be edited during tweening..
I’m afraid that it costs some CPU haha… maybe I’ll let this feature available just to static curves..
Yes, Eduardo, it does cost CPU … and this algorithm is only approximate. It costs more CPU to make it more accurate. I’ll illustrate this in a future release so that I can show the difference between natural, approximate arc-length, and highly accurate arc-length parameterization and the computational tradeoffs. I hope this will be a useful tool for computational geometry students.
regards,
– jim
would it not be easier to analytically solve integral for every piece, and then re-calculate for combined curve? these cubic splines are simple polys, the exact expressions for s(t) can’t possibly be more of overhead than integrating curves numerically.
…on the other hand, I have just tried that with MathCAD and it did not find symbolic expression for s(t). huh. such a simple problem, one would think 😦
In general, it’s an elliptic integral – no analytic solution and you would change your mind really quick if you saw the analytic formula for a quad. Bezier 🙂
Not such a simple problem.