Skip to content

flush_into_objects=1 silently collapses a multi-colour slice to a single filament #211

Description

@jwalker279-cmd

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

  1. Take a working multi-colour 3MF (2+ filaments, confirmed to slice with all colours present).
  2. Set flush_into_objects=1 in the process settings, leave flush_into_infill at its default.
  3. Slice headlessly.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions