3.6.0 - "Fill Gaps Between Walls" is causing printing problems

[amagr0]

Application Version - CURA 3.6.0
Platform - Win 10 Pro, 64 bit
Display Driver - NVIDIA GeForce 840M

Steps to Reproduce - Open Cura Project; analyse the toolpath.

Actual Results - After generated the toolpath I found some gaps that are printed with small width lines on some random layers that is causing printing problems.

This strategy of printing very small width lines are increasing a lot the vibrations on the machine, and sometimes for smaller layers (100 micron) it cloguing the extruder. And also increase a lot the print time.

Sometimes on the same gap Cura choose "randomly" print with a bigger single line, or with the "fill area" way, as you can see in the bellow images.

Layer 200

Layer 221

Layer 104

Layer 113

And this situation happens on almost every models, for example on this simple cylinder with a hole, the gap is all printed with the "fill area".

On most of the times this situation could be simply solved with a bigger single line than the default "line width".
Since this only happens when the feature "Fill Gaps Between Walls" is selected, in order to hide the gap, I suggest also the possibility of only fill the gaps on the botton and top of the printed part.

fill_gaps_issues.zip

[smartavionics]

As a stop-gap (ho ho!) solution, if you use my master build it has a new implementation of both the gap filling and thin wall printing which doesn't behave like your example. As always, you can find my builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

[amagr0]

Really appreciate @smartavionics

Is there's any obvious reason to why Ultimaker is not implementing your solution for this big problem?

This is the result with your release

[smartavionics]

Is there's any obvious reason to why Ultimaker is not implementing your solution for this big problem?

Yes, I haven't submitted this as a PR yet for a few good reasons:

1 - Although it produces good results in a lot of prints, I would still like to improve it for some situations.

2 - It's probably quite slow if a model has a lot of thin walls or gaps to fill.

3 - I already have a lot of PRs outstanding that the Cura devs are not addressing and so until they are dealt with I am not submitting anything but bug fixes.

[amagr0]

It's amazing your contribution and continuous work, even without the Ultimaker approval.
Thanks for that.

[regularlabs]

So any word from the Cura devs on when this can/will be fixed?

[smartavionics]

The Cura devs continue to work on their implementation. Whether it will ever be any good, I cannot say.
Independently, I continue to work on my implementation. Whether it will ever be any good, I cannot say.

[regularlabs]

:)

[smartavionics]

Personally, I think the approach they are taking is a loser and they would be better off putting effort into a new implementation. My implementation can produce nice results but it can also be very slow and I know that some models will really be handled poorly so it's certainly not yet suitable for general use.

[Ghostkeeper]

It's a difficult problem. I mean, there are 600 commits in Smartavionics' implementation too, and a good 100 commits in the current one as well.

I think the current implementation can be good in practice for any case given two changes:

• The case of thin walls must be separated from the case of a sharp corner.
• We must apply the tiny lines in two perpendicular directions and take the merged lines from both.

[smartavionics]

I mean, there are 600 commits in Smartavionics' implementation too

It's actually more like 75 commits in that branch.

[regularlabs]

Not sure if this is covered by:

We must apply the tiny lines in two perpendicular directions and take the merged lines from both.

But it could also be a nice addition/improvement/solution to make Cura look for very short infill lines. And have it combine these into longer lines in a different direction.
So instead of ////////, do =======

[Ghostkeeper]

But it could also be a nice addition/improvement/solution to make Cura look for very short infill lines. And have it combine these into longer lines in a different direction.
So instead of ////////, do =======

That's precisely what the current implementation tries to achieve. There's a lot of edge cases to cover though.

[regularlabs]

ok, awesome.
Let me know if you want me to test stuff (on OSX).

[smartavionics]

Let me know if you want me to test stuff (on OSX).

Thanks, but the problem is that I can no longer build a working OS X release because the Mac Book I have is too ancient. I don't need an OS X machine for any other reason so I am not going to buy a Mac Book just so I can build Cura for OS X. All of my source code is on github so it just needs someone willing to build the OS X release from time to time.

[regularlabs]

I tried building the current Cura build on my mac. But it throws errors during the make.
Python isn't my thing and no time to figure this out more at the moment. So can't build it for you.

But I was actually offering @Ghostkeeper the testing help.
Where you, @Ghostkeeper, referring to the implementation of Cura core? Or @smartavionics implementation?

[Ghostkeeper]

With the "current implementation" I'm referring to the normal distribution of Cura from Ultimaker.

[b4545]

Has there been any progress on this issue? From a cursory search I can see this has been a problem since at least 2.3.1 around January 2017 (#1303 #4685 #4871 #5110 #5445).

In 4.0, with and without fill wall gaps option:

This is by far my worst issue with Cura. Can you please escalate the resolution of this issue?

Also, I'm certain this doesn't get said enough, but thank you devs and Ultimaker for this software. I have really enjoyed the new interface and don't have many issues besides this one.

[Ghostkeeper]

It's a bit of an iterative improvement case. I've made such an iterative improvement here: Ultimaker/CuraEngine#1047

The pull request really just changes 2 hard-coded constants in CuraEngine. It should be fairly high priority, considering the problems that this bug is giving. However it's being forgotten a bit at the moment... I'll see who I need to poke about this.

[ssjbardock]

As a stop-gap (ho ho!) solution, if you use my master build it has a new implementation of both the gap filling and thin wall printing which doesn't behave like your example. As always, you can find my builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

I could kiss you. I thought the strange 4.0 infill was taking up extra time, and your build just cut a 20 hr print down to 12. Fantastic job.

[richfelker]

I'm moving discussion here from the just-closed dup on CuraEngine (1086). My problem doesn't seem to be exactly the same, so I'm not sure this is the right place for it, but if not we can move it/open a new issue later:

Simple test case I have for this is https://www.thingiverse.com/thing:11895. With 0.4 nozzle/line width, the concentric rings should print as three lines, but instead they're printing very slowly as zigzag fill between the two outer wall lines.

Enabling or disabling fill_outline_gaps, which @Ghostkeeper recommended, makes no difference, and by my understanding of how it's documented, shouldn't make a difference.

[richfelker]

Also, I read the patch in the above PR and it doesn't look like it would help. If you think it would I can try updating or just applying it (I'm building CuraEngine from source anyway).

[richfelker]

Update to git master does partly fix the issue, but the zigzag is still present in a neighborhood of +45 or -45 degrees in alternating layers. This inconsistency is in some ways worse since it breaks symmetries. It's happening in the regions where long line segments of the skin fill fit; the regions where it's a rapid zigzag are getting replaced. Tuning skin_overlap_mm alters the behavior but doesn't seem to be able to make the problem go away.

[richfelker]

What I don't understand is why a complex and error-prone (at least corner-case-prone) fill-then-merge process is necessary at all here, rather than just setting the requested number of wall lines to begin with, narrowing ones that only partially fit and clipping the ones that don't fit at all. The current wall setting process seems to be stopping when a full-width wall no longer fits then relying on "fill gaps between walls" to patch it up, then relying on this merge process to convert back into thin walls.

[richfelker]

Indeed, the fundamental problem seems to be that WallsComputation::generateInsets simply successively offsets the outline polygon by multiples of wall line width, stopping and leaving gaps when the offset operation yields an empty result. This would be entirely correct, I think, if each stage represented the outline of the not-yet-filled area left after the previous one. However, they're all (of course) offset by an additional half line width, which means that any remainder smaller than the line width is completely lost.

As a really stupid hack, I think it would work to double the number of wall insets generated here, spacing them by half the line distance instead of the whole line distance, and relying on overlap compensation to fix them. A smarter approach would be starting with a "fattened" version of the previous inset when computing the offset that will be the next inset. The algorithm I have in mind is something like this:

1. Offset by half line width to get the region that's not yet filled.
2. Augment the inset outline by, for each segment, unioning on the rectangle swept by offsetting the segment another line width inward. This is a NOP except where the sweep crosses the "other side" of the region.
3. Offset the result by another half line width inward.

This will produce wall line overlaps - any solution inherently does - so it doesn't work without compensation. But with compensation, I think it should give very good results.

[Ghostkeeper]

Let me try to follow that algorithm then on this shape:

Insetting by half the line width produces the inner side of the red outline. Then drawing a rectangle swept by offsetting the segment another line width inwards:

Unioning all those rectangles, together with the first inset:

This union would be a very expensive operation to do. Going by a thousand or so line segments on a layer, you'd be unioning a thousand polygons together which is a quadratic operation. Heuristics like bounding box checking won't work very well since the polygons are long and thin. You can also see the algorithm go wrong here in the thin part.

Then insetting this shape by half a line width:

And afterwards it would draw a line there. On the right hand side it would compensate for overlaps down to where the desired width is 1 line width perfectly, but beyond that it would compensate less and less until the desired width is 0 but the actually drawn width is 2 line widths.

This algorithm is effectively an "abs()" operation on the thickness of the wall: If it goes negative, it becomes greater again. This will lead to blobs in all corners.

[richfelker]

Sorry for the lack of clarity; the "rectangles" description was a high-level one, not an explanation of how to actually implement it. I think the same (or ideally a better) version of it could be implemented on the polygon object in a much less expensive manner, though I didn't go into working out the details.

I don't understand your claim that it would produce a blob. Assuming you use overlap compensation, the flow should reach 0 in the corner, and if you set a minimum flow, the end of it would get replaced by a travel move.

Indeed the path produced is not ideal, and I already saw that. Ideally the final shape here should be essentially a triangle, without the "inverted small triangle" on the right tip. I'll see if I can formulate a better approach that would avoid extending the region in incorrect/unnecessary ways.

[Antotabo]

Wow ! Thank you Mark @smartavionics for these builds ! Works great so far.

[davispw]

Still an issue with 4.4.1. Cura generates strange ultra-tiny zig-zags whenever Fill Gaps is enabled and a feature is not an even multiple of line-width wide.

Impact: blobs, slow prints, inaccurate print time estimates. The blobs can collect and cause blobby surfaces and collisions between print and nozzle.

[smartavionics]

Still an issue with 4.4.1.

And my builds (see above) still provide an alternative implementation that very often makes a much better job of thin walls and filled gaps (YMMV).

[bondarev]

Same problem

[thierryzoller]

Same Problem :

[papaxas]

As a stop-gap (ho ho!) solution, if you use my master build it has a new implementation of both the gap filling and thin wall printing which doesn't behave like your example. As always, you can find my builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

Smartavionics THANK YOU. Your build gives me better and faster prints. Finally I got free from those tiny movements, trembling and blobs. Thanks man. Great build.

[viesturz]

Adding my 2 cents, a 2x2x100mm cube on 0.4 nozzzle gets trerrible over-extrusion in the center with "Fill gaps between walls" enabled.

With 0.4 line size, it should perfectly fit 5 lines, but Cura generates 6 lines, with the middle one doubled.
Tested with master 20200515 and 4.6.1.

CFFFP_straight_100mm.zip

Edit relevant GCode:

;TYPE:WALL-OUTER
G1 F900 E1
G1 F2400 X-54.712 Y16.2 E0.04843
G1 X44.69 Y16.2 E3.00857
G1 X44.69 Y17.8 E0.04843
G1 X-54.712 Y17.8 E3.00857
G0 F7200 X-54.312 Y17.4
;TYPE:WALL-INNER
G1 F4800 X-54.312 Y16.6 E0.02421
G1 X44.29 Y16.6 E2.98436
G1 X44.29 Y17.4 E0.02421
G1 X-54.312 Y17.4 E2.98436
G0 F7200 X-53.922 Y17.01
;TYPE:SKIN
G1 F2400 X-53.922 Y16.99 E0.00061
G1 X43.9 Y16.99 E2.96075
G1 X43.9 Y17.01 E0.00061
G1 X-53.922 Y17.01 E2.96075
G0 F7200 X-53.912 Y17

[earldbjr]

I'm glad SmartAvionics has this pretty much solved. I gave up on regular cura for a year over this problem, and came back to find an instance of "we solved it" followed by evidence to the contrary.

Thanks SA!

[Liamnerf]

Just here to say that I've found this to still be an issue in 4.6.1. Anyone heard anything from the Cura devs about it recently?

[richfelker]

Does anyone have a testcase showing SA getting this right? I tried SA a month or so back trying to improve this type of issue and did not see any differences, but it's possible that my examples weren't the type of fill affected.

[smartavionics]

They are working hard to provide a new all singing and dancing wall printing implementation. It's a lot of work to do it right so please be patient.

[earldbjr]

SA's builds have been working for me for all use cases. I've started using them exclusively since this became a problem.

[Liamnerf]

They are working hard to provide a new all singing and dancing wall printing implementation. It's a lot of work to do it right so please be patient.

Cool, as long as they’re working on it I’m happy. And thanks for taking the time to put out your own build, I’ll give it a go soon.

[Ghostkeeper]

To track progress, see here: Ultimaker/CuraEngine#1210
It's an implementation to get a variable line width. Several sub-branches have also been created where development is being done.

[richfelker]

@Ghostkeeper Thanks for the update! This is really exciting work.

[matthijsberg]

As a stop-gap (ho ho!) solution, if you use my master build it has a new implementation of both the gap filling and thin wall printing which doesn't behave like your example. As always, you can find my builds at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

This really works super for me! Thanks a bazillion for this.

One thing and I'm not sure if this is connected to your solution, but when I use your version with "Print Thin Lines" a line of the nozzle width is printed in a slightly smaller area. This builds up a "pile" of material for me, especially in top layers. Can we alternate print thin lines per layer? So we print one thin line on layer 1, not on 2, do on 3, etc.?

[Ghostkeeper]

This is fixed in Ultimaker/CuraEngine#1210.