- 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!
=====================================================================
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
====================================================
Creation of solver geometry definitions from Part::BSpline geometries and update of solved geometry back.
===============================================
Main Sketch solver parabola addition and update, with exception of the rules of the parabola arc, that will be implemented with the solver constraints.
===============================================
- 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 is an advanced setting just for allowing increased choices to power users that have problems with a given sketch and want to
test different flavours of DogLeg algorithm.
This commit does not change the default behaviour of FreeCAD. It is only intended to give more options to power users.
The advanced solver configuration is extended to support three different Gauss-newton steps for DogLeg:
FullPivLU => h_gn = Jx.fullPivLu().solve(-fx);
LeastNormFullPivLU => h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).fullPivLu().solve(-fx);
LeastNormLdlt => h_gn = Jx.adjoint()*(Jx*Jx.adjoint()).ldlt().solve(-fx);
This setting is applied only to DogLeg. It is applied to DogLeg as normal or redundant solver, if DogLeg is the selected solver.
Selecting a solver different from DogLeg for both normal and redundant disables the setting.
We have been told:
https://forum.kde.org/viewtopic.php?f=74&t=129439#p346104
that our default Gauss-Newton step in DogLeg may not be adequate in general (we generally deal with underconstraint systems
unless we have a fully constraint sketch, and even then it is many times overconstraint at least for redundant solving).
We have been told that maybe these LeastNorm options are more suitable for us (performance set aside). This enables you as power
user to test if it works fine with FreeCAD.
================================================================
A new parameter added to the form in order to control how low a value should be
to be considered zero (how high a value shall be to be accounted for in rank calculation)
Debug for QR pivot threshold is also added.
==================================================================================
The solver has been adapted to use Eigen's SparseQR QR decomposition algorithm. The original
Dense QR implementation is maintained and can be selected using the Advanced Control TaskBox (see below).
The use of SparseQR provides over an order of magnitude improvement in solving time in complex sketches due to
the Sparse nature of the Jacobian matrix of the system of equations.
The solver advanced control is a new TaskBox in the Sketcher that allows to select which algorithms are to be used for
the different solving operations and tweak its parameters. It is not intended to be a user control, but means to debug
solving problems and improve the algorithms and their configuration.
This commit also introduces multithread support for Eigen. Currently it is only limited to products and does not provide
a substantial speed improvement. It is expected to have more multithreaded operations in Eigen in the future.
As a bonus, the TaskBoxes in the Taskbar of the Sketcher remember the last state (collapsed or deployed).
=======================================================================================
ActSketch in ViewProvider dissapears. The temporal sketch (sketch.cpp) for solving is now a data member of SketchObject.cpp (hereinafter solvedSketch). All the solving is concentrated in SketchObject.cpp.
SketchObject provides an interface to expose its solver, as it is still currently needed for some UI operations from ViewProviderSketch, like dragging points (solving rubber bands).
ViewProviderSketch still can select whether to draw the solvedSketch geometry (previously ActSketch) geometry (UI staff) or the SketchObject geometry. Performancewise, it makes sense to separate this two
geometries, as the SketchObject one involves modifying the Geometry and Constraint Properties (including all the undo related functionality), which would mess the undo functinality and incur in a big
peformance penalisation while dragging. One characteristic of solvedSketch is that its geometry is solved, whereas the geometry of SketchObject may not have been solved yet.
These geometries may differ at for the following reasons:
1. The geometry corresponds to an ongoing dragging operation, so solvedSketch has the last calculated dragging geometry, while SketchObject has the one corresponding to initial position.
2. Geometry/constraints were added to the sketch, but no solve/execute was triggered yet (envisioned situation is the future group creation functionality not in this commit).
What do I gain?
- Inserting a (simple) geometry element now costs 1 solver execution.
- Inserting a constraint now costs 1 solver executions.
For reference, in previous versions inserting a constraint involved 5 solver executions.
The following information provide a historical review of the coding of this commit (formed of 10 squashed commits):
This is a general sketch solve call reduction, not only during geometry creation (this commit does not include until here any specific measure to reduce calls on geometry creation, that is another branch)
After a lot of profiling, it seems that the "cause"(tm) that creates so many solver calls is that every update generates a solving in ViewProviderSketch, regardless of the need for that update,
many times with the only aim of providing the DoF for the message dialog and keeping ActSketch in sync with SketchObject in case it is needed (currently UI moving points, constraints,...).
Sketch solver is now a data member of SketchObject instead of a temporal object that gets initilized and destroyed.
This allows:
1. Potentially more synergy reducing calls to setUpSketch (still to be seen, still to be optimized)
2. Allowing SketchObject to access the latest geometry that has been solved => In future, allow objects that use SketchObject to obtain the latest
solved geometry instead the geometry of SketchObject that may still be unsolved. This is relevant for drawing the geometry
No more solving in ViewProviderSketch. Solving a Sketch is now an exclusive competence of SketchObject.
There is however a lot of cleaning to do in ViewProviderSketch
(I mean, not that these commits are making a mess in VPSketch,
but that as a consequence of the changes, it should be possible to
optimize VPSketch, specially moving and drawing methods)
Very useful comment for future developers that may wonder why a solve per constraint just upon addition is necessary.
Added a new function to get the size of the geometry of the instance of the solver object (Sketch.cpp).
The previous way was to extract the geometry, which is costly and error prone, as you have to delete it afterwards.
Inserted comment about the necessity of triggering a Part2D update during edit mode
===================================================================================================
This fixes a bug in the original implementation, that a non-driving constraint value could be
edited by double clicking on it in the 3D view.
It also includes minimal documentation on some functions.
It also includes:
- Color setting for non-driving constraints was not working.
- Settle UI terminology dispute:
* Driving Constraint (normal red constraint)
* Reference Constraint (non-driving constraint)
====================================================================================
It allows to enable and disable a constraint in the constraint list.
When disabled, the constraints current value is shown, but its value is not enforced (it is driven by the other constraints and user interaction).
A disabled constraint can be enabled (as far as it is enforceable, see non-driving constraints to external geometry below).
The sketcher functionality has been extended to support non-driving constraints to external geometry elements. This were previously excluded from
the possibility of creating a constraint on them (as their values depend on other sketches and would be redundant with the unchanged value or conflicting when value is changed).
Now these constraints are created as non-driving, but as they are not enforceable, the UI does not allow you to make them driving.
The constraint filter has been extended to include a Non-Driving constraints category.
Thanks again to Werner for his continuous support, and specially in this case to DeepSOIC, as he pointed towards a much better implementation solution than my original idea.
Fix AngleViaPoint to support new derivative calculation technique.
OpticConstraints: Adding Snell's law. Fix AngleViaPoint to support new derivative calculation technique.
Snell's law constraint added to GCS, but not yet exposed and cannot be
tested.
Since the way CalculateNormal() returns derivatives had changed,
AngleViaPoint constraint needed modifications. Nothing serious.
OpticConstraints: SnellsLaw progress
Addable through python. Fix math. Some quick-and-dirty visual stuff to
get rid of hangs and to see the constraint in action.
OpticConstraints: SnellsLaw: flipping logic fix
OpticConstraints: SnellsLaw progress
Added toolbar button. Allowed editing a datum by doubleclick. New error
message approach during constraint creation.
OpticConstraints: SnellsLaw
OpticConstraints: SnellsLaw: list label improvement
OpticConstraints: SnellsLaw: fix after rebase
OpticConstraints: SnellsLaw: expose helper constraints
Snell's law internally is made of three constraints: point-on-object,
coincident and the Snell's sin/sin. They were all buried under one UI
constraint. Exposing them allows to construct reflection and
birefringence on the point (attempting to do so used to result in
redundant constraints and was often not functional at all).
This commit breaks compatibility with older files.
OpticConstraints: SnellsLaw: small refactor of math
Placing the duplicated code of error and gradient calculation into a
private method.
OpticConstraints: SnellsLaw: fix datum edit unit
OpticConstraints: SnellsLaw: fix datum edit bug
After previous fix, the dimensionless value was not accepted (the
constraint's value did not change, the changes were ignored).
AngleViaPoint: fixes in UI routines + new messages
Goofed undo message in tangency via point is fixed.
Forgotten updateActive, clearSelection have been added.
New more informative error messages for tangent constraint.
AngleViaPoint: using it instead of via line tangency
* replaced the helper construction line for ellipse-to-ellipse and
similar tangency with a point. Using tangent-via-point there
* deleted tangency via line for point-to-point on
(cherry picked from commit 9e3fa8c8de0f49c0ef3c978e015eb905358dbdd9)
AngleViaPoint: internal/external tangency locking
*Added automatic tangency type lockdown for all new constraints (only
for point-wise tangency).
Tangency type is stored in the constraint datum field, as an angle value
shifted by Pi/2 (to be able to treat 0.0 as undefined type).
Added ability to switch the tangency by setting datum value from python
(can be abused by passing arbitrary angle).
Further simplified the tangency related code in Sketch.cpp.
AngleViaPoint: added license to Geo.cpp
AngleViaPoint: renames in Constraints.cpp/.h
Changed some names to increase self-explanatoryness:
bool "remapped" renamed to "pvecChangedFlag"
"ReconstructEverything()" renamed to "ReconstructGeomPointers()"
AngleViaPoint: renames in Constraints.cpp/.h
Changed some names to increase self-explanatoryness:
bool "remapped" renamed to "pvecChangedFlag"
"ReconstructEverything()" renamed to "ReconstructGeomPointers()"
AngleViaPoint: using for endpoint perpendicularity
+ direction lockdown, just as with tangency.
+ quite a lot of old code is gone because of that
AngleViaPoint: perp-ty UI routine made similar to tangent
(Git has made a very messy diff.)
The changes are:
* Perpendicularity-via-point (3-element selection) support added.
* Endpoint-to-curve and endpoint-to-endpoint supports all shape
combinations.
* a bit of code cleanup and clarifications.
AngleViaPoint: placement of perpendicular icon in 3d view
AngleViaPoint: fix: allow setDatum of perpendicular constraint
AngleViaPoint: fix: centers of ellipses are not endpoints
isSimpleVertex used to return false for centers of ellipses and arcs of
ellipses, which made them being accepted for point-to-point tangency.
Should be fixed forever, mo more changes are expected to be necessary
for new types of geometry.
AngleViaPoint: precalc with OCC (work in progress)
Work in progress (not yet working).
Using OCC's tangent to replace implementation of
SketchObject::calculateAngleViaPoint.
AngleViaPoint: fix math: normal now points inwards, where it was intended initially and goofed up.
AngleViaPoint: adding comments to the code
AngleViaPoint: using GeomCurve::closestParameterToBasicCurve for angle precalculation
AngleViaPoint: Py method: changeConstraintsLocking
changeConstraintsLocking(True) - locks/re-locks all lockable
tangency/perpendicularity constraints of the sketch (applicable to
existing sketches).
changeConstraintsLocking(False) - removes locking information from
lockable constraints
AngleViaPoint: final SketchObject::calculateAngleViaPoint
Now, finally, using OCC functionality (thanks Abdullah!), without
composing temporary Sketch object.
Solver iteration limit independent of system size (reduces hangs when
solver fails to converge).
Repaint() instead of update() to force render for every movePoint.
Sketcher: New Constraint AngleViaPoint
* Adding generic CalculateNormal() method
* Reconfiguration of GCS geometry classes: adding a base class "Curve",
that has a pure virtual function CalculateNormal().
* Initial inplementation of the new function.
* adding Vector2D class (I wanted to reuse the existing, but got wierd
compile errors, so implemented a new one... TODO.)
* Adding redirection support into GCS shapes. Adding a Copy method to
GCS::Curve.
* Automatic point-on-object
* Angle precalculation: when AngleViaPoint is added, angle is properly calculated based on
existing geometry.
* Added tangency-via-point using one.
* Implemented placement of tangency-via-point icon in 3d view. Also
affected is the placement of point-on-object icon (since it is very
similar code, it is now shared with tangency-via-point)
* Placement and moving of angle datum
Functions: calculateAngleViaPoint, isPointOnCurve,
calculateConstraintError exposed to python
* Endpoint tangency: All endpoint-to-endpoint and endpoint-to-curve tangency now works
through AngleViaPoint constraint and obsolete code clean up (most procedures
addConstraintTangentXXX2YYY)
Elements that have internal geometry are created with the internal geometry on creation.
It has been under discussion for a long time. Ulrich was in favour (asked for it several times).
DeepSOIC implemented the focus because he hated the poor dragging of the ellipse when empty.
- Change mode so that focus1 is not a point, but two doubles so that visual model and solver model match in number of points.
- Solver fix to deal with reduced constraint partials accuracy (threshold for matrix rank calculation tweak)
- Changes suggested by logari81
- Ellipse introduction button via (center,majaxis extreme, a point in edge), ellipse is always CCW so that Z axis goes in the positive direction of the sketch
- Backwards compatibility with files of previous versions of ellipse not defining a phi angle
- Art by Jim (all the icons you see and the XPMs shown on creation of an ellipse)
- Element Widget support for ellipses
- Box selection for ellipses
- Point on Ellipse constraint based on the gardener's method based on Ulrich's function proposal (radcan simplified, i.e. with simplify_radical sage function)
- Tangent: Ellipse to Line based on DeepSOIC's geometric formulation (radcan simplified)
Sketcher New Feature: Internal Alignment Constraint
- The element to which internal alignment is applied has to be selected last.
- All other elements are added in the order of priority, taking into account existing elements
- Art by Jim (beautiful icons).
Sketcher New Feature: Tool to show/hide/restore the internal geometry of an element
- New functionality for show/hide internal geometry:
toggles between hiding all unused internal geometry elements and showing all internal geometry.
The restore function is implicit to the showing all internal geometry
Sketcher New Feature: Arc of Ellipse support
- Part::Geometry + Python implementation
- ArcOfEllipse creation method
- Art by Jim (all the icons you see and the XPMs shown on creation of arc of ellipse elements)
- Sketcher Element widget for ArcOfEllipse.
Bug fix: Select elements associated to constraints works now for foci internal alignment constraints
+ change value of H_Axis and V_Axis constants
+ external Geometry transferred in reverse order from SketchObject to Sketch
+ replace construction property with external property in GeoDef
+ support negative geometry indices in the Sketch class
+ whitespace and variables naming improvements, typo fixes
git-svn-id: https://free-cad.svn.sourceforge.net/svnroot/free-cad/trunk@5340 e8eeb9e2-ec13-0410-a4a9-efa5cf37419d
