Colors and boolean operations
I was just trying to get the colors right on some of my models, and
found that I hadn't properly understood how color interacts with
intersection and difference, and the documentation doesn't say. My
mental model was completely wrong.
It seems like the rule is that a surface resulting from a boolean
operation gets the color of the object that contributed that surface.
Thus, for instance, if you use difference() { something(); cylinder() }
to drill a hole though something, the resulting hole is the color of the
cylinder. If you intersection() { cube(10); sphere(10); }, the flat
parts will get the color of the cube while the curved parts get the
color of the sphere.
Another way to look at it is that colors are painted onto surfaces -
including negative surfaces - and are not at all properties of the
volumes enclosed.
With the special case that the default is a different color for the
subtrahend in difference().
For (better) completeness, I checked hull, minkowski, and resize. They
all seem to reset the color to the default.
I'd like to update the documentation to reflect this behavior. Is what
I say above reasonably correct? Does anybody have anything to add?
On 05.04.20 23:23, Jordan Brown wrote:
I'd like to update the documentation to reflect this
behavior. Is what I say above reasonably correct?
Does anybody have anything to add?
The behavior is basically an artifact of the preview
algorithm, so it might even change when switching those
(I'm not sure about that).
So just documenting observed behavior is probably not
a good choice.
ciao,
Torsten.
tp3 wrote
On 05.04.20 23:23, Jordan Brown wrote:
I'd like to update the documentation to reflect this
behavior. Is what I say above reasonably correct?
Does anybody have anything to add?
The behavior is basically an artifact of the preview
algorithm, so it might even change when switching those
(I'm not sure about that).
So just documenting observed behavior is probably not
a good choice.
This sort of issue has come up in the past, where the argument is made that
it's better to keep users guessing than to document the behavior "because it
might change". It seems to me that for people trying to use OpenSCAD, it
is valuable to have documentation on what OpenSCAD actually does. This idea
that we can't document its behavior because it might change just makes
everything harder on user who are trying to use it today, in its current
instantiation. Programming environments change. Then the fact of the
change gets (hopefully) gets documented, people fix their code, and life
goes on. One could argue that any aspect of a programming language might
change someday, which would appear to be an argument for documenting
nothing! I think it's much easier for people if the old behavior and
changed behavior are clearly documented than a mist of uncertainty. If
there's an expectation that it might change, I suggest that it be documented
with a tag that "In version 19.05 colors are handled as follows. This may
change in a later version."
--
Sent from: http://forum.openscad.org/
On 06.04.20 00:50, adrianv wrote:
This idea that we can't document its behavior because it might
change just makes everything harder on user who are trying to
use it today, in its current instantiation.
That is not what I said.
ciao,
Torsten.
Probably lots of other issues that are higher priority, but I have thought for some time it would be useful to be able to import an image file as a useful guide to dimensioning objects from real life… this feature is available in illustrator and Inkscape and I think it would have utility in OpenSCAD as well. Don’t know how difficult it would be to implement, but I just offer it as a suggestion.
On 4/5/2020 3:50 PM, adrianv wrote:
Programming environments change. Then the fact of the change gets
(hopefully) gets documented, people fix their code, and life goes on.
Having worked on enterprise software[1] for the last 25 years, I'm very
sympathetic to the need to maintain compatibility. "People fix their
code" plays quite poorly when the people involved have millions of lines
of code and can't accept an upgrade until they've spent staff-years
fixing and re-certifying their programs. (Python 3.0 was released in
2008, and people are still converting software. It looks like support
for Python 2.x is finally being dropped this year, but that doesn't mean
that it's dead.)
Documenting a behavior doesn't cast it in concrete, but if you've
documented it then people will be justifiably upset if you then change
it, especially for some invisible reason like "we're using a different
library". Left undocumented, the answer is that people shouldn't rely
on the behavior, and if they do then it's on them. One of the big
rules, if you want to maintain compatibility, is not to document
anything that you're not willing to commit to. (Or mark it specially if
it might change, but that doesn't work well.)
That said... OpenSCAD isn't the same class of product as Solaris or
Python. Projects aren't nearly as big. I don't know how big other
people's projects are, but mine is "only" ~9000 lines, and it's a hobby
project, and if something goes slightly wrong somewhere in it I might
never notice. I'm sure there are some people using it for "mission
critical" projects, but I expect that there are very few. It's not a
directly attackable program[3], so it's not like you need to stay at the
bleeding edge to maintain security; if you have to stall upgrading for a
year or two you're probably fine. If there's a good reason for an
incompatibility, I'd say it's OK.
In this particular case, I'd say that having colors and Boolean
operations and not defining how the two interact is ... incomplete.
I'd say one should pick a definition and stick with it, unless a new
definition comes along that is clearly better. The current behavior[2]
seems reasonable; if I were a developer I'd be willing to commit to it.
[1] https://en.wikipedia.org/wiki/Solaris_(operating_system) ,
https://www.oracle.com/storage/nas/
[2] Behavior of colors, that is. Transparency appears to have problems.
[3] Which is not to say that it's not security-sensitive. It's bad if a
malicious OpenSCAD program can attack your system; people should be able
to download OpenSCAD designs and execute them without fear.
The behaviour is that cut faces are the colour of the subtracted object but
that doesn't make sense for 3D printing, so I always apply colour after all
the boolean ops, so each solid is only ever one colour. If I want a surface
to be a different colour, for example I recently made the machined face of
my stepper motor model brighter, I add a thin object over the face.
On Mon, 6 Apr 2020 at 00:53, Jordan Brown openscad@jordan.maileater.net
wrote:
On 4/5/2020 3:50 PM, adrianv wrote:
Programming environments change. Then the fact of the change gets
(hopefully) gets documented, people fix their code, and life goes on.
Having worked on enterprise software[1] for the last 25 years, I'm very
sympathetic to the need to maintain compatibility. "People fix their code"
plays quite poorly when the people involved have millions of lines of code
and can't accept an upgrade until they've spent staff-years fixing and
re-certifying their programs. (Python 3.0 was released in 2008, and people
are still converting software. It looks like support for Python 2.x is
finally being dropped this year, but that doesn't mean that it's dead.)
Documenting a behavior doesn't cast it in concrete, but if you've
documented it then people will be justifiably upset if you then change it,
especially for some invisible reason like "we're using a different
library". Left undocumented, the answer is that people shouldn't rely on
the behavior, and if they do then it's on them. One of the big rules, if
you want to maintain compatibility, is not to document anything that you're
not willing to commit to. (Or mark it specially if it might change, but
that doesn't work well.)
That said... OpenSCAD isn't the same class of product as Solaris or
Python. Projects aren't nearly as big. I don't know how big other
people's projects are, but mine is "only" ~9000 lines, and it's a hobby
project, and if something goes slightly wrong somewhere in it I might never
notice. I'm sure there are some people using it for "mission critical"
projects, but I expect that there are very few. It's not a directly
attackable program[3], so it's not like you need to stay at the bleeding
edge to maintain security; if you have to stall upgrading for a year or two
you're probably fine. If there's a good reason for an incompatibility, I'd
say it's OK.
In this particular case, I'd say that having colors and Boolean operations
and not defining how the two interact is ... incomplete. I'd say one
should pick a definition and stick with it, unless a new definition comes
along that is clearly better. The current behavior[2] seems reasonable; if
I were a developer I'd be willing to commit to it.
[1] https://en.wikipedia.org/wiki/Solaris_(operating_system) ,
https://www.oracle.com/storage/nas/
[2] Behavior of colors, that is. Transparency appears to have problems.
[3] Which is not to say that it's not security-sensitive. It's bad if a
malicious OpenSCAD program can attack your system; people should be able to
download OpenSCAD designs and execute them without fear.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2020-04-06 09:48, nop head wrote:
The behaviour is that cut faces are the colour of the subtracted
object but that doesn't make sense for 3D printing, so I always apply
colour after all the boolean ops, so each solid is only ever one
colour. If I want a surface to be a different colour, for example I
recently made the machined face of my stepper motor model brighter, I
add a thin object over the face.
Has anyone mentioned that colour is irrelevant for STL files?
Carsten Arnholm
Has anyone mentioned that colour is irrelevant for STL files?
But not for 3MF!
Would be great to have one file for multimaterial print.
Lada
I love this suggestion! I create designs for keyguards that aid individuals with disabilities in using their tablets. I'd love to be able to import a screenshot of the tablet directly into OpenSCAD to verify the fit of the keyguard. As it is now, I have to export a PNG of the design from OpenSCAD, import it into PowerPoint, go through the painful process in PP of cropping/resizing the image and removing the background, and then overlay the result on an imported version of the screenshot.
-----Original Message-----
From: Hugo Jackson hugo@apres.net
Sent: Sunday, April 5, 2020 5:03 PM
To: OpenSCAD general discussion discuss@lists.openscad.org
Subject: [OpenSCAD] New feature suggestion. Import PNG as background
Probably lots of other issues that are higher priority, but I have thought for some time it would be useful to be able to import an image file as a useful guide to dimensioning objects from real life… this feature is available in illustrator and Inkscape and I think it would have utility in OpenSCAD as well. Don’t know how difficult it would be to implement, but I just offer it as a suggestion.