==================================================
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
- 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.
========================================
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.
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.
=====================================================================================
Support for tangency/perpendicularity using angle via point for BSpline with appropriate
endpoint multiplicity so that the endpoints goes thru the first and last poles (control points).
Warning: Not applicable to periodic BSplines.
Warning: Not applicable to any non-periodic BSpline with inappropriate endpoint conditions.
=============================================
multiplicities, degree and periodic are left as non-parameters of the solver, while still allowing certain manipulations to be effected from the solver
in certain situations (for example modifying the multiplicity of start/end nodes when applying G1,G2,G3 constraints between BSplines).
The Ellipse radii solver constraint was reused generalised to MajorAxisConic class.
UI representation of the Equality sign not yet handled (appears on the origin).
- Fixing Hyperbola classes to get CCW emulation (like Ellipse classes).
In Sketcher:
- The Sketcher representation deals with the right branch of the Hyperbola only.
- Solver model is: Center, Focus1 (focus of the right branch), minor radius (b).
- HyperbolicArcRangeToEndPoints code is the one of Ellipse <= Awaiting DeepSOIC help ;)
- ConstraintPointOnHyperbola solver constraint is now implemented and should be working.
- No InternalAligment constraints implemented yet.
===============================================
- ArcOfHyperbola creation method
- Solver representation (undefined moving)
- SketchObjectPyImp (here we still miss the Part->Partdesign conversion)
- Sketch validation for hyperbola
- Hyperbola creation method: shows the "proof of concept", but it is very buggy!!
Notes:
- Missing icons, probably missing geo normal curve implementation - rebasing -
- Fixes to adapt Hyperbola to Derivector implementation and make it compile
==================================================
This fix enables usage of the Eigen SparseQR starting in Eigen-3.3. It optimizes the code enabling it
to work with the new assignation interface of Eigen-3.3, which is more strict than that of Eigen-3.2.
It provides the same optimization for DenseQR code, and omits the extraction of the Q matrix in DenseQR
as this is not used anywhere else.
[NOTE: This is only to be merged after Debian has updated the Eigen-3.3-alpha1 package]
See:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12769&start=30#p104740https://forum.kde.org/viewtopic.php?f=74&t=129115
