How to prepare model for multicolor print option?
Dear all,
I've got a multicolor printer now and wanted to export parts for multicolor prints. I use the PrusaSlicer.
Please consider the following code for (an extremely simplified) example:
eps = 0.01;
difference() {
cube([20, 20, 10], center = true);
translate([0, 0, 4.4]) engraving();
}
module engraving() {
cylinder(h = 0.6 + eps, d = 10, $fn = 30);
}
I would now like to be able to export two things:
-
the cube with the engraving cut out for non-multicolor prints
-
the cube with the cylinder embedded for multicolor prints such that I can configure them separately in the slicer
It would be nice If I just had to modify a flag to distinguish between the export versions.
I have already read about the lazy union feature in this context, but I have no clue how to do it correctly and maintainable. How would you do it?
Bonus question: How would you in general handle models consisting of multiple parts where you want to export the parts separately (not just for multicolor)?
AFAIK, your two options are lazy union + export as a 3MF file, or export
separate STLs and import them simultaneously into PrusaSlicer.
Printing tip: I find the prints to look much better if the secondary color
(engraving() in your case) protrudes one or two layer thicknesses above the
main color (cube()).
Dan
On Tue, Sep 1, 2026 at 7:24 AM Thomas Richter via Discuss <
discuss@lists.openscad.org> wrote:
Dear all,
I've got a multicolor printer now and wanted to export parts for
multicolor prints. I use the PrusaSlicer.
Please consider the following code for (an extremely simplified) example:
eps = 0.01;
difference() {
cube([20, 20, 10], center = true);
translate([0, 0, 4.4]) engraving();
}
module engraving() {
cylinder(h = 0.6 + eps, d = 10, $fn = 30);
}
I would now like to be able to export two things:
-
the cube with the engraving cut out for non-multicolor prints
-
the cube with the cylinder embedded for multicolor prints such that I
can configure them separately in the slicer
It would be nice If I just had to modify a flag to distinguish between the
export versions.
I have already read about the lazy union feature in this context, but I
have no clue how to do it correctly and maintainable. How would you do it?
Bonus question: How would you in general handle models consisting of
multiple parts where you want to export the parts separately (not just for
multicolor)?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I would now like to be able to export two things:
-
the cube with the engraving cut out for non-multicolor prints
-
the cube with the cylinder embedded for multicolor prints such that
I can configure them separately in the slicer
It would be nice If I just had to modify a flag to distinguish
between the export versions.
I haven't done this before, but here's how I would approach it.
Define two variables, and use them to control which part to render:
colour_red = true;
colour_green = true;
if (colour_red) {
color("red") {
// Draw shape and subtract cylinder
difference() {
cube([20, 20, 10], center = true);
translate([0, 0, 4.4]) engraving();
}
}
}
if (colour_green) {
color("green") {
// Draw cylinder
translate([0, 0, 4.4]) engraving();
}
}
This way you could leave both variables 'true' when designing, set one
to 'false' for the red-only and green-only versions, and use the
red-only version as the single-colour version as well.
When you get to PrusaSlicer you just import both files (red and green)
and they will overlay but appear as two separate objects, then you
should be able to set your options (like which filament to use)
differently for each of the two objects.
If you save the PrusaSlicer project as a .3MF file then it will keep
those separate objects and filament settings.
Cheers,
Adam.
Thank you! Export as .3mf was the trick I was looking for. I just realized that multiple single color / multi color export options lead to finer granulated modules which I really like from a software engineering perspective.
Best,
Thomas
Am 01.09.2026 um 10:28 schrieb Adam Nielsen a.nielsen@shikadi.net:
I would now like to be able to export two things:
-
the cube with the engraving cut out for non-multicolor prints
-
the cube with the cylinder embedded for multicolor prints such that
I can configure them separately in the slicer
It would be nice If I just had to modify a flag to distinguish
between the export versions.
I haven't done this before, but here's how I would approach it.
Define two variables, and use them to control which part to render:
colour_red = true;
colour_green = true;
if (colour_red) {
color("red") {
// Draw shape and subtract cylinder
difference() {
cube([20, 20, 10], center = true);
translate([0, 0, 4.4]) engraving();
}
}
}
if (colour_green) {
color("green") {
// Draw cylinder
translate([0, 0, 4.4]) engraving();
}
}
This way you could leave both variables 'true' when designing, set one
to 'false' for the red-only and green-only versions, and use the
red-only version as the single-colour version as well.
When you get to PrusaSlicer you just import both files (red and green)
and they will overlay but appear as two separate objects, then you
should be able to set your options (like which filament to use)
differently for each of the two objects.
If you save the PrusaSlicer project as a .3MF file then it will keep
those separate objects and filament settings.
Cheers,
Adam.
Where would I find documentation on "lazy union + export as a 3MF file"
please?
On 9/1/2026 4:16 AM, Dan Perry via Discuss wrote:
AFAIK, your two options are lazy union + export as a 3MF file, or
export separate STLs and import them simultaneously into PrusaSlicer.
Printing tip: I find the prints to look much better if the secondary
color (engraving() in your case) protrudes one or two layer
thicknesses above the main color (cube()).
Dan
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
There are no really good answers.
"Lazy union" shows up in most of the answers. However, LU as it is
currently designed and implemented is not a good answer... it just
happens to sort of accidentally produce useful results. It was designed
as an optimization, and one of its key problems is that it produces
results that aren't compatible with "ordinary" operation. You should
assume that it will not continue to exist in its current form and that
any workflow based on it will need changes when something better comes
along. (This is why it is classified as "experimental".)
I would do something like Adam says, with a wrapper module that
selectively generates each color, and a shell script that runs OpenSCAD
multiple times to generate individual per-color files.
It looks like colorscad https://github.com/jschobben/colorscad is a
shell script that automates most of the process.
The good news is that I just ordered an INDX kit for my Core ONE+, and
so my personal incentive to make something better happen is bumping way
up...
Yes, the original use case for lazy union was ill-considered, but there
are still other reasons for retaining it. Particularly, if one (well,
I) wants to model an assembly of discrete parts and save it as a
multi-mesh .3mf. OpenSCAD will currently save such, owing to LU, but it
doesn't provide the capability to name the individual meshes in the 3mf
export.
It's not all just about 3D printing...
On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
There are no really good answers.
"Lazy union" shows up in most of the answers. However, LU as it is
currently designed and implemented is not a good answer... it just
happens to sort of accidentally produce useful results. It was
designed as an optimization, and one of its key problems is that it
produces results that aren't compatible with "ordinary" operation.
You should assume that it will not continue to exist in its current
form and that any workflow based on it will need changes when
something better comes along. (This is why it is classified as
"experimental".)
I would do something like Adam says, with a wrapper module that
selectively generates each color, and a shell script that runs
OpenSCAD multiple times to generate individual per-color files.
It looks like colorscad https://github.com/jschobben/colorscad is a
shell script that automates most of the process.
The good news is that I just ordered an INDX kit for my Core ONE+, and
so my personal incentive to make something better happen is bumping
way up...
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
Here's how I generate a separate STL for each color and then combine them in the slicer:
https://nextjeff.com/creating-multi-extruder-designs-in-openscad-for-3d-printing-6c43a002ef64
It is easy to automate and to code for.
The new PrusaSlicer alpha supports plugins and I hope to find a creative way to further automate and streamline my process.
BTW I use OpenSCAD to create cool geometric designs that I print on fabric. More info at:
https://nextjeff.com/3d-printing-on-fabric-tips-and-tricks-f306f4d56833
Enjoy,
Jeff;
On Wed, Sep 2, 2026, at 7:35 AM, Glenn Butcher via Discuss wrote:
Yes, the original use case for lazy union was ill-considered, but there are still other reasons for retaining it. Particularly, if one (well, I) wants to model an assembly of discrete parts and save it as a multi-mesh .3mf. OpenSCAD will currently save such, owing to LU, but it doesn't provide the capability to name the individual meshes in the 3mf export.
It's not all just about 3D printing...
On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
There are no really good answers.
"Lazy union" shows up in most of the answers. However, LU as it is currently designed and implemented is not a good answer... it just happens to sort of accidentally produce useful results. It was designed as an optimization, and one of its key problems is that it produces results that aren't compatible with "ordinary" operation. You should assume that it will not continue to exist in its current form and that any workflow based on it will need changes when something better comes along. (This is why it is classified as "experimental".)
I would do something like Adam says, with a wrapper module that selectively generates each color, and a shell script that runs OpenSCAD multiple times to generate individual per-color files.
It looks like colorscad https://github.com/jschobben/colorscad is a shell script that automates most of the process.
The good news is that I just ordered an INDX kit for my Core ONE+, and so my personal incentive to make something better happen is bumping way up...
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 9/2/2026 6:35 AM, Glenn Butcher via Discuss wrote:
Yes, the original use case for lazy union was ill-considered, but
there are still other reasons for retaining it. Particularly, if one
(well, I) wants to model an assembly of discrete parts and save it as
a multi-mesh .3mf. OpenSCAD will currently save such, owing to LU,
but it doesn't provide the capability to name the individual meshes in
the 3mf export.
Yes. As I said, it sort of accidentally produces useful results.
Generating multi-mesh 3MFs is one of the key use cases for any replacement.
I’ve been using a lazy union for multi-color models. It works well and I hope if it is “fixed” it doesn’t break a lot of my models. Here’s some demo code:
module base()
{
color("#00ae42") // bambu green
translate([0,0,1.5])
cube([40,15,3],center=true);
}
module label()
{
color("#0086d6") // cyan
translate([0,0,3])
linear_extrude(1)
text("demo", halign="center", valign="center");
}
base();
label();
I render this and save it as a .3mf file. I load the .3mf file into my slicer (Bambu Studio). Since I used color codes that correspond to the color code of filaments loaded on my printer, all I have to do is slice and print.
This is a simplified model with the label on top of the base, but I can create complex components and have multiple colors on multiple layers and still all I have to do is slice and print.
Mark