[metapost] Re: workaround for turningnumber bug
laurent at math.toronto.edu
Mon Jan 31 04:05:24 CET 2005
Hi mp maintainers,
Taco writes concerning the turning number bug:
> Making the test_pen smaller would solve some of the reported
> bugs, you think? The used pen is a triangle:
Nat a recipe easy to analyze in detail. So vary pensize liberally.
The triangle choice is clever. It does tend to round off cusps,
suppress tiny loops, suppress minuscule paths, break up paths that
turn >180 degrees.
Questions: Is 'buildcycle' or parts thereof involved in the
triangular pen envelope construction? Or directiontime? Or
'intersectiontime'. I still don't fully see what is going on at a
low level. Is Werner's approach involved at some level?
Taco> But if you (or anyone else) knows of a good algorithm to calculate
> the turning number directly from the path nodes, I'd be more than
> happy to implement that.
I think that is the way to move ahead --- be it to get a better
function or just as likely, to understand how to improve/debug
JDH's clever trick solution.
One could start with Werner's code and introduce the following
*initially optional* modifications:
(1) politely refuse paths that mathematically speaking have no
turning number. These are
(a) paths with a cusp, equivalently an interior point where the
derivative is 0 (or within eps of 0).
(b) paths with an internal node at which the turning angle is
angle is 180 degrees or within eps thereof.
(Am I forgetting something?)
(1*) optionally give warning in case a b'ezier segment
has a self intersection. Or a small loop?
(2) before applying Werner's current calculation break in two or
three pieces those bezier *segments* for which |total turning angle|
is is >= 180 degrees.
A criterion to detect such a b'ezier segment is that the direction
opposite to the initial direction is assumed (to within eps)
at some time
Bezier segments can be excused from the above criterion test if the
control trilateral is nondegenerate and has total |turning angle|
< (180 degrees) - eps.
When the criterion signals the need, the break can be made at (say)
120 degree intervals. Both test and splitting can use
(3) Simply omit from the calculation those b'ezier path segments
that are invisibly small say with controll trilateral of length
< 3000sp. (This seems to give the same result as an
alternative used by B.Jackovski that requires modifying the paths;
the alternatives merit some discussion here; they relate to
'buildcycle'.) Appearance of several successive invisibly small
bezier segments should parhaps trigger a warning.
Taco> It doesn't have to be fast, but it has to cover all of the
> possible weird stuff like cusps and opposing control points ...
Hope some of this is more or less on target.
More information about the metapost