Multi colored slicer output not matching painted part
I'm having trouble getting part of an object that I colored for use with my MK4S and MMU3 to slice with that color.
The zipped .3mf: Bag End Sign
Here's the piece I'm coloring. The troublesome part is the scroll. I wish to have just the bottom of it painted in gold, but I have found that the slicer prints that in the same color as the rest of it. Here I have painted the bottom (red arrow), one section of the side of the scroll (cyan arrow), and then two horizontal sections of the "Bag End" sign, (orange arrows).
Here's the output from the slicer (sorry I haven't coordinated the colors - orange is the green from the editor, magenta is the yellow). Note that the edge of the scroll plus both surfaces of the Bag End sign are in a different color, but the bottom of the scroll is not.
What am I doing wrong?
The bottom of the scroll is pretty thin, .5mm thick. Could that be the problem? If so, is there a way around it?
Thanks!
Scott
I'm not quite sure what effect you are describing, attached is a .zip that demonstrates the two most likely. Unzip and load the two files together as parts, assign a different extruder to each. It is intended for 0.2mm layers.
The 'paint' function does not colour a surface, it marks sections of extrusion with the desired extruder - you cannot colour one side of a single extrusion.
Painting is a fallback option, if you have the original files it should be easier to create parts similar to the example.
Cheerio,
RE: Multi colored slicer output not matching painted part
Diem,
Thank you for your response. I unfortunately do not have the original files, these are STLs exported from a .3MF for Bambu Studio.
Looking into it further, I found that if I also 'painted' the backside, then it behaved properly, although it gave me a one layer band of the gold color on the outside.
So I guess I'm more curious about why the area pointed to by the red arrow is behaving differently than the area pointed to by the upper orange arrow. To me, they seem the same, but they obviously are not.
Scott