Before, partial bridges were calculated. For each of these an angle
has been choosen and after that all the bridges have been merged.
Becouse of the merge a single angle had to be picked.
The first angle that the algorithm has stumbled upon has been picked,
resulting in sub-optimal bridging directions.
Now the partial bridges are calcualted, then merged and then
the angle is decided over the whole merged bridge.
This approach at least ensures that the orientation is the best possible
for the merged bridge.
* 1. Remove all global include_directories.
* 2. Move 3d party dependencies from src to budled deps if possible.
* Unify and enforce one way of including headers:
e.g. #include "libslic3r/GCode.hpp" vs #include "GCode.hpp"
(always use the "libslic3r/GCode.hpp" option).
* Make all dependencies (also header only) a cmake target.
This enables addition of other expansion zones in the future.
For example to make sure bridges are anchored properly even
if there is top fill next to them.
Split the function expand_bridges_detect_orientations into
multiple functions. And allow any number of expansion zones
by using a vector instead of explicitly listing the
parameters.
There are several ExPolygons with very thin lines and holes formed by very close (1-5nm) vertices that are on the edge of our resolution. Those thin lines and holes are both unprintable and cause the Voronoi diagram to be invalid.
So, we filtered out such thin lines and holes and tried to compute the Voronoi diagram again.
Split Integrals constructor to accept polygon and polygons.
Add operator+(Integrals, Integrals).
Make sure extrusion extraction for integral calculation throws in invalid case.
In SupportSpotsGenerator there is a need to compute integral over
extrusions.
The mentioned function is slow for this use case. As it solves a harder
problem.
It is better to iterate the extrusion lines directly.
There was a test that relied on randomness and also checked the result
with very hight precision. That led to a failed test once upon a time.
Now the checking is more benevolent (it should be, as the code is
not expected to be precise) and also the randomness is removed.
SupportSpotsGenerator originally used a heuristic formula. Current
formula is properly derived using known properties of
second moment of area. Several tests of this formula are added.
