difference() {
union() {
translate([0,0,1]) color("green") cube([1,1,1]);
color("red") cube([1,1,1]);
};
translate([-.5, -.5, -.5]) color("pink") cube([2,1,3]);
}
From two cubes of different color, a third, pink cube is removed.
The exposed interface is pink (the color of the invisible object that was used to cut), instead of the color of the cubes that were there originally
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
This is not really a bug - it's how it's supposed to work. Color information is only for illustration purposes. If you want an object to be negative in the same color as the positive, you can color the objects accordingly.
I am not sure if it is all that useful to see the color of the object that was used to remove something though.
Consider this:
I have made an exquisitely complex model, with lots of internal structure.
Now, I would like to create a cutaway, or maybe even many cutaways, maybe slicing the part!
My understanding is that as it is now, I'd have to color hundreds of different polygons after the cutaway is cut away.
Maybe there could be an invisible color that allows the cut away interface to retain the color its object has?
OK, I understand your needs :)
It could be possible to simply ignore the color for negative objects and inherit the color form the closest positive object. I'm not sure if this is trivial this is to implement though.
Do you have some nice examples which could be used to create developer motivation for this?
Sure. Just pilfered from thingieverse, I have to refactor mine some more.
Thingieverse has a nice winch. But when I take out a cross section, all the coloring is gone!
http://www.thingiverse.com/thing:161157/#files
// Difference to Winch.scad to get cross section
===
- winch();
+++
difference() {
winch();
translate([-100,-100,-1])
cube([300,100,200]);
}
===
+1, I would also like to see this issue fixed :)
Workaround for some instances: make the cut transparent.
difference()
{
stack();
color("Blue", 0) //0 is fully transparent
cube([8,8,8], true);
}
both use cases are valid.
the current behaviour is useful if you want to see where the difference is being applied (usually on a single shape) which I would assume is the original use case.
obviously the currently requested function would also be useful especially when applied to assemblies.
could we just have a parameter on difference? something like
difference(cut_color = true) { }
or maybe only apply the color of the differenced object if it is explicitly given a color? so:
difference() {
union(){
translate([0,0,0])
color("red")
cylinder(h = 1, r = 20);
translate([0,0,1])
color("green")
cylinder(h = 1, r = 20);
translate([0,0,2])
color("blue")
cylinder(h = 1, r = 20);
translate([0,0,3])
color("yellow")
cylinder(h = 1, r = 20);
}
translate([0,0,2.5])
color([1,0,0]) //<-------------explicitly set color
cube([20,20,20], center = true);
}
would make
but
difference() {
union(){
translate([0,0,0])
color("red")
cylinder(h = 1, r = 20);
translate([0,0,1])
color("green")
cylinder(h = 1, r = 20);
translate([0,0,2])
color("blue")
cylinder(h = 1, r = 20);
translate([0,0,3])
color("yellow")
cylinder(h = 1, r = 20);
}
translate([0,0,2.5]) //<-------------no color set
cube([20,20,20], center = true);
}
could make
Sounds like a good solution.
Are there any plans on implementing this?
No plans, but the task is up for grabs if someone wants to take a stab at it.
I don't think it is possible with the way OpenCSG works. The second part of the difference will always be one colour I think because it is drawn as a single cube.
yep, this could easily turn into rewriting OpenCSG ...
Most helpful comment
or maybe only apply the color of the differenced object if it is explicitly given a color? so:
would make
but
could make