STL with small structures can cause 'generating gcode' to hang for very long time

jnweiger commented 2 months ago

Description of the bug

I made a chessboard like object freecad, that has numerals on rows and columns. Loading the board into prusaslicer causes no problem. Slicing advances to 90 % and already shows a fine rendering how the filament is layed down. But then prusaslicer consumes 100% of one CPU with no apparent progress for over half an hour.

I was able to reduce the issue to the number 1 numeral in my case. All other numerals cause no significant delay. I am aware that this may well be considered a bug in the freecad STL exporter. But in any case, it is completely bewildering, why prusaslicer burns so much cpu time, after all the complex operations are apparenty already done.

Project file & How to reproduce

numerals_1+2.zip The attached file numerals_1+2.3mf contains three objects. As is, only the original version of the "numeral_1" is enabled. This generating g-code takes ca. 6 min on my cpu.

grafik

For reference,

another "numeral_2" generated by the very same freecad export is included. It takes ca 1 second to generate g-code.
running "numeral_1" through a quick meshlab filter produces "test1-ml-iso". This also generates g-code very quickly.

Workarounds

Use STEP instead of STL as the export format.
Run the problematic STL through meshlab's Decimation Quadric Edge Collapse filter ms.meshing_decimation_quadric_edge_collapse(targetperc = 0.9, preserveboundary = True, preservetopology = True, planarquadric = True) fixes the issue.
Rotate the "numeral_1" by some amount (0.2° seem sufficient) around x or y axis fixes the issue.
Run the object through prusaslicer's simplyfy object quality high. Very likely it is fast then.

Checklist of files included above

[X] Project file
[X] Screenshot

Version of PrusaSlicer

Version 2.8.0+linux-x64-GTK3 - and 2.8.1

Operating system

Linux mint

Printer model

mk4

u89djt commented 2 months ago

(fellow user having a closer look) I've imported the bad 1 into Fusion, then opened it in the slicer and right clicked and chosen fix by windows repair algorithm and exported that to also import into fusion. Here's the top of the bad one: Here's the top of the repaired version: You can see that it didn't go well. But, that repaired version slices well enough, and perhaps more to the point, quickly. The freecad stl exporter made a really horrible mesh. Have you tried saving as step and loading that into the slicer? It might work for you, I don't know. It could be that the step data is messy, too.

jnweiger commented 2 months ago

Thanks @u89djt for the inspection. Exporting step from freecad produces good results! Thanks for the idea, I am adding this as the prefered workaround.

In my case of the bad 1, the step file actually does not have a fully triangulated mesh, but bspline instructions instead:

#48 = SURFACE_CURVE('',#49,(#54),.PCURVE_S1.);
#49 = B_SPLINE_CURVE_WITH_KNOTS('',3,(#50,#51,#52,#53),.UNSPECIFIED.,.F.
  ,.F.,(4,4),(0.,1.),.PIECEWISE_BEZIER_KNOTS.);
#50 = CARTESIAN_POINT('',(39.271465,-73.516731,0.));
#51 = CARTESIAN_POINT('',(39.319655,-73.778051,0.));
#52 = CARTESIAN_POINT('',(39.333915,-74.047848,0.));
#53 = CARTESIAN_POINT('',(39.314265,-74.326124,0.));
#54 = PCURVE('',#55,#60);
#55 = B_SPLINE_SURFACE_WITH_KNOTS('',1,1,(
    (#56,#57)
    ,(#58,#59
    )),.UNSPECIFIED.,.F.,.F.,.F.,(2,2),(2,2),(-0.813458275582,
    1.112356724418),(-3.782354050717,3.603577949283),
  .PIECEWISE_BEZIER_KNOTS.);

... which means, that it is left to prusaslicer to do bspline interpolation, which it does perfectly fine. (After loading this step, I am exporting the build plate as stl: this mesh looks excellent :innocent: )

I fully agree that the core issue is the horrible mesh produced by the freecad stl export.

Still I'd like to see an expert opinion on this:

the fact that the final rendering is already shown before it hangs,
the fact that rotating the mesh by a few degrees helps

indicate to me, that we probably run into a silly edge case. I have the hope that someone would say something like: "yes, line xxxxx misses an epsilon like we do in all other places of the code."

For comparison: Detail view of the same corner seen in meshlab (before fixing): grafik

After applying a remeshing filter: grafik

The differences are almost invisible to the eye, but make prusaslicer run fast now. The number of vertices went down from 115.000 to 103.000 but the gcode generation time goes down from 6 min to 1 sec. I'd say the sheer amount of data is not really causing the delay.

u89djt commented 2 months ago

This issue seems likely to have things in common with https://github.com/prusa3d/PrusaSlicer/issues/12772 Version 2.7.2 and earlier didn't have the problem - maybe someone can try this file on one of those earlier versions.

prusa3d / PrusaSlicer