I'm in full agreement that bezier curves are hard to learn to use well! I created an app called Bezie (http://bezie.io/) about a year ago in which you could create quadratic and cubic bezier MIDI automation. I ended up not including it in the release, but I had a smoothness feature where it'd basically update the amount of steps that it'd pass to the interpolate function (using De Casteljau's algorithm). The more steps the higher the curve resolution. I found 64 steps to be somewhat of a magic number as it always looked and sounded smooth. There's also the balance of how many times you want the interpolate function to run while dragging points. With too high a resolution it gets CPU intensive and lags and with too low it starts getting boxy and no longer represents a curve. It's been on my plate to open source the app. It includes some helpful math for deriving control points while dragging points on the curve. Anyhow, nice post and thanks for sharing!
I got motivated today after this post and finally open sourced Bezie! If anyone wants to see some of the bezier logic I used you can check that out in `app/utils`. https://github.com/jperler/bezie
Fun fact that I came across while researching this. Hobby's PhD work (which I probably should have cited) was reviewed by one Kevin Karplus, who is perhaps best known for his role in the Karplus-Strong algorithm for plucked string sound synthesis.
I implemented that once, if I remember right, it was a huge pain to read because the OCR messed up many of the symbols. Hobby splines look pretty nice though.
Spiro curves are necessarily smooth, but beziers aren't. To show what makes beziers smooth, you created a viz that maps spiro curves to their bezier equivalents:
* x,y = spiro curve angles
* color = bezier handle lengths (to best approximate spiro)
The abrupt changes in color in the image reveal the difficulty in creating smooth bezier curves—because it forces abrupt changes in handle lengths for small angle changes.
Yes, that's about right. The only thing I'd qualify is that Spiro contains Euler spiral segments but also other things, especially smooth straight-to-curved transitions. This is only about the first, but the others are also important to font design. I wanted to keep it simple though.
I don’t think that’s the right assessment about the abrupt changes in color.
What I think those instead reveal is areas of the parameter space where there is a collapse of a degree of freedom: if your curve is close to a parabola, then you can make many different cubic curves which are close approximations, and it doesn’t much matter which among them you choose.
Raph’s optimizer picks opposite choices for which arm should be the short one when you go across that boundary, but if you smoothed the map out so there were no creases I don’t think you’d get significantly worse results. (I’d be interested to see him try this ;)
The Euler spiral seems very similar to a curve I was generating in a stepwise manner while doing self driving car work.
I was trying to generate the path the vehicle would follow if you were driving at a constant speed, and start turning the steering wheel at a constant rate. The full curve would then see you holding that angle, then returning the wheel to center.
After brute forcing this curved portion, I was able to solve a linear algebra problem to determine how far to drive during these straight segments to smoothly enter a parking spot with exactly 3 turns: 2 arbitrary turns, and a 3rd that brings the vehicle to the correct angle.
After brute forcing each combo of the first 2 turns, throwing the path through a weighted fitness function that minimised travel, and penalized reverse moves, while at the same time checking for collisions, it would spit out a very simple and elegant parking plan.
It's a little weird in Firefox 63 in Linux. Holding down the mouse drags the image, but after I release, it changes the curve correctly until my mouse leaves the image. It also works fine if I hold down middle click.
This can be fixed by inserting this line after line 308 of euler_explorer.js, in the onpointerdown handler:
e.preventDefault();
By default, if you drag an image, then it moves the image. You should need to call preventDefault to prevent that, so I'm kind of annoyed with Chromium.
Argh, I used "modern web platform" but tried not to be too aggressive. I don't see any errors in the Safari console, so not sure what's wrong. The source is not (yet) in a public Git repo, but when it is, I'll happily accept PR's to improve browser compatibility.
Right, this is also why it doesn't work in Safari. That's fixed now, but imperfectly (I don't know how to do the equivalent of setPointerCapture in ancient browsers, and also it only adds a mouse, not a touch handler, so still doesn't work in mobile Safari). Thanks!
Rational curves give you another degree of freedom. CAD people like them because they can exactly represent conics.
Neither polynomials nor NURBS are IMO especially intuitive to work with as a design tool. As an approximate output target I think cubic polynomials are okay: a few cubic segments strung together are plenty flexible for typical drawing/modeling purposes.
"Easier for what?" is a legitimate question. I also had the question after I submitted my question because the "for what" wasn't specified in the article. If the target application only takes beziers, then that is the only tool you have.
My original question was that a rational bezier would be easier to use since a rational bezier would make an exact representation of a Euler Curve instead of an approximate representation.
I agree with you that full NURBs are difficult. But if you ignore the "Non Uniform" (NU) part of NURBs and just use the "Rational BSpline" (RB) part of NURBs then they are as easy to use as just beziers. The rational term just means a projection from n+1 space to n space. It is what gives an exact representation of a conic.
If you want to fully model the parametric equation then you would need the "non uniform" part. I don't know why you would want to do this since you can analyze the original curve directly.
The reason to try to approximate Euler spirals by Bézier curves is that Bézier curves are ubiquitous in existing implementations. Trigonometric Bézier curves (https://ac.els-cdn.com/S0893965908001262/1-s2.0-S08939659080...) are not to my knowledge implemented anywhere.
Very very interesting papers, will deep on it this week.
Also I'm interested on this Baziers and here is my papers about "Quadratic bezier through three points and the -equivalent quadratic bezier-" and "Quadratic bezier offsetting with selective subdivision" here → http://microbians.com/?page=math
https://pomax.github.io/bezierinfo/