# pouët.net

Go to bottom

## angle curves- new kind of mathematical curves I made

category: code [glöplog]
Quote:
the curve itself is as smooth as Hermite

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.
added on the 2015-05-12 10:37:11 by arm1n
What spike said. I'm pretty certain that your curve is not C2 continuous.
added on the 2015-05-12 10:40:49 by las
AFAIU this curve is composed of connected circular arcs under affine transformation, therefore, it is of class C0, and not even C1.
added on the 2015-05-12 11:49:38 by tomkh
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).
added on the 2015-05-12 12:19:07 by tomkh
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
added on the 2015-05-12 12:52:44 by gorgh
sorry,sine[0...360]
added on the 2015-05-12 12:54:51 by gorgh
Or you could use forward differencing and use only additions (except for setup)...
added on the 2015-05-12 14:06:03 by raer
Btw any hints on how to do adaptive subdivision of a catmull-rom spline based on curvature?
added on the 2015-05-12 14:08:19 by raer
@raer: You could convert it to Bernstein form and do De Casteljau.
added on the 2015-05-12 17:58:58 by kusma
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.
added on the 2015-05-12 19:20:33 by Hofstee
yeah, i know that, that's just proof of concept
added on the 2015-05-12 19:46:34 by gorgh
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
added on the 2015-05-12 22:00:19 by T\$
today I'm going to consult it with the university professor, we will see if it's any good
added on the 2015-05-13 09:17:45 by gorgh
with prof. Kiciak btw :)
added on the 2015-05-13 09:19:50 by gorgh
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
added on the 2015-05-14 11:05:59 by gorgh
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...
added on the 2015-05-14 15:07:21 by tomkh
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?
added on the 2015-05-14 16:49:32 by skrebbel
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?
added on the 2015-05-14 17:11:33 by tomkh
because it makes you sound like a douche.
added on the 2015-05-14 17:18:22 by psenough
psenough: sure, if you don't go into details, it very well may "sound" like this.
added on the 2015-05-14 17:50:31 by tomkh
@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... :/
added on the 2015-05-15 00:55:10 by raer
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.
added on the 2015-05-15 01:38:05 by tomkh
...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....
added on the 2015-05-15 01:51:07 by tomkh
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.
added on the 2015-05-15 02:23:43 by tomkh
Quote:

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.

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.
added on the 2015-05-15 08:37:25 by raer