You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have some of the primitives for path simplification in place, there are some followup issues to make it more generally usable. There are two in particular:
There are adversarial inputs (identified in Experiments with offset curves #230) that can cause the quartic solver to find no real roots. This currently causes a panic, which is definitely not the best behavior.
The existing logic basically assumes a smooth curve on input and does not deal with corners when simplifying Bezier paths (though it can handle cusps in offset curves).
To address the latter question, I propose a function (which may end up being a method on BezPath) that handles general paths including corners. At a high level, it works something like this:
The input path is divided into ranges, each of which is smooth.
If a range is a single path segments, it is copied unmodified (this includes line segments).
Degenerate cubics which are actually lines should be lowered.
Zero-length line segments should be eliminated.
The criterion for corner or no should probably be a configurable parameter. I propose an Options struct with a default of one milliradian, and also a setting for optimization level. Error tolerance is also obviously a configurable parameter, and maybe should have a reasonable default (1.0?) for convenience.
The test for tangent continuity depends on a tangent method. We generally use derivatives for this, but it doesn't handle non-regular curves. Likely, general methods for evaluating tangents that also work for non-regular cubics would be useful and should have their own public API.
There's some level of heuristics to all this. One open question is whether inputs containing cusps should be subdivided at the cusp points.
Before diving into the implementation, I'd love to hear more feedback about use cases, and what the interface should look like.
The text was updated successfully, but these errors were encountered:
Now that we have some of the primitives for path simplification in place, there are some followup issues to make it more generally usable. There are two in particular:
To address the latter question, I propose a function (which may end up being a method on
BezPath
) that handles general paths including corners. At a high level, it works something like this:The criterion for corner or no should probably be a configurable parameter. I propose an
Options
struct with a default of one milliradian, and also a setting for optimization level. Error tolerance is also obviously a configurable parameter, and maybe should have a reasonable default (1.0?) for convenience.The test for tangent continuity depends on a tangent method. We generally use derivatives for this, but it doesn't handle non-regular curves. Likely, general methods for evaluating tangents that also work for non-regular cubics would be useful and should have their own public API.
There's some level of heuristics to all this. One open question is whether inputs containing cusps should be subdivided at the cusp points.
Before diving into the implementation, I'd love to hear more feedback about use cases, and what the interface should look like.
The text was updated successfully, but these errors were encountered: