Mention non-intersection/cusp property of centripetal parameterization of Catmul-Rom spline

[JobLeonard]

As per my comment on HN, it has been proven that for cubic Catmul-Rom splines. only centripetal parameterization (alpha = 0.5) is guaranteed to never have self-intersections or cusps:

In this paper we prove that, for cubic Catmull-Rom curves, centripetal parameterization is the only parameterization in this family that guarantees that the curves do not form cusps or self-intersections within curve segments.

http://www.cemyuksel.com/research/catmullrom_param/catmullrom_cad.pdf

While neither self-intersection or cusps has to be a technical bug, it can be a visual one that the artist using them did not intend to have (and which only become visible when zoomed in), so I think it's good to make this part of the "general knowledge" for people using such splines.

[Pomax]

It's not even "a bug" at all - that's literally how they work. CR spines are not presented as a somehow different curve, they are presented as being the same as Beziers, just (yet another) way to represent them. We've already seen the geometric (lerps of lerps), analytic (polynomial), and algebraic (power matrix) ways to look at Beziers based on the same set of coordinates for each solution, and CR splines are a variation on that theme, where we see that if we describe the curve using a different set of inputs (specifically, coordinates and tangents at those coordinates) then we can see that CR splines with those inputs are in fact equivalent to Bezier curves with plain coordinate inputs, and we can find the mapping that turns one into the other and back. Both approaches yield an identical curve. Logically, it follows that any property of Beziers therefore applies to CR splines.

Can you explain where in the text you thought it implied that CR are somehow different? Especially so different that you thought they were presented as somehow being safer (for visual purposes) than regular Bezier curves?

[JobLeonard]

I think my intent is being misunderstood: I'm not talking from the point of view of the text, but of how CR splines are used in practice. I just did a quick CTRL+F of the word "centripetal" and noticed it wasn't being mentioned anywhere.

I brought this up because I recently saw an animation where applying a lens warping effect on a thought bubble image lead to loops in said though bubble (you know, where the inward pointing pointy bits should be). When I notified the animator of this, he claimed this was unavoidable. Except that it isn't: if he would have used centripetal CR splines instead of the uniform one this wouldn't have happened. And the main reason he used uniform CR splines is because it is the default value and he didn't know any better.

https://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline

I just think it would be nice if people were more aware of this possibility; a brief aside basically saying "By the way, if you are planning on using CR splines, you can achieve various effects by changing the parameterization, but it might be useful to know that the centripetal version has the nice mathematical property of never having cusps or self-intersections, making it easier to avoid certain visual artefacts," (but in a more appropriate wording for the text of course), optionally linking to Cem Yuksel's webpage discussing this in more detail

Of course, now that I read the section on CR splines in more detail, I noticed that parameterization isn't even mentioned at all, and the formulation is different than the explanation in the wikipedia article; I'm not sure how the "tightness" of the processing version translates to the method of construction used in the Wiki page.

[Pomax]

Ah, I see. To be fair this primer is way more geared towards "for when you need to program these" rather than "for when you're designing with them". I'll think about if there's an appropriate way to add in this information, but the guiding principle is "this is for you programmers who need to implement curve code" before all else =)

[JobLeonard]

Maybe you could have a discussion for the importance of choosing the right default values somewhere?

[Pomax]

maybe, but again that phrasing suggests something that doesn't exist. There are no "right" default values, not even for design. There might be aesthetically pleasing ones, but that's not enough to give it its own discussion as that's not something the primer cares about. As a discussion on continuity, cusp detection would be a good topic to cover, but self intersection is then still not a problem in the slightest (not even for design - having control over fill rules let you do tracing with self-intersecting curves just fine) so it becomes a very small footnote without a larger section to go in. I can't really think of another section at the moment where a discussion of this topic makes sense, but I'll keep mulling it over.

[JobLeonard]

Before you read the rest of this comment, I think you'll agree with me that this is turning into a very principled debate on a very minor matter :P

We're also predominantly approaching it from two different perspectives I think: the discussion of the application of a technique in a localised context vs universal discussion of how to implement it.

There are no "right" default values, not even for design

So here I disagree, because the statement implicitly assumes all users know what they are doing in all aspects and always make conscious choices. Which is blatantly wrong, as anyone working in interaction design, security, and a whole host of other fields can tell you. Default values matter, a lot. Just compare countries with opt-in or opt-out organ donation.

Unless your drawing application randomises each brush tool setting every time you use it, until the user explicitly sets all of them, there will always be a default value and that has real-world effects of introducing a systematic bias.

Sure, there are no universally objectively "right" values. But that does not mean programmers are exempt from thinking about which default value is likely the best fit for the specific use case they program their tools for. When designing a system, a conscious, well-informed choice should be made, instead of just naively copying an implementation.

But anyway, I honestly don't know if this has any consequence for whether centripetal CR spline behaviour should be mentioned in the primer, since that depends on what you are going for with the text. Sorry for wasting a few minutes of your life :P

[Pomax]

No, as a discussion on adding content to the primer for a special audience, this is certainly not a very minor matter, and discussions are not a waste of time. You're learning something about me, I'm learning something about you, and we have a topic that we disagree on that can only be reached agreement on by understanding each other's positions and thoughts on the matter. If you feel that's a waste of time, then it is. But for what it's worth I don't.

So with that on the table, when I say there is no "right" default values I'm talking about mathematics. No assumptions on what people know, purely the maths: there are no right, and no wrong, values. Just coordinates that give you curves, and those curves have certain properties, and one of those properties could be "there is a cusp" and in some contexts that can lead to problems, and in others, not. So, in order to figure out where this information should go, if anywhere, we need to discuss this in fairly clinical terms. So in order to figure this out, three questions:

1. under which circumstances and in which context are cusps a problem,
2. does it make sense to talk about CR splines in that context, in addition to talking Beziers, and
3. who are the people that would run into this.

Because if the answer to that set of questions is "when using a design tool", "not really, because the tool only offers Bezier pen tools" and "designers" then there is no point in adding this information to a primer on Bezier curves. That's something to put in a detailed writeup of CR splines (which this primer isn't, and shouldn't be) or a writeup on curve design in the context of some specific task (lettering,

However, if there are more answers here, such as "curve offsetting/path animation", "yes, because it relies on low level code", and "game programmers", then absolutely: it would make sense to talk about cusps and how to avoid them, with a secondary section specific to "if you've defined the path as a Bezier-equivalent CR spline, here are your options".

Given that I have to write this, I want to know what I'm writing, where, and why, and so while for you this might sound like a minor issue, for me this is a day of work to make sure it all makes sense, write it up, set up the maths latex, and make sure the information is presented in a way that does not require reordering sections, or if it does, reordering sections in a way that keeps making sense. While you don't see that work, and you probably didn't even realize it would take that much work, even small suggestions can require a significant time investment on my part, and so to me understanding the exact nature of this information in the context that you're thinking of is criticially important. I'd rather "waste time" with a few back and forths on github (which don't take a lot of time) if that means I can reach a well informed decision on whether or not to invest that day in working this information in, or whether to go "cool, marking as help wanted, this will require a fair bit of work and so I may get to it eventually but other work and other projects comes first" =)

[JobLeonard]

I'm sorry that my remarks felt like I was belittling your work - I was aiming for the opposite!

What I meant with "minor matter" was that it was already clear to me that the cost of adding this information to the primer would be quite high in terms of your time and brain cycles. It would be rude of me to waste those. And while it's obvious that I find this topic important in the context of the subjective art of applying the mathematics, the primer (as you repeatedly stated) is more focused on the objective maths itself (that is what I meant with us approaching the topic from two angles).

Essentially, to continue to debate the subjective merits of thinking about default values felt like an inappropriate way of demanding your time, since I did not see how it was relevant for the decision of including centripetal splines in this primer. What I was trying to convey is that I understand if you'd rather not spend your time on this if you have more pressing issues to attend to and a limited time/energy budget.

So again, my apologies.

But since we do seem to be continuing the discussion of whether this topic is worthy of inclusion, I only think I can add some thoughts on the first question ("under which circumstances and in which context are cusps a problem"), where my example scenario can be generalised to:

"Any context where control points positions are placed in key-frames, and interpolated between these key-frames. If cusps are not present in the paths of the key-frames, but appear in the interpolation, it can safely be assumed this goes against the original intent of the user who placed these control points."

I guess you already concluded something similar, based on the second list of examples you gave. However, I'm afraid I have else to contribute.

[Pomax]

hm, so that would be animation contexts? I think with how the sections are ordered at the moment it would make sense to put a path traversal/animation section near the "Tracing a curve at fixed distance intervals" section, as that deals with the other aspect of janky animation, although that precedes CR splines...

[JobLeonard]

Well, if this is also something that could be an issue with interpolating control points of Bezier curves, an option would be discussing this in the purely Bezier-context there, and then briefly bring it up again at the CR splines section.

[Pomax]

yeah that's what I'm also leaning towards