--filament-colour
"#FF0000;#0000FF"Replace per-slot filament_colour values in the project config before slicing, driving thumbnail regeneration, purge-volume recalculation, and — when all slots share one filament preset name — wipe-tower suppression or re-enablement depending on whether the supplied colors are distinct.
Details
Overrides the filament_colour config values embedded in the project before slicing begins. The argument is a semicolon-delimited list of hex color strings, one entry per filament slot, matched positionally: the first color maps to slot 1, the second to slot 2, and so on. Each color must be either #RRGGBB (six hex digits, fully opaque) or #RRGGBBAA (eight hex digits with an alpha byte). The # prefix is required; those are the only two lengths accepted by the color parser. Entries that do not match these formats are still written verbatim to the project's color array if they are non-empty — the format check operates on a copy used purely to detect whether the value changed, not as a gate before the write.
Empty string entries in the list (#FF0000;;#0000FF) are valid and act as pass-through: the corresponding slot retains whatever color was stored in the project. Any non-empty entry, valid or not, overwrites its slot.
When the flag is present, the engine loads the project's existing filament_colour array (initializing it to all #FFFFFF entries first if the project file carries none), then iterates up to the project's slot count and writes each non-empty CLI value over the corresponding project entry. CLI entries beyond the project's slot count are silently dropped; CLI entries fewer than the slot count leave the trailing slots at their project values. After the overwrite, any slot whose color differs from the original triggers regeneration of the plate thumbnail. The flag also causes an immediate recalculation of the per-transition purge-volume table that drives wipe-tower output.
There is one behavioral side-effect worth knowing: when every loaded filament slot resolves to the same single filament preset name (all entries in the --load-filaments list share the same preset), the engine normally suppresses the wipe tower on the assumption that no material transition is needed. If --filament-colour is then supplied and the color list contains two or more distinct non-empty values, the engine reverses that suppression and re-enables the wipe tower, reasoning that the colors differ even if the filament material is nominally the same. Supplying only one unique color (or leaving all but one entry empty) leaves the suppression in place. This flag is also mutually exclusive with per-vertex or per-face color data embedded in the input geometry: if the input objects carry such color data that the engine is consuming to assign filament slots automatically, passing --filament-colour is a fatal error.
Examples
"#FF0000;#0000FF" // two slots: opaque red, opaque blue
"#FF0000FF;#0000FF80" // same, second slot at ~50% alpha
"#FF0000;;#0000FF" // three slots: red, slot 2 unchanged, blueWatch out for
- ▲ The option name uses British spelling — `--filament-colour`, not `--filament-color`. The two are not aliases; passing the unrecognized spelling causes a parse error that aborts execution immediately.
- ▲ Passing this flag while the engine is reading per-vertex or per-face color data from the model geometry causes an immediate `CLI_INVALID_PARAMS` exit. The two color-assignment paths are mutually exclusive.
- ▲ If your CLI color list is shorter than the number of filament slots in the project, trailing slots keep their project-embedded colors. If it is longer, the extra entries are dropped without warning. Match the count to the slot count to avoid silent mismatches.
Related flags
Sign up for free today
No credit card required. Connect unlimited printers and get production automation running in minutes.