In other words, Ctrl inverts the normal action of LMB. It is already
possible to deselect entities through the context menu, but that
can be very awkward on laptop touchpads with a crowded sketch; with
Ctrl, a misclick is easily corrected without moving cursor at all.
This means that automatically added H/V constraints now will never
cause the sketch to become overconstrained, which currently makes
that feature almost unusable.
Supported metric units: km, m, cm, mm, µm, nm.
Supported USCS units: in, mil, µin.
Also, use the newly introduced unit formatting machinery in tools for
measuring perimeter, area and volume, so that e.g. volume is not
displayed in millions of cubic millimeters.
Also, mark not just curves, but also points and normals derived from
construction requests as construction.
Also, don't always mark arc center point as construction just to
exclude it from chord tolerance bounding box calculation; instead,
special-case it there.
We plan to use flatbuffers in the future for the next generation of
the .slvs file format, so flatbuffers are built unconditionally; and
the Q3DO exporter itself is tiny.
Before this commit, the default font chosen for TTF text is Arial
(chosen by the basename of arial.ttf), which isn't present on most
Linux systems, and cannot be redistributed. After this commit, it is
replaced with Bitstream Vera Sans, which can be. Existing files
are not affected.
The font name in the TTF file was artificially modified to add
the (built-in) suffix, which will need to be done if more built-in
fonts are added.
Modifying the original entities instead of deleting them, retains the
original associated constraints. This makes creating rounded rectangles
a lot easier.
This commit removes a large amount of code partially duplicated
between the text and the graphics windows, and opens the path to
having more than one model window on screen at any given time,
as well as simplifies platform work.
This commit also adds complete support for High-DPI device pixel
ratio. It adds support for font scale factor (a fractional factor
on top of integral device pixel ratio) on the platform side, but not
on the application side.
This commit also adds error checking to all Windows API calls
(within the abstracted code) and fixes a significant number of
misuses and non-future-proof uses of Windows API.
This commit also makes uses of Windows API idiomatic, e.g. using
the built-in vertical scroll bar, native tooltips, control
subclassing instead of hooks in the global dispatch loop, and so on.
It reinstates tooltip support and removes menu-related hacks.
Before this commit, if the source group of a step rotate/translate
group is forced to triangle mesh, the UI would show that the step
rotate/translate group is also forced to triangle mesh, but the group
would in fact contain NURBS surfaces.
Before this commit, when a point is constrained to an entity (point,
circle, arc of circle or line segment) by clicking on it,
the resulting constraint is not necessarily satisfied, and the next
regeneration may place the newly constrained point somewhere other
than the intended position. After this commit, the parameters
are modified to satisfy the constraint.
Before this commit, if any rendering mode except "show all occluded"
is enabled, points can be highlighted for corresponding to a DOF
after "Analyze → Degrees of Freedom" but then promptly occluded,
which is confusing.
This is a fairly standard CAD feature; it conveys the same
information and has the same recovery path, without erroring out,
so seems like an obvious win.
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.
Koen Schmeets
EvilSpirit
nabijaczleweli
phkahler
whitequark
Dynamo Dan
Bauke Conijn
Sergiusz Bazanski
Bauke Conijn
Guido