Internal Perimeters First default sometimes starts on the external perimeter (hole perimeter)

[eVenom]

Description of the bug

As you can see in the picture in some cases the external perimeter prints first making overhangs dificult to print. It seems to be on the external perimeter of a hole.

it seems to be the case when the external perimeter in question is on the center of the object(hole).

Checking the "External perimeters first" option does not change the behavior on the inside perimeter(hole) and it only changes on the very outside of the objext

once the perimeter is not part of a hole the the function works as expected

Project file & How to reproduce

Fidget_spiral_cone.zip

Go to second layer and see the order of the layers, Check and uncheck the "External perimeters first' and see that it doesnt do the internal perimeters first no matter what.

go the some of the top layers to see that the behavior gets resolved once its not in the perimeter of a hole

Checklist of files included above

• [X] Project file
• [X] Screenshot

Version of PrusaSlicer

2.8.0+win64

Operating system

Windows 10

Printer model

Ender 3

[u89djt]

(Fellow user having a quick look) I set the scale to 200% and note that the outer perimeter is printed first when the internal perimeters of the outer and inner surfaces of the object merge or disappear. At 200% scale, at layer 14 the inner perimeters are separate and the perimeters are laid in the order you want. At layer 15, the inner perimeters merge, and the outer perimeter of the inner face is laid first. The classic perimeter generator (as opposed to arachne) lays them in the order you want over the whole object.

[u89djt]

Additional detail: how ever many perimeters you set (try 6), the order is wrong when there's one merged perimeter or no perimeter between the external perimeters at the nearest points between the inner and outer surfaces before the helices separate. That again is at 200% up to the 21st layer. Could be a nice example for someone to look into when working on the arachne generator. Classic always works as intended.

[eVenom]

I also just tried this in OrcaSlicer and it gets handled as expected in both classic and arachne.

So this is obviously a bug in PrusaSlicer using arachne perimeter generator

[u89djt]

How do the extrusions look in comparison to in prusaslicer? Screenshots of the same layers created by both slicers with all the same settings - I only just saw that you've picked huge values for width and height - might hold clues.

[u89djt]

Maybe show the extrusion width colouring? It's taken as read that you've checked the extrusion order (I did too) so just frames of the extrusion widths if they're different might be informative.

[agrif]

I think I'm seeing exactly the same thing. I have internal threads on my part (project file zip) that are failing to print on PrusaSlicer 2.8.0. I've determined that they are failing because they print the external perimeter of the hole first, and it has no support to stick to and it sags:

I believe this is a regression. In PrusaSlicer 2.7.4, with exactly the same settings, it prints the internal perimeters first, and the print succeeds:

What I'm seeing agrees with @u89djt's observation that this occurs when internal perimeters merge. This issue might also be the same as the one in #13075.

If I can figure out how to build PrusaSlicer reliably, I will try to bisect and try to figure out which commit changed the order. But maybe somebody familiar with the source will know why this is happening.

[agrif]

The commit that caused this change is very likely to be SPE-1963: Improve ordering of perimeters with Arachne perimeter generator. Slicing on this commit prints the external perimeter first, while slicing on the parent commit does the internal perimeter first.

This looks to be completely intentional. I'm mentioning the author @hejllukas to bring this to their attention: It looks like some parts that used to print before this commit now fail or print poorly due to unsupported perimeters. Is there a way to either turn this off in configuration, or to detect this situation and keep the old perimeter order? Or is this possibly a bug?

[eVenom]

I think you are into something with SPE-1963 I will try with an older version and get report back.

[hejllukas]

Hi, unfortunately, this is the side effect of the mitigations for seam gaps in some cases (mentioned here: https://github.com/prusa3d/PrusaSlicer/issues/11914#issuecomment-2182686870).

It is intentional that when Arachne is used on objects with holes and with less than four closed perimeters (not split into several pieces caused by thin parts of objects), then the perimeter of the contour is printed as the last right after the internal perimeter. This, unfortunately, implies that the perimeter of the hole is printed before the internal perimeter.

In the current version, there isn't an option to turn off this behavior. But I admit that, in this case, it likely has a negative impact on overhangs.

[u89djt]

I'd be inclined to thank them for providing a neat pathological test case.

[eVenom]

Hi, unfortunately, this is the side effect of the mitigations for seam gaps in some cases (mentioned here: #11914 (comment)).

It is intentional that when Arachne is used on objects with holes and with less than four closed perimeters (not split into several pieces caused by thin parts of objects), then the perimeter of the contour is printed as the last right after the internal perimeter. This, unfortunately, implies that the perimeter of the hole is printed before the internal perimeter.

In the current version, there isn't an option to turn off this behavior. But I admit that, in this case, it likely has a negative impact on overhangs.

Thank you so much for the reply. I have found that this example is not so unique, it happens more that expected and yes its a negative impact to the point that it makes the print fail. One thing I don't understand is how reversing the expected wall order resolves the seam gaps.

Thank you again and I am happy that there could be someone possibly working on a solution.

[MartijnGevaert]

Below is another real world example where this is leading to ugly print artifacts. In this case, the external perimeter first behavior is caused by a single 2-perimeter wide section (image 2 is at the bottom, just out of view of the first image) My printer is underextruding somewhat at the start of travel, I'm still trying to fix that, but this leads to a very visible gap at the seam location.

[kubispe1]

Hi, thanks to everyone for your investigation. As @hejllukas mentioned, this is an intentional change intended to improve seam quality. For now, we will not revert the behavior or add a switch. We have a more general solution and fix planned regarding the Arachne engine. Sorry for the unpleasant message. Have a nice day