I have found a few problems while applying an angle constraint to parallel lines:
a save/load "round trip" error (angle property of an angle constraint saved as null)
an angle computation problem: angle is occasionally NaN (causes the first problem if saved)
an angle constraint display problem: "missing" label
failing to notice the redundant constraint situation
All of these have happened for me while applying an angle constraint to parallel(-ized) 2-line paths.
The first one seems important (could be seen as data loss (though fairly easily recoverable by editing the JSON), and it transforms into a crash if the Logs windows has already been closed: #71). The others might be less important since adding an angle constraint to parallel lines is arguably silly, useless, or extremely rare.
When applying an angle constraint to parallel lines, I see various results:
180.0° label
-nan° label
missing angle label
The lines don't have to be (currently) constrained to be parallel, but making them so (and then possibly removing the parallel constraint) seems the easiest way to make (de facto) parallel lines at arbitrary angles.
The solver does not converge for the NaN cases, but that seems like a reasonable side effect of involving a NaN. It would be nice if it would consistently come up as 180 instead of sometimes getting NaN. If the document is saved with a NaN-computed angle constraint, it will serialize as null (JSON only officially supports the finite numeric values, I think). This turns out to be unloadable; the Logs window show this detail: [json.exception.type_error.302] type must be number, but is null.
For the "missing label" cases, if I force an unsolvable state (e.g. perpendicular and parallel constraints applied to some other pair of lines), I can "tear apart" the coincident point and see that the angle constraint label reappears and moves when the endpoints are moved. It looks like the angle label is always placed at the projected intersection of the lines. I guess for the "missing label" cases the intersection is being solved to Infinity instead of to the coincident point? For non-colinear parallel lines there won't even be a coincident point...
Separately, if the lines are actively constrained to be parallel when the angle constraint is added, sometimes the DOF is incorrectly decremented and no redundant constraint warning is produced.
The attached file has several examples that I have collected. They were all created by drawing two-line contours (usually without H/V constraints) and then constraining both lines to be parallel. They seem to be sensitive to small changes in positioning and orientation (they often change behavior when any of the three points has been moved, or even if all three have been translated together at the same time).
The first sketch has 5 examples in quadrant II of the XY plane (-X,+Y). From left to right (increasing X):
OK; saves as 180.0
OK-ish: but decrements DOF and not flagged as redundant; saves as 179.9999...
error: -nan° label; fails to converge; saves as non-loadable null
error: missing label; otherwise like "OK" case
error: missing label; otherwise like the OK-ish case
The second sketch has nine more examples in quadrants I, III, and IV.
I (+X,+Y): these five are all the "OK" case
three save as 180.0
the right-most vertical-ish ones save as not-quite-180, but don't trigger the DOF decrement and correctly still flag as redundant
III (-X,-Y): this one is like the NaN case (does not converge; saves as null), but also lacks a label; if I rearrange the lines while the solver diverges I can pull a -nan° label into view
IV (+X,-Y): these three all get -nan° labels, fail to converge, and save as null
I have found a few problems while applying an angle constraint to parallel lines:
angleproperty of an angle constraint saved asnull)All of these have happened for me while applying an angle constraint to parallel(-ized) 2-line paths.
The first one seems important (could be seen as data loss (though fairly easily recoverable by editing the JSON), and it transforms into a crash if the Logs windows has already been closed: #71). The others might be less important since adding an angle constraint to parallel lines is arguably silly, useless, or extremely rare.
When applying an angle constraint to parallel lines, I see various results:
180.0°label-nan°labelThe lines don't have to be (currently) constrained to be parallel, but making them so (and then possibly removing the parallel constraint) seems the easiest way to make (de facto) parallel lines at arbitrary angles.
The solver does not converge for the NaN cases, but that seems like a reasonable side effect of involving a NaN. It would be nice if it would consistently come up as 180 instead of sometimes getting NaN. If the document is saved with a NaN-computed angle constraint, it will serialize as null (JSON only officially supports the finite numeric values, I think). This turns out to be unloadable; the Logs window show this detail:
[json.exception.type_error.302] type must be number, but is null.For the "missing label" cases, if I force an unsolvable state (e.g. perpendicular and parallel constraints applied to some other pair of lines), I can "tear apart" the coincident point and see that the angle constraint label reappears and moves when the endpoints are moved. It looks like the angle label is always placed at the projected intersection of the lines. I guess for the "missing label" cases the intersection is being solved to Infinity instead of to the coincident point? For non-colinear parallel lines there won't even be a coincident point...
Separately, if the lines are actively constrained to be parallel when the angle constraint is added, sometimes the DOF is incorrectly decremented and no redundant constraint warning is produced.
The attached file has several examples that I have collected. They were all created by drawing two-line contours (usually without H/V constraints) and then constraining both lines to be parallel. They seem to be sensitive to small changes in positioning and orientation (they often change behavior when any of the three points has been moved, or even if all three have been translated together at the same time).
The first sketch has 5 examples in quadrant II of the XY plane (-X,+Y). From left to right (increasing X):
The second sketch has nine more examples in quadrants I, III, and IV.