As discussed in issue #278, printing of perimeters and infill in this order:
perimeter->next island->perimeter->first island->infill->next island->infill
is suboptimal and probably never a requirement, whereas
would be a better approach. I don't see any use cases where the first approach is superior.
The option "avoid crossing perimeters" was introduced, and when this option is enabled, the optimal ordering happens. But this option does more than that, and can also introduce other issues in some cases, like potentially much longer moves that can result in ooze.
Since "avoid crossing perimeters" seems unlikely to become slic3r's default behaviour without an option to disable it, I'd like to suggest that slic3r should always complete an island before moving to the next one, even when this option is disabled. For me the option is currently a workaround that solves one issue but sometimes introduces other ones. Solving this ordering appears to be a generic fix to optimizing moves and print ordering anyway.
I agree with you. People will complain, but still I think it's a good change.
+1 when using avoid crossing perimeters + only retrect when crossing perimeters the nozzle can crash when moving a long distance over infill and often the extruder oozes into the infill which leads to gaps when starting the next printer section after the travel move.
so finishing island after island withouth the need of using avoid crossing perimeters would be really nice!
Maybe decreasing CROSSING_PENALTY (https://github.com/alexrj/Slic3r/blob/master/lib/Slic3r/GCode/MotionPlanner.pm#L24) will work as expected. With low CROSSING_PENALTY planner will still try to avoid perimeters if good path is close and it will use right angle (aproximately) to cross them.
Currently penalty region is 3mm (https://github.com/alexrj/Slic3r/blob/master/lib/Slic3r/GCode/MotionPlanner.pm#L14) and crossing penalty is 20, so planer will use path that is up to 60mm longer.
Any test file around?
@ledvinap, not sure about your comment.. @kefir- is referring to https://github.com/alexrj/Slic3r/blob/6f3844c1ba87610a29356e91081811c35d815ddc/lib/Slic3r/GCode/Layer.pm#L149 whose behavior should be the default regardless of avoid_crossing_perimeters
Always do one island at time instead of doing that only when avoid_cr…
…ossing_perimeters is enabled. #1907
Done! Let's wait for the complaints.
Nice, I can't wait to try it out!! And I'll try to help you fend off any complaints with good reasoning! :-)
I found a case where this logic doesn't appear to work quite as expected. It may be related to thin infill logic or something like that. Here's some screenshots of a layer that does perimeter -> next island -> perimeter -> infill -> first island -> infill with both 1.1.1 and 1.1.2-dev as of yesterday.
perimeter -> next island -> perimeter -> infill -> first island -> infill
This first picture shows that the perimeter of both the first and second island are done, and no infill has yet been started.
In this second picture, you can see that the infill is almost done on both layers. This is the same layer as the first picture.
gcode with embedded config: http://kefirshare.dreamhosters.com/bridge-torture-test_m2_20140423-232035_1.1.2-dev.gcode
@kefir-, I need config.ini exported from File->Export config, as the embedded one isn't complete. Also maybe the issue was fixed in current master?
Sure, here's a variant. I think the only difference from the first case was the use of brim, here there's no brim. And with this config the issue is still reproduced with current master fetched after your post about 30 minutes ago.
Are you adding the full config to the embedded comments, or should I create an issue for that? :)
Yeah, I'll check that.
The problem is, Slic3r now supports distinct configs inside a single print (per-object and per-object part), so that one will represent a random one.
Or maybe, all of them should be appended...
Bugfix: gap fill was not inserted in the correct order before leaving…
… island. Includes regression test. #1907
Fixed and added regression test. Thanks! :)