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

Bob Cousins bobcousins42 at googlemail.com
Wed May 20 14:31:23 EDT 2015


Thanks for your thoughts, some good ideas there I think.

You are right about AMF, the color attribute is supported at all levels
from object down to vertex. Materials can be specified at the object or
volume level. Although we are dealing with materials in FDM/FFF, I was
hoping to create a general purpose solution. In principle, FDM can support
colored surfaces in the slicer.

I was hoping that handling surface colors would be a little easier than
handling volumes but I think that was optimistic, it appears preserving
surface colors depends on preserving volume boundaries. I will need to
bring forward the rework required in my csg code to support volumes to
further investigate.

On 3), AMF requires volumes to be non-overlapping, so I think that would
need to be preserved in the internal representation.

I found Don Bright's blog, he discusses some of the issues quite well
https://sozvyezdami.wordpress.com/2013/02/03/on-adding-colors-to-cgals-nef-polyhedron/
He suggests a new operation "color_union", to reflect the different
semantics. I would prefer to use union() if that can be made backward
compatible, but I'm not sure it can.

bob

On 19 May 2015 at 21:40, doug moen <doug at moens.org> wrote:

> 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
> purpose).
>
> 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
> manufacturing."
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20150520/3b15be3a/attachment-0002.html>


More information about the Discuss mailing list