- 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.
===================================
In the unusual event that endpoint knot multiplicity is edited, avoid trying to force the bspline end-point
to match the corresponding control point (aka pole), as this leads to unsolvable sketches.
==============================================
This commit is intended to allow to early merging to master of BSpline support. Parts of it will be reverted when a more advanced solver implementation is available.
The intention is to have an advances solver implementation in the future.
This commit cripples part of the potential functionality, but allows a very simplistic solver structure (no de Boor, no recursion).
In particular:
1. Knots are not solver parameters and the solver acts as if such a parameter did not exist.
2. For non-periodic case, the start point and the endpoint coincide with the first pole and the last pole respectively. This is only valid under certain first and last
knot multiplicity. If the user manually changes this multiplicities, the sketch will remain unsolved. For the periodic case, end and start points are not even solver
parameters as an end and start point is an ilusion and we really do not care where that happens. It is not reasonable to ask the user to constrain where this point should
be.
