Infill strategy for solid layers performs unnecessary travel moves

[DrLex0]

Version

1.2.9

Operating system type + version

Mac OS X 10.11.6

Behavior

The rectilinear infill of solid (top and bottom) layers is often needlessly executed in two or more phases, causing the nozzle to travel across the layer and marring the top infill.
One would expect that for a simple ellipse, the infill would begin nearest to a tangent line, and go to the other end in one continous stretch. However, the following diagram shows what Slic3r does for the top layer of the attached ‘top hat’ model:

After doing the perimeters, it begins the infill at the fourth line from the left. When it has reached the right edge, it zaps across the layer and extrudes the three remaining lines. The travel move is visible in the photo. Of course I could enable Z lift during retraction, but that would only be a workaround.

Here is another example with a simple elliptical cylinder:

Although the infill is now done from left to right, it still is interrupted by a travel move that causes two lines to be extruded in the same direction.

STL/Config (.ZIP) where problem occurs

Tophat.zip

[JeffreyRodriguez]

I was digging into related unnecessary moves before the CPP port, and it doesn't seem to have changed much during the port.

The relevant code is in the for-loop at libslic3r/Fill/FillRectilinear.cpp:101

From my reading:

1. A pattern of disconnected infill lines is laid over the model's bounding box. (think stripes)
2. The current-layer slice of the model is intersected with those lines, cutting many of them, creating lots of shorter lines.
3. The resulting list of lines is joined, end-to-end, into long chains, if they satisfy certain proximity requirements. (can_connect)
4. Certain joins will send the printhead off far away, or can paint shorter chains into corners. Many of these 'islands' of infill chains could be joined together with some clever splicing.

Thinking over the problem, I was attracted to a post-processing step. Look for islands and see if they can be linked back into a continuous chain. This could greatly reduce unnecessary travel for a whole lot of prints out there.

Edit: Thinking about it some more, that's exactly the right metaphor - this algorithm regularly paints itself into corners.

[bubnikv]

The prusa fork has a new rectilinear2 infill, which builds up a graph, which it traverses along the perimeters. The rectilinear2 infill is on by default and it makes a difference for the supports, if the supports are printed without a sheath. The new infill achieves better line continuity. AFAIK the infill sequences are sorted inside an island and islands are sorted into a chain. So there is some code for ordering the infill, though it could be improved. Currently I find a bigger issue in breaking solid infill into top/bottom/solid infill regions at the same layer with very similar properties.Often the infill pieces are tiny and the print would benefit from merging them. It would also be great to visualize the infill type by color in the preview.

…

On Nov 25, 2016 7:12 PM, "Jeff Rodriguez" ***@***.***> wrote: I was digging into related unnecessary moves before the CPP port, and it doesn't seem to have changed much during the port. The relevant code is in the for-loop at libslic3r/Fill/ FillRectilinear.cpp:101 <https://github.com/alexrj/Slic3r/blob/master/xs/src/libslic3r/Fill/FillRectilinear.cpp#L101> From my reading: 1. A pattern of disconnected infill lines is laid over the model's bounding box. (think stripes) 2. The current-layer slice of the model is intersected with those lines, cutting many of them, creating lots of shorter lines. 3. The resulting list of lines is joined, end-to-end, into long chains, if they satisfy certain proximity requirements. (can_connect) 4. Certain joins will send the printhead off far away, or can paint shorter chains into corners. Many of these 'islands' of infill chains *could* be joined together with some clever splicing. Thinking over the problem, I was attracted to a post-processing step. Look for islands and see if they can be linked back into a continuous chain. This could greatly reduce unnecessary travel for a whole lot of prints out there. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3492 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj5I3WNHpkcXTvr4tETKwNWddaGzNBXks5rByT3gaJpZM4J0X9K> .

[bubnikv]

Thinking about it once again, the infill continuity could be improved in the new rectilinear2 infill by extending the infill line at both sides. Currently my code extends the infill line at a single end only.

[JeffreyRodriguez]

For large complex parts, connecting infill lines would go a long way - In the old version I noticed a lot of <retract, lift, move, restart> operations that could have been contiguous.

If rectilinear2 has improved half of that, it might go a long way to finish the other half. I still need to get round to running a dev build of Slic3r personally - Still on 1.2.9 release.

[lordofhyphens]

@JeffreyRodriguez On Windows, there's currently the bintray builds, which replaced rectilinear with rectilinear2.

[JeffreyRodriguez]

@lordofhyphens - Alas - Linux :)

I'm also running into a problem that segfaults unless I disable the plater - but that's literally another issue.

[lordofhyphens]

@JeffreyRodriguez Really? Weird. I do my dev work on linux. Feel free to open up a new issue, but my gut feeling is "disable background processing and see what happens".

[lordofhyphens]

@JeffreyRodriguez https://bintray.com/lordofhyphens/Slic3r/download_file?file_path=slic3r.zip if you want to give it a try (I just did a one-off package from my dev system, no guarantees if it doesn't work ^^;)

Was built on a Debian Linux system with perl 5.20.2, 64-bit.