pouët.net

i doubt that. AFAIK a hermite curve wouldn't have the cusp visible on the left in the image of your original post, for example.

What spike said. I'm pretty certain that your curve is not C2 continuous.

AFAIU this curve is composed of connected circular arcs under affine transformation, therefore, it is of class C0, and not even C1.

Grgh: Bezier or NURBS are still used commonly, because it is in fact difficult to construct an interpolatory curve (or surface) that is of a class C2 with good properties for 2d/3d editing, i.e. fine control, retopo (in the easiest form: splitting without changing shape) and still fast to calculate/evaluate/render. I can recommend you a classic literature on this topic, which you can find plenty (even one pretty extensive in polish by P.Kiciak). There is also an ongoing research on alternatives, here is a classic one related to subdivision surfaces (by Jos Stam) that become pretty successful in CG (i.e. implemented in Maya), and here some relatively fresh direction (by L.Romani and others).

And as for circular arcs, you can actually achieve C1/C2 continuity by interpolating two arcs with smoothstep (or so called smootherstep).

actually when it comes to sharp edges I thought how to eliminate it, probably one just need to multiply the section of the curve by sine[0...180] or something like that

sorry,sine[0...360]

Or you could use forward differencing and use only additions (except for setup)...

Btw any hints on how to do adaptive subdivision of a catmull-rom spline based on curvature?

@raer: You could convert it to Bernstein form and do De Casteljau.

Your javascript demo (at least) has a small bug. If you have too many points close together the curves stop begin drawn for new points, since something fails to be recognized as an arc.

yeah, i know that, that's just proof of concept

Connected arcs have two nice properties which can be useful:
-calculating an offset path is easier than for splines
-piecewise constant speed animation/parametrization/... is easy

today I'm going to consult it with the university professor, we will see if it's any good

with prof. Kiciak btw :)

he couldn't point out similar curves, but he also said it's nothing special. Anyway- I found some bugs- the curve wasn't drawn properly because errors in js implementation, I'll try to fix this. It appears that changing direction of a curve can be done in a smooth way, I haven't done that yet, but the idea is to multiply the Y values by sine[0...360] which you can see in updated demonstration (proof of concept only, isn't smooth yet) http://hit8b.it/anglecurves.html

Grgh: the thing is your research methodology is sloppy - you should really work out equations and continuity criteria before you go any "public". I did some more digging and indeed there was some interest in circular arcs used for splines in early CAD era 1975-1992, not only using arcs+line segments, but also so called biarc curves, here some article - it's also nice example how article (even on blog) should look like, has meaningful analysis, references etc...

tomkh fucking bullshit, people should go "public" sooner, not later. you write crap like this and wonder why new people shy away from making demoscene stuff?

skrebbel: if this is how you perceive my posts, then it wasn't my point at all. As you can see I share some hints/and many links that I think might be valuable for further curve research, so if any criticism, I hope it's all constructive from my side. Moreover, I think it's good not to tap someone on the back if he is doing beginner mistakes - I don't know here, but even that grgh seem to be a long-time scener, but I guess he is still relatively fresh with coding/math./research. Still, even if not, it doesn't matter, his methodology can be called sloppy regardless of his experience - just for the fact he didn't do enough background research, and it's nothing he cannot improve, so why not point this out?

because it makes you sound like a douche.

psenough: sure, if you don't go into details, it very well may "sound" like this.

@kusma: Currently for every single spline a fixed number of subdivisions is done, forward differencing is used to calculate line endpoints and then lines are drawn. I'd like to subdivide based on the "maximum/absolute" curvature of the spline. Afair I calculated some curvature value, but couldn't wrap my head around how to interpret it... :/

raer: why fixed number of subdivisions for the whole spline? Obviously, you could use recursive algorithm (like kusma said) with some error estimation, like this guy (from antigrain lib) is estimating distance and angular error, although to be honest this atan2 in a code look a little bit expensive (maybe its called only in extreme cases though). He also shows that with the fixed number of subdivisions no matter what you do (avg.curvature or whatever) cusps will never look good enough.

...on the other hand, maybe it is feasible to initially split the curve into fixed number of parts (I guess for a bezier spline with a degree N, you can do at most N-1 "turns"/cusps) and then use forward differencing with some good error estimation for every part separately, actually I've never tried this approach, need to think about it more hmm....

lol, if you read the article of antigrain guy I've just shared carefully, you will see that in the end he is in fact pointing out to this forum with a valid critique of his unprofessional approach (at least he admits it himself) with tons of links to papers about detecting cusps, adaptive forward differencing methods from 1987 and so on...
To @psenough again - as you can see, pointing out beginner mistakes is a common practice and it doesn't mean anyone doing it is a "douche" - we are talking here about stuff that was solved years ago afterall.

uhm. that was pretty much exactly what I was saying...

You could actually use forward differencing for every single pixel, but this is not trivial, because of cusps/curvature. Drawing lines is much, much easier.