Smoother splines than catmull-rom?

[davepagurek]

Topic

@dhowe was mentioning to me that sometimes when making shapes with splineVertex, you end up with sharp-looking edges where one wouldn't expect it. e.g. on the right here:

This happens because the bezier equivalent of catmull-rom curves puts control points on either size of a given by going +/- one sixth of the distance from the previous to the next point (scaled up or down by the tightness parameter.)

This means that the bezier control points will be an equal distance on either side, which generally looks OK but breaks down when the distance to the next point is a lot larger than the distance to the previous point.

However, we don't need them to be equidistant. It'll still look continuous as long as they lie on the same line. So one thing we could do make the distance on each side relative to just the distance from the middle to the next or to the previous point.

This gives us something like the following:

I have a little demo here where you can click to add points. When asymmetric tangents are allowed, that's the updated version: https://editor.p5js.org/davepagurek/sketches/TYV8cCxze

Is something like this significant enough to be worth considering? It's a subtle but still breaking change. We've talked in the past about having different splineMode()s, of which this could potentially be one. (Possibly as an addon if scaffolding for adding spline modes is added in core?)

[dhowe]

This is a significant improvement over the current behavior if the goal is to get smooth, intuitive curves. So I'd vote for including this as an option via splineMode. An addon is another option but as its < 20 lines of code, not sure its warranted.

[LalitNarayanYadav]

This makes sense to me as a meaningful improvement over the current uniform Catmull–Rom behavior. The sharp corners seem to come specifically from enforcing symmetric tangent magnitudes when adjacent segment lengths differ.

Allowing asymmetric tangents, while keeping them collinear, appears to preserve continuity but significantly reduces overshoot in unevenly spaced points. Conceptually this feels close to a centripetal/chordal variant, but implemented at the Bézier control level, which fits well with the existing pipeline.

Given that this is localized and relatively small in scope, exposing it via a new splineMode() (rather than changing the default) seems like a reasonable and low-risk path forward.

[davepagurek]

One other point for having a splineMode is that it could open up space for community addons. This blog post on rounding corners of polygons with circular arcs is one I return to https://www.gorillasun.de/blog/an-algorithm-for-polygons-with-rounded-corners and there is often discussion of Hobby curves (e.g. https://www.jakelow.com/blog/hobby-curves) as something that could be useful too.

There's a question of what a splineMode would look like so that we can swap out implementations without any features breaking, like WebGL rendering. The first thing that comes to mind is setting them up to be functions that convert a set of control points to Bezier control points, although that would force the circular arc one to approximate itself using beziers. Maybe that's a good enough compromise?

A more futureproof API could be to turn a spline segment in p5.Shape into any other p5.Shape segment, so that when we add circular arc support there, that could be a valid output mode too. Currently all of that is internal so it'd need a bit of developer docs.