Before this commit, when an entity is clicked at or dragged, and it
shares a place with other entities, which of them is selected is
decided more or less at random. This is particularly annoying when
dragging.
After this commit, when clicking, an entity from the current group
is given preference, and when dragging, an entity from a request
is given preference. This allows e.g. dragging points of a sketch
even when an extrusion of that sketch is active.
Before this commit, it was possible to add some redundant constraints
(e.g. vertical, horizontal or midpoint) without failing the sketch,
because SolveBySubstitution() removed the redundant equations.
However, this could result in the solve failing later because
the system didn't converge, without any pointers as to the true
cause of the failure.
Before this commit, parallel constraints in 3d are fragile:
constraints that are geometrically fine can end up singular anyway
because VectorsParallel() pivots wrong but converges anyway.
After this commit, much like in cc07058, the constraints are written
in a different form: instead of trying to remove two degrees of
freedom out of three, all three are removed, and one added; namely,
the constraint introduces a free parameter, signed length ratio.
Before this commit, pt-on-line constraints are buggy. To reproduce,
extrude a circle, then add a datum point and constrain it to the
axis of the circle, then move it. The cylinder will collapse.
To quote Jonathan:
> On investigation, I (a) confirm that the problem is
> the unconstrained extrusion depth going to zero, and (b) retract
> my earlier statement blaming extrude and other similar non-entity
> parameter treatment for this problem; you can easily reproduce it
> with a point in 3d constrained to lie on any line whose length
> is free.
>
> PT_ON_LINE is written using VectorsParallel, for no obvious reason.
> Rewriting that constraint to work on two projected distances (using
> any two basis vectors perpendicular to the line) should fix that
> problem, since replacing the "point on line in 3d" constraint with
> two "point on line in 2d" constraints works. That still has
> the hairy ball problem of choosing the basis vectors, which you
> can't do with a continuous function; you'd need Vector::Normal()
> or equivalent.
>
> You could write three equations and make the constraint itself
> introduce one new parameter for t. I don't know how well that
> would work numerically, but it would avoid the hairy ball problem,
> perhaps elegant at the cost of speed.
Indeed, this commit implements the latter solution: it introduces
an additional free parameter. The point being coincident with
the start of the line corresponds to the parameter being zero, and
point being coincident with the end corresponds to one).
In effect, instead of constraining two of three degrees of freedom
(for which the equations do not exist because of the hairy ball
theorem), it constrains three and adds one more.
Before this commit, polylines got flattened but all other entities
got exported with the proper Z coordinate. After this commit, all
entities are exported with proper Z coordinate.
Also, instead of exporting LWPOLYLINE (2d only), POLYLINE (2d/3d)
is exported; as a bonus it is more compatible with 3rd party
software, since it is older.
SSurface::TriangulateInto first populates the mesh with triangles
that have no color, and then paints them, which confused the code
that detects if a mesh is transparent into thinking that all of them
are; and that broke the "draw back faces in red" feature, since it
is disabled for transparent meshes.
This is useful in case one wants to create a workplane based on
one of the reference ones, to be explicit, or to avoid fishing out
again the line segments used to create a workplane at an angle.
These points can be used for constraining the width of the text
(or to the width of the text).
The main parts of the commit are:
* TtfFont is restructured to be able to return the aspect ratio
for a given string.
* This aspect ratio is written to the savefile, such that even if
the font is missing, the sketch would still be solved correctly.
* The two additional points are constrained via perpendicularly
to the two main points (which form a v vector).
The compatibility features are as follows:
* When the font is missing in old files, 1:1 aspect ratio is used,
which works for the replacement symbol anyhow.
* When the two additional points are missing in old files, their
would-be positions are calculated and they are moved there,
avoiding 'jumping' of underconstrained sketches.
Before this commit, a translate group based on another translate
group would always use the "union" boolean operation, which does not
work at all if one wants an array with a difference operation, and
results in degraded performance if one wants an array with
an assemble operation.
This significantly improves performance e.g. in case of a sketch
containing a multitude of wooden panels, as the meshes can be
merely transformed instead of being joined.
The states are:
* Draw all lines (on top of shaded mesh).
* Draw occluded (by shaded mesh) lines as stippled.
* Do not draw occluded (by shaded mesh) lines.
As usual, the export output follows the screen output.
In 2.0, the distance between the points in the TTF request specified
cap height. In 2.1, that was accidentally changed to some arbitrary
value near cap height instead, due to a 72pt factor mess-up.
This commit restores the old behavior.
If SolveSpace crashes after the open, or hangs and is forcibly
killed, data would be lost. (I lost my data.) Instead, remove
autosave only in two cases: right after a successful save, or right
after a save is declined. This should be completely safe.
whitequark
EvilSpirit
Elvira Khabirova