Internal perimeters split into multiple small pieces

[gregsaun]

Version

2.1.0+win64

Operating system type + version

Windows 10 Pro Build 18362

3D printer brand / version + firmware version (if known)

Prusa MK2.5S

Behavior

I made a circle where the wall thickness is calculated to have exactly 7 perimeters. When sliced the middle perimeter is split into multiple small pieces.

The circle dimensions :

The value 2.89248 has been calculated like this:

2.89248mm = extrusion_width + (num_perimeters-1)*perimeter_spacing

extrusion_width = 0.45mm
num_perimeters = 7
perimeter_spacing = extrusion_width - layer_height * (1 - π/4)
layer_height = 0.2mm

The perimeter spacing formula comes from official Slic3r documentation: https://manual.slic3r.org/advanced/flow-math#spacing-paths

Here is the result when sliced with 4 perimeters:

Project File (.3MF) where problem occurs

prusaslicer_issue_perimeter_split.zip

[gregsaun]

Here with wall thickness of the circle set at 2.89 (instead of 2.89248):

And here with wall thickness of the circle set at 2.9 (instead of 2.89248):

[gregsaun]

I get the expected result with a value of 2.91mm (instead of 2.89248):

Note that I used Fusion 360 to create the STL and exported as shown in the screen shot (here at 2.91mm):

[Jebtrix]

A value is being rounded up or more specifically precision on a lot of internal float values is set for %.2f

perimeter_spacing = extrusion_width - layer_height * (1 - π/4)

= 0.40707963267948966

If you round that up to 0.41 you will get 2.91

[gregsaun]

Makes sense but then precision should not split the line in multiple parts, just reduce the thickness accuracy. Also I have just tested and we don't have the same issue with a square (here at 2.89248).

[Jebtrix]

Oh there is a definitely a problem. I'm just answering how to calculate your initial intent:

I made a circle where the wall thickness is calculated to have exactly 7 perimeters.

[Jebtrix]

There has been issues posted that are caused by this. I'm having trouble finding the one I'm thinking of but this can be really problematic on a model that has a circular wall that varies in thickness depending on height (usually not intended but can be trickier to do in certain 3D/CAD packages). You have to check all layers to find possibly bad ones. I have used modifiers on problem layers by tweaking extrusion widths just to alleviate this problem. I'm guessing issue #2984 is another reference to this problem.

[gregsaun]

Yes I agree with you. I know I have seen this issue in the past but I was not able to reproduce it like that (or didn't had time to do dig into it). This issue is probably older than 2.x as well. I also know that several people have encountered that and it is not isolated and as you said sounds like the issue of #2984.

[Jebtrix]

The calc of using a rounded up number peaked my curiosity. The precision formatting of %.2f is for UI display. If a single precision number is safe to 7-8 decimal digits, and a double precision number is safe to 15-16 decimal digits I'm not exactly sure why this rounding up is needed here.

Looking at it some more it is only required when an odd number of perimeters is needed to fill. Even numbers work fine both with rounded and non-rounded up perimeter_spacing. Maybe it is a coincidence rounded up perimeter_spacing just added enough to nudge the math here. The center perimeter is technically 2 perimeters. To get 7 you use perimeter of 4. So its the merging or discarding of the 1 that gets janky. Whatever it is it sure seems like it could crop up in multiple places and causes issues.

[gregsaun]

The center perimeter is technically 2 perimeters. To get 7 you use perimeter of 4. So its the merging or discarding of the 1 that gets janky. Whatever it is it sure seems like it could crop up in multiple places and causes issues.

This looks interesting yes. Maybe it switches between 1-2 perimeters due to the triangles of STL which could explain why we don't see it on the square.

[trustfm]

I have posted another example here : https://github.com/prusa3d/PrusaSlicer/issues/4330 this effect does not appear at slic3r 1.29 I know that that version had an overfill bug but never generated holes between external perimeters and gap fill