===================================================
The bug was introduced by myself here:
47c0859c1b
[code]
void SketchObject::onDocumentRestored()
{
try {
- rebuildExternalGeometry();
+ if(Support.getValue()) {
+ validateExternalLinks();
+ rebuildExternalGeometry();
+ }
Constraints.acceptGeometry(getCompleteGeometry());
}
[/code]
The issue is that "rebuildExternalGeometry" calls "rebuildVertexIndex". So for any sketch not having external geometry, if you open it, select everything and hit del, you will have a crash because
I effectively removed the creation of the index in this dossier. You won't have one if you do anything rebuilding the index before hitting del, like creating geometry, though.
================================================
Issue reported inter alia here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12380#p99456
How to reproduce:
1. Make an external geometry hexagon (make a hexagon, pad it, make a sketch on a hexagonal face and make all the lines external geometry)
2. Box select the external lines and press "del"
On the first pressing of "del" 3 lines were deleted and 3 remained, select again, on the second press 1 remains, select again, on the last press all are deleted.
Why?
Internal and External geometry were handled together in a single set. Group deletion of geometry is effected starting from the highest index,
so that upon deleting an element, the index of the remaining elements does not change. Handling both groups together caused that the external geometry
was actually deleted on the inversed order (as they are (decreasing) negative values for representation, but increasing positive indexes in the external geometry array).
Solution:
Internal and External geometries are handled separatedly
+ fix SoAutoZoomTranslation and SoZoomTranslation to get correct scaling factor
(do not rely on active view because this can be the wrong one and thus delivers wrong results)
=================================================================
First bug: Inability to create links to external geometry as described here:
http://forum.freecadweb.org/download/file.php?id=16668
Second bug: FC crashes on changing the support after having imported external geometry as described here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12380
and solving this ticket:
http://www.freecadweb.org/tracker/view.php?id=2225
Solution to first bug:
If for some reason a sketch ends up having a list of external geometries (property) that can not be recreated (rebuilt),
they remain latent, do not show the external elements in the elements widget or in the screen and prevent adding the
elements again.
In cases where the saved file contains invalid external geometry links (which will give raise to a handled exception that would prevent external geometry creation),
this condition gets detected during restore and the invalid links are deleted before external geometry creation, so as to allow the rest of external links to be recreated.
Solution to second bug:
It is also related to invalid external links (the link was existing, but upon change on the support, it is possible that an external edge is no longer valid, reduction of edges in support).
This situation is detected upon entering into edit mode, and the invalid ones are deleted.
Note that there is still the possibility for the user to remap an invalid sketch BEFORE editing, if the remapping is successful, it may not be necessary to delete links (all depends on the
specific case).
==============================================================================
What is this?
method
getCoincidentPoints
actually only included (as indicated in the documentation comment) those points coincident by a single constraint.
That is not "all the coincident points".
However some methods currently using it are expecting exactly that (coincident points linked by a single constraint).
A new method is introduced:
const std::map<int, Sketcher::PointPos> getAllCoincidentPoints(int GeoId, PointPos PosId);
that provides all the points coincident with the given one, directly (via a single constraint) or indirectly (via multiple coincident constraints).
The old method is renamed to:
getDirectlyCoincidentPoints
So as to have a more meaningful name to differentiate between both methods.
======================================================================
1. SketchObject::arePointsCoincident upgraded to check for indirect coincidence.
2. Coincidence constraint creation now checks for indirect coincidences and avoids
creating redundant coincidence constraints (for example during box selection).
=====================================================================================
This fixes a bug related to:
http://www.freecadweb.org/tracker/view.php?id=2093
that during creation of a geometric element if a vertical/horiz autoconstraint is to be enforced, it is not enforced if the endpoints of the geometric element under creation are
coincident with external geometry.
According to the discussion here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=12254&sid=eacf5bdee068cb71cc54dc5a62a6849d&start=20#p99359
this fixes the bug.
It does not fulfil the request on the ticket as it was decided to still allow an explicit addition of a vertical/horizontal constraint, as
it may be needed in some cases and the user expects to be able to add them, even if it will lead to an overconstrained sketch.
How to reproduce?
1. Create a rectange
2. Pad it
3. Create a new sketch on a face
4. link two corners as "external geometry" (but not the ones of a diagonal)
5. Create a line coincident with the first and second corners, so that the line is horizontal or vertical
In master it will force horiz or vert leading to a overconstrained sketch.
With this patch, the horiz/vert will not be enforced in this case.
==================================================================
A recent improvement was to allow to create an object (several geometric elements) as construction lines
by providing an additional parameter as true (that defaults to false).
This introduced a bug, that when a list of geometries mixing construction and normal lines was added (with the parameter as false),
construction lines would be converted to normal lines.
This fixes the bug.
===============================================
Support for mirroring a full sketch.
A dialog appears allowing to select X, Y axis mirroring or mirroring about the origin of the sketch.
=========================================================
This commit provides with a single toolbar button to select between a copy and clone.
Copy just copies the constraints.
Clone modifies the dimensional constraints to geometric constraints, so that the constrained geometry follows the changes in the original object.
=============================================================
This commit allows the user to select in advance whether he wants a simple copy or a clone.
This involves substitution of dimensional constraints in the copies by equality and parallel constraints.
Terminology change for Arrays, now it is Rectangular array
==========================================================
- Support for copying geometric elements in the sketcher with Ctrl+C (or using the still missing icon). It will show you the vector of displacement from the
"reference point". The reference point can be chosen by the user (although it is not necessary to do it so) by making the point the user wish to be the reference point
the last selected element. It conveniently incorporates "autoconstraints", so that you can make this point (the one of the copy) directly coincident with any other point in the sketch.
- Python 2D array command modified to lock elements position using construction lines and constraints.
- Support for different spacing between u and v directions (the direction of the cols and the direction of the rows).
- Support to avoid copying DistanceX and DistanceY constraints when used for locking a point. This means that if the geometry that you copy(array) is
fully constraint, the resulting 2D array is also fully constraint.
- UI support for creating 2D linear arrays in the sketcher.
- Bug fix in python addArray, wrong line copy startingpoint calculation fixed.
How to create a 2D array in the sketcher:
1. Select your geometric elements.
2. Click the button
3. Fill in the rows/cols and preferences on spacing and constraining each element of the array
4. Click Ok
5. Define the direction of the cols of the array and click
========================================================
For a while End-to-endpoint tangency is implemented via AngleViaPoint constraint. The code was not recalculating the "value" of the constraint in this case.
This also forces to set the geometry first and constraints afterwards, as the AutoLockTangencyAndPerpty function requires a valid GeoId to operate (not a big deal anyway).
Correction of the condition to allow the symmetry when a single line is mirrored about a point pertaining to a geometric element.
======================================================
Two new python commands (no UI yet).
Copy: Copies the geoids in a list by a displacement given by a Vector3d:
App.ActiveDocument.Sketch001.addCopy([0,1,2,3,4,5],App.Vector(150,150,0))
Array: Copies the geoids in a list cols times in the displacement vector
direction and rows times in the perpendicular to the displacement vector:
App.ActiveDocument.Sketch001.addArray([0,1,2,3,4,5], App.Vector(150,150,0),3,4)
N.B.: You need to recompute or solve to update the view
App.ActiveDocument.recompute()
or
App.ActiveDocument.Sketch001.solve()
=====================================
Creates geometry symmetric to the selected one with respect to the last selected point or line.
It does not support the following constraints:
- Angle
- Horiz/vertical distance
- SnellLaw
Horizontal and Vertical (directional) dimensions removed from the the copying process when created
on a single edge (by picking one edge instead of two points), i.e. Constraint involving only one GeoId at "First".
=============================================================
http://forum.freecadweb.org/viewtopic.php?f=10&t=11341&start=80#p92820
...I already have a minor bug, if you insert a conflicting dimensional constraint,
the solver information is not updated, the work-around is to hit "Manual Update".
=========================================================================
What?
Sometimes this widgets where out of sync
Why?
Under the update only when it is redrawn policy, sometimes only one of them, i.e. the one associated with the property
triggering the updateData was updated.
Solution:
Both are updated after every redraw.
It also complements the previous bug fix related to crash on deleting, by updating the widgets to account for the deleted geometry.
==========================================================
Fixes the one reported by JMG here (Thanks!!):
http://forum.freecadweb.org/viewtopic.php?f=3&t=11508#p92693
Why?
- The newly introduced redrawing policy requires that the solver geometry matches in number the sketchobject geometry.
- Most (all) problems with updateColor or getGeometry returning a null pointer are related to an out of sync between UI geometry and SketchObject geometry.
General solution:
- In other bugs, a missing "solve()" is the problem, once the solver and sketchobject geometries have the same number, an SketchObject::OnChanged triggers
a VPSketch::draw (via VPSketch::updateData) which updates the UI geometry to match SketchObject geometry and then the problem does not arise.
Particular solution:
- In this bug, the problem is not a missing solve, but the fact that the solving was not succesful and did not synchronize the geometries, however triggering a
draw() on unsuccessful solving, syncronizes the UI geometry with the SketchObject geometry and the crash is gone.
=======================================
The SparseQR is set as default method. However, in accordance with the previous commit, only if a new enough Eigen library is present will SparseQR be executed.
If the library is old and SparseQR can not be reliably used, FC will automatically fall back to use DenseQR.
This ensures that users that have a new enough library > 3.2.2 will benefit from the performance increase, while the users that use older library will still have
the same performance as in legacy FC.
==========================================
For Eigen>=3.2.2 SparseQR is compiled in
For older versions SparseQR is not compiled in and if the option is selected FC gives a warning in the console and falls back to DenseQR.
This ensures that a user can get a sketch solved and work normally even if SparseQR is selected and the Eigen version is too old to support SparseQR.
================================================================
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.
===================================
Eigen currently only provides multithread for matrix products. It has been reported that it is even slightly slower than single-thread.
Therefore, temporarely the code is commented out. If Eigen ever implements multithread for QR decomposition, then it will make a lot of
sense to enable this.
==================================================================
It allows the view sketch perpendicular button to be active during continuous mode creation (and if activated does not exit the continuous mode).
Feature requested:
http://forum.freecadweb.org/viewtopic.php?f=10&t=11051&start=30#p92256
=============================================
EigenQR branch 3.2 with debug code fails an assertion. The result is generally ok if we disable the assertions, however it
eventually leads to memory leakage.
This commit reenables Eigen's assertions when in debug mode, and sets dense QR as default QR algoritm until Eigen's issue is solved.
==================================================
- ternary operator usage was making BFGS not to iterate
- Amount of debug information for BFGS increased
============================================================
This enables to exit the sketch by clicking the corresponding toolbar icon, even when in creation mode, i.e.
with a drawHandler active.
Requested here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=11051&start=30#p92181
===============================================
- Increased solver debug
- Changing default values from float to string, as float has "only" a precision of 12 decimals.
- Default values as macros
===========================================
- Improvement Debug added to redundant solving in Iteration Mode, to show when just one iteration solved the system
- Fix wrong QR information on empty sketch
===================================================
I makes the advanced solver taskbox by default disabled (not shown) and provides
a setting in Preferences->Display->Sketcher to enable it.
==================================================================================
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).
===============================================================
The sketcher crashed for example during effecting a fillet operation.
Cause:
The ElementsWidget/ConstraintWidget was being updated as a consequence of adding/removing geometry/constraints, and it was effecting
a selection after the update, in cases where the geometry in the screen was not being redraw (because the sketchobject was still unsolved), therefore
trying to select an element that according to ViewProvider did not exist (as it is created during redraw).
Solution:
Widgets update when their properties changes, provided that a redraw is effected (which actually also saves some (negligible) time, as they are only updated when they should).
======================
In no update mode, the last constraint was not enforced. The DoF was not properly shown.
The trim operation it is always solved at the end now if in no recompute mode.
============================================================
- Crashing on deleting line on fully constraint box
As a bonus:
- Fully constrained sketch not shown in green on opening the sketch
================================================================
A last moment change to regulate redrawing introduced this issue (reducing the redrawing to the cases where the solver geometry and the sketchObject geometry are equal).
This change also solved other issues.
The case of adding external geometry is special because the DoF is the same after insertion, yet there is an insertion (as opposed to the toggle case, where there is a change but no insertion).
SketchObject has been adapted to require a solver update before moving (which also caused a non-yet-reported crash, a separate bug), and CommandCreateGeo has been adapted to trigger a solve with
auto update mode disabled. This solve is a very low cost one as the geometry is already in place.
===============================================================================================
Group creation:
- complex geometries (consisting of several geometry elements and constraints) have been rewritten to use python list (one command call for all geometries and constraints)
- Ellipse ExposeInternalGeo as group creation of geometries and constraints
To construction mode creation:
- addGeometry python and SketchObject functions modified to take an additional optional parameter "construction" to create the geometry/geometries directly as construction.
In addition to the shorter form, this helps generate less amount of onChange propagation and Redraws.
- all the geometry creation commands in CommandCreateGeo.cpp have been rewritten to use the new construction argument. This includes modifying the regular polygon script to
take a new optional parameter to create geometry as construction in addGeometry.
- special care is taken in group creation not make construction points
- Show/hide internal geometry implemented with this option.
To solving:
- the solve previously included after every geometry addition (when in no Update, e.i. no Recompute mode) has been removed and each Gui::Command calls either an UpdateActive
for recompute or a Solve in no Update mode. This is behaviour is less intrusive and uniform with group creation.
Bug fixes and redrawing reduction:
- Fixes the CheckId exception problem. The solution also helps further remove redraws during creation of complex geometry (e.g. Slot)
- Fixes touching the sketch by only opening it.
- Code clean up.
===============================================
The help button next to the close button in the Task dialog is now removed.
It was requested that this button is removed as it is inconsistent with other help sources and it is not implemented.
================================================
Fixes a bug in master that the dependent 3D geometry would not update on Undo (in Auto update mode enabled).
Undo and redo signals are handled by ViewProvider in order to introduce an recompute or solve() of the sketchObject
as determined by the Auto Update Mode in order to update DoF and dependent geometry if necessary.
=================================================================
The new solving architecture focus all the solving on the SketchObject.
Actions that change the DoF can call execute() (i.e. recompute) or Solve() depending on whether a full recompute of dependent features is required or not.
In both calls the geometry of the solver is updated with the geometry of the SketchObject.
The only additional call that calls the solver is MovePoint. This function may or may not update the geometry of the SketchObject
(as now it is intended for UI related solving, like dragging, rubberbands, ...).
In operations that do not involve a change of DoF and therefore do not require a sketch solving, it may happen that as a side effect of moving a point, the
geometry changes to old behaviour. In order to avoid that, those SketchObject operations, as for example setConstruction or ToggleConstruction,
must set a flag "bool solverNeedsUpdate" to true. In case a movePoint is executed before any other solver execution, the geometry is first updated and then
the moving is performed.
So to keep in mind when programming sketcher operations:
-> Need recompute (UpdateActive)
-> Need solving because DoF changed (solve())
-> The operation does not change DoF (set solverNeedsUpdate to true)
=======================================
- Fixing toggle AutoUpdate Mode
- Fix Auto-Update Sketcher tools
- Fix missing createGeo recomputes
- Missing constraints recomputes fixed
Various fixes for non-Update mode:
- Fixes lack of update upon entering a conflicting datum constraint.
- Fixes lack of update upon setting the reference/driving status of a constraint
- Added tooltips to buttons
=========================================================
Upon deletion of a constraint, the constraint was still enforced for UI operations (dragging of a point) and DoF was not updated.
======================================================================================
There is a checkbox, default disabled, that makes the commands NOT to generate a recompute after each.
This means that if you are editing a sketch that is used to generate a pad or pocket, if the checkbox is
disabled, the dependent objects do not get recomputed.
There is a button next to it to force a manual recompute, in case it is needed.
If the user wants the previous behavior, he only needs to activate the checkbox. The previous status of the box
is restored upon entering a sketch in edit mode.
It is remarkable the case of the Fillet and Trim
On changing ActSketch (solvedSketch) to SketchObject and making movePoint not systematically update the geometry, the solving in MovePoint was confronted with solving for "the last solved geometry",
which is the default behaviour, in some situations (Fillet and Trim) where geometry had changed at SketchObject level, and was the subject of the moving actions.
MovePoint has been updated to take an extra optional parameter, to force the change in solved geometry in those situations.
Some other minor bug also fixed in Fillet creation in CommandCreateGeo.cpp
This commit also introduces conditional recompute on some operations of:
- constraints
- geometry creation (reubication of update active to comprise the autoconstraints within a single UpdateActive)
=======================================================================================
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
==============================================================================
Now you can switch from one tool to the next just by clicking on the next tool
==================================================================================
Geometry button:
- if no object selected, the legacy toggle icon has a new functionality, switch to/from creating in construction mode
- if object selected, it has the legacy functionality
- the button can be clicked during "continuos creation mode" to switch from creating to/from creating in construction mode
Constraint button:
- The button is not selectable if nothing is selected (it would be impossible to determine the effect)
- When constraints are selected, the button toggles the constraints to/from Driving.
- When geometry is selected, the button switches from/to reference mode, the change is apparent from the color of the constraint icons.
Continuous creation mode:
- Default changed so that it is active unless you change it in settings
Updated terminology
======================================================================
- Changing from Driving to reference does not include unnecessary solvings.
- Added some checks to avoid making Driving constraints when calling directly from python and involving only external geometry (would give redundant constraints).
- New python command toggleDriving to just change the status from reference to Driving
- New UI toolbar Command to toggle constraints
- Fix to allow switching from/to construction mode during continuous mode creation.
- Enable/Disable for constraints in constraints widget has changed to operate on multiselection and now effects "toggle" instead of enable/disable.
- Disable the option to directly create a SnellsLaw non-driving constraint (this constraint does not support direct creation, it can be toggled to non-driving after creation though).
==============================================
The fillet applied to construction lines generates normal (not construction) geometry.
How to replicate?
1.Make a square and make all lines construction lines.
2.Apply fillet tool, there result will be a white line fillet connecting two blue constructions lines.
===================================================================
It allows to create constraints directly into Reference or Driving mode.
It does not include icons
