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