Enhancement: ERS - Option to limit ERS to external perimeters and overhangs only

[igiannakas]

Description

Extrusion rate smoothing can materially help smooth out speed transitions during overhangs, leading to better external finish. This is similar to the latest bambu slicer release where speed transition smoothing has been introduced.

However current implementation applies smoothing to all features which will increase print time with marginal benefit visually.

Therefore, this PR introduces an option to limit ERS to the areas that are visible to the user, reducing print time impact.

Debating whether to enable this option by default when ERS is enabled, as internal features do not benefit much from extrusion rate smoothing compared to slowdown for overhangs that does materially benefit especially for printers with high accelerations, where PA cannot keep up with the requested speed changes over time.

If merged, ideally they should be done in this order to reduce possibility of conflicts in GitHub:
#7398
#7399
#7400

Screenshots/Recordings/Graphs

Tests

Basic regression tests done-no adverse impact with it disabled to the existing feature. Enabled limits only to external perimeters & overhangs.

[lookypanda]

Hi, sounds as really cool feature!
Is there any way to somehow download the orca build with all three of your ERS improvements at once?
I would like to test it.

[igiannakas]

Yes I have them all on my dev branch here: https://github.com/igiannakas/OrcaSlicer/actions/runs/11783977166

[lookypanda]

Hi, @igiannakas . I tested a bit the build with your modifications.
Should ERS be applied on the top surface?
Because when the external perimeters option are ticked, ERS is not applied on the top surface, but maybe it could be useful there. (But I haven't tested how much the ERS is really needed on the top surface).

[igiannakas]

Nope it should only be applied to external perimeters specifically for overhang regions. To avoid artefacts from rapid acceleration and deceleration when moving in and away from sharp overhangs.

[lookypanda]

Over the past few days I have tested the build with all 3 new ERS improvements on about 5 prints.
No problems have been detected. ERS works as it should, slowing down before and after overhangs.
printer Ender 3 S1 on klipper
Thanks for a great work and a great feature!

[igiannakas]

These look perfect! Well done on taming the S1!!

[lookypanda]

Hi. Found a bit of strange behaviour when the ERS is switched on. (build #7399 (comment))

Strong slowdowns in a couple of places where it doesn't seem to be needed, after a seam. Print movements and flow is not different from other layers.
At the same time the distance with slowdown is too big, not dependent and not changed by increasing the ERS value (just turning it on is enough).
razor holder.zip

BUT I haven't checked this behaviour on the Main release build of Orca yet, maybe it's a general ERS bug. (haven't had time yet).

[igiannakas]

Are you using scarf seam? I’ll take a look at the project probably next week.

would you mind in the meantime time cross checking against the latest stable release too please?

[lookypanda]

Are you using scarf seam?
would you mind in the meantime time cross checking against the latest stable release too please?

Tested this.
This artefact is present regardless of scasrt join.
It is also present on the release version of Orca.
I.e. it is not a issue with this Pull Request, but a general problem in Orca with ERS.

[igiannakas]

Cool no worries, thank you for helping pin point it. I was concerned that the segment simplification would have caused this but it’s “good” to see it’s present in the release version - that means it’s unrelated :)

[lookypanda]

I found kind of the source of the issue (On release version):

[igiannakas]

Huh… that makes no sense!! Something is triggering a boundary condition that is not triggered when slightly higher flow exists is my guess. It would be good to see that specific layer and more specifically the move that is before the external perimeter.

[lookypanda]

Something is triggering a boundary condition that is not triggered when slightly higher flow exists is my guess.

Yeah, something like that one.
The artefact is almost completely absent at 1.0 and equally present at 0.99 and 1.01

But one can definitely say that this or these problems are clearly somewhere outside of this Pull request. I will describe them rather for formality in spoiler below:

Details under spoiler:

On an interesting note about this strange behavior with pics:

On an interesting note: the roots of the problem go somewhere in the bowels of Orca and\or Arachne. (When Flow == 1.01)

1. If resolution is reduced to 0.008 - the position of the seam moves significantly. The artefact goes away, AND(!) micro-irregularities on the walls also go away (maybe some problems in rounding maths).

wall irregularities - 0.008

wall irregularities - 0.0125

2. when changing to Classic, the generator and Flow and Resolution values no longer produce any artefacts or wall irregularities.