==================================================
The solver uses some heuristics to determine the "redundant to remove" and notify it to the user.
Basically it would pick the solver redundant constraint that affects most groups of redundants (popularity contest).
In the simple cases, all the redundants are equally popular and the popularity contest is untied by using the tagid (let say for simplicity it is the number at sketcher level Constraint3, the tagid=3).
This means that in simple cases, the solver systematically decides that the redundant constraint to handle from those showing a linear dependency is the one appearing the last.
This commits changes the way to untie the popularity contest, by giving more priority to those sketcher constraints that need a lower number of solver constraints (in other words,
those constraints that remove a lower amount of DoF). In case of tie, the tagid is then used to break the tie.
At least:
fixes#3434fixes#1557
- 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
- Improve Debug information.
- Support for addition of constraints with driving information for the solver constraints.
- Removal of the driven constraints from the Jacobian for QR decomposition
- Removal of the value freewheeling parameter from the Jacobian for QR decomposition
- Full detection of dependent parameters where DoF are present for Dense QR.
=================================================
With the support for external geometry during carbon copy, it was introduced a way for creating inter-part/inter-body links. See:
https://forum.freecadweb.org/viewtopic.php?f=10&t=27700&p=223736#p223736
This commit closes this door, while still allows carbon copy with external geometry support within the same body.
=======================================================
set/get/toggle python interface to enable to set the virtual space status of a constraint via SketchObject.
=====================================================================
The constraint class has been extended so that every constraint knows and serializes whether it is in virtual space or in normal real space.
===========================================================================
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.
========================================
When writting solver implementations it has to be taken into account that the normal is not to be provided in the sense of the curvature, but to
the left when walking a curve from start to end.
https://forum.freecadweb.org/viewtopic.php?f=10&t=26312#p209486
This commit has impact on all the previous files using bspline and endpoint to endpoint tangency.
A work-around is to delete the tangency and do it again.
================================================================================
When transfering constraints to coincident points on deletion of geometry, a tangency/perpendicular constraint
cannot be blindly transfered as the destination edge may not be tangent/perpendicular leading to unexpected behaviour.
However, the user does expect that something that was coincident with such end-to-endpoint constraint (which implicitly includes a coincident constraint)
remains coincident after deletion. Therefore, the change of type to coincident.
This implicitly solves the problem of representation of constraints leading to a crash in coin3d.
fixes#3291
=============================================================
Just amazed it was working "so well" without never reseting to zero this.
It might bring advantages and close bugs... who knows!
