Exporting colors

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Exporting colors

bobc
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

Triffid Hunter

On Mon, Feb 20, 2012 at 7:37 AM, Bob Cousins <[hidden email]> 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.

as far as I can tell, STL format does not support colour. we need AMF or similar for that sort of thing
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

stonysmith
In reply to this post by bobc
I would vote for VRML output.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

Len Trigg
In reply to this post by Triffid Hunter
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:

>
> On Mon, Feb 20, 2012 at 7:37 AM, Bob Cousins <[hidden email]>
> 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.
>
>
> as far as I can tell, STL format does not support colour. we need AMF or
> similar for that sort of thing
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

nophead
In reply to this post by stonysmith
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.

On 20 February 2012 00:00, <[hidden email]> wrote:
I would vote for VRML output.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

Gordon Wrigley
Is color rigorously defined for all of the CSG operations? for example if you union a red thing and a green thing, what color is the intersecting volume (presuming there was one).

On Mon, Feb 20, 2012 at 11:07 AM, nop head <[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.

On 20 February 2012 00:00, <[hidden email]> wrote:
I would vote for VRML output.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

clothbot
In reply to this post by Len Trigg
This "amf" branch being worked on by github user logxen looks promising:


For 2D, multi-layer DXF export could be useful as well.

Andrew.

On 2012-02-19, at 7:02 PM, Len Trigg wrote:

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:

On Mon, Feb 20, 2012 at 7:37 AM, Bob Cousins <[hidden email]>
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.


as far as I can tell, STL format does not support colour. we need AMF or
similar for that sort of thing


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

--

"The future is already here.  It's just not very evenly distributed" -- William Gibson

Me: http://clothbot.com/wiki/



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

Christopher Olah
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:

> This "amf" branch being worked on by github user logxen looks promising:
>
> https://github.com/logxen/openscad/tree/amf
>
> For 2D, multi-layer DXF export could be useful as well.
>
> Andrew.
>
> On 2012-02-19, at 7:02 PM, Len Trigg wrote:
>
> 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:
>
>
> On Mon, Feb 20, 2012 at 7:37 AM, Bob Cousins <[hidden email]>
>
> 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.
>
>
>
> as far as I can tell, STL format does not support colour. we need AMF or
>
> similar for that sort of thing
>
>
>
> _______________________________________________
>
> OpenSCAD mailing list
>
> [hidden email]
>
> http://rocklinux.net/mailman/listinfo/openscad
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>
>
> --
>
> "The future is already here.  It's just not very evenly distributed" --
> William Gibson
>
> Me: http://clothbot.com/wiki/
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

kintel
Administrator
In reply to this post by bobc
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

kintel
Administrator
In reply to this post by nophead
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

nophead


On 20 February 2012 12:55, Marius Kintel <[hidden email]> wrote:
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.

Perhaps I should have said flavours, rather than versions. I think there is a lot of flexibility in what you can have in the file. In my limited experience nothing works with anything else. I.e. lots of apps export it but when you try to import it, or view it, it comes out rubbish. Things like the lighting screwed up so everything is black or white and no shades in between.

Has anybody had a better experience with VRML?

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

kintel
Administrator
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

bobc
In reply to this post by stonysmith
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

Alan Cox
> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

Triffid Hunter
In reply to this post by kintel
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 :)


Perhaps it would be easiest in openscad to support something like:

material() tree1();
material() tree2();

and if a material appears in a subtree to just ditch the result?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Exporting colors

Gordon Wrigley
A grouping construct could also be useful for assemblies.
Currently people handle assemblies with union, which gets the job done. However it would be nice to have some support for detecting overlap between the parts in the assembly.
Currently I do this with a module that can be switched between a production mode where it's just the union of the children and a debug mode where it is the union of the children in yellow at 50% opacity and the pairwise intersections of the children in opaque red.
This works reasonably well, especially for significant overlaps, however it requires all the parts to be in a single flat assembly which can be inconvenient requiring duplication of rotate and translate operations that otherwise could be applied to groups of parts. It would also be nice to generate compile warnings when overlaps are present.
If this debug functionality were integrated into the tool then these things could be improved and a grouping construct would be a logical place to hang it.

G

On Wed, Feb 22, 2012 at 11:54 AM, Triffid Hunter <[hidden email]> wrote:
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 :)


Perhaps it would be easiest in openscad to support something like:

material() tree1();
material() tree2();

and if a material appears in a subtree to just ditch the result?


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Loading...