[OpenSCAD] Semantics CSG ops with respect to color, materials

doug moen doug at moens.org
Tue May 19 16:40:45 EDT 2015

My interest in OpenSCAD is in constructing solid models for 3D printing. I
have access to multicolor printers, although I've not used the color()
operator for that purpose (in fact I don't think it's supported for that

You said "It's already been noted on this list that the CSG ops designed
for image
generation don't necessarily match the semantics of solid modelling for

Since I only care about solid modelling for manufacturing, I'd like the
color() operator to apply a color to an entire solid volume. My
understanding after reading the color() entry in the documentation was that
it does colour an entire volume. But I could be wrong: apparently right now
it effectively applies color to surfaces or faces, and has surprising (to
me) semantics for difference, but that behaviour only manifests during
preview, and it's to help with debugging.

I looked at the AMF file format documentation, and that standard does
support applying color to a solid volume, but also to a triangle or vertex.
There are 3D printer toolchains (eg Cura) that support AMF color for
multicolor printing, but apparently our AMF export doesn't support that
yet? For AMF Cura support, I assume we want color() to apply to volumes,
not to surfaces. It's theoretically possible that other people might want
the ability to apply colour to surfaces for AMF export, but I'm not aware
of what actual use cases, if any, that would support.

In issue 1304, Marius Kintel said "The challenge is that color information
isn't preserved across CSG operation boundaries", and bobc said "'the main
challenge is to get the CSG operations to support colors/materials' -- I
think that challenge is extremely hard, both semantically and
implementation wise. So hard that I suggest avoiding it. In the case of
union, what properties should the intersection have? Remember we want to
support material properties other than color. We would need a blending
function to specify the properties of the intersection. Even providing a
sensible default is problematic."

I could live with a simple minded approach to solving this problem.

   1. A multi-material object is represented as a group of shapes, where
   each shape in the group has a single material/colour.
   2. On conversion to AMF, I expect each shape in the group to be
   converted to a separate volume in AMF. If there are overlapping shapes,
   then it is up to the AMF consumer to decide what to do.
   3. Union cheats: it refuses to union two shapes with different
   colour/material. But if two shapes in the group have the same material,
   they are unioned. So union may return a group. Yes, it's true that two
   objects of different colour might overlap, and union isn't dealing with the
   situation, but I'm prepared to live with that.
   4. Difference removes the first shape from each remaining shape in the
   group. The color of the first shape has no effect on the colour of the
   shapes in the output.
   5. Intersection, Hull and Minkowski are more difficult, since there is
   no mathematically preferred behaviour. So we arbitrarily choose the colour
   and material of the first object, and that is applied to the result.

On 19 May 2015 at 14:36, bobc <bobcousins42 at googlemail.com> wrote:

> Hmm, no takers. Never mind, I will press on. :)
> Just a reminder, the scope here is to look at semantics and what sort of
> language extensions might be required, to guide future implementation.
> I've been looking at how color is handled on difference() and intersect().
> The main issue is how the "cut" face of the result should be colored.
> Conventionally, the color is that of the contributing surface. Illustrated
> here
> http://en.wikipedia.org/wiki/Constructive_solid_geometry#Workings_of_CSG
> In various cases, it would be useful to have different behaviour
> https://github.com/openscad/openscad/issues/501
> After playing around with a version of csg.js (csg.cs), I would like to
> propose a simple extension to difference() and union() to allow colors of
> the result to be defined in a more flexible way. The method is to add an
> "alpha" parameter, which works in the same way as alpha color blending.
> For an operation such difference() {a(); b();}, then the color of the cut
> surface is color(A).alpha + color(B).(1-alpha), where alpha = [0:1].
> The default value would be zero, which corresponds to standard behaviour,
> with alpha=1, the color of the original objects is preserved.
> If an object has no defined color, then the object with a defined color
> takes precedence.
> Adding color preservation to csg.cs was quite easy, as there is a property
> which can be attached to polygons. With that type of feature, I think it
> should be relatively easy to create boolean ops which allow the user to
> express a full range of color properties to the result.
> --
> View this message in context:
> http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12705.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20150519/d96cf9b3/attachment-0002.html>

More information about the Discuss mailing list