Updated message

Discovered this while investigating CURA-7943.

This is already implemented in CURA-7830.

This is an optimisation that removes parts that are too small to print, if they don't even generate an outer wall. But if the wall line count is zero, there is not going to be any outer wall either. So if it's zero, don't remove any parts with this optimisation.

Contributes to issue CURA-7943.

Because size_t is always positive. This generates a warning in my compiler.

Just see if a part is getting filled.

Contributes to issue CURA-7943.

Can't leave this hanging.

Contributes to issue CURA-7943.

Conflicts:
	src/InsetOrderOptimizer.cpp -> Changes to an algorithm that was completely rewritten, so the Arachne version was taken.
	src/Wireframe2gcode.cpp -> Some MM2INT stuff and round offsets for skirt are now merged into Arachne code.
	src/pathOrderOptimizer.cpp -> File was changed on master but removed in Arachne. Keeping it removed.
	src/skin.cpp -> Changes to top surface skin only applying to top skin merged into Arachne.

Outer walls react to what happens inside. While technically correct behaviour given the basic premise of Arahcne, this can cause noticable artifacts in what would otherwise be a straight wall. This would already be worthy of fixing, but it seems these artifacts can be exacerbated by the printing process, making it a at least a critical and probably even a blocker for release.

This commit sets up the basic premise. Add a parameter to adjust how close the outer walls are to their 'optimal' width (and, because they are outer walls therefore also placement, which is what is needed), with 1.0 meaning completely optimal (mostly ignore any width changes to the outer walls coming in, let the inner walls 'solve it as much as possible') and 0.0 being the old 'correct' behaviour (no compensation is applied to the previous strategy other than the 'relative widths for inner and outer' redistribution which was already happening).

What still needs to be done is:
 - Add the parameter as a class parameter and expose it to the frontend (and add it to the frontend).
 - Handle the case where there where previously only 2 outer walls ... but a middle (inner) wall might be needed after compensation.
 - Handle the case where all(a?) middle wall(s) should be eliminated because the space for inner walls has become too small after the compensation for outer walls is applied.

CURA-7979

CURA-7979

Even if there are only outer walls (perhaps especially so) they'll need to be locked in place (depending on the outer wall lock factor). In case there is one, there isn't much that can be changed. The same goes for, 'two, but closer together than the optimum'. With two and some room to play with, there are a number of possibilities. In any case, the outer walls themselves should be repositioned according to the outer wall lock factor. The hard part is to determine when a third wall needs the be inserted, since the outer walls will become narrower. The transition thickness from 0 walls to 1 seemed like a natural choice (this will actually call the parent strategy, so that's neat as well).

CURA-7979

It makes everything more complicated, and the zero width signalling walls are now guaranteed to be handled _after_ the redistribution 'stage' (beading meta strategy).

CURA-7979

Not _entirely_ sure if and when this can happen... If so, then the situation must've been happening in the 'old' situation as well perhaps. A bit of defensive programming is usually a good idea though.

CURA-7979

CURA-7979

In retrospect it's really weird that it compiled, ran _and_ passed the tests without that setting here locally.

CURA-7979

when connect infill lines was selected, small travel moves were observed
 in the infill perimeter contour. This happened because stitching the
generated toolpaths - needed for obtaining the inner contour -
introduced small segments of lines. Simplifying this contour before the
crossings and segments are stitched ensured that these tiny segments
were "merged" in a proper way, not leaving any gaps in the connected
contour line segments.

Fixes CURA-7764_small_travel_moves

When multiple extruders are used for a print, the `optimize()` function of the InsetOrderOptimizer
is called once for every extruder. This function would then add all the wall insets for all
extruders in the final layer data. As a result, the outer and inner walls were printed multiple
times, once for each extruder.

Why is this happening?

To optimize travelling (i.e. to make sure that the extruder that ends in the previous layer is the
extruder that starts in the next layer), the list of extruders is iterated with a different
direction on each consecutive iteration in multi-extruder prints (e.g. layer 0: 0->1->2->3,
layer 1: 3->2->1->0, layer 2: 0->1->2->3 etc.). This was leading to the print looking like it
alternates extruders in consecutive layer while in truth it was just instructed to print all the
walls with all the layers.

This commit fixes that by making sure that each wall type (outer or inner) is printed only once
with the extruder indicated by the user (the outer wall should be printed with the wall_0_extruder
_nr and the inner wall with the wall_x_extruder_nr).

The commit also ensures that infill walls and skin walls will not take into account the setting
"Outer Before Inner Walls" when the wall_0 and wall_x extruders are different (considering that the
"Outer Before Inner Walls" setting is disabled in the front-end in that case).

CURA-7927

If there is a combing path possible, it will make a detour to reduce the amount of retractions and prevent crossing the walls. This is the most major determinant of what the actual travel time is going to be. Whether there is a combing path possible depends on the minimum combing boundary, not the preferred combing boundary, since if there is no preferred combing path possible it will fall back to the minimum combing boundary.
This can cause the planner to slightly underestimate the distance to comb, but that'll be very minimal especially since the combing distance itself is much greater in comparison.

Contributes to issue CURA-7891.

The infill travel optimisation was disabling itself when the combing boundary consisted of just 1 polygon. That > symbol should've been >=. But then it's more semantic to just test for whether it's empty.

Stupidest bug ever.

Fixes CURA-7891.

CURA-7979_fix_outer_wall_artifacts

The weights were calculated twice, first to determine the total weight,
then to determine the actual weight of the bead. These where a lot of
unnecessary multiplications. Stored the weight in a vector, summed it up
and called upon the weight later on.

Contributes to CURA-7979

Contributes to issue CURA-7927.

…r_and_outer_walls' into libArachne_rebased

Contributes to CURA-7979

Contributes to CURA-7979

Contributes to CURA-7979

Contributes to CURA-7979

For some reason I don't notice a big difference between the
 locking and "old" behaviour. Probably because of the usage
 of resetToolPath function.

Contributes to CURA-7979

Contributes to CURA-7979

I have been thinking really hard how a beading strategy could be applied
to two different wall regions (inner/outer) and still be true to the
strategy and the difference in wall width specified, and this is
basically the only way I see how.

I think of having the "Lock Wall 0" feature always on (no check-box in
the front-end) just normal behavior.

Rational behind this:

> If two different wall thicknesses are specified for outer and inner
walls, the user wants that outer wall to have that dimension. Since the
outer wall always consist of 1 wall there isn't anything to distribute.
It either is the specified dimension or less if the thickness of the
outline is less then (2 x the optimal outer wall width + 1 x minimal
inner wall width).
Now it is entirely possible that the inner wall has more then 1 walls
(even when 1 inner wall is specified, for the cases of converging walls)
In this case the strategies define the distributed width.

This would result in a cleaner code (since  you basically don't have to
re-distribute all walls according to ratio). Also After running multiple
test prints with a constant outer wall I see a huge improvement in
surface quality.

Contributes to CURA-7979

Contributes to CURA-7979

Contributes to CURA-7979

Instead of just casting them, actually round them. The Voronoi calculation has some minor inaccuracies in due to floating point rounding. If the coordinates are rounded down this can cause a vertex from the source polygon to change position, causing it to no longer be recognised as a vertex from the source polygon.

Contributes to issue CURA-7970.

Properly remove the medial axis bead during bead transitions.

CURA-7936

Forgot about that. Thanks, unit test.

Contributes to issue CURA-7970.

…79_fix_outer_wall_artifacts

CURA-7979

…om/Ultimaker/CuraEngine into CURA-7979_fix_outer_wall_artifacts

…facts

[CURA-7979] Lock outer wall in place and width as much as possible

This used to happen in 4.6 and before. When the algorithm was rewritten this was tightened up. However the Voronoi graph doesn't deal well with long segments with very minor deviation since the Voronoi's coordinates get extremely far out then, which causes floating point rounding errors in the Voronoi's coordinates close to the model. This is causing crashes because the Skeletal Trapezoidation is then unable to find the coordinates that belong to the outline.

Contributes to issue CURA-7970.

…er_rounding

Properly round Voronoi coordinates to IntPoint coordinates

This was causing the wall placement to become in precise. Rounding errors caused by scaling
down and then up again made the object slightly larger than it was before.

I've tested this with the models that should have been fixed with the original change and
they still seem to be fixed, as well as fixing the newly introduced issue

CURA-7853

…tioning

Remove scaling to fix self intersections

Seems to be nonstandard, maybe?

As Arachne ahas a tendency to 'smear' all corners out over a number of vertices, first make a copy on which we detect the corners, then find closest point, instead of directly finding corners. This approach (like some others tried) works for smart hiding, but not the normal hide option (completely). Also there are some magic values to be fixed. Committing this to see if this can be combined with the initial approach that was stashed somewhere to get better results.

CURA-7902

Other than what was suspected in the explanation of previous commit, the part that still made it not work was that previously (before Arachne) it could be assumed that polygons where always clockwise iff they are outer polygons. While technically still true that the winding for clipper-lib polygons works that way, polygons implicitly defined by closed paths _do not_have this property and can be either clockwise or anticlockwise. This commit makes the algorithm take that into account.

CURA-7902

Use sensible numbers that are based on something instead of magic numbers.

CURA-7902

They are so minor that i'm not going to bother the other devs with this. It's just spacing and a typo in a comment.

The problem is currently that the walls are fed as small segments and
the PathOrderOptimizer ensures they are processed in a correct order and
it really doesn't matter that all segments are small and broken up.
Now all is well, you would think, But then the outer wipe distance comes
in to play. Add the end of a small wall segment it thinks: He, I need to
wipe. I will traverse all long the path a do a travel afterwards. This
occurs after each small wall segment. So when a wall is split in two
walls it does the outer wall wipe thingy.

By storing the end point of the last path and checking if this is
aligned with the start point of the new point I will know it this path
is part of a continuously linked path consisting of smaller segments.
If that is the case the outer wall wipe isn't performed.

Contrinutes to CURA-7949_outer_wall_wipe_distance

Due to an oversight, each time an infill wall was needed, the input toolpaths would be reassigned. Because this was an input variable, anything already in there was overwritten. In the context of the current bug (only walls around the dense part of gradual support infill) this solves the part of why not _every_density had walls around it, since the same amount of walls was supposed to be generated for each density blob. This however leaves the second part, that it should only print for the least density (ie only around the support as a whole).

CURA-7934

Make it so that if there are dense areas in support (with gradual support infill) walls are only printed around the support as a whole. Take care that denser areas take holes into account as well. For this reason a offset is substracted from the infill overlap for any areas denser than the least dense one.

CURA-7934

Contrinutes to CURA-7949_outer_wall_wipe_distance

[CURA-7934] fix walls for gradual

All the mesh was used for was retrieving settings, and for support generation (where it's needed to fix the current 'feature gap') there is a settings object, but not a mesh.

CURA-7946

Paths (as opposed to polygons and lines) where just not implemented yet as a valid output of support interfaces (both roof and bottom). After the little refactor in the last commit, it was easy to slot it in there.

CURA-7946

[CURA-7946] fix concentric support interface

…49_outer_wall_wipe_distance

# Conflicts:
#	src/LayerPlan.cpp
#	src/LayerPlan.h

Fixed bool traps.

Contrinutes to CURA-7949_outer_wall_wipe_distance

Basically a small but crucial part of what formed the fix for CURA-7934 applied to another part of the code.

…into libArachne_rebased

Found during investigation of CURA-7948.

Handy if you know some coordinates from other types of debugging and want to figure out where they are in the image.

Contributes to issue CURA-7948.

Contributes to issue CURA-7948.

No longer give it an offset at all. Instead of using two lines, make a single polygon where the tip of the arrow is simply offset in a certain 45 degree direction. Also don't cast to integer first when calculating the normalised direction, but work purely with floats.

Contributes to issue CURA-7948.

This is common with SVG images, and guarantees it all stays readable as long as your line width is readable.

The generation of the SkeletalTrapezoidation does not handle well very thin corners. While in most
cases these corners were properly removed by the closing and opening operation, there were still
some corners left in holes.

These thin corners would lead to the generation of a graph that had edges without twins, which
would then lead crashes and all sorts of problems when generating the beads for the polygons.

This commit fixes that by applying an extra opening and closing operation which makes sure that
very thin corners in holes are properly removed.

Contributes to CURA-7651, CURA-7680, CURA-7948, and CURA-7952

Previously, `removeColinearEdges()` would only remove points that had an angle of ~180degrees.

            angle=~180
  o------------o-----------------o
prev           pr              next

This commit fixes that by making sure that the function above also removes colinear edges with an
angle of ~0deg or ~360deg.

By removing these cases too, the `SkeletalTrapezoidation` will not fall into the issue of
generating an edge without a twin.

CURA-7952

The previous value (0.0005) was way to small, which would still allow for almost-colinear segments
to be included.

CURA-7952

This function can be called stand-alone, allowing the generating of
walls and inner_contours to take place when the gradual infill densities
are created.

CURA-7756 Wrong infill layer thickness and missing infill walls

When removing collinear edges, self-intersections may be introduced. These self-intersections
cannot be handled properly by the Voronoi diagram generation, thus introducing edges without
twins, which lead to crashes in the SkeletalTrapezoidation.

This commit fixes that by re-applying the `fixSelfIntersections()` function after removing
collinear edges.

Fixes CURA-8056 and remaining crash in CURA-7948

This allows it to be called without the creation of an Class instance

CURA-7756 Wrong infill layer thickness and missing infill walls

The wall toolpaths are now generated earlier in the process such that
the inner contours of the wall toolpaths can be combined without issues
for multiple layers.

CURA-7756 Wrong infill layer thickness and missing infill walls

And a bit of refactoring

CURA-7756 Wrong infill layer thickness and missing infill walls

…56_infill_layer_thickness

Previously we were generating a new data structure every time an endpoint needed to be generated for the edge. This effectively erased all the previous endpoints (and also was a bit unnecessary in its memory usage, producing linked lists of length 1). As a result, transition ends were missing and sharp corners weren't properly transitioning oftentimes.

Fixes issue CURA-7854.

Found during investigation of CURA-7854.

`generate()`` uses the earlier wall toolpaths for gap filling. This
should be processed the same way as in processSingleLayerInfill

CURA-7756 Wrong infill layer thickness and missing infill walls

The range upon which the remove_if function is called would be empty if there are 2 beads. If there is 1 bead or 0 beads, the range would become negative: The start iterator would be beyond the end iterator. This is undefined behaviour. Perhaps this is what is crashing the build made with Clang.

Contributes to issue CURA-8059.

Layers for support wouldn't combine vertically where this was needed, like for PVA printing. This relies on the work done in jira ticket CURA-7756 where almost, but not quite, the same thing happens for infill. In fact, it relies on that PR for how the infill generation class now has promoted the wall generating part to a publicly callable function, as one of the problems of both this ticket and its precursor was that (extra) walls _shouldn't_ combine. (And the 'normal' lines of course _should_ that's the whole point.)

CURA-8060 -- see also: CURA-7756

- Make infill aware of existing toolpaths.
- Use those toolpaths to print the walls instead of only the separately generated walls.
- Double check the offset (it should definitely not be _more_ at least, so the - part can stay).
- Lift parameter to constexpr for better readability.

CURA-8060

…ion_endpoints

Fix missing transition endpoints in Arachne

…60_support_infill_layer_thickness

…t2_walls

Don't remove any inner walls if there are no inner walls

Only write the wall toolpaths in the processSingleLayerInfill

CURA-7756 Wrong infill layer thickness and missing infill walls

Renamed generateWalltoolpaths -> generateWallToolPaths

CURA-7756 Wrong infill layer thickness and missing infill walls

…56_infill_layer_thickness

…t_infill_layer_thickness

Renamed generateWalltoolpaths -> generateWallToolPaths

CURA-7756 Wrong infill layer thickness and missing infill walls

Cura 7756 infill layer thickness

…r_thickness

[CURA-8060] Fix combine layers (vertically) for support as well.

It's not a coordinate at all. If negative numbers are desired here, an integer would do. But they are not. We don't want to keep checking that this is negative. Just make the variable type an index, like it is.

Found during investigation of CURA-8073.

The check was wrong, in this case. It should be the same as the assertion above it.

Found during investigation of issue CURA-8073.

Instead of with the width at the far end of the line segment, print it with the average. Previously, the width of a line would depend on the direction in which you were printing it. Quite often, as a path went into a narrow peak and back out, one side of this peak would be printed with a small line width (the peak being narrow) and as the nozzle goes back out, that segment would be printed with a large line width (the base being wider). This is inconsistent and leads to larger flow changes than necessary. Often this would also vary from layer to layer (a different bug) which would look extra messy.

Fixes issue CURA-8073.