A system solved as REDUNDANT_OKAY is still solved correctly,
even if the UI would consider this an error, in case that
g->allowRedundant==false. So there's no reason to discard this
solution; we might find it useful if a system loses a degree of
freedom while dragging, or to avoid regeneration after redundant
constraints are allowed.
This commit also reverts commit 3ff236c, as that is not necessary
anymore.
This setting is generally useful, but it especially shines when
assembling, since the "same orientation" and "parallel" constraints
remove three and two rotational degrees of freedom, which makes them
impossible to use with 3d "point on line" constraint that removes
two spatial and two rotational degrees of freedom.
The setting is not enabled for all imported groups by default
because it exhibits some edge case failures. For example:
* draw two line segments sharing a point,
* constrain lengths of line segments,
* constrain line segments perpendicular,
* constrain line segments to a 90° angle.
This is a truly degenerate case and so it is not considered very
important. However, we can fix this later by using Eigen::SparseQR.
Before this commit, overconstraining a system past a certain point
resulted in a wrong error message: instead of "redundant constraints",
"unsolvable constraints" was displayed.
To reproduce, place more six or more length constraints with the same
value onto the same line segment.
When a solver error arises after a change to the sketch, it should
be easy to understand exactly why it happened. Before this change,
two functionally distinct modes of failure were lumped into one:
the same "redundant constraints" message was displayed when all
degrees of freedom were exhausted and the had a solution, but also
when it had not.
To understand why this is problematic, let's examine several ways
in which we can end up with linearly dependent equations in our
system:
0) create a triangle, then constrain two different pairs of edges
to be perpendicular
1) add two distinct distance constraints on the same segment
2) add two identical distance constraints on the same segment
3) create a triangle, then constrain edges to lengths a, b, and c
so that a+b=c
The case (0) is our baseline case: the constraints in it make
the system unsolvable yet they do not remove more degrees of freedom
than the amount we started with. So the displayed error is
"unsolvable constraints".
The constraints in case (1) remove one too many degrees of freedom,
but otherwise are quite like the case (0): the cause of failure that
is useful to the user is that the constraints are mutually
incompatible.
The constraints in cases (2) and (3) however are not like the others:
there is a set of parameters that satisfies all of the constraints,
but the constraints still remove one degree of freedom too many.
It makes sense to display a different error message for cases (2)
and (3) because in practice, cases like this are likely to arise from
adjustment of constraint values on sketches corresponding to systems
that have a small amount of degenerate solutions, and this is very
different from systems arising in cases like (0) where no adjustment
of constraint values will ever result in a successful solution.
So the error message displayed is "redundant constraints".
At last, this commit makes cases (0) and (1) display a message
with only a minor difference in wording. This is deliberate.
The reason is that the facts "the system is unsolvable" and
"the system is unsolvable and also has linearly dependent equations"
present no meaningful, actionable difference to the user, and placing
emphasis on it would only cause confusion.
However, they are still distinguished, because in case (0) we
list all relevant constraints (and thus we say they are "mutually
incompatible") but in case (1) we only list the ones that constrain
the sketch further than some valid solution (and we say they are
"unsatisfied").
The current messages accurately reflect what happens to the system
of equations that represents the sketch, but can be quite confusing
to users that only think in terms of the constraints.
We use "unsolvable" and not "impossible" because while most of
the cases that result in this error message will indeed stem from
mutually exclusive sets of constraints, it is still possible that
there is some solution that our solver is unable to find using
numeric methods.
Before this change, it was possible to adjust constraints in a way
that removes a degree of freedom and makes the sketch unsolvable,
but rank test was performed before solving the system, and an error
was not displayed immediately. Instead, a solution would seemingly
be found, but it would be very unstable--unrelated changes to
the sketch would cause rank test to fail.
To reproduce the bug, do this:
* Draw a triangle.
* Create a length constraint for all sides.
* Set side lengths to a, b, and c such that a + b = c.
* Add a line segment.
the documentation accordingly. Also rename the C example for
consistency, and update copyright dates.
[git-p4: depot-paths = "//depot/solvespace/": change = 2190]
after decimal) current value of the dimension, not the value
truncated to the same number of digits that are usually displayed.
And make the paste transformed screen accept expressions, not
just integers, for the count, angle, and scale.
[git-p4: depot-paths = "//depot/solvespace/": change = 2181]
as they are displayed on the drawing, and for many other places) a
user-configurable parameter.
Also reshuffle some options in the configuration screen, to put all
the stuff relating to exports together.
[git-p4: depot-paths = "//depot/solvespace/": change = 2179]
and up for special things, the number of times that a group may
be stepped is limited to 999. So avoid a crash by not letting
the user specify more than that.
[git-p4: depot-paths = "//depot/solvespace/": change = 2178]
color picker.
And apply same rule to rewrite nearly-white colors (when exporting
with a file format typically viewed on a white background) for fill
color as for stroke color.
[git-p4: depot-paths = "//depot/solvespace/": change = 2176]
of that, where you can pick the hue and blackness, and then the
whiteness) color picker and some swatches.
This is used in three places now: the special colors in the config
screen, the background color, and the style colors.
[git-p4: depot-paths = "//depot/solvespace/": change = 2174]
in the text window. This means that I can move the conversion from
half-row and column to (x, y) into the platform-independent code,
and that I'll be ready to add my color picker.
[git-p4: depot-paths = "//depot/solvespace/": change = 2171]
library. If I understand correctly, that will avoid all the
compiler version issues with different required versions of libc.
[git-p4: depot-paths = "//depot/solvespace/": change = 2167]
for the tangent arc thing.
And update the version number to 1.7, in preparation for the next
release.
[git-p4: depot-paths = "//depot/solvespace/": change = 2147]
circles, using a numerical method. And the user can specify a
radius, instead of letting us choose automatically, and specify
whether the original lines should be kept and made construction, or
deleted.
[git-p4: depot-paths = "//depot/solvespace/": change = 2146]
an in-plane rotation of the view, or of a set of entities) would
remain on screen after the action was over.
[git-p4: depot-paths = "//depot/solvespace/": change = 2142]
and cubics. Also add that to the library interface.
It might have been better to use a single constraint for that,
plus all the line-curve or line-line cases, but it would break
backwards compatibility if I did that now, and perhaps be
confusing with the 'other' member (which is meaningless for
lines) anyways.
[git-p4: depot-paths = "//depot/solvespace/": change = 2141]
useful because it makes it possible to add cosmetic dimensions to
an existing model, without REF appended.
[git-p4: depot-paths = "//depot/solvespace/": change = 2140]
possible. This replaces all of the color-coded links, that I liked
but that were nonstandard.
Also rip out the old sweep and helical sweep UI; that was disabled,
but the code was still present.
And fix dependencies in makefile, since textwin.cpp depends on the
icons now.
[git-p4: depot-paths = "//depot/solvespace/": change = 2139]
buttons. This requires some tools to convert .png images to that,
and that I put the characters in a two-dimensional grid in the
texture (since one-dimensional strip gets wider than the hardware
supports).
[git-p4: depot-paths = "//depot/solvespace/": change = 2138]
