Not Generating Perimeter Where Loop Would Fit

[CCS86]

What happened?

I would expect any area wider than 2 times the perimeter spacing value would get a full perimeter loop. Instead, in this area, I am getting a gap fill bead 2.5 times wider than the perimeter spacing:

I have been backing down the perimeter max overlap, as it causes really bad over extrusion.

Project file & How to reproduce

Outlet Nozzle 3.3mf.txt

Version

2.4.58.3

Operating system

Windows 10 x64

Printer model

UMO+

[supermerill]

put higher "overlapping perimeter -> all", like 10% (from your 5%)

[CCS86]

The problem is, that many of my prints have large runs of pure perimeters. Allowing 10% over-extrusion over a large distance really screws up print quality.

[supermerill]

Then, you may want a new feature that doesn't exist yet, like splitting a gap fill into a normal+ thinner line loop.

[CCS86]

Is there a way to see the exact width of a line like that? If it is in fact over 2 times the perimeter spacing width, it should be filled with a perimeter loop, right?

[tome9111991]

maybe that will be better with Arachne engine?

[supermerill]

If it is in fact over 2 times the perimeter spacing width, it should be filled with a perimeter loop, right?

That's the theory, but there is also an algorithm that check if it's not better to use gapfill all the way instead of that:

(I had to modify the code to disable the 'checker' to be able to create this image)
With the checker, you have:

I may be able to use the "overlapping perimeter" setting to disable the checker...
If negative then the checker disabled,

[CCS86]

maybe that will be better with Arachne engine?

I was hoping the same.

My only issue right now with arachne, is that the transitions are relatively abrupt. I was really hoping it would be more like the current Superslicer gap fill, which does a great job of using short segments to taper a bead smoothly.

[CCS86]

If it is in fact over 2 times the perimeter spacing width, it should be filled with a perimeter loop, right?

That's the theory, but there is also an algorithm that check if it's not better to use gapfill all the way instead of that: (I had to modify the code to disable the 'checker' to be able to create this image) With the checker, you have:

I may be able to use the "overlapping perimeter" setting to disable the checker... If negative then the checker disabled,

In that example, the resolution looks quite coarse. Can that cause failures to fit perimeters because of the facet deviations?

[supermerill]

Can that cause failures to fit perimeters because of the facet deviations?

Yes, that's the problem.

But for your part, as the gapfill began just before the end of the curve im 99% sure it's just a little too thin. Pushing the overlap from 5% to 7% is enough to make it pass.

[CCS86]

I'm guessing that you are correct in my gap being just narrower than 2x perimeter spacing. It would be cool diagnostically to know exactly how wide that gap fill bead is.

I'm sure you can appreciate that allowing so much overlap (80% external / 20% others) by default, and to avoid an unprintably wide bead, opens you up to a number of print quality issues. When perimeters have long sections that take advantage of this overlap, you build a large amount of pressure in the nozzle, which burps out during the next travel or print move. Often, it will move straight from this over-extruded area, right to the next layer's external perimeter start and cause a big wart.

I think this actually ranks as the biggest functional issue currently in SS.

Do you think it would be easier to develop a way to fit half the perimeter loop (single pass perimeter), and then let the beautiful gap filling algorithm take care of the rest. Or, to apply a flow rate compensation proportional to the amount of overlap, with the existing method?

[supermerill]

I have to create an algo that, for each fat gapfill, split it in two starting with a perimeter width.
It's a bit complicated as it has to take into account the extrusion shortening at some places, and such.
So it can be:

for a shape like : [===>
It should be something like:
peri width -> reduce to very thin at the tip-> reverse with almost no flow -> extrude the thin part with growing flow -> stop when reaching the other side.

btw #525

[CCS86]

Well, I am essentially useless for actual code. But, always happy to talk through potential approaches to weight pros and cons.

I'll throw out another idea, maybe useless, maybe not...

If you are already generating the overlapping perimeter sets, could they be flagged as "overlapping", and have half of each set removed? This would always leave you with a gap easily managed by the existing gap fill. Not necessarily the most elegant approach, but if it functioned well and reduced development time, that would be a win.

[supermerill]

But it won't overlap on the full length. It's localized at certain sections. And it's overextruding only on one side.
And you don't want to go lower than the extrusion width unless it's supported/printed at both side to constrain the flow where it should go, so it began to be tricky.

I guess if I have a min-max periemeter width, I can use them to print at max width everywhere and reduce up to the min if it overlap.

[CCS86]

I was thinking like this:

• The overlapping perimeter segments are flagged as a pair (marked red)
• One half of the pair is deleted before the gap filling is run, leaving a full width perimeter in the correct location
• Gap filling is run, and fills in the smaller-than-perimeter-spacing area left behind (with good support on both sides

[supermerill]

Yes, that could work.

[CCS86]

Yes, that could work.

Hey @supermerill I know the list must be crazy long right now. But I wanted to bump this ticket, since it is currently flagged as a 'question', but I think this feature I suggested could be a massive step forward for the slicer.

I know many people think that Arachne is "the way forward", but I think it really has some serious limitations. Especially while printing fast, the changes to line width and path deviations to accommodate, cause extrusion inconsistency. It can also be significantly slower than classic perimeters with comparable settings.

I really believe the classic perimeter method, with the "recursive gap fill" or the "overlap subtraction + gap fill" I suggested , would outperform Arachne in the real world.

Currently, I struggle with massive attempted gap fill lines like this:

Maybe this issue can be relabeled as a feature request?