3DPrinting/PrusaSlicer-NonPlainar
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Bugfix: a wrong optimization caused some top-level perimeters not to be sorted using the nearest-neighbor search. #2322

Browse Source
This commit is contained in:
Alessandro Ranellucci 2014-12-24 00:10:31 +01:00
parent af446dc7d4
commit d47e12f05c
1 changed files with 6 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
lib/Slic3r/Layer/Region.pm
View File

@ -350,16 +350,12 @@ sub make_perimeters {
# use a nearest neighbor search to order these children
# TODO: supply second argument to chained_path() too?
# Optimization: since islands are going to be sorted by slice anyway in the
# G-code export process, we skip chained_path here
my ($sorted_collection, @orig_indices);
if ($is_contour && $depth == 0) {
$sorted_collection = $collection;
@orig_indices = (0..$#$sorted_collection);
} else {
$sorted_collection = $collection->chained_path_indices(0);
@orig_indices = @{$sorted_collection->orig_indices};
}
# (We used to skip this chiained_path() when $is_contour &&
# $depth == 0 because slices are ordered at G_code export
# time, but multiple top-level perimeters might belong to
# the same slice actually, so that was a broken optimization.)
my $sorted_collection = $collection->chained_path_indices(0);
my @orig_indices = @{$sorted_collection->orig_indices};
my @loops = ();
foreach my $loop (@$sorted_collection) {