Bridge direction ... "abnormality"

[codefaux]

Description of the bug

I'm printing a subframe unit with a dovetail-like guide slot. I've tried modifying the file a few different ways, but PrusaSlicer consistently fails to make the correct choice.

The piece in question is here;

Said guide slot is mirrored, and runs the entire length of the piece. It creates an overhang area of roughly 5.5mm x 330mm. One would expect any slicer to bridge this piece across the 5.5mm gap. I did. I gave it so much faith that I attempted printing it three times before I was actually present during the bridge.

PrusaSlicer is running a 332.5mm bridge a total of 18 or so times, across the 5.5mm gap THE WRONG WAY.

Upon closer inspection, the geometry which is encouraging this misbehavior is likely here -- pictured rotated 180 on X to expose underside view; (See second post, that geometry has been modified and still causes exact same behavior)

At those points, the solver has two options, and clearly selects incorrectly:

• "Route A": (Pictured in screenshots)
  -- Along the groove: ~330mm bridge, unsupported at both ends aka nearly universally unprintable on FDM
  -- Across the holes: Properly supported with smallest gap, aka perfect

• "Route B": (Expected operation, bridge rotated 90 degrees to screenshots)
  -- Along the groove: ~5.5mm bridge, supported at both ends, aka perfect
  -- Across the holes: Unsupported on one side, total gap ~9.5mm, aka not ideal but likely very printable.

Project file & How to reproduce

Subframe.zip

Load and slice at 0.25mm at any height

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.6.0-alpha6+win64

Operating system

Windows 10 64-bit

Printer model

Ground-up custom

[codefaux]

I was incorrect. I fixed that suspect geometry to make the correct choice more clear to the slicer, and PrusaSlicer still choses violence lol the wrong direction for the bridges. I don't really understand.

Layer before;

Layer of;

Layer after;

Part in question;

Transparent;

Project file;
Subframe2.zip

[codefaux]

Ok so. I went back to the first project file since the second one didn't fix it and had oversized lockpin channels. I manually set the bridging angle so the bridge anchors actually connect to things, and PrusaSlicer got mad at me. It didn't get mad at itself when they explicitly weren't connecting to things, as you can see by a lack of error message in the other screenshots.

Before;

Of;

After;

My workaround is to manually set bridging angle and ignore the warning, thankfully that doesn't break other bridges in the print. I've got no further testing to do, so I'll stop posting here until someone replies.

[rcmaniac25]

Can confirm this issue too. The models https://www.printables.com/model/387217-3-layer-gift-envelopes require very specific bridging direction and until 2.6, PrusaSlicer picked the correct directions.

So first bridge it does correctly and overlaps the print below...

But then the 2nd bridge it is at the wrong angle...

This prevents folding the envelope is has been commented on a few times in that model's comments.

My thought is the new "Ensure vertical shell thickness" code in PrusaSlicer 2.6 is forcing the bridging at the incorrect angle in an effort to reduce lots of short back and forth... except that's exactly what is needed here.

Example 3mf: Issue.zip

[zmeygeruch]

I'm having issue with bridges too.
In prusa 2.5* looks good and works fine, but in 2.6.0 it looks so.... bad and i don't understand, how it would work on circle....
I'm using the same profiles to both versions of prusa. I also tried tweaking the settings but that didn't work.

In Prusa 2.5.2:

In Prusa 2.6.0:

3mf's files:
3mfs.zip

UPDATE1:
Looks better when I turn off "extra perimeters on overhangs" or "detect bridging perimeters"

[bramp]

I had a similar issue, the bridge would be built between two far edges, instead of via the two nearer edges.

Trying

turn off "extra perimeters on overhangs" or "detect bridging perimeters""

did not fix this for me, but I could mitigate it by setting the Infill > Bridging Angle to 45. I attached a very simple STL showing this problem.

[rcmaniac25]

Ran into this again, at least tangentially.

I went to print a large calicat_3mf.zip and noticed over 2h into the print that the body of the cat didn't really anchor the bridge infill.

As it was an 18h print, I didn't want to come back to find the bottom basically failed because of bad bridging. So to save restarting and the waste that comes from it, I cut the model up, added supports, and printed it on a different printer then attached the supports to the bed, and the print continued without issue.

It would be great if this issue was resolved because it's not fun having to remember the slicer can't bridge "perfectly" anymore (or, at least since 2.6) and needing to rush to resolve it or need to restart the print hours in.

[Jan-Soustruznik]

Reported problem look similar of #10493

[rcmaniac25]

So an earlier issue I had is now resolved with the new 2.7.3-alpha1 release

But the more recent issue

Still exists.

I'll make a new ticket around that since it may be different in the end. But glad to see this fixed in other areas...