Improve overhang slowdown granularity & line segmentation handling

[igiannakas]

When encountering an overhanging region in non-classic mode, the slicer checks if the extrusion segment leading to the overhang is greater than 4mm. If it is, it splits the extrusion path to smaller segments, irrespective of if the segment will actually get slowed down. It then evaluates and applies the slowdown speeds to the resulting smaller paths depending on their overlap with the perimeter underneath.

However, there are two issues with this approach:

1. if the length of the last path segment from the overhang is less than 4mm, the entire 4mm path is slowed down, even if this is not in an overhanging region (as its last point ends in an overhang).

This can lead to large visible areas with external wall artefacts, as the entire 4mm area is slowed down, while layers above or below may or may not be, depending on the model geometry, and specifically the length of the extrusion from a corner or sharp edge.

2. because there is no check whether the overhanging lines will be affected by the slowdown for overhangs, it generates unnecessary segmentations if the speeds actually don’t change. This is particularly important for tiny overhangs, like the sides of the benchy hull.

For example on issue 1 above:

Example of the visual impact seen below:

This PR reduces the artificial 4mm limit to 0.8mm, as it is visually small enough to not cause a significant artefact, hence the visual impact should be diminished to the eye.

Same for the curled perimeter speed segmentation here:
Before:

Notice the extended slowdown above the "S" and "r"

After:

Removed unnecessary slowdown while preserving the benchy hull slowdown completely intact in the background (which is really what the curled edges is intended to solve).

print shots with combined changes
Before left, after right, taken with top down lighting to illustrate the extrusion variations

From a distance

PS. this has been one of my biggest bugbears on visual fidelity, as till now I could not figure out why arbitrarily some lines have large areas where they are slowed down, resulting in external wall artefacts. Finally managed to find the cause :D

fixes #4553

edit:

this PR has been expanded to better handle segmentation of lines on overhangs when applying slowdown.

Perimeter segmentation / splitting based on overhang degree whether there is an impact on speed:
The current Orca and Prusa code when it detects a perimeter has even one overhang, it commences segmenting that contiguous extrusion into smaller "chunks" in order to apply the slowdown algorithm.

However it doesnt check whether the newly generated point needs to be created. For example if the overhanging region doesnt need to change in speed, because it is only slightly overhanging and the user has elected to only slow down after the 20% overhang mark, then this segmentation is not needed, and it just creates more perimeter points and inflates the gcode. Hence why it always doesnt segment below 8mm in line length.

The new approach here checks if the overhang is material enough to change speeds first - if it is, then it proceeds to segment the perimeter into smaller chunks. If not, it leaves the original points untouched, hence saving on gcode volume (and accuracy as artificial points are not created via extrapolation).

Quantise speed transitions to 1mm/sec
The currently calculated speed change at an overhang is currently calculated as a float - meaning any arbitrary value is allowed. However from a practical perspective, this is not needed - and may result in a large number of speed changes being emitted to the printer with small deviation from each other. I have currently rounded and quantised the speed changes to 1mm/sec so any speed change that is less than this from the current speed will not be emitted, hopefully making gcode slightly less big and also reduce the overhead on the firmware.

This may be unnecessary, but feel like it may be a good practice.

Screenshots:

Print tests.
Print test completed successfully.

Test 1: increased segmentation without consideration on the overhangs and with a 0.8 mm split distance. Can see even with klipper some rounding issues / micro extrusion issues causing spots.

test 2: this PR now, with segmentation in overhangs only.

and a comparison

benefits from improving segmentation remain against the current release:

also the current release does create some minor artefacts like the below on occasion, which are eliminated with this PR.

[Ataraxia-Mechanica]

How about using 2x nozzle size instead of 0.8mm? Hardcoded value might cause some problems with larger nozzles. Or would this cause some problems because the code surrounding it also uses hardcoded values

[igiannakas]

How about using 2x nozzle size instead of 0.8mm? Hardcoded value might cause some problems with larger nozzles. Or would this cause some problems because the code surrounding it also uses hardcoded values

I don’t think a larger nozzle will have an issue with this - there are plenty of times where a single extrusion is composed of smaller line segments than 0.8 size in a print. The nozzle just prints them as normal as it’s a continuation of the existing line. Width matters, line size especially when it’s a continuation of a larger line less so I think.

(and technically I don’t think the printer config variables are available to this utility function :()

[Ataraxia-Mechanica]

Yeah, now I think about it, it probably shouldn't matter, didn't read through the description thoroughly, sorry about that. Can you run the build action for your dev branch by the way? A build with both this and dynamic PA during extrusion would be cool.

[ramorimdias]

This is awesome, incredible results! Thanks you!

[igiannakas]

Turns out 0.8mm segmentation was way too small and it ended up segmenting the path too short for overhangs over smooth surfaces, causing slight extrusion variations.

A new approach has now been created.

[igiannakas]

While this works there is scope for improvement. Marking it as draft and will come back with further commits.

for example the estimate point properties function splits the path even though there may be no slowdown due to an overhang resulting in unnecessary segments.

Edit: the above has now been addressed.

[igiannakas]

So I've made some changes to the approach for overhang speed handling.

Perimeter segmentation / splitting based on overhang degree whether there is an impact on speed:
The current Orca and Prusa code when it detects a perimeter has even one overhang, it commences segmenting that contiguous extrusion into smaller "chunks" in order to apply the slowdown algorithm.

However it doesnt check whether the newly generated point needs to be created. For example if the overhanging region doesnt need to change in speed, because it is only slightly overhanging and the user has elected to only slow down after the 20% overhang mark, then this segmentation is not needed, and it just creates more perimeter points and inflates the gcode. Hence why it always doesnt segment below 8mm in line length.

The new approach here checks if the overhang is material enough to change speeds first - if it is, then it proceeds to segment the perimeter into smaller chunks. If not, it leaves the original points untouched, hence saving on gcode volume (and accuracy as artificial points are not created via extrapolation).

Quantise speed transitions to 1mm/sec
The currently calculated speed change at an overhang is currently calculated as a float - meaning any arbitrary value is allowed. However from a practical perspective, this is not needed - and may result in a large number of speed changes being emitted to the printer with small deviation from each other. I have currently rounded and quantised the speed changes to 1mm/sec so any speed change that is less than this from the current speed will not be emitted, hopefully making gcode slightly less big and also reduce the overhead on the firmware.

This may be unnecessary, but feel like it may be a good practice.

Screenshots:

Print tests to follow.

[igiannakas]

Below left screenshot is this PR - Right screenshot is simply segmenting the line paths more without consideration on whether the overhang is big enough to actually affect the speed:

(both fix the overhang granularity issue but right one is larger in volume of segments)

Left GCode is with the new PR, right gcode is with current Orca release

Can clearly see the reduction in gcode volume as well as the reduction in non-round speed changes.

While also fixing the slowdown granularity issue for small perimeters before an overhang:

Also notice the 5500 less gcode lines this PR produces :)

[igiannakas]

As I'm not 100% familiar with the code in that area I've made some assumptions:

1. In the estimate_points_properties method, I've assumed that we need to use the absolute value of the distances - as I am not 100% sure what the negative or positive distance value here means. I'm assuming its offset internally from the line below (negative) or externally (positive) but would be good to confirm this

Eg: (std::abs(curr.distance) > min_distance) || (std::abs(next.distance) > min_distance))
EG: (std::abs(p0_dist) > min_distance

2. I've clamped the minimum segment length to 2mm when in an overhang, instead of 4mm that was in the past. This is an arbitrary value, as was the previous one, but from what I see this seems to be the right value as you really dont want to be creating more segments unecessarily

Ideas for the future:
Currently the existing split algorithm and the changes in this PR creates at most 2 new points, i.e. subdivides the line in consideration to 3 segments irrespective if the overhang angle (i.e. distance from the line underneath) being similar to each other.

This is unnecessary in some cases, i.e. a bridge, as the overhang angle doesnt really change, so why bother splitting this line either. Another change that could be implemented is to check whether the overhang angle of the produced points is similar to each other (within some tolerance). If it is, skip creating them as we are probably just printing a straight overhang line instead of a complex curve that would benefit from different speeds per segment.

[igiannakas]

Print test completed successfully.

Test 1: increased segmentation without consideration on the overhangs and with a 0.8 mm split distance. Can see even with klipper some rounding issues / micro extrusion issues causing spots.

test 2: this PR now, with segmentation in overhangs only.

and a comparison

benefits from improving segmentation remain against the current release:

also the current release does create some minor artefacts like the below on occasion, which are eliminated with this PR.

[celtare21]

Would love to see this merged!

[igiannakas]

It needs more testing - both from the community and myself. It’s a pretty radical change in an important area of the slicer so any consequences need to be evaluated.
Personally I’d love some real world feedback on the feature as I’m currently only testing it on a Voron and X1C with both being high speed printers with reasonably capable MCUs

[SoftFever]

Look good!
I noticed this artefacts too, this improvement is fantastic!

[SoftFever]

Could you take a look at the conflicts?

[igiannakas]

Of course no problem. I’ll get them sorted in the next couple of days

[SoftFever]

Fantastic!
Thank you

[igiannakas]

Think its done :)

[Rickthebig]

I was investigating how bridge settings work and found some inconsistencies using the current Orca v. 2.1.1, which apparently are corrected using a version with this feature #5996 implemented (thanks to igiannakas who provided me with that version).

I have a number of bridges, for which I changed settings per-object wise:
Namely, bridge speed (external bridge):

Speeds are in the range 10-70 mm/s in the row. What do I see then?
The 1st layer of all bridges have the same speed! See this:

Bridge speed settings affect only the topmost layer, as one can see here:

Obviously, the crucial speed for a bridge is the one of the 1st layer. This seems a bit wrong to me. In all of these cases, "Slow down for curled perimeters" was set and then the speed of bridge lines (between the outer perimeter lines of the bridge) should change accordingly. The speed of the overhang walls (the perimeter walls of the bridge) should be controlled by overhang settings - that is not the case in Orca 2.1.1. In the following picture the overhang speed was deliberately set to 70% just to make a difference.

This is the result:

So the overhang speed affects not only the border lines of the bridge, but also the bridge lines (which are internal in the bridge). In order to control the bridge perimeter speed, I have to disable "Slow down for curled perimeters" and then the bridge speed settings are applied to the bridge perimeters, but may not always be desirable.

Just to illustrate the bug, pay attention at the different bridge speed settings in the following pictures.
100 mm/s:

1 mm/s:

The speed does not change as commanded.

OK, all this misbehaviour is corrected using the Orca version with the change in this Pull Request (https://github.com/igiannakas/OrcaSlicer/actions/runs/10008381271), as I was able to verify.

@SoftFever
I strongly recommend it, in case it is not yet approved for next release, since it not only improves subtle extrusion defects in the indicated cases, but also fixes bugs related to bridge/overhang speed settings.

[igiannakas]

So does this PR work, right?

This feature has already been merged in the latest nightly and will be present in the upcoming 2.2 release