Arachne attempts to bridge before adding filament bridges connect to

[DFEvans]

Description of the bug

With a model where bridges are connected to additional, adjacent extrusions, the Arachne perimeter generator will sometimes attempt to extrude the bridges first, not connecting to any adjacent filament, or filament in the layer below.

I have the following layer in an object, where the dark blue bridging sections in the middle connect to adjacent areas of infill printed on this layer:

If I scroll through the GCode preview for the layer, it shows that it will attempt to print these bridging sections in thin air, isolated from the layer underneath, and before printing the adjacent filament the bridges would connect to:

In contrast, the Classic perimeter generator will print connecting filament around the bridged sections, so there is something to attach to:

Project file & How to reproduce

BridgingInThinAir.zip

Slice the model, scroll to layer 27 in the preview, and scroll the GCode preview to near the start of the layer.

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

Version 2.5.0+win64

Operating system

Windows 10

Printer model

Original Prusa Mini+

[MrBlackmidi]

i feel like arachne is really weird in prusaslicer as of right now

[kubispe1]

Retested with 2.6.0-alpha6 + 100 issue is still there.

[fluksh]

Same problem in 2.6alpha6, it is not even recognizing the free floating extrusions as bridges

[BloodyRain2k]

I've run into the same problem with the 2.6 release version:
Edit: only now noticed that I took a bad screenshot, but it's simply starting the entire layer trying to print the blue perimeters mid-air.

I've already tried disabling various experimental settings that work fine everywhere else, but the only difference was the preview's line color changing from blue to orange.
Still tried to start the layer mid-air regardless : (

Here's the project with the settings I tried.
Soap_Stand.zip

[tuct]

Any news on this, I still see this in 2.6.1 and hate falling back to classic besides the fact that usually I only realize the issue when printing not before.

[MrBlackmidi]

Afaik, arachne is low priority rn

[nicole-ashley]

Why would Arachne be a low priority, isn't it the default? This is a pretty glaring issue for a default setting.

Here's another example, slicing this model at 0.2mm layer height on a 0.4mm nozzle with Arachne (the only setting I can find that changes the behaviour):

Layer 199:

It's not always the case, for example layer 330:

[tastyratz]

I did a lot of digging on this issue and narrowed it down in the linked orcaslicer bug and reference the same bug downstream on superslicer as well.
This has to do with Arachne wall order when more than 1 perimeter is selected.

The solution would be "print detected bridges last/after perimeters" as a default behavior or checkbox for when bridges are detected. This should drastically improve bridging performance.

[nicole-ashley]

@tastyratz You have indeed put a lot of work into figuring this out which I very much appreciate! Hopefully it's enough to get a fix in one of the Slic3r derivatives that can easily be ported across all of them.

[WhiterRice]

Adding some simple recreation steps,

Model: https://www.printables.com/model/116915-bridge-test-piece
Prusa Slicer 2.7.4
Mk3s default 0.4 Profile 0.2mm quality
Project FIle: Issue_9047.zip

Arachne Perimeter:

Classic Perimeter: