Show HN: A new spline

Well, there's my thesis :)

There has been some work on this. Apple's Pages uses an implementation of the Hobby spline, demonstrating that it can be used in real consumer products. I think if you put these two side-by-side though, mine comes out quite a bit better; when you push the Hobby spline you get curvature extrema quite a distance from the control points, and mine doesn't do that.

Hobby's work has of course been an inspiration for mine for a long time, and it holds up academically quite well too - it has just the right blend of practical and aesthetic considerations and theoretical analysis; his solver runs in linear time and there's a proof it always converges (as long as tension values are within a reasonable range).

And of course there's the k-Curve work from Adobe. I think it is a step forward from Hobby in some ways (more robust) but a step back in others (it's not as smooth and most especially doesn't form true inflections).

I'll add curvature combs in a future revision. I'll also point out that you can see a curvature plot of the underlying 2-parameter curve family by playing with beztoy.html in the linked github repo, which is one of the main ways I evaluated this.

Higher degree Béziers illustrate the "curse of too many parameters." Yes, they're very expressive, and yes you can have very high degrees of continuity, but it's also easy to make very wiggly or lumpy curves. I don't know of anyone who uses them, certainly not for font design.

Actually manipulating higher-degree Bézier curves (or B splines, etc.) is a pain in the butt. In theory you can make any possible shape, but in practice it’s very difficult to get it to do what you want using the standard provided user interface.

> weights of the tangent vectors

Is this a synonym for curvature? In theory you could directly specify the curvature at a knot.

Or do you mean something more explicitly like weights in NURBS? Those could also conceivably be added, but IMO the hit to human intuition / intelligible UIs makes it not worth the trouble.

They are not very handy because the controls points don't mean much to the user.

Thanks, that's music to my ears! A major focus of this work was making a primitive that would be intuitive and that you could build a good UX around. Considering the nontrivial learning curve for Béziers, I think your report is significant.

Also as someone who's never touched splines before, I found it pretty difficult to replicate. The "a" from the screenshot looks fairly smooth everywhere (except possibly the upper-right outside curve), but I found that unless I got the positioning just right, I could run into some degree of "bumpiness". This may, of course, say more about me than about Raph's new splines :P.

If I wanted to try Raph's prior work on spiro splines for comparison, is there some way to do that that's easier than learning to use Fontforge? (When I last tried Fontforge, it didn't seem to handle hi-DPI screens well...)

You might want to add some basic instructions somewhere too. I had to dig through the source to figure out what some of the keyboard and tool tricks are. Perhaps they are standard in Illustrator or some other tool, but double clicking, shift-clicking, option/alt-clicking, nudging etc... I only figured out by poking around the .js.

Done, thanks for the suggestion.

This is very similar to the "Minimum Energy Curve" fairness metric, which minimizes sum of of bending energy, which in turn is proportional to curvature squared. And, thanks to basic physics, curvature is proportional to the centripetal force given a constant velocity.

The problem with MEC is that it tends to optimize for low tension; for inputs that are not well behaved, it sometimes optimizes for infinitely low tension, ie an infinitely long road. So there are other metrics, like Minimum Variation of Curvature, that work better for actual spline use, even though they have an energy metric that's "worse."

These curves are absolutely useful for path planning. A lot of the literature on "clothoids" from a hundred years or so ago is on transition curves for railroads. The G2 continuity condition basically means that you never have to suddenly turn the steering wheel to follow the curve, it's always moving continuously.

For what it’s worth it makes beautiful sense to me. Both as a motorcyclist and also as someone who has thought a lot about splines.

My favorite spline editor is the Bezigon tool in Macromedia Freehand of yore. It sprang to mind as I read the passages you wrote.

It's likely it could be reworked to not make those spikes. The reason it happens is tricky. The basic curve family (what you get when you don't add explicit tangents) has a π-periodicity in the angles. Essentially it cares about the slope of the tangent but not the signed direction, and reverses the sign as needed. The curvature blending uses the same family but the sign reversals don't always "make sense" in terms of producing a smooth result. It's not obvious it would be better, as what you'd get would be more "twisty," and it's also possible the twistiness would snap as you rotated the handles. So making a direction reversal might be one of the less visually objectionable ways to handle the problem.

This is one of those "deep UX" questions I find fascinating.

What is his company doing?

It's very good, but I think the problem is "too many parameters." In some contexts that's fine (animators are used to it) but in others it might not be ideal. People don't use that spline for font design work; why? The Hobby spline has a tension parameter, which is said to be "very useful" in the paper, but when Apple adapted it for Pages, they left it out of the UI. Was that a mistake, or did they make an informed user experience tradeoff? (Incidentally, I believe tension is in there, as part of the illusion of extensibility, but deeply hidden)

So whether this spline is better for, say, animation, is what I consider a fascinating research question. Hopefully putting it out there will start to get answers.

> Kochanek–Bartels spline

YMMV, but the problem I have is that it generally makes ugly shapes unless you are very skilled/practiced with it and very careful about twiddling parameters, because the control parameters are based on the implementation details of the mathematical tool rather than directly on features of human perception.

There’s basically a mismatch between human-centered goals and the mathematical model of those.

As an analogy, you might think of it like trying to learn how to dance vs. learning how to make a puppet dance by manipulating a control bar with your fingers to pull on its strings. The latter involves more indirection, which makes it harder for novices to get approximately their desired result.

For anyone unfamiliar with this tool, see the image in https://en.wikipedia.org/wiki/Kochanek%E2%80%93Bartels_splin...

I tweaked the language, thanks for pointing that out. Obviously JavaScript is capable of very real systems and many of the potential applications of this work. Regarding the timeline, I'm hoping soon, but it's going to depend on where I want to take this codebase; I still haven't really decided, and it will depend in large part on what kind of interest I see. The multiple subpaths question is of course not a problem with the spline itself but whether the test app has a sophisticated enough document model to manage multiple path objects.

What do you mean by “shape optimization”?

This comment kinda rubs me the wrong way, especially since the author notes that I also want to preserve full ownership of the code so that I can do commercial licensing of code derived from it. If there are many companies that want a curve like this (which means it presumably took non-trivial time and skills to develop), maybe they should come to a commercial agreement with the author?

What is it with pushing people to unpaid labour to make megacorps happy with some fuzzy notion of potential "wide adoption" as the only reward?

> Many companies […] would avoid GPL just avoid any possible litigation

There are so many examples of GPL software being blacklisted by commercial companies and dying out as a result. Linux, Bash, gcc, Blender, Ansible, MySQL, git… It really is quite a graveyard.

In all seriousness, the licensing choice seems very reasonable for someone wishing to partner with commercial companies rather than have their work lifted without royalties.

He considers commercial licensing.

GPL is perfect, we get to play around with it and the author may make money from it. And if it doesn't work, the author can still switch to a more permissive license (MIT, BSD,...), the other way around won't work.

Also worth noting that it is presumably not patented, so nothing prevent companies from rewriting the algorithm.

The author is still able to give out commercial licences to companies, so where is the problem?

Anyone interested is free to obtain a better license aligned with their needs.

Surely the curve function is worth something. Take that something and invest in a non GPL license.

GPL = Share and share alike

A company using the curve function for profit is not sharing. And that is OK, but they should also be paying for that, due to the fact that they are unwilling to pay by contributing more open code.

The open code comes from people who have to eat. It makes perfect sense for closed projects to pay for a suitable license. The author makes mention of all this, indicating commercial license plans.

That's exactly as it should be.

Agree, GPL effectively means non-commercial.

Most companies won't touch GPL code with a barge-pole.

> This is the typical engineer mindset, after having spent years doing something they consider obvious what it is not.

More charitably, this is the way all research prototypes work in any field.

Production vector illustration packages hire a team of people who spend man-years of effort canvassing customers, collecting bug reports, adding features and affordances and refining the user interface, writing documentation, and so on. Someone making a research prototype where the UI per se was built in a few weeks is not going to have the same feature richness, level of polish, or clarity of outward-facing documentation.

Give it some time.

"The Design of Everyday Things" is a great book, I enjoyed it.

Part of why I put it up with no instructions is to get feedback on how intuitive it is to use without any explicit instruction. I've gotten mixed response; some people seem to get it, others don't. So thanks for this bit of feedback. There's a basic help panel now.

I just clicked around on it and figured it out in 10 seconds. Maybe you should not approach new things with prior assumptions.