=========================================================================================================
Former mechanism with hasDependentParameters is not flexible enough for the new kind of information.
This commit further enhances the calculation of dependent parameters and dependent parameter groups by
caching the parameter-geoelement (GeoId, PointPos) relationship during geometry creation.
This commit provides traditional information whether a parameter is dependent via SolverGeometryExtension. New
enhanced information about groups of dependent parameters are available via the Sketch API.
=============================================================================================
This commits removes the Geometry construction data member and adapts sketcher code to use
GeometryFacade to access construction information via the SketchGeometryExtension.
========================================================================
Until now BSpline poles were circles relying on physical length units. This lead to several
problems:
- While the BSpline weight follows the circle size, weights do not have length units, but are adimensinal
- As representation of the BSpline depends on the physical size of the circle, the numerical value to be
set to a pole circle differs from the numerical value of the weight.
The present commit:
1. Separates pole circle representation (physical size), from the numerical value used in the radius constraint,
so that the value in the constraint is the weight, the value representation is a factor of the weight value (in this
commit is getScaleFactor(), but this will change in the next commit). Dragging accounts for this scale factor too.
2. While Radius constraint button is used to constraint a B-Spline weight as before, this creates a Weight constraint,
which is a new type of constraint. This is done so that the value is truly adimensional and is so presented in all kind
of editors that rely on the units indicated by the constraint. It is obviously also shown as adimensional (thus without units),
in the 3D view and in the datum dialogs.
3. Because the circle of the pole of a B-Spline is not a geometric circle, but a graphical representation of the pole and how
it affects the corresponding B-Spline, constraint creation commands are limited so that no point on object, tangent, perpendicular
or SnellLaw constraints can be created on a B-Spline weight circle. This is also the case for the Diameter constraint, which won't
accept the circle. Equality constraints work either on only circles or only weights, but not on a mixture of them.
Bonus: This commit fixes a bug in master, that using the select equality constraint then click in two geometric elements mode, you
could make a circle equal to an ellipse resulting in malformed solver constraints.
========================================================================================
Until this commit, B-Spline knots were stored, and checked at solver level as sketch points GeomPoints having the
construction status set to true.
This behaviour is removed to eventually enable normal non-construction points to define the shape out of edit mode.
This commit leverages the new mechanism for the solver interface.
- Support for addition of driving information to GCS constraints
- Support for keeping track of value parameters of driven constraints
- Support for getting which QR algoritm is being used at GCS level
===========================================================================
Block constraint is naturally redundant/conflicting with almost any other constraint applied to an edge (certainly with constraints operating only on that element).
As such, a block constraint will have very little applicability in absence of a way to handle this redundancy/conflicting. For example, in the case of a BSpline all its
internal geometry (construction circles on poles and its constraints) would have to be removed before locking. This would mean that it is not possible to define the BSpline shape
and then block it, as when removing the internal geometry the shape would be lost. In other cases, like temporally blocking to avoid that a part of the sketch moves while performing some
operation with the idea of afterwards unblocking it, it would mean removing all constraints, to add the block constraint, then perform the action, then remove the block constraint and manually
constraint it again.
Handling this situation in a user expected way means ignoring certain constraints (those causing the redundancy/conflicting), so that the solver is not aware of them and does not complain. However,
generally ignoring those constraints has a negative effect, in that constraints applied by the user on already blocked geometry, or constraints that otherwise lead to a conflicting or redundant
situation as a consequence of actions (further constraining) after the Block constrain is applied are ignored, thereby not properly informing the user of this situation, which is undesirable.
This new mechanism takes account on the position of the constraints relative to the involved blocked constraint(s). As such, redundant/conflicting constraints that were added before the Block
constraint are ignored, whereas those constraints that lead to a redundant/conflicting situation and added AFTER the block constraint was already in place, those are not ignored and are reported
accordingly.
=============================================================
Just amazed it was working "so well" without never reseting to zero this.
It might bring advantages and close bugs... who knows!
===========================================================================
Cleaning up ViewProviderSketch, as relative mode is never used for points.
Adapting the recalculation of the initial solution only to non-relative cases.
For relative movement cases (movePoint with relative=true) no cases where such a solution will be advantageous have been identified
and applying a similar solution involves changing the current behaviour too much, as to run the risk of introducing further bugs.
Decision to be revised if such cases where an advantage can be found are discovered.
=====================================================================
fixes#1734
Upon dragging, the initial solution is first calculated and them DogLeg is left with the work of solving for a solution next to the initial solution.
When the change is too big and the gradients are no longer accurate to continue dragging, the dragging flips and jumps.
The solution offered here is, not to update always the solution, as this also creates artifacts, but update it if the dragging goes beyond 20 times the initial dragging distance.
https://forum.freecadweb.org/viewtopic.php?f=3&t=7589#p203580https://forum.freecadweb.org/viewtopic.php?f=3&t=7589#p203712
=======================================================
Introduction of construction points as fixed solver entities introduced this bug, as there was no specific code to check for points as they were by default construction.
Internal geometry knot points, which were added as fixed parameters to the solver according to a previous commit, are tracked in the corresponding bspline as solver level,
without being a parameter to the solver, and upon solving, the position thereof is updated by means of OCC functionality.
This allows to show the knot points and solidarily move them when moving a bspline.
