It is possible to ask for splitting at an end point of the curve. This leads to
a `CADKernelError` and leaves us with a "hanging" clone. This check prevents that.
===================================
Changes from naked pointers to smart pointers are motivated to the use of functions that can reasonably throw under certain circumnstances (such as trim).
When introducing smart pointers, it is not necessary to explicitly delete the new geometry array at the end of the function.
When using the new facility to add a smart pointer geometry (previous commit), the copies generated in the split algorithm can be reused, which renders
keeping track of the new geometry for memory management unnecessary.
As geometry is added to the property which each call to addGeometry, the stored newIds can be reused if access is necessary to geometry pointers afterwards
(e.g. for constraint management).
================================================================
This new facility avoids to have to create a new copy() when a user copy is already created.
As the user copy is reused via move semantics, memory management is simplified.
CAVEAT: When this facility is used, the client code has to ensure whether a copy() or a clone() of the Part::Geometry
should be undertaken. The different between both is that the former creates a new uuid (tag), whereas the latter does not.
=========================================================================
A migrated parabola cannot be openned with a previous version of FreeCAD. The user is notified upfront.
Algorithm to join b-splines:
The code simple concatenates the knots, poles, weights, and knot multiplicities
together, removing data on the connection point of the second curve. Some
further study is needed to see if/when it will give an exact/good connection.
Icon courtesy @bitacovir.
Comments by @abdullahtahiriyo.
Remove default values and smaller constructor for `CenterOfGravity` and
`WeightedLinearCombination` constraints.
Clarify comments.
Improve readability of `CenterOfGravity` and `WeightedLinearCombination`
constraints.
Also squashes:
[Sketcher] Create center of gravity constraint in planegcs
[Sketcher] typo
[Sketcher] Use accurate "weights" for knots
By weights we mean the linear combination factor B_i(x) such that
spline(x) = sum(pole_i * B_i(x)) for _non-rational_ splines.
[Sketcher] Use more appropriate weights for knots
These are relevant for knots _away_ from any ends (and possibly other high
multiplicity knots).
[Sketcher] Make COG constraint weights user-definable
[Sketcher] Make `flattenedknots` for periodic B-Splines
[Sketcher] Fix incorrect setup of `flattenedknots`
Without ensuring enough space, iterators become invalid. These iterators are
needed because for periodic B-splines we need to pad flattenedknots with offset
values within flattenedknots.
Apparently there is still some iterator issues even after the reserve. Just use
fresh vectors instead.
[Sketcher] Apply knot constraints by parameter
Hopefully this will allow directly applying constraints on knots.
[Sketcher] Disable some knot updating
[Sketcher] Use center of gravity constraint on knots
[Sketcher] Fix knot COG constraint for periodic splines
[Sketcher] Add start/end point of periodic spline to solver
This removes the trouble of transferring constraints to the underlying knot.
[Sketcher] Support knot constraints on rational B-splines
[Sketcher] Remove virtual from overridden methods in planegcs
Follow 0penbrain's comments
[Sketcher][planegcs] Use `unsigned int` in signatures
Also `size_t` at places
Suggestions by @abdullahtahiriyo
================================================================
Master has a problem in that internal alignment constraints are suggested to the user for removal.
This is fundamentally wrong, as an internal alignment constraint are an inherent part of the geometry. They cannot be the ones suggested for removal.
The popularity contest algorithm is an heuristic algorithm that determines which redundant/conflicting constraints should be proposed for removal.
Basically, the algorithm works on groups of redundant/conflicting constraints detected via the QR decomposition. A constraint may belong to more than one group.
The algorithm runs some heuristics, each constraint scoring a value, the one constraint from each group scoring the highest is proposed (is more popular and wins the contest).
This PR documents the algorithm, and adds a further condition, that internal alignment constraints are never proposed.
As the solver works with solver constraints as opposed to the sketcher, which works with sketcher constraints, information about whether a solver constraint originated from a
sketcher constraint that is internal alignment is necessary. So the solver constraint is extended to accomodate this piece of information.
As a bonus, it fixes a bug. Solver constraints carry information of the ID of the corresponding sketcher constraint in their tag. Knots are not currently implemented as constraints.
However, the tag index was not being update. This caused the popularity contest to provide wrong suggestions despite good detection.
Fixes issue #7442.
Also, the following commits are squashed into this one:
[Sketcher] Remove unnecessary variables
[Sketcher] Use `setDriving` within `toggleDriving`
Suggestion courtesy @0penbrain.
[Sketcher] Remove redundant check: `SketchObject::testDrivingChange`
`GeoEnum::GeoUndef = -2000` so checking if it's `< 0` is redundant.
Some equations were mentioned by just the number without telling the resource they were from. The book was found couple years ago but not mentioned here.
This undoes most of the Xerces related part of the commits listed below.
The issue resolved here is that the Xerces include dir *is* set in the
CMakeLists.txt of src/Base, but it got removed from various App and Gui
dirs in src/Mod. If those now include a header from src/Base, which
itself includes xercesc, the build fails using Apple clang version 11.0.0
(clang-1100.0.33.17) on Mojave, configured using cmake 3.22.1, with
errors like the following:
In file included from .../src/Mod/Part/App/FeaturePartBoolean.cpp:34:
In file included from .../src/App/Application.h:33:
.../src/Base/Parameter.h:54:10: fatal error: 'xercesc/util/XercesDefs.hpp' file not found
#include <xercesc/util/XercesDefs.hpp>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Finally, a full list of the commits that introduced this spurious include
dir optimization for reference:
- Drawing: commit f4411478d106ba9f4827754a50efa53bd7767a66
- Image: commit e3476815c04c571199779bd1e444b950e6398025
- Import: commit b7b264e52c8fd97e83987c4ce42ce563170c8918
- Inspection: commit 1f64d8b1b8fcabe983c6e5e624d65766b4429ea0
- Mesh: commit 5a8fed0720d681cdbb9fedc840d2532c4f2f6042
- Part: commit 26bb65f11f4b51e5e47b65b2d6049ece10705a83
- PartDesign: commit f4e49f2aecf08f2337e84510ed019b7fa4b685a3
- Path: commit e3d9cc98577d2073297d55ffd8de28dd50f8444c
- Points: commit 09f3e867cdccd31294cced4e3c73015d3add3f4a
- Raytracing: commit 7b92dedc53f09e2ce8365408f3003e5700aebfc8
- ReverseEnginering: commit eeacc51ad0cd82e5f17d63207f78f79eb20bf9a9
- Robot: commit 4d06684cbd0328e4f43c78b5dab7e7fcebab148d
- Sketcher: commit 079125665495a08a7e2e2a4f01da406128dca625
- Spreadsheet: commit 514097954e95c04a7ec9d7e8ec1afc3aac3dd8d
- Start: commit 2ea2bb0dc393d7b8b41e9137c6d4ae40ce29719d
- Surface: commit 272268dd6c0b460ae9aeecdf371495ea26aa044d
- TechDraw: commit c70fdc3e0aa6b409626a6fa6b7266d05f3338c6d
- Test: commit 49a07b121e08e9bf3fef0f414a8da5602533592e
- Web: commit a93a23d7e4da13b2d5c37ac087b2dcf41aae197d
* Missing reference in range-for with non trivial type [-Wclazy-range-loop-reference]
* Unused QString [-Wclazy-unused-non-trivial-variable]
* Missing emit keyword on signal call [-Wclazy-incorrect-emit]
* Don't call QList::operator[]() on temporary [-Wclazy-detaching-temporary]
* Use multi-arg instead [-Wclazy-qstring-arg]
* Maybe you meant to call ViewProvider2DObjectGrid::onChanged() instead [-Wclazy-skipped-base-method]
Here, "small" means that the number of poles of the spline is so low that moving
any piece of the curve without changing shape would require moving all the
poles. In that case the rest of the algorithm in `initBSplinePieceMove()` only
complicates the matter.
