PrusaSlicer doesn't bridge the hole in the shortest direction

[VorpalBlade]

Description of the bug

When slicing the attached file (both STEP and 3mf attached), for two of the areas to bridge on layer 14, PrusaSlicer doesn't take the short "across" but rather goes in the long direction. Printing this would require supports (which it warns about). There is no reason to bridge in that direction, and prusaSlicer gets it right for the other areas. See image below with the problematic area indicated by the red arrow

I have no clue how to fix this (without enabling unnecessary supports). Rotating the model a bit to be on the diagonal of the print bed doesn't help (that was the first thing I tried).

Project file & How to reproduce

Both 3mf and STEP file (exported from OnShape) are in the attached zip file: Saxhållare - Saxhållare.zip

Checklist of files included above

• [X] Project file
• [X] Screenshot

Version of PrusaSlicer

Version 2.8.1

Operating system

Arch Linux (x86-64, rolling release distro, KDE Plasma 6.2.3 Wayland)

Printer model

Prusa Mk3.9s

[u89djt]

(Fellow user having a go) Very nice torture test! It's a failure, but I don't know how buggy it is. When I built a denser mesh, it sliced ok. Back to your project file. The underside of that layer is at 3.5mm in the model. Unless it coincides with a physical layer boundary, the slicer will be performing rounding up or down of percentage occupation of the volume of an extrusion at every boundary, and I guess it slipped for your case. Your workaround is to massage the layer heights beneath that layer to escape the unfortunate interaction. You can do that by - just what I tried, so keep looking! - setting the first layer thickness to 0.25 (I don't claim to know why!), or by clicking on the variable layer profile you've set up to see what happens. Here's a successful change, for example: [Uploading epsilon Saxhållare - Saxhållare.zip…]()

[VorpalBlade]

@u89djt Hm... Since I use adaptive variable layer heights in that project, it shouldn't be an issue where exactly the features end up, the adaptive layers should adapt. At least as I understood it.

What do you mean by building a denser mesh? I simply imported the STEP files, I have not seen any meshing parameters for STEP import in PrusaSlicer. Or do you mean using some third party tool for meshing more densly before importing as a STL?

[u89djt]

@VorpalBlade It doesn't line the layers up with that surface. That would be a good thing for it to do, certainly. Respecting a lot of different horizontal surfaces would be tough, I guess. That's interesting. But we've found an assumption to clear up, so that's good, for a finite value of good.

I imported your step file into Fusion and exported a mesh and used "replace with stl" in your project file. That begins to suggest that the step conversion in the slicer doesn't deal with those horizontal faces in the way we need, or the way the slicer needs. That's also interesting.

[VorpalBlade]

I imported your step file into Fusion and exported a mesh and used "replace with stl" in your project file.

I will look at what options exist for exporting as a 3mf in OnShape or if I can use FreeCAD for this (Fusion is not an option, I'm on Linux).

[u89djt]

I just tried exporting a low density mesh from Fusion the same way and the slicer did the same as your original project file, so it does seem like the mesh needs to be denser. That tells us that the slicer's step conversion isn't dense enough to infer good bridging in your torture test, I think.

[VorpalBlade]

Another point of interest: As you said, changing first layer height is a workaround. But if you then redo adaptive layer height it breaks again.

That tells us that the slicer's step conversion isn't dense enough to infer good bridging in your torture test, I think.

I will admit I'm totally ignorant of the algorithms used for most of the things a slicer does, but why would the number of triangles per flat area affect things? Does the slicer algorithms really operate on surface polygons? I would assumed it converted to a volumetric representation internally first?

[VorpalBlade]

I went ahead and exported a mesh from FreeCAD, it still has the bridging issue when I replace with STL in the project (though on a different bottom triangle, the one right above the "MK3.9S" on the build plate): Saxhållare (Meshed).zip

[u89djt]

I'm just going off the observable phenomena. The mesh is the source of information, so any internal representation is going to say exactly or approximately the same thing. If it's approximate, then an approximate mesh is notionally worse. I don't know.

[u89djt]

That it's a different triangle tells you that something is being guessed at differently. I'll have a look at the mesh.

[VorpalBlade]

Same thing when exporting with "fine" setting for tesselation from the source OnShape document (it has an issue with that triangle above "MK3.9S" on the build plate). Saxhållare - onshape_tesselated_fine.zip

[u89djt]

Right, so it seems that mesh resolution isn't the solution per se. I was just lucky with that one. You can see that the slicer places more internal bridging when it's given the higher resolution meshes. I don't know why that is. The slicer has to decide what to do with surfaces that don't correspond to its horizontal surface. Nope, I don't know. I guess we need to give it a horizontal surface that corresponds with what it can print to be sure it's dealt with cleanly. You've provided an estimate of failure rate :)

[u89djt]

No, I shouldn't suggest a failure rate. The neighbouring regions interact with each other, so there isn't an independent probability involved. I think I don't know enough about what's going on to infer the problem. I suspect you've created the perfect storm for the slicer :)

[u89djt]

When it gets all the shortest distances right, there are no patches of bridge infill outside the main regions. That's got to be interesting. I'm still fond of fractional volume occupation at boundaries as a place to look. The orientation of the shaped volume (e.g. a cuboid) you test will change the estimate.