flush_into_objects=1 silently collapses a multi-colour slice to a single filament
Version: QIDIStudio 02.07.02.10 (Win64), headless CLI.
Mode: headless CLI slicing with a multi-filament project.
Summary
Setting the process option flush_into_objects=1 (purge into the printed part rather than a wipe tower) causes the CLI to silently slice as if only one filament were used — used_extruders drops to 1 in the gcode header, only the majority colour's grams/weight are reported, and the other filament(s)/their geometry disappear from the output. Exit code is 0, result.json says "Success.", and there is no warning that a colour was dropped.
This produces output that is symptomatically identical to the separate "extruder ≥2 parts vanish" issue (filed separately), which makes it easy to mistake for a geometry/model problem rather than a config problem.
Repro
- Take a working multi-colour 3MF (2+ filaments, confirmed to slice with all colours present).
- Set
flush_into_objects=1 in the process settings, leave flush_into_infill at its default.
- Slice headlessly.
- Compare
; used_extruders = and per-filament grams in the gcode header / result.json against the same file with flush_into_objects=0.
Expected: all filaments still extrude; purge material lands inside the printed part's infill/walls instead of a wipe tower.
Actual: the slice collapses to one filament; the rest of the colours are gone from the gcode with no error.
Isolation
Bisected one config key at a time on a known-good multi-colour file:
flush_into_infill = 1 → still multi-colour, correct. ✅
flush_into_objects = 1 (alone or paired with flush_into_infill=1) → collapses to one filament. ❌
So the failure is specific to flush_into_objects, not the general "purge into part instead of tower" feature.
Workaround (in use here)
Use flush_into_infill=1 alone for "purge into the print" behaviour; never set flush_into_objects=1 on a multi-colour job. Because the failure mode looks identical to a dropped-part/geometry bug, when a multi-colour slice unexpectedly comes back single-filament, diff the process config before touching the model.
Suggested fix
Either make flush_into_objects=1 actually purge into whichever object/layer is present at that Z (matching its stated purpose) instead of silently dropping other filaments, or fail loudly with an error_string/warning_message when the option is incompatible with the current geometry/filament count.
flush_into_objects=1silently collapses a multi-colour slice to a single filamentVersion: QIDIStudio 02.07.02.10 (Win64), headless CLI.
Mode: headless CLI slicing with a multi-filament project.
Summary
Setting the process option
flush_into_objects=1(purge into the printed part rather than a wipe tower) causes the CLI to silently slice as if only one filament were used —used_extrudersdrops to1in the gcode header, only the majority colour's grams/weight are reported, and the other filament(s)/their geometry disappear from the output. Exit code is0,result.jsonsays"Success.", and there is no warning that a colour was dropped.This produces output that is symptomatically identical to the separate "extruder ≥2 parts vanish" issue (filed separately), which makes it easy to mistake for a geometry/model problem rather than a config problem.
Repro
flush_into_objects=1in the process settings, leaveflush_into_infillat its default.; used_extruders =and per-filament grams in the gcode header /result.jsonagainst the same file withflush_into_objects=0.Expected: all filaments still extrude; purge material lands inside the printed part's infill/walls instead of a wipe tower.
Actual: the slice collapses to one filament; the rest of the colours are gone from the gcode with no error.
Isolation
Bisected one config key at a time on a known-good multi-colour file:
flush_into_infill = 1→ still multi-colour, correct. ✅flush_into_objects = 1(alone or paired withflush_into_infill=1) → collapses to one filament. ❌So the failure is specific to
flush_into_objects, not the general "purge into part instead of tower" feature.Workaround (in use here)
Use
flush_into_infill=1alone for "purge into the print" behaviour; never setflush_into_objects=1on a multi-colour job. Because the failure mode looks identical to a dropped-part/geometry bug, when a multi-colour slice unexpectedly comes back single-filament, diff the process config before touching the model.Suggested fix
Either make
flush_into_objects=1actually purge into whichever object/layer is present at that Z (matching its stated purpose) instead of silently dropping other filaments, or fail loudly with anerror_string/warning_messagewhen the option is incompatible with the current geometry/filament count.