CURA-13250 chamfered tree base

[Erwan MATHIEU (wawanbreton)]

This PR's main goal is to implement the chamfered base for the support, both tree and normal. The base makes the bottom of the support much sturdier and also improves adhesion to the buildplate, so it is now possible to use higher supports, or tree supports with less trunks.

In addition to that, it contains a few other significant changes:

• The support walls are no more generated using Arachne, but a naive insetting operation instead. Since we don't really care about dimentional accuracy nor fine details in the support, using a naive algorithm helps reducing the slicing time a lot when using especially tree support that generate a lot of tiny tips.
• Fix in the skirt generation: so far, the skirt generation was using an approximation of the convex hull of the models on the buildplate. In some situations this process would generate invalid self-intersecting polygons, so it is now replaced by the actual convex hull calculation, which gives a correct result and also happens to be way faster. This is a very visible behavior change though, because the skirt is no more rounded as it used to be, however it has more straight lines which help for adhesion while priming, and also it is now always composed of a single line enclosing the whole print, no more multiple pieces attracted to each other.
• introduction of CuraEngineViz: we now have a dedicated tool to visualize the internal data of the engine in real-time. The engine contains the interface part that sends the raw data to the visualizer, which is of course disabled by default and can be enabled with a -o "with_curaviz=True" at conan install time

Requires Ultimaker/Cura#21714

[github-actions]

Test Results

31 tests   31 ✅  5s ⏱️
 1 suites   0 💤
 1 files     0 ❌

Results for commit d567470.

♻️ This comment has been updated with latest results.

[Erwan MATHIEU (wawanbreton)]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'C++ Benchmark'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.50.

Benchmark suite	Current: 10f1b81	Previous: 93f5d54	Ratio
InfillTest/Infill_generate_connect/0/400	5.766691518246707 ms/iter	3.646253201438742 ms/iter	1.58
HolesWallTestFixture/InsetOrderOptimizer_getInsetOrder/3	0.00026352653403075943 ms/iter	0.00016906826041988748 ms/iter	1.56

This comment was automatically generated by workflow using github-action-benchmark.

CC: Jelle Spijker (@jellespijker) Erwan MATHIEU (@wawanbreton) Casper Lamboo (@casperlamboo) HellAholic

[Casper Lamboo (casperlamboo)]

I don;t fully understand the need of changing x.getInfillArea() to x.outline_

[Casper Lamboo (casperlamboo)]

This function feels a bit weird to me since

• distance in this case can be negative
• distance returns an Index type
  A better name for this function would be layerDelta, layersBetween or layersTo in my opinion.

[Erwan MATHIEU (wawanbreton)]

Well, it has to be called distance to match the standard std::distance so that we can use LayerIndex directly in a parallel_for loop.
Maybe a comment would be helpful ?

[Erwan MATHIEU (wawanbreton)]

I don;t fully understand the need of changing x.getInfillArea() to x.outline_

SupportInfillPart was a class with only public variables. Now it is a struct, still with the same elements. I actually don't see a need for the getInfillArea method, since it just returns the outline_ which is publicly accessible anyway. It was confusing that you could get the same element by 2 different means IMHO.