======================================
* Refactor the code for all GeomTrimmedCurve and non-periodic BSplines in a single block, adding
support for arcs of hyperbola, parabola and B-Splines.
* Refactor the code for periodic curves (circle, ellipse) in a single block, adding support for
periodic B-Splines.
* Add support for trimming limited by external geometry
* Trim deletes a geometry if intersections are detected and nothing would be left after trimming
* Trim deletes a geometry if no intersection are detected
Bonus:
* Function addConstraint moving the constraint instead of cloning it again
* SketchObject::seekTrimPoints as a wrapper of Part2DObject::seekTrimPoints providing
a correct handling of GeoId indices.
* Helper functions addConstraint/createconstraint to create new constraints and move them
into the Constraint property
* New getGeometry with templated return type defaulting to Part::Geometry.
====================================================================
When the ellipse to be projected and the sketch plane are parallel, the original code
by shermelin provided for a translation of the original ellipse, which would be the best solution
if it weren't because the Sketcher, internally, works under the assumption of a normal vector to the
sketcher plane being (0,0,1). If the original ellipse is parallel to the sketch plane, but the sketch
plane is not the XY plane, the copy and translation would result in a ellipse not in the XY plane of the
Sketcher. Then the sketcher internals will not properly consider its dimensions.
The solution applied here is to default to the general method for non-parallel planes.
It solves:
https://forum.freecadweb.org/viewtopic.php?f=3&t=55284#p477522
========================================================
Users chennes and hyarion made me aware of this covereity issue:
Fixes Coverity: geoit can be end() when dereferenced
https://github.com/FreeCAD/FreeCAD/pull/4429/files#
When analysing the block where the dereferrencing appears, it
appears that it is a left-over that no longer makes sense:
- The algorithm classifies block constraints into those that are
not affected by any other driving constraint and those that are
affected by other driving constraints.
- The offending block deals with internal aligned geometry, thus
per definition has a driving internal alignment constraint, for which
the previous block already set the need of post-analysis.
- No matter what, the geometries, the complex one and the internal one
will have at least the driving internal alignment constraint, so they
cannot become "not affected by any other driving constraint".
- If the geometry had a block constraint on it, it was already added for
post-analysis in the previous block. If it did not have one block constraint,
the fact that it is internal aligned geometry is an irrelevant consideration.
Probably there was a point during development when this made sense, but with
the current post-analysis, it does not appear to make sense anymore. So the
block was removed.
This commit adds a unit test for blocked geometry (new block constraint).
Fixes Coverity issue:
CID 316539 (#1 of 1): Uninitialized scalar field (UNINIT_CTOR)
uninit_member: Non-static class member lastHasPartialRedundancies is not initialized in this constructor nor in any functions that it calls.
=================================================
Knot position is not calculated by the solver, but by OCCT when updating the
b-spline to conform to given pole positions, as mandated by the solver. Before
this commit, all constraints driving and non-driving operating on the knots required
and extra solve (from advanced solver dialog, or from the Python console), or a recompute
to be recomputed.
This commit introduces transparently re-solving at Sketch.cpp level if B-Splines are present,
so that when the Sketcher mandated solve returns, the geometry is fully solved.
========================================
The geometry state stored in the geometryFacade is modified following a mutable model
(without setting the Geometry property on Constraint change), in order to avoid coupling
the addition/removal of a constraint with a change of the Geometry Property.
This design decision however interferes with the ability of the Geometry property to restore
the correct geometry state upon redo/undo.
While such a situation is rare in the case of Internal Alignment geometry, because constraint
addition/removal is performed with the corresponding geometry addition/removal (within the same
transaction. That is not the case with the Block constraint (or another future general case where
the geometry state may be applied).
This commit leverages the synchronisation mechanism already in use for non-properties (e.g. external geometry or
vertex indices) to check and synchronise geometry state upon undo/redo and restore.
Bonus:
- addGeometryState is refactored to separate the checking logic from the setting logic.
Currently the sketch fillet tool deletes any constraints associated with
the two lines to be filleted. By leaving a vertex at the intersection,
we can instead preserve most constraints in reasonable ways.
Sketch fillet horizontal and vertical point-to-point constraint support
Also better future compatibility for point constraints, and some minor tweaks.
============================================================================
This specific constraint removes the free parameter of the previous implementation. This solves:
https://tracker.freecadweb.org/view.php?id=4501fixes#4501
However, this implementation of equal size produces zero gradients when coordinates of lines are aligned,
e.g. vertical or horizontal. These zero gradients, which are mathematically right ruin the diagnosis, which
regards corresponding elements as fully constraint (because they are locked from a solver point of view), when
they are simply locked, but are movable and constrainable. For this, when the rightful gradient is small enough
(<1e-10) it is substituted by a surrogate gradient of 1e-10, which solves the problem with the diagnose, which
treats as zero only values under 1e-13 (pivot threshold used in QR decomposition).
This special behaviour fixes the wrong detection here:
https://forum.freecadweb.org/viewtopic.php?f=8&t=53466&start=40#p464168
It also fixes this one:
https://forum.freecadweb.org/viewtopic.php?p=468585#p468587
=========================================================================================
- Long overdue refactor to avoid repetition during save/restore and copy.
- New interface to notify an extension when it is attached. It also enables the extension to gain
a pointer to the geometry container. This is intended to extend the functionality already existing
in Part::Geometry.
================================
New deleteGeometries function, according to the comment should the same
as deleteGeometry but at a time. However, this is not accurate, as deleteGeometry
deletes any internal geometry associated to the provided GeoIds, whereas
deleteGeometries does not delete that internal geometry.
Solution:
Split deleteGeometries into two different functions:
1) delGeometriesExclusiveList
2) delGeometry
The former will not delete associated internal geometry. It is more efficient, but
it is the resposibility of the caller not to leave internal geometry undeleted.
The latter, implemented in terms of the former, will delete associated internal
geometry too.
As a bonus, the latter will also remove any GeoId duplicates.
=========================================================================
Sometimes it happens that malformed constraints are arrived to.
Example:
https://forum.freecadweb.org/viewtopic.php?f=3&t=53780#p463271
It is not the first time. They usually go under the radar and when they are
detected is too late to know what caused them. The user is desperate too.
This commit makes malformed constraints to prevent the recompute of the project.
This is in the best interest of the user.
========================================================
This property stores whether a Sketch has 0 DoF or not upon solve.
It is serialised to disk, enabling a recently loaded project to have an accurate
populated property even before the first solve() call.
========================================
Previous versions relied on a heuristic that proved insufficient for cummulative use of the Block constraint.
The effect is that Block constraints stopped blocking, which is a major bug, as it lead to inadvertedly moving
geometry that was supposed to be blocked.
Fixes:
https://forum.freecadweb.org/viewtopic.php?f=13&t=53515&start=30#p461215
(Thanks Chaospilot)
Know problems with old block constraint (v0.18):
1. If driving constraints were present, they were ignored if inserted before the block constraint (to avoid
redundancy/conflicting). They resulted in
Principles of Working of the new block constraint:
1. Handling of the new block constraint is based two processes, a pre-analysis and a post-analysis. Pre-analysis
works *before* diagnosing the system in the solver. Post-analysis works *after* diagnosing the system in the solver.
2. Pre-analysis is directed to detect geometries affected *exclusively* by a block constraint. This is important
because these geometries can be pre-fixed when creating the solver geometry and constraints before GCS::diagnose()
via initSolution() AND because if no other constraint affects the geometry, the geometry parameters won't even appear
in the Jacobian of GCS, so they won't be reported as dependent parameters (for which post-analysis would be of no use).
3. Post-analysis is directed to detect Geometries affected *not only* by a block constraint. This is important
because pre-fixing these geometries would lead to redundant constraints. The post-analysis, enables to fix just the
parameters that fulfil the dependacy groups.
4. Post-analysis basically identifies which parameters shall be fixed to make geometries having blocking constraints
fixed, while not leading to redundant/conflicting constraints. These parameters must belong to blocked geometry. This
is, groups may comprise parameters belonging to blocked geometry and parameters belonging to unconstrained geometry. It
is licit that the latter remain as dependent parameters. The former are referred to as "blockable parameters". Extending
this concept, there may be unsatisfiable groups (because they do not comprise any bloackable parameter), and it is the
desired outcome NOT to satisfy such groups. It must be emphasised that there is not a single combination of fixed parameters
from the blockable parameters that satisfy all the dependency groups. However:
1) some combinations do not satisfy all the dependency groups that must be satisfied (e.g. fixing one group containing
two blockable parameters with a given one may result in another group, fixable only by the former, not to be satisfied).
This leads, in a subsequent diagnosis, to satisfiable unsatisfied groups.
2) some combinations lead to partially redundant constraints, that the solver will silently drop in a subsequent diagnosis,
thereby reducing the rank of the system fixing less than it should.
5. The implementation rationale is as follows:
1) The implementation is on the order of the groups provided by the QR decomposition used to reveal the parameters
(see System::identifyDependentParameters in GCS). Zeros are made over the pilot of the full R matrix of the QR decomposition,
which is a top triangular matrix.This, together with the permutation matrix, allow to know groups of dependent parameters
(cols between rank and full size). Each group refers to a new parameter not affected by the rank in combination with other free
parameters intervening in the rank (because of the triangular shape of the R matrix). This results in that each the first column
between the rank and the full size, may only depend on a number of parameters, while the last full size colum may dependent on
any amount of previously introduced parameters.
2) Thus the rationale is to start from the last group (having **potentially** the larger amount of parameters) and selecting as blocking
for that group the latest blockable parameter. Because previous groups do not have access to the last parameter, this can never
interfere with previous groups. However, because the last parameter may not be a blockable one, there is a risk of selecting a parameter
common with other group, albeit the probability is reduced and probably (I have not demonstrated it though and I am not sure), it
systematically leads to the right solution in one iteration.
GCS: Change dependency group from std::set to std::vector to prevent reordering of parameters.
========================================
Report:
https://github.com/FreeCAD/FreeCAD/pull/4183https://github.com/realthunder/FreeCAD_assembly3/issues/387
Problem:
renameConstraint() previously implemented exclusively in SketchObjectPyImp.cpp,
will change the Constraints property without updating the solver. A prospective
drag operation would rely on a deleted pointer constraint which leads to the
crash.
Solution:
- mark the solver status as needing an update
- leverage new through sketchobject r/w interface to ensure solver is synchronised
before the temporary move operation starts
Bonus:
move the core of the function to SketchObject.cpp so that input data validity
check on constraint change is inhibited.
=========================================================
-> Split read and read/write operations
New interface to access the solver object (Sketch) of SketchObject is now read only (const):
const Sketcher::Sketch &getSolvedSketch(void) const;
-> Encapsulate solver r/w access in SketchObject
Rationale:
- r/w access (access to non-const functions of the solver) leads to unsynchronised solver status.
- Before this commit there was a non-enforceable shared responsibility between ViewProviderSketch
and SketchObject.
- This commit centralises r/w access in SketchObject and SketchObject takes responsibility for doing whatever
necessary so that the solver is synchronised as appropriate.
- For read-only access (const functions) it is possible to use at ViewProviderSketch getSolvedSketch() returning
a const reference to the solver object.
- As it regards the advanced solver configuration dialog, it has been modified to configure by const-casting that reference. This
is not optimal, but it is deemed acceptable, because it should be rewritten sooner or later to include only useful information
and the configuration probably centralised in an individual configuration object, possibly compatible with several solvers
(e.g. DeepSOIC's ConstraintSolver too).
