The gap fill was disabled for zero infill.
Now the gap fill is enabled in between the perimeters, but disabled between
the inner-most perimeter and infill in case the infill is set to zero.
Also in case there are multiple infill regions inside a perimeter,
the mutliple infills are considered as non-zero if at least one infill
is non-zero, therefore the gap fill will be added inside the inner-most
perimeter.
In case there were empty object layers supposed to be floating on supports which were set to use a specific extruder, wipe tower was missing layer required to do the toolchange, leading to a crash
Such cases are now detected and layers that need it are additionally assigned as wipe tower layers
Also tracked as SPE-526
This can happen if the user enters invalid toolchange through the custom gcodes
Such toolchange is now simply ignored by the CoolingBuffer, exporting gcode is NOT stopped, a log error is emitted
The very first slicing step needs to be invalidated if support is
enabled or disabled while the soluble supports are configured,
as the bridging is disabled for soluble supports, while the bridging
is enabled with supports disabled.
If the custom toolchange gcode switches extruder to the one that is expected, PrusaSlicer does not issue its own T command
Otherwise, this command is inserted just after the custom gcode, even in case it is not empty
This should prevent issues such as #2884 and #2886 from being reported
Fix of "Bridging infill not connecting with infill set to 0%" #1301
Top, bottom and bridging areas are extended into infill as long
as the infill is not zero. If the infill is zero,
top, bottom and bridging areas wound not expand into these "void" areas.
With this commit, the top, bottom and bridging areas are allowed to expand
into the "void" areas as long as these "void" areas are supported below
with perimeters or some other non-empty infill, and slightly beyond
these supporting areas into the voids (currently hard coded to 1mm).