| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Feat/Fix: transition filter limit
|
|
# Conflicts:
# CMakeLists.txt
|
|
This commit should allow for the usage of Conan to manage our dependencies
simply do a `conan install . -if <cmake_build_folder> -pr:h default --build=missing`
and configure the CMake project using the toolchain `-DCMAKE_TOOLCHAIN_FILE=<cmake_build_folder>/conan_toolchain.cmake`
I did my best to make this change backwards compatible and allow falling back to
shipped third-party sourcecode e.q. clipper and rapidjson.
This third party sourcecode will be removed in the near future.
Contributes to CURA-8640
|
|
Conflicts:
src/infill.cpp -> Modifications to fix density of concentric infill, while a typedef was removed in this branch.
Contributes to issue CURA-8998.
|
|
github.com:Ultimaker/CuraEngine
|
|
We always want to use Inwards Distributed beading strategy from now on. We'll keep the system of expansible strategies in though.
Contributes to issue CURA-8466.
|
|
|
|
Separate flow ratio from line width factor
|
|
The back-pressure compensation now only compensates for changes in line width (away from the nominal width, only the width factor). This needs to be tested.
Contributes to issue CURA-8737.
|
|
We want two multipliers on the amount of extrusion here: One to reduce the flow rate out the nozzle, and another to reduce the flow rate but possibly get compensated for by changing the print speed.
So the paths need to contain an extra field. I'm calling it width_factor. It's a multiplier on the line width that gets compensated for by applyBackPressureCompensation. That function now no longer takes the flow ratio into account, just the line width.
Because of this extra field, a bunch of function calls to addExtrusionLine need to have that extra parameter too, so that applyBackPressureCompensation can separate the width from the flow still. This is a bit of a hassle!
Contributes to issue CURA-8737.
|
|
github.com:Ultimaker/CuraEngine
|
|
It was confusing, since we also had VariableWidthLines.
|
|
Since widths are stored per vertex, and the line-segments inbetween have their averge widths, changing the width of one vertex will change the width of _two_ line-segments. One of these line-segments will likely be one that doesn't need to be simplified, and we don't at this point in the algortihm even know how long that (other) line-segment is. This potentially introducing a large change in extruded area for that line that we don't take into account at all. The cure is way worse than the dissease. Accept the maximum area deviation as given by the user, and don't try to 'properly' adjust the width.
part of CURA-9036
|
|
Which then also have to be fixed when the wrong assumptions in the code where found and fixed.
part of CURA-9036
|
|
Which then also have to be fixed when the wrong assumptions in the code where found and fixed.
part of CURA-9036
|
|
Since split- and add- middle thresholds are now handled by the base-class and there are no pre-calculated values for the total width of a minimum (even or odd) middle wall, this test has become nearly useless. Keep it anyway just so we don't forget should this change again.
done as part of CURA-9027
|
|
part of CURA-9027
|
|
And don't execute tests in the set-up function, please! We now have a controlled test that simply runs separately, and with shapes that we can follow and understand.
Contributes to issue CURA-7828.
|
|
Contributes to issue CURA-7828.
|
|
It shouldn't bridge that then.
Contributes to issue CURA-7828.
|
|
A major constraint for this connector.
Contributes to issue CURA-7828.
|
|
Contributes to issue CURA-7828.
|
|
Contributes to issue CURA-7828.
|
|
Now it compiles again. I did have to disable the tests temporarily.
Contributes to issue CURA-7828.
|
|
The subroutine is meant to become generic. It accepts a template parameter (which is why it's in the header) and does some of it generically. However it calls more subroutines that now will need to become either generic (to reduce code duplication) or specialised (to make it work for each data type). If it were used on the VariableWidthPaths it would now not compile, since the subroutines can't be ran on that yet.
Contributes to issue CURA-7828.
|
|
It works a little bit different now. Because there are two types of output, I'm giving it output parameters. And there's two types of input as well now.
This change effectively makes it remove concentric patterns now when connecting it. Because the concentric patterns are variable-width paths and those are not yet returned in the output.
Contributes to issue CURA-7828.
|
|
There was a ton of code duplication between PathOrder, PathOrderOptimizer and PathOrderMonotonic
CURA-8983
|
|
Components of containers must be assignable.
Since std::vector<Object&> is not allowed, we also shouldn't use container<PolygonRef>
CURA-8983
|
|
The test assumed that the pat hwas closed.
Only for closed polygons is a size of 2 or 1 not allowed.
|
|
|
|
The canPrecede predicate was less informative.
Using the order_requirements natively allows for more flexible code
|
|
Components of containers must be assignable.
Since std::vector<Object&> is not allowed, we also shouldn't use container<PolygonRef>
|
|
|
|
|
|
|
|
Polyline handling fixes
|
|
Co-authored-by: Casper Lamboo <c.lamboo@ultimaker.com>
|
|
Fixes CURA-8913
|
|
|
|
|
|
Quite unrelated to the raft changes I made, but because this initialises the data storage it needs to know the raft configs too.
Contributes to issue CURA-8868.
|
|
It's a sub-setting now.
Contributes to issue CURA-8868.
|
|
Automatically split and restitch polylines when doing a polyline intersection within an area.
|
|
because of the zig-zag econnections walking along the outline of the polygon,
there might be overextrusion there.
The worse case scenario is a long polyon which fits one infill line,
but also has a zig-zag connector running along the legnth of the polygon
at nearly the same location as the infill line.
|
|
polygons aren't guaranteed to represent correct areas.
Arbitrary zigzagged patterns can be connected into polygons which violate the even-odd rule
|
|
clipper doesnt handle polylines well when they are longer than single segments,
so we split polylines into segments before calling intersectionPolylines
always stitch polylines after intersection
|
|
|
|
|
|
when there are colinear line segments within the same polyline,
clipper produces extraneous or missing segments in the result of an intersection clipping operation.
|
