I do the same thing, difference() the text from my main part, then use lazy
union to export the main part and the text in a separate color.  Using
PrusaSlicer, I've never experienced any issues in the slicer with this
approach.  I did have some problems when I tried skipping the difference().
Dan

On Mon, Apr 20, 2026 at 7:49 PM Mark Erbaugh via Discuss <
discuss@lists.openscad.org> wrote:

I do something similar, but I export the base and the text as two
separate STL files and then combine them in the slicer, assigning
materials and colors there.

If there is a smarter/easier way to do this, exporting both in a single
.3MF, then I would like to learn how to do that

Jon

On 4/20/2026 3:57 PM, Dan Perry via Discuss wrote:

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

A chance for me to contribute to the forum 😊.

I used to do the same, multiple STL files, but I’ve been trying different ways to use just one import.

I’ve attached Flag Shield.svg and USA 250.scad. Flag Sield.scad is a four color image. It has five layers, one for each color labeled with the color name and a fifth layer labeled outline with the overall outline.

USA 250.scad reads in that information and can create a .3mf file with color information that can be read by Bambu Studio as a single import. Here are some notes:

When exporting the .3mf file, you have to use the export function and then read that into Bambu Studio, you can’t use the 3d print button. If you hold down shift while clicking the .3mf export button, OpenSCAD brings up the export options dialog. Make sure that format (in the middle) is set to export colors as Color. Once you have set this, OpenSCAD will remember this setting so you can just click the export button in the future. The issue is that if you click the 3d Print button, there is no option to configure the export colors. They are always exported as Base Material. While Base Material still contains color information, Bambu Slicer doesn’t use that, colors must be exported as color.

At the top of the file are variables black, cobalt_blue, jade_white and red. These contain the hex representation of the colors of Bambu Lab PLA BASIC filaments with those colors. If you use those color codes, Bambu Slicer will automatically map the color to the corresponding filament.

These are the parts I’m still working on (see my other recent posts). Even though the .scad file creates the top and bottom colored layers with one 0.2mm layers each, Bambu Studio uses the “Top Paint Penetration Layers” and “Bottom Paint Penetration Layers"settings to determine the number of layers with color. Also, and I think this is an issue where due to rounding the color layers don’t exactly match one another and there can be small gaps between them. If the gap is large enough, it confuses the slicer and there can be artifacts in the interior layers.



I hope this helps. Feel free to fine tune the process.

Mark

On 4/20/26 11:49 AM, Mark Erbaugh via Discuss wrote:

Maybe, but try "arachne" wall instead.

OpenSCAD does not have volumetric coloring (use that term to search the
list). You should treat each object exported by OpenSCAD as a single
color -- web search for "colorscad" for how it handles multi-color
objects; even if you don't use it, it explains the limitations.

Cory

"You should treat each object exported by OpenSCAD as a single color"

And yet, I JUST learned how to export what is essentially two different
objects by coloring them.

I imagine there is a lot more that I do not understand.

On 4/20/2026 7:55 PM, Cory Cross via Discuss wrote:

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 4/20/2026 11:49 AM, Mark Erbaugh via Discuss wrote:

Entirely possible, though if it causes problems for the slicer I would
consider it to be a problem with the slicer. That is, if it's ending up
as multiple parts/objects in the slicer.

If it's ending up as a single part in the slicer, and it's the result of
lazy union, then it may be a case that I've been worried about since I
heard about lazy union.  People say that slicers are ready to handle
models with overlapping pieces, but I think it's a very gray area where
I wouldn't be surprised if there are problems.  STL in particular is
ill-suited for representing such cases.

Other than lazy union - which, as I said, I don't think you can rely on

• it isn't meaningful to talk about "multiple parts for the same
  volume".  If you union overlapping shapes, the result is one shape.  The
  now-internal boundaries are lost.  Color of faces is preserved on
  preview.  Historically, with CGAL, color of faces was lost on render. 
  Manifold preserves some face coloring but I don't think the result ends
  up the same as preview... and it does not do volume coloring; it is
  not meaningful to talk about the color inside the shape.

On 4/20/2026 12:12 PM, Nathan Sokalski via Discuss wrote:

Historically, yes.  Manifold preserves come color, and I think some of
it may be exported into 3MF.  But as I noted above, it's face coloring
only; it doesn't tell you about the interior of the shape.

I have not heard that; in fact, if anything, the reverse:  avoid
intersection.  Intersection can apparently cause the previewing
mechanism to explode in complexity.

I have not heard of any difference between the two for rendering.