Thread-like structures make PS add space around internal perimeters

[haarp]

Version

2.4.0

Operating system type + version

Gentoo Linux rolling release

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

MK3, irrelevant

Behavior

• Describe the problem When trying to print small threads lying down, Prusaslicer will add a large space around the internal perimeters. This kind of defeats the point of having internal perimeters :)

• Steps needed to reproduce the problem Grab attached .zip, rename from .zip to .3mf, load, slice, look at the layers including threads. You'll see the effect of the screenshot below.

• Expected Results Internal perimeters follow external one as close as possible

• Actual Results Large spacing between external and internal perimeters, aswell as between internal ones

• Screenshots from PrusaSlicer preview are preferred

Is this a new feature request? No

Project File (.3MF) where problem occurs

PartAmkii.zip (rename from .zip to .3mf first)

Thanks!

[haarp]

Reducing extrusion width also reduces the spacing. It seems Prusaslicer doesn't think it can overlap the perimeters, and thus leaves this huge gap.

[n8bot]

This is interesting. Did you try printing and see what the result is?

There is a chance that there would be no gap leftover. The visualization is just a visualization. It doesn't account for the overlap that happens on corners and the way the plastic will "squish out."

Each of those corners on the ZigZag are overlapping slightly. They maybe produce the desired result when all the plastic settles in its final location.

As well, slicer previews and other 3d design programs suffer from what I have heard referred to as "SolidWorks syndrome" which is the ability to get lost in tiny scales and forget the true size of the objects being designed or looked at.

But, also, this might not print properly as you think and so could/should be fixed.

[haarp]

The printer indeed leaves these gaps, so it's not just a visualization issue. :)

[n8bot]

Well, shoot!

It's probably related to the miterlimit and style: http://www.angusj.com/delphi/clipper/documentation/Docs/Units/ClipperLib/Classes/ClipperOffset/Properties/MiterLimit.htm

[bubnikv]

I will discuss with @enricoturri1966 who is responsible for the G-code viewer / renderer.

In reality the extrusions are not truncated, they are rounded, where the rounding diameter is equal to extrusion width. Thus in reality you should get most of the gaps filled in:

[n8bot]

These were my thoughts as well. IME, small gaps like this in the visualization do end up filled-in.

Perhaps there is underextrusion happening when you print it. As an example, gaps are often seen in the corners, like the image above posted by bubnikv. Those gaps do not appear in the end print, if there is proper extrusion.

Also, if you analyze the g-code X/Y positions of the end points of those zig zags, then you model the full width of the extrusion width at those points as circles, you'll probably see them all touch (just like shown with the red circles in the photo posted above). If not, then we know there is extra gap.

And actually, depending on what settings you have for your extruder acceleration, etc., and the speed at which you are printing those perimeters, the rapid changing in acceleration and speed caused by the zigzags might be causing your extruder to be unable to keep up, and under-extrude.

We must simply analyze the g-code. I spent months analyzing the g-code of prusaslicer. It is very robust. I think you'll find those paths are correct.

[haarp]

I took a photo of the printed part. It's a bit hard to see on this black PETG, so I highlighted some gaps with a red line. The gap is considerable, not something I would attribute to underextrusion either.

And once more without the red line

[n8bot]

PETG is notorious for not "sticking to the path" it's given. I think it's a combination of the sticky gummy PETG wanting to smush around with the nozzle, and fast inner perimeters not helping it.

Can you try printing it with PLA, and at very conservative speeds? PrusaSlicer is only responsible for generating X,Y,Z, and E values. If the values are correct, there is nothing else that can be done except behavioural changes to avoid these edge cases. (Though, PETG is quite a common edge case... maybe just an "off-center" case lol)

[bubnikv]

We will print ourselves. I wonder that there is no gap fill kicking in, maybe the theoretic gap fill calculated is too small.

čt 6. 1. 2022 v 18:53 odesílatel n8bot @.***> napsal:

PETG is notorious for not "sticking to the path" it's given. I think it's a combination of the sticky gummy PETG wanting to smush around with the nozzle, and fast inner perimeters not helping it.

Can you try printing it with PLA, and at very conservative speeds? PrusaSlicer is only responsible for generating X,Y,Z, and E values. If the values are correct, there is nothing else that can be done except behavioural changes to avoid these edge cases. (Though, PETG is quite a common edge case... maybe just an "off-center" case lol)

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/7696#issuecomment-1006793769, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI3THYLX4WHPV5YNBG3UUXJKPANCNFSM5LMJ52OA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[haarp]

I had already started a PLA print :)

Printed with max cooling fan at 40% speed of my 0.20mm profile. MK3 with 0.4mm nozzle. It can be clearly seen that the perimeters baaaarely even touch at the tips.

So it's definitely sliced this way. If such a situation can be detected, it would probably be easiest to reduce the "pointiness" of the internal perimeters, maybe even turn them into straight lines. This way they could be snugly laid down next to the external perimeter.

[n8bot]

I think you are completely right -- there is a potential problem with the extrusion model.

[Edit: Nope, check my latest conclusion below.]

What is happening is that the inner perimeter is not being "squished" to the outer perimeter as intended. I think this is because the extrusion width is too big -- with smaller extrusion widths, the proper squish seems to return.

[Edit: Nope, check my latest conclusion below.]

Looking at the images above, the perimeters overlap slightly at the top-most part. This is what should happen with the stock PrusaSlicer flow logic. But, the parts with the zig-zag have no squish.

I have modeled, in the image above, the extrusions the way slicer does -- rounded corner rectangles. [Edit: but the rounding of the ends and corners of the zigzag is not how slicer does it -- I just rounded the corners to show extrusion width as a radius. So this is not a perfect depiction of the way slicer models the extrusion, but it's close enough for these purposes -- there should be sharp corners on the ends and at sharp corners.]

[Edit: Nope, check my latest conclusion below.]

I have not accounted for the fact that the paths slightly overlap each-pother in corners -- this is not accounted for by the slicer, but this is good. This overlap perfectly equals the small gaps that are left at corners. With the right luck, the excess plastic finds its way into the gaps and balances out.

This image shows that with a smaller extrusion width, the problem would not present itself.

I do not know exactly what is "causing" this. It could be an error in the way slicer calculates the placement for the squish, etc. [Edit: Or, it's not an error at all and this is just the way slicer handles not being able to squeeze into those gaps of the zig-zag. You can see similar behaviour even in the smaller extrusion width image above, at the lowest zig-zag in the image, on the right.]

[n8bot]

[Edit: Ignore this check my latest conclusion below.]

As an added piece of data:

In my modified version of PrusaSlicer, I have removed the Slic3r flow math. This way, the extrusions are supposed to be modelled as plain rectangluar prisms, with their nominal width, and with no "squish" other than what happens naturally from the surface tension causing the bulges (which is exaclty what Slic3r is modelling).

With this removed, there is a GAP left. So something wonky is definitely going on. If everything were correct, these two paths should always just touch:

(I did not put the rounding on the top/bottom of the extrusion because Fusion 360 was giving me errors lol. but the depiction is still useful.)

[n8bot]

I thought about this further. There is no error and my previous illustrations above are misleading due to me rounding the corners. If you look carefully, there is squish for the zigzags, if you project the outer line past where it ends due to me rounding the corners.

The amount that the paths overlap eachother is the same volume as the "gaps" left.

This is why I removed the slic3r flow math. It actually messes up the volumetric accuracy of the print somewhat. Anyway, I digress -- there is no error in the placement of the lines.

The PLA print you showed actually is what I would expect with rapid zigzag and underextrusion. It's the same reason some printers need infill overlap to compensate for this problem: pushing the printer past its physically possible limits.

My printer requires 0% infill overlap. It extrudes the right amount, at the right speeds, to avoid gaps.

[haarp]

Yes, I see what you mean. Here's a quick mockup with Gimp from the PS preview:

The peaks meet the valleys pretty well.

Still, the problem remains that the perimeters ultimately don't (or barely) touch.

[n8bot]

I just edited my comment, sorry! lol. For the same reason that your printer might need infill overlap, it would need to overlap the ends of those points somewhat. It gets complicated with all the slicer extrusion modelling, and being able to capture that scenario in order to add an extra overlap seems difficult.

Do you have any smaller nozzles to use? That might work better, as seen by the slicer visualization.

[n8bot]

One last thing to check, because I did not check for this specific scenario, is that the volumetric amounts being generated as E moves is correct for the moves as we expect them to be. Hmm. I will double check that now to ensure it's as we expect.

[haarp]

My extruder is calibrated to produce the correct wall thickness, according to https://guides.bear-lab.com/Guide/Extrusion+multiplier+and+filament+diameter/8

This is such a large gap that it cannot be explained by flow rate alone. There's roughly half a perimeter worth of material missing inbetween. Normal straight perimeters use the correct spacing and are properly "squished" together.

Using a smaller nozzle and smaller extrusion width would work. But the point was to report what looked like a bug, not to get my print fixed :)

[n8bot]

I was not trying to say your individual printer is incorrectly calibrated.

Rather, there are features in PrusaSlicer, from upstream Slic3r days, that model extrusion as rounded-corner rectangles. While they attempt to re-squish the inner perimeters to the outer, the end result is that the volume of plastic extruded is less than would actually be required to fill every gap. [Edit: this statement only applies to the outer perimeter -- since the inner perimeters are squished together, they fill in the gaps perfectly. The outer perimeter, tho, optimizes the position and extrusion width so that the peak of the bulge is the outermost part of the model, rather than allowing the surface tension to flow outside of the model edge. This is not volumetrically correct, but it seems more correct to users when measuring X/Y.]

That, combined with the apparent "need" to perform infill/perimeter overlap (which is over and above the extrusion model "squish") indicates that the methodology of the types of printer you are using is providing the exact results expected.

There is no "error" in the slicer per-se. One could argue that the visualization could reflect the reality differently. But the math behind where the lines are placed is correct.

[n8bot]

Here is a visualization of how the extrusions are actually modelled. They are discrete rounded-edge rectangular prisms. Where they overlap, the material gets squished out to fill the corners and gaps. The positioning of the plastic on the corners is somewhat probablistic.

The volume of each of those segments is EXACTLY the volume specified by the E values in the G-code (I checked).

[n8bot]

Here is demonstration (and confirmation -- I just verified) that the volume of plastic that is overlapped is exactly equal to the amount of plastic needed to fill the gaps:

The total volume of all the overlapping bodies on the left is ~0.37613 millimeter^3

The total volume of the combined bodies, with their corners clipped (which is subtracting the volume of the overlap) is ~0.27398 millimeter^3

The total volume of all the bodies on the right: the combined inner piece, and the discrete added corner caps is ~0.37613 millimeter^3

The values above are approximate because fusion rounds them to the give number of decimal places.

[n8bot]

Here is the Fusion 360 file that contains the work shown above, so anyone can verify that the volumes are as I said. The sketches with the coordinates of the points are viewable as well.

PSIssue7696 ZigZag perimeters gap StockPS.zip

The G-code used to make the inner perimeter (the zig zag on the right in the photos) is here (This is the one I used to do the analysis of volume):

G1 X80.759 Y51.193 E.38317 ; ignore this E value, it's from a move that is not visualized here.
G1 X81.715 Y50.643 E.03731
G1 X81.276 Y50.392 E.01709
G1 X81.712 Y50.139 E.01705
G1 X81.277 Y49.892 E.01692
G1 X81.712 Y49.639 E.01701
G1 X81.277 Y49.392 E.01692
G1 X81.712 Y49.139 E.01701
G1 X81.277 Y48.892 E.01692

The G-code used to make the outer perimeter (the zig zag on the left in most of the photos):

G1 X80.299 Y50.988 E.09662 ; ignore this E value, it's from a move that is not visualized here.
G1 X80.896 Y50.644 E.02331
G1 X80.461 Y50.396 E.01698
G1 X80.896 Y50.143 E.01702
G1 X80.461 Y49.895 E.01692
G1 X80.896 Y49.643 E.01701
G1 X80.461 Y49.395 E.01692
G1 X80.896 Y49.143 E.01701

[n8bot]

(Ok, last caveat -- as much as I said these volumes were "exactly" right -- there is a tiny tiny known issue in PS, where the extrusion rate will fluctuate very very slightly due to short moves, such as this zigzag. The fluctuation is on the order of 0.00003 mm^3 -- I don't think this would be noticeable.)

[bubnikv]

The problem is that even if the volume of plastic programmed by slicer is right, the viscosity of plastic is too low to fill the gaps, resulting in compression or slippage of filament in the extruder. At the end of the day less filament is pushed through the extruder than programmed. Also the die swell plays its role, the sharp corners are not followed precisely due to plastic shrinkage, and the die swell effect will be worse with some filaments and some print speeds and temps than with others.

Simply said, this model is too detailed for FDM.

[n8bot]

With very small layer heights (<0.05 mm) and small nozzles (like 0.2 mm) one can get closer to an approximation of the model.

But when you look under the microscope, it exhibits the exact same behaviour just scaled down. Find the best combination of settings, and move on, is what I try to do.

[n8bot]

BTW, for anyone following along: fun fact. The amount of "squish" of the rounded rectangle edges exactly equals the apparent "gap" above and below the squished parts -- just like the self-overlap squishing out into the corners. So, the volume of plastic is just perfectly enough to fill the gaps completely in all directions. (If you happened to get so impossibly lucky for that to happen perfectly.)

[haarp]

Yes, clearly I won't be able to print such fine details with FDM, especially with a 0.4mm nozzle. But that wasn't the point of this bug report.

There are evidently gaps between the perimeters, even if the amount of material extruded is supposedly correct.

When there's a gap, strength suffers. Ultimately, this section of the print becomes a 1-perimeter section with some funny looking infill :) That should be avoided.

[n8bot]

I suggest you slow down the print and/or increase the extrusion rate.

Unless you have a proposal for how the slicer could handle this better?

I can't envision a way to capture this scenario of a zigzag perimeter in order to adjust it somehow.

How would the slicer identify a region with zigzag perimeters? If the slicer could perfectly reliably identify only those zig-zag perimeters, what do you propose the slicer do? Push the corners of the inner perimeter zig-zag further into the outer perimeter to create additional overlap?

That might sound simple. But, that is definitely something that would be a hassle to implement and would likely identify regions incorrectly, or miss regions that need it, and now we have additional unwanted behaviour.

If there was an error in the placement of the lines, or the extrusion amounts, it would be an easier fix -- and something that would require immediate attention.

But, the slicer works as intended. The methodology is what it is.

Do you have a proposal for changes in behaviour? I'm personally always open to hear new ideas.

[haarp]

I suggest you slow down the print

The white PLA pictured above was already printed at 40% of my regular speed. Evidently speed is not what's causing the gaps.

and/or increase the extrusion rate.

To what? I'd need at least 150% to fill these gaps, and perimeter adhesion would be terrible due to lack of squish. Not to mention this would ruin the rest of the print.

Unless you have a proposal for how the slicer could handle this better?

I'm certainly not an expert on the matter. But surely it must be possible to recognize this situation and do something about it. Even if it's impossible to print such details with FDM, IMO the slicer should at least attempt to do the "right thing" at all times. Take the length of a perimeter before a sharp turn, the amount of rounding being applied to its tip, or the average perimeter distance to triggers a move-closer-fudge-factor when too far away. Surely, something must be possible?

I know I'm just an user, and I'm at awe at what kind of algorithmic magic residing within a slicer to begin with. You know more than I do. But still, saying "working as intended" when something is evidently wrong (the print photos confirm it) is odd. Maybe, then, the intention is flawed at this scale and can be improved upon.

Thanks! :)

[n8bot]

If you ask the Prusa Team, I bet they would confirm to you that I am very good at ranting about perceived problems with PrusaSlicer! I'm not part of the team, I'm also just a user like you. I was at first very excited to believe we indeed found a problem with the slicer here. But, the truth remains -- there is not a problem with the slicer. There is a problem with the process you are using to create the results that you desire. Maybe the results you desire are more than your process could ever offer?

I want to continue to help you, though, so that you can find an acceptable solution.

Please try printing this attached 3MF. I have radically reduced the speed, and more importantly, the acceleration of the perimeters. I have also lowered the extruder jerk and acceleration, and a few other small tweaks.

It takes twice as long to print according to the slicer estimate. So, sorry about that. This is meant to be a baseline. If this doesn't seem to improve your results enough/at all, I would then suggest to print this new file with added extrusion rate. After that, if the prints still have grand canyons in them, I will concede defeat and begin modifying the slicer to overlap zig-zags (😉).

PartAmkiiSLOW.zip

[dartrax]

Unless you have a proposal for how the slicer could handle this better?

In my opinion, the solution can't be that the slicer tries to identify those szenarios and does something special only in this case. I think @n8bot agrees in this point.

The problem is the shape of the second perimeter. Currently it's an offset copy of the first perimeters original path. But after the first perimeter is printed, the second perimeter should better use the expected outline of the first perimeter as a path!

Luckily, @supermerill already implemented that in SuperSlicer:

I enabled "Round corners" to achieve this.

[n8bot]

SuperSlicer's solution looks interesting. My first thought is that it appears to be over-extruded now. If you read through my rambling explanation above, you'll find a description of how the apparent gap is needed as space for the overlapped extrusion to squirt into. It seems the SuSi solution optimizes for the visualization, not reality.

[dartrax]

I know, I‘ve read all of that 😉

Depends on the print order I think. If external perimeters are printed first, it should be better, if not, the excessive squirt would flow to the outside of the model which is worse.

We should ask how @supermerill handles that (or may be you like to find out in the code). I think, either a small gap for the excessive squirt (for the amount that realistcally flows to the side) should be taken into account, or the extrusion rate needs to be adjusted accordingly. If not, we should open an issue at his repository (if it‘s not already there). If all is right, shouldn‘t be „rounded corners“ implemented into Prusa and be the default behavior?

Also, shouldn‘t get the external perimeter also rounded on the inside-facing spikes? Like „jtRound“? That way, there would be less overextrusion. Example (sorry, no gimp, only iPhone available atm):

Edit: I think CraftWare Pro does that:

And IceSL also:

I tested Simplify3D and ideaMaker as well, but S3D behaves like Prusa and ideaMaker has really strange results/vizualisation of that.

[n8bot]

Yes I quite like the way IceSL rounds the inner perimeters and inner corners. I'm not sure if it really makes all the big of a difference -- we're talking about features which are too small for the current nozzle to print well. I suppose if one really wishes to optimize for this situation, those solutions provided by SuSi, Craftware, and IceSL are good options.

In general, avoiding extrusion path self-overlap would be a good thing.

[haarp]

Superslicer's solution does look very good, and more correct in this situation.

SuperSlicer's solution looks interesting. My first thought is that it appears to be over-extruded now. If you read through my rambling explanation above, you'll find a description of how the apparent gap is needed as space for the overlapped extrusion to squirt into. It seems the SuSi solution optimizes for the visualization, not reality.

I haven't printed Superslicer's solution, but I disagree with this statement. From my Prusaslicer prints, it's evident that the gap exists in reality. There is no practical need to leave such a large gap, it's merely an artifact of the slicer trying to fit perimeters with very sharp corners together. In fact, Superslicer is likely to deposit less material (due to being a straighter line), rather than causing overextrusion.

And it doesn't always matter if the nozzle can accurately print such details. In this example, the first bolt to be screwed in would "fix" inaccuracies in the threads. However, if the perimeters are not backed up by more tightly-coupled internal perimeters, this might just end up destroying the threads. Superslicer is more correct and produces the desired results.

[n8bot]

I do agree that since the features are too small too print, it would be more ideal to make a more direct path for the extrusion rather than overlapping itself constantly.

I think there would be a small amount of local over-extrusion, but it might not really print worse than the other result.

Keep in mind that different printer setups will handle the situation differently. Just because your printer reacts a certain way, does not mean all printers react the same way. Capturing edge cases and catering behaviour to them is a great way to introduce bugs. And someone could literally say "It's not a bug, it's a feature!"

What is the problem with the way the print results as shown in this thread? Is that not a completely acceptable result?

[supermerill]

We should ask how @supermerill handles that

Also, shouldn‘t get the external perimeter also rounded on the inside-facing spikes? Like „jtRound“? That way, there would be less overextrusion. Example (sorry, no gimp, only iPhone available atm):

The option switch internal perimeter to 'jtRound' instead of 'jtMiter'. It doesn't for the external one because it's offseted in both direction, and so may 'smoothen' the external shape. A more sophisticated algo is needed to avoid that (probably a kind of intersection with a mask).