Exporting colors

Hi all,

Long time lurker here!

I know in the past there has been discussion on adding colors to
models, and while nice is not so useful for printing. However, I would
like to create parameterised models for KiCAD (PCB components) which
would benefit from colors.

I tried converting STL to VRML via Meshlab and ran into several
problems, so I have written a quick C# program to convert ASCII STL to
VRML format required by KiCAD, which works quite nicely. Now to add
color...

Therefore I want to check the current state, and see what I can do to
help. AFAIK there is no color support in any of the formats exported
by OpenSCAD, please correct me if I am wrong!

I think one option is to add binary STL which does have color, or
maybe to export VRML directly from OpenSCAD, retaining color
information. This would eliminate an extra step.

In the meantime I will have a go at building OpenSCAD from source.

Regards

I would vote for VRML output.

On a related note, it looks like slic3r has recently had support for
AMF added. If OpenSCAD could output AMF directly and had a material()
function that annotated child nodes like color() does, multi-material
printing would become a whole lot easier.

Cheers,
Len.

On Mon, Feb 20, 2012 at 11:51 AM, Triffid Hunter
<[hidden email]> wrote:

There seems to be several incompatible versions of VRML. I haven't had much luck with viewers and moving files from one app to another.

This "amf" branch being worked on by github user logxen looks promising:

Worth noting that there are some variations of STL files that support colours:

http://en.wikipedia.org/wiki/STL_%28file_format%29#Colour_in_binary_STL

On Sun, Feb 19, 2012 at 8:57 PM, Andrew Plumb <[hidden email]> wrote:

On Feb 19, 2012, at 21:37 PM, Bob Cousins wrote:
> I know in the past there has been discussion on adding colors to
> models, and while nice is not so useful for printing. However, I would
> like to create parameterised models for KiCAD (PCB components) which
> would benefit from colors.
>
The problem is that when doing CSG operations, the resulting object will be uniform and not support having more than one color. This is an inherent limitation on the underlying CGAL library.

It could be possible to remedy this by supporting building non-CSG assemblies by e.g. supporting grouping objects instead of having to do a union. This needs some thinking and has been discussed from time to time on the mailing list.
We need more use-cases, and this is a good one.

 -Marius

On Feb 20, 2012, at 01:07 AM, nop head wrote:

> There seems to be several incompatible versions of VRML. I haven't had much luck with viewers and moving files from one app to another.
>
There is really only two; VRML1 and VRML2. Supporting both wouldn't be a problem as long as we don't have to import.

 -Marius

On Feb 20, 2012, at 14:12 PM, nop head wrote:
> There is really only two; VRML1 and VRML2. Supporting both wouldn't be a problem as long as we don't have to import.
> [...]
> Has anybody had a better experience with VRML?
>
I've been working with VRML for many years, and haven't really had such issues.
Admittedly, it's tricky to write a good VRML2 importer since you can put a lot of crap in there, including Javascript, but just geometry should work out ok.
VRML1 is, otoh, very simple.

The main issue here is, I think, that many software vendors use VRML import/export as a feature they can tick off in their marketing material, and don't actually implement it further than early prototype stage, effectively killing something which could be a decent exchange format.

As long as we export well-formed VRML, it's possible to complain to said companies when they don't import (or buy another product ;)).

 -Marius

Firstly, apologies for length :)

> From: Marius Kintel <[hidden email]>
> Subject: Re: [OpenSCAD] Exporting colors
>
> The problem is that when doing CSG operations, the resulting object will be uniform and not support having more than one color. This is an inherent limitation on the underlying CGAL library.
>
> It could be possible to remedy this by supporting building non-CSG assemblies by e.g. supporting grouping objects instead of having to do a union. This needs some thinking and has been discussed from time to time on the mailing list.

That is a fundamental point of course, which I should have considered
earlier. Putting aside colors for the moment, I have been thinking
about some more basic questions, in terms of printers and specifying
materials.

The AMF spec allows for an object to be composed of multiple
non-overlapping volumes, each of which may have an associated
"material" identifier. So you might have id 1 meaning ABS, 2 = PLA or
whatever, but by identifying distinct volumes it allows the operator
to assign materials to volumes, as desired. AMF also allows composite
materials, e.g. id 3 is some mix of 1 and 2, but in the simple case a
material is just a unique id.

So the question then is, what do the CSG ops mean where there is a
material spec? Clearly for two objects A and B, if the material of A
and B is the same, then result of all ops is the same material. If A
and B are different, then their intersection creates a problem - what
material is it? There are a number of answers, but a 50:50 mix of A
and B is probably not the right one. It be assigned automatically to A
or B depending on a dominance rule, or is specified by the user as the
material of A or B, or a new material ID.

However, before any of that is possible, it would be necessary to
represent multiple objects (non-overlapping volumes) in OpenSCAD,
which I would guess needs some significant syntax/semantic extensions.
A work around is to generate a set of STLs (or better, AMFs) one for
each volume. These could then be assigned materials, and combined into
a single AMF or VRML. I have already written an STL/AMF to VRML
converter which handles single volumes.

One way to represent colors is then by having different materials,
e..g #1 and #2. They could be rendered by arbitrary colors, red and
blue say, but when printed could end up being black ABS and black PLA,
or anything.

AMF also allows the specification of color at various levels down to
single facets. In manufacturing terms, I would distinguish a material
from a finish (aka appearance). A part could be created all in the
same material and a different finish applied to different faces via
paint, anodising or just polishing.

> We need more use-cases, and this is a good one.

For this case, where the part is designed to be viewed, unions may not
be a problem if the intersection is hidden. It might be nice if a
difference and intersection results in a new color being applied to
the face. Some examples here,
http://en.wikipedia.org/wiki/Constructive_solid_geometry which I
assume are illustrative rather than definitive, but could actually be
a useful rule? Obviously this would rely on a suitable underlying
representation.

I have worked up a simple model shown here http://flic.kr/p/bxjpXp For
viewing, it is not important what happens where the pin goes through
the plastic carrier. In real life, and 3D printing, the exclusion
principle applies and there is a hole in the plastic. Ignoring the
plating,  if the object was properly composed of non-overlapping
volumes, it would view correctly and print correctly (with a suitable
printer!).

The plating illustrates the other issue, with material finish. IRL
it's a few microns of gold on the pin. On screen, it's just a
different color. To represent as a printable material is perhaps
impractical - an ultra thin volume around the pin. A workaround then
is to create the pins in two pieces, the plated part and non-plated
part.

So to create the model currently I need to create 3 STL files, import
each (non-overlapping) volume into my converter, and allocate a
material for each part. Then export to AMF or VRML. I think a similar
workflow could be used to create multi material print models.

An alternative I am considering is to export the CSG tree from
OpenSCAD, and create the mesh from there, although I would really like
not to re-invent an otherwise good wheel!

So I *think* the two things needed are the ability to specify multiple
volumes (group(n) perhaps?) and a disambiguation rule for CSG ops on
different materials, perhaps simply taking the property from the left
operand is enough.

> and B is the same, then result of all ops is the same material. If A
> and B are different, then their intersection creates a problem - what
> material is it? There are a number of answers, but a 50:50 mix of A
> and B is probably not the right one. It be assigned automatically to A
> or B depending on a dominance rule, or is specified by the user as the
> material of A or B, or a new material ID.

I would have thought that a dominance rule based on the first thing would
be most natural providing you also have a material function ie so you can
do

material("abs") {
        union() {
                cube([5,5,5], center=true);
                ..
        }
}

when the rule isn't the right thing. It might even make sense to spit out
non fatal warnings if you try and union/intersect differing materials.

> One way to represent colors is then by having different materials,
> e..g #1 and #2. They could be rendered by arbitrary colors, red and

This only works to a point. Remember that at some point surface printing
as opposed to material colouring is going to become relevant. That really
requires being able to attach textures.

(and also gets into another big limit with OpenSCAD - the lack of an
ability to bend one object around the surface of another - eg to do
writing on a pot, or even around a 2D poly)

Alan

slic3r has a multi-STL to AMF converter supporting differing materials in its git master, so our chicken and egg is starting to become resolved :)

A grouping construct could also be useful for assemblies.