Hacker News new | ask | show | jobs
by TheRealPomax 1018 days ago
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.

Making people draw Bezier curves just because "the file format uses those" is by far the bigger problem here.

2 comments

There are a few misunderstandings here. Rational Bézier curves are incidental in this article, and the conclusion is not that they are correct. They were just a convenient curve I used to express the main message of local control, and the article endorses looking for other curves that fit the properties.

The parameter count has not gone up; it's equal to or less than usual Bézier control handles, because I forced the parameters to take specific values.

The part that is "new" about the Béziers is the new formula that selects one specific Bézier out of all the possible choices. I think this linguistic accusation is silly; for example, if someone discovers a new rock, it would be fair to call it a "new rock" even though rocks have been discovered thousands of years ago.

These curves are also unrelated to the file format; the curves are designed to fit how the user thinks about curves rather than be computer-efficient. For the tooling point, I think you are agreeing with me while arguing; I agree that there's no reason the curve should match what is used in the final product, and some of the other curve choices I considered require a complex conversion step.

Maybe I'm not reading what you wrote, but what I'm getting from the writeup is not that you're describing a new set of curve constraints, not a new Bezier curve (even if we just go by the list of constraints you're trying to satisfy), so that doesn't feel like a linguistic accusation so much as a pretty important thing to call out?

In the analogy of rocks: we've certainly been discovering rocks thousands of years ago, but if you pick up the same rock that others have already picked up, from the same patch that we've been picking up rocks from for a long time, but using a different set of rules to decide how to pick the rock up, that's not a new rock. That's a new method.

So describing it as a new methodoly for finding appropriate Bezier curves, rather than finding new Bezier curves, would make it much more clear what you're doing. And new methodologies are always exciting.

This article is really stretching when the conclusion is smacking him in the face: "Use quadratic Beziers."

The original article points out that quadratic Beziers have most of the desirable properties with very few of the downsides.

It used to be that the issue was that you would have to use significantly more quadratic Beziers to approximate something that a much smaller number of cubic Bezier's could do. This was a big deal when a font file might clog up a floppy disk.

Now that we're slinging around gigabyte patch files. Do we really care?