"I don't know of a reasonable way to guess the right location."<p>1. Drag curve handles out to 1/3 of the length of the curve segment they control.<p>2. Eschew s-curves between two control points.<p>3. Don't turn more than about 90º between two control points.<p>I learnt this about a year into what is now a 23-year career as an Illustrator artist. It has served me well. You will note that the first interactive example on this page is asking you to violate rule 2.<p>"Béziers can't represent circles. If you try to approximate one by hand, it'll look lopsided."<p>If you try to draw a circle by hand, it'll look lopsided too. Any pro traditional artist will have a compass and a few circle templates in their kit. In Illustrator there's an ellipse tool one keypress away. I've been drawing at a pro level for about thirty years and while I can probably pick up a pencil and draw a better circle in a couple quick arm motions than you can in a bunch of little sketchy attempts, they're still nowhere near perfect, and they don't <i>need</i> to be.<p>I also draw about 90% of my paths with the Pencil tool, which just abstracts worrying all of this way. Unless you are doing very geometric work, or require the absolute minimum possible number of points, I feel that using the Pen tool to draw everything is about as sensible as writing a program entirely in assembly language. And if I <i>do</i> need to work under a tight point count constraint, then I will <i>still</i> draw it with the Pencil, then pull out Astute's Smart Point Removal tool, which does a <i>great</i> job of optimizing the heck out of my paths, much better than Adobe's tools for this.
Cool to see others working on this problem. I hope more people do.<p>Funnily I've seen a lot of programmers and math folks who express how truly, genuinely beautiful Beziers and the math behind them are. But I've never met an artist or graphic designer who didn't express some deep frustration at Bezier controls and how hard they are to work with.<p>There are even games[0] which make a mockery out of how hard Bezier controls are to use, where the game is purely using the controls.<p>Controls are just one side of the problem, in my view; the other side is that cubics are terrible for GPUs, they don't understand them - and I believe many of the best 2D graphics libraries today are not even fully GPU accelerated, e.g. Skia. There are folks working on compute shader-based approaches, where we try to shoe-horn this CPU-focused algorithm into GPUs and pray - but it still isn't really suitable.<p>The controls suck for artists, and the math sucks for GPUs. This is only true of cubics, if you restrict yourself to quadratics (although that brings other challenges), both the control issue goes away (you can just click+drag the curve!) and the performance issue goes away (quadratics are triangles, GPUs love them)<p>That's the summary of the talk[1] I gave at SYCL'22. In that talk, I didn't have time to present the downsides of my solution (which are real!) so if you watch it please keep that in mind - the talk is about the problem statement, not a solution. We are exploring a different solution today than what was presented in that talk. My overall point in there, though, is a solid one: vector graphics as they exist today suck for artists and GPUs alike.<p>The only reason we stick with vector graphics in their current form is because of SVG & compatibility with existing tooling. But isn't it crazy? We have new bitmap image formats all the time, and so few vector graphics formats.<p>In Mach engine[2] we're continuing to explore this space, end-to-end, from author tooling -> format -> rendering. I'm not claiming we have a perfect solution, we don't, but we're at least thinking about this problem. Kudos to the authors of this article for thinking about this space as well.<p>[0] <a href="https://bezier.method.ac/" rel="nofollow noreferrer">https://bezier.method.ac/</a><p>[1] <a href="https://www.youtube.com/watch?v=QTybQ-5MlrE">https://www.youtube.com/watch?v=QTybQ-5MlrE</a><p>[2] <a href="https://machengine.org" rel="nofollow noreferrer">https://machengine.org</a>
Are Bézier curves with handles “worth it”? I've always found the easiest method for drawing curves to be, simply, “give me the (cubic) spline curve that goes through these points”. You place your points and continuity conditions determine the cubic, as described in <a href="https://mathworld.wolfram.com/CubicSpline.html" rel="nofollow noreferrer">https://mathworld.wolfram.com/CubicSpline.html</a> .
It looks like the conclusion is "let's use rational Bezier curves instead of plain Bezier curves", in which case: you can, you just have more parameters to tweak now. Also calling this "new" is a bit disingenous given that rational Beziers have been around half a century now. They're useful, but if you only look at Bezier curves from the tooling side of things, you're going to miss the reason why we use them so much. And the biggest mistake in design software is having tools that actually let you work with the datatypes that your final product is going to end up using. Need a circle? Draw a circle based on a center point and a radius. Good tooling won't surface that fact that it's going to end up being a Bezier curve, it just lets you design with the primitives you need, and will take care of the conversion as needed when you export it to whatever format your deliverable needs to be.<p>Making people draw Bezier curves just because "the file format uses those" is by far the bigger problem here.
There are these civilized curves<p><a href="https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline</a><p>which you never saw because patents kept them off the markets until Beziers were completely entrenched.
This is a nice post but not a valid Show HN - please see <a href="https://news.ycombinator.com/showhn.html">https://news.ycombinator.com/showhn.html</a>.<p>I've taken "Show HN" out of the title now.
I was really hyped up by the beginning of the article, but it seems really miss the points with the conclusion.<p>I don't think it is easier to manipulate with the last two examples, and I am guessing no actual graphic artist has read this or play with this before you publish it. To think of ways to improve bezier curves for vector graphics, you need to fully contextualize your thinking about the use case; this is not an academic mathematical discussion after all. Based on my understanding, your finding has no mathematical value as Pomax pointed it out, it is not new, it is an old math with a few constraints that is pre-defined, based on your assumption of what graphic artist wanted most of the time, which I agree is a good direction.<p>I strongly suggest for anyone to try to make a better vector graphics tool, try to draw a letter S with the new approach as a test case, you can choose an existing font to match. And know existing vector graphics rules, here is a couple as example:<p>- add anchor points at the horizontal and vertical extrema of your paths<p>- control points should not cross path with one another<p>Curves that doesn't follow these rules are valid, fine mathematical curves, but graphic artists has practices this for years to rule out them as bad for the purpose of graphic design. Again, the goal is to find the more much smaller set of suitable curves from the infinite realm of mathematical possibilities, for the context of graphic design
The goals look quite similar to my hyperbezier explorations. There's an online demo of the first draft[1], and a Zulip thread on some progress toward a second draft[2]. The tl;dr is that I think I have the mathematics of the curve family, but I haven't finished the mapping between control points and the parameters of the curve family.<p>Both drafts have (exact) Euler spirals inside their parameter space, and thus circular arcs as well. I think that's a good criterion for a Bézier successor.<p>It's on the back burner for now, but I hope to get back to it, and am open to collaboration.<p>[1]: <a href="https://www.cmyr.net/blog/hyperbezier.html" rel="nofollow noreferrer">https://www.cmyr.net/blog/hyperbezier.html</a><p>[2]: <a href="https://xi.zulipchat.com/#narrow/stream/260979-kurbo/topic/Hyperbezier.20progress" rel="nofollow noreferrer">https://xi.zulipchat.com/#narrow/stream/260979-kurbo/topic/H...</a>
> Béziers can't represent circles. If you try to approximate one by hand, it'll look lopsided.<p>Many graphics algorithms (vector operations: scale, translate, rotate; raster operations like rasterisation and interpolation) specialise for straight lines (and hence also triangles), Bézier curves, circles, etc separately, rather than forcing everything to be a Bézier curve.
I like using the "split tweak" method to do my curves. Converts polygons to curves. Works VERY well. Very intuitive, straightforward and ez. It's a variety of bezier.<p>Alg :<p><pre><code> given polygon P.
For each vertex V in P.
Get the midpoints of the 2 segs adjacent to V. M0 M1. Add those 2 points to the polygon.
Get the midpoint of seg(M0, M1). M2. Move V to the midpoint of (V,M2).
</code></pre>
Repeat 2 or 3 times or whatever. Each iteration increases smoothness.<p>And here's the code for that<p><a href="https://github.com/johnalexandergreene/Geom_2D/blob/master/CurveSmoother_Closed.java">https://github.com/johnalexandergreene/Geom_2D/blob/master/C...</a><p>There's a version of that for open curves too, elsewhere in that package .
The guy from the mach engine has also talked about issues dealing with Bézier curves and came up with a interesting set a primitives:
Triangles, quadratic curves and semi-circles.<p>Mostly this is make it easier to do vector graphics on a gpu, which is why I'm interested in it, but I think it might be easier to understand.
Obligatory links for anyone that is interested in learning more about Bézier curves:<p><a href="https://pomax.github.io/bezierinfo/" rel="nofollow noreferrer">https://pomax.github.io/bezierinfo/</a><p><a href="https://pomax.github.io/bezierjs/" rel="nofollow noreferrer">https://pomax.github.io/bezierjs/</a><p><a href="https://github.com/Pomax/bezierjs">https://github.com/Pomax/bezierjs</a>
good work. i've always found bezier curves impractical and overrated, using standard polynomial interpolations or more easily understood variants.
beautifully made. However I think one's intuition for where the control points go and what they do are very clear if you've ever taken calculus. The line segments control the direction and magnitude of the tangent to the curve at that position. If you understand that, then it makes the motivating problem go away, and all the challenge problems are easy to solve.