Semantics CSG ops with respect to color, materials

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Semantics CSG ops with respect to color, materials

bobc
Hi there,

Spurred by https://github.com/openscad/openscad/issues/1304 I wondered what the "standard" semantics of CSG are wrt to how surface properties (e.g color) and interior properties (materials), and also with reference to https://github.com/openscad/openscad/wiki/Project:-Survey-of-CSG-algorithms

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.

For example, difference() paints the cut object with the color of the cutting object. A reference I've now lost, gave the example "if you cut a red cube with a blue drill, you don't get a blue hole". Another example, when taking a section through a model, it would be useful to see the colors of the cut objects, not the tool that did the cutting.

However, the standard behaviour is also useful in some cases, e.g. to paint surfaces, or as a diagnostic to see which object did the cutting. Additionally when you add materials, you could have a cube made of a blue material but painted red. So then if you take a section, should that expose a blue surface?

So even a simple op like difference() leads to some complicated implications. Even more tricky is union or intersection. What properties should the intersection have? Currently, union create a single meshed object. If joining two objects with heterogenous materials, then we need to represent the union with 2 (maybe 3) volumes, in order to preserve the interior properties.

I am working on some standalone code to explore possible semantics, and perhaps point the way to an implementation. I would like to collect some use cases, and get some feedback. Perhaps there are CAD tools that already implement these type of semantics, but I didn't find any freely available (not a comprehensive survey). I had a play with FreeCAD, it creates passable VRML output, but not AMF. I couldn't find any other output formats that are mesh based and preserve color properties.

Here are some use cases I have identified :

1. create models for 3D printing (output AMF, or multiple STL?)  
2. create models for kicad (VRML output)
3. when taking a section through object, allow difference() to preserve original colors

Constructive feedback welcome.

Regards
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

bobc
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.
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

doug.moen
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.

On 19 May 2015 at 14:36, bobc <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

bobc
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 <[hidden email]> 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

MichaelAtOz
Administrator
Focusing on Volumes would support FFF/FDM where multiple nozzles are used for multi colour/material where each volume represents one material/colour and hence any 'bit' of space is one or the other. However, and I'm sure I'm not telling you how to suck eggs, it is more complicated.

There are however multiple material/colour extruders (1)(2) with a single mixing nozzle where the properties of a particular 'bit' of space is some combination of materials/colours based (in one simplistic way) as a ratio of the inputs, but could presumably be expressed in many ways. (I think Don's blog was written before these became more available).

Other technology has a white powder base and then uses an ink-jet printer to colour & bind the layer.

This paper proposes a reprap style six feed mixer with CMY + B + W for full spectrum colour output.

color() is currently RGB which is not so suited to FFF/FDM colour specification as it is additive (255,255,255 = white, whereas in plastic that = black). A subtractive colour space CMYK is more suited to FFF/FDM colour mixing, but not to the likes of the ink-jet machines. Apparently conversion between RGB & CMYK is not straight forward.

Also colour is one attribute of a material, ie blue PLA, red ABS, black NijaFlex, white Nylon. The mixing nozzles can combine both materials and colours. Other technology can mix material (which is white/transparent) with different properties, then add colour, so for example, you could have a gradual shift of flexibility/hardness, irrespective of the colour pattern across that span. (transparency introduces alpha as another property)

Then there is surface colours, I haven't look into this much, but Shapeways for example can use either per face colour (easy?) or UV texture maps. Which may be more in the realm of other 3D modelling software.

I don't have the solution, but it looks like material & colour (& alpha?) are required, there is probably more that I haven't conceived.



Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

doug.moen
Yes, these are all issues that need to be dealt with at some point in the 3D printer toolchain. However, unless we are inventing a new 3D model file format, we only worry about supporting features that are present in popular 3D model file formats that we currently export or would like to export in the future.

You talk about different color spaces (RGB vs CMYK for example), but I think we are too high up in the toolchain to worry about this. The only color space supported by AMF is sRGB, which is the standard RGB colour space that everybody in the computer industry uses. Are there any popular 3D model file formats that support anything other than sRGB? I haven't found that, but maybe someone else has deeper insight.

Multi-material 3D printers have the potential ability to build objects out of composite materials that are created on the fly by alternating between different materials at the sub-millimeter scale, or by fusing together different materials in varying ratios. And that's fascinating, but what toolchains exist that let you do this? AMF has some features for supporting this, but are there any slicers that support these features of AMF? If there are, then we have a target that we can work towards. If not, then it might be premature for us to design language features that can't be used by any toolchain.

Shapeways has designed the SVX voxel file format that supports multiple materials and RGB colours. It looks like it supports fine grained composites and objects with fine grained structure. This is a real toolchain that we could consider supporting. The types of models that would benefit from this format have huge numbers of triangles, and I wonder if the OpenSCAD geometry engine is up to the task of creating the necessary meshes in the first place. To quote Shapeways, "One promise of 3D printing is that complexity is free. Sadly with STL files we’ve had the disconnect that more complexity equals more triangles equals larger files. Above a certain limit you just can’t use triangles to specify the details you want in a 3D printed model."

The Shapeways quote suggests that OpenSCAD needs to move beyond triangular meshes in order to fully support complex 3D printed models with fine grained structure. For example, we could support a hybrid system where coarse grained features are specified by solids, represented by meshes, as today, but fine grained features are specified "procedurally" by continuous functions that map (x,y,z) onto materials. OpenSCAD could export this kind of model to SVX by using an internal slicing engine.

If we use this approach, then we'll have an operation that attaches a material function to a solid. Then we are left with the problem of generalizing the CSG operations so that union, intersection, etc of solids with attached material functions does something predictable, which is not that different from Bob's original goal at the start of this thread.

As before, I am not sure that the way forward involves defining CSG operations on colours and materials. What is the union of red and blue? Is it different from the intersection of red and blue? What is the intersection of PLA and Ninjaflex? I don't see how these questions make sense, or that a system that gave answers would be useful. So I would be happy with a simple CSG implementation that sidesteps these issues, as I suggested earlier.

On 21 May 2015 at 01:33, MichaelAtOz <[hidden email]> wrote:
Focusing on Volumes would support FFF/FDM where multiple nozzles are used for
multi colour/material where each volume represents one material/colour and
hence any 'bit' of space is one or the other. However, and I'm sure I'm not
telling you how to suck eggs, it is more complicated.

There are however multiple material/colour extruders  (1)
<http://richrap.blogspot.com/2012/08/3-way-quick-fit-extruder-and-colour.html>
(2) <http://reprap.org/wiki/Diamond_Hotend>   with a single mixing nozzle
where the properties of a particular 'bit' of space is some combination of
materials/colours based (in one simplistic way) as a ratio of the inputs,
but could presumably be expressed in many ways. (I think Don's blog was
written before these became more available).

Other technology has a white powder base and then uses an ink-jet printer to
colour & bind the layer.

This  paper
<http://reprap.org/mediawiki/images/a/a5/Pia-taubert-material-mixing-report.pdf>
proposes a reprap style six feed mixer with CMY + B + W for full spectrum
colour output.

color() is currently RGB which is not so suited to FFF/FDM colour
specification as it is additive (255,255,255 = white, whereas in plastic
that = black). A subtractive colour space  CMYK
<http://en.wikipedia.org/wiki/CMYK_color_model>   is more suited to FFF/FDM
colour mixing, but not to the likes of the ink-jet machines. Apparently
conversion between RGB & CMYK is not straight forward.

Also colour is one attribute of a material, ie blue PLA, red ABS, black
NijaFlex, white Nylon. The mixing nozzles can combine both materials and
colours. Other technology can mix material (which is white/transparent) with
different properties, then add colour, so for example, you could have a
gradual shift of flexibility/hardness, irrespective of the colour pattern
across that span. (transparency introduces alpha as another property)

Then there is surface colours, I haven't look into this much, but  Shapeways
<https://www.shapeways.com/tutorials/exporting_to_vrml_and_x3d_for_color_printing>
for example can use either per face colour (easy?) or  UV texture maps
<http://en.wikipedia.org/w/index.php?title=UV_mapping>  . Which may be more
in the realm of other 3D modelling software.

I don't have the solution, but it looks like material & colour (& alpha?)
are required, there is probably more that I haven't conceived.







-----
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12718.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

MichaelAtOz
Administrator
Note previous discussions (1)

Lets talk practicality, not theory.

I'm building my second 3D printer, an Ordbot 300x300, but have not selected my extruder yet.

I want to expand beyond single material, so two main options,
a. multiple extruder/hotend sets (the old main material plus support material or two+ colour setup)
b. multiple extruder with mixing hotend. (for this discussion say Diamond Hotend)

At the moment a. is supported, for support material this is in the slicer, or using two+ STLs merged in some slicers.
While b. would similarly be supported when not mixing, but just using one extruder at a time.
So there is the c. case where it could mix up to three materials, this is where smart things can happen.

Let"s have a simple example. No difference() or intersection() & just implicit union()

color("red")
        linear_extrude(height=2)
                translate([0,1,0])
                text("Hello");
color("grey",1)
        cube([32,12,2]);


Which currently has issues with co-planar faces. Ideally it should be printable without too much embellishment.

Note also a variation of this where the grey has an alpha < 1. This currently displays for F5 nicely (except co-planar faces) to reflect what would happen if a translucent material is used.


Q? Can we, should we, automajically fix co-planar faces? Based on order? Probably not.

So to fix the co-planar issue and clearly define what I want, it looks like something like this is required:

module t(h=2,zAdjust=0) {
color("red")
        translate([0,0,-zAdjust])
                linear_extrude(height=h+zAdjust*2, convexity=10)
                        translate([0,1,0])
                        text("Hello");
}

module c(h=2)
color("grey",0.5) // note alpha is lost
        cube([32,12,h]);

union() { // showing to represent the implicit
                difference() { // the grey volume
                        c();
                        t(zAdjust=0.2);
                }
                t(); // the red volume


Of course F6 render loses all that so something like:

module t(h=2,zAdjust=0) {
echo(h=h,zAdjust);
color("red")
        translate([0,0,-zAdjust])
                linear_extrude(height=h+zAdjust*2, convexity=10)
                        translate([0,1,0])
                        text("Hello");
}

module c(h=2)
color("grey",0.5) // note alpha is lost
        cube([32,12,h]);

module part(p=0)
        if (p==MainPart)
                children();

MainPart=0;
union() { // showing to represent the implicit
                part(p=0) difference() { // the grey volume
                        c();
                        t(zAdjust=0.2);
                }
                part(p=1) t(); // the red volume
}

With an export to STL for each part.

So for AMF or other multi-aware formats a simplistic approach would be to flag the material with something similar to part() and let the user manually make the distinct parts, as above.

Or we could try to make the union() intersection() etc, material aware.

The simple approach would support extruder options a. & b. above, but would not be able to control c. the mixed extruder. (baring difficult manually slicing using a range of materials, a PITA).

(time to take a break)





Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

biskero
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

doug.moen
Hi, Biskero, that's an interesting requirement.

I'm not sure if AMF is suitable for this. You could explicitly break up your object into a series of layers, with each layer represented as a triangle mesh, but that would kind of suck: you'd get a huge file, and you might run into some limits on model size (either OpenSCAD or the slicer might choke on the number of triangles). There might be a clever way to encode this in AMF, where you configure the slicer to generate alternate layers of different materials if it sees [something clever] in the AMF representation, but I don't have a specific proposal.

It's easy to see how to do this with the SVX file format, since the object is represented as a stack of layers.

I'm quite enthusiastic about SVX, because it's so simple and yet so powerful. It should be a lot easier to write a slicer that converts SVX to gcode than to convert STL to gcode. I'm not sure if anybody in the open source community is working on this yet, but I think SVX support will open up new possibilities for multi-material printing on open source 3D printers.

On 22 May 2015 at 04:45, biskero <[hidden email]> wrote:
Ciao,

I read the thread and looks very interesting. I am new here so hopefully I
am not out of space in what I say! :)
I am building a large 3D printer with multi materials and I am interested in
a Openscad solution to this.

So the first idea that would come to my mind is to have multi material per
different layers based on a simple %. Let say you have an object with hight
or thickness of 10mm, I would specify to have 25% layers alternate the
materials between the one you choose. Does it make sense?

Right know I have a very large object 1000mm and I need to alternate 2 or 3
materials based on layers so that I would have a sandwich of 3 layers with 3
materials.

Isn't the AMF format suitable for that?
Thanks in advance!



--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12726.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

biskero
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

bobc
In reply to this post by biskero
AMF does have a way to support that, by specifying a composite material with a function depending on z axis. That is a use case outside what I have considered so far, and I'm not sure how many slicers support that sort of "advanced AMF". I will add it to the list though.

On 22 May 2015 at 09:45, biskero <[hidden email]> wrote:
Ciao,

I read the thread and looks very interesting. I am new here so hopefully I
am not out of space in what I say! :)
I am building a large 3D printer with multi materials and I am interested in
a Openscad solution to this.

So the first idea that would come to my mind is to have multi material per
different layers based on a simple %. Let say you have an object with hight
or thickness of 10mm, I would specify to have 25% layers alternate the
materials between the one you choose. Does it make sense?

Right know I have a very large object 1000mm and I need to alternate 2 or 3
materials based on layers so that I would have a sandwich of 3 layers with 3
materials.

Isn't the AMF format suitable for that?
Thanks in advance!



--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12726.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

biskero
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

yvette
On 05/22/2015 10:37 AM, biskero wrote:

> Here another video on what it means printing with different
> layers/materials, in this case kevlar and nylon:

> https://youtu.be/qaieXVIOMc8

what printer was used?  please let us know!

thanks
yvette


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

biskero
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

Peter Falke
b. multiple extruder with mixing hotend. (for this discussion say  Diamond
Hotend <http://reprap.org/wiki/Diamond_Hotend>


Please be aware that a nozzle like Diamond Hotend does not do a color mixing.
There is no mixing chamber.
The 3 colors meet in the center and come out together like toothpaste, one color one one side.

See: https://www.youtube.com/watch?v=_g0fiWx8RyM




2015-05-22 20:10 GMT+02:00 biskero <[hidden email]>:
Ciao,

the printer is made by a company based in Cambridge/Boston, here a video

https://www.youtube.com/watch?v=nbuu7UD2GVk

They are doing special filaments development too.

Alessandro



--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12732.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

MichaelAtOz
Administrator
Peter Falke wrote
Please be aware that a nozzle like Diamond Hotend does not do a color mixing.
There is no mixing chamber.
The 3 colors meet in the center and come out together like toothpaste, one color one one side.
I'm still doing my research. That can still be useful for different material properties, such as ABS & NinjaFlex to have variable flexibility.

So for colours in this discussion, say the one here (skip to [pdf page num] 32 if you don't want history of 3D printing, or pg 18 if you want to read about colour theory). It uses active mixing ie motorised.

It also proposes a G-code method to control multiple extruders at varying rates of output. Basically all the extruder ratios (0-1) add up to 1, and they are extruded at those rates to the overall E extrude number, at any point in time. See pg 40+.

So when such a technique progresses some means of representing those ratios in the material specification is needed.
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

MichaelAtOz
Administrator
In reply to this post by Peter Falke
Peter Falke wrote
b. multiple extruder with mixing hotend. (for this discussion say  Diamond
Hotend <http://reprap.org/wiki/Diamond_Hotend>


Please be aware that a nozzle like Diamond Hotend does not do a color
mixing.
There is no mixing chamber.
Actually have a look at mixing with the diamond head. Looks promising.
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

Peter Falke
With the partly transparent PLA there doesnt seem to be a toothpaste effect.
But if you look at the print with (non-transparent) black and copper you`ll see it quiet clearly:
https://www.youtube.com/watch?v=cr88NUZ6XnY



2015-05-24 5:40 GMT+02:00 MichaelAtOz <[hidden email]>:
Peter Falke wrote
> b. multiple extruder with mixing hotend. (for this discussion say  Diamond
> Hotend &lt;http://reprap.org/wiki/Diamond_Hotend&gt;
>
>
> Please be aware that a nozzle like Diamond Hotend does not do a color
> mixing.
> There is no mixing chamber.

Actually have a look at  mixing
<https://www.youtube.com/watch?v=saryph9t9L8>   with the diamond head. Looks
promising.



-----
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12739.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

Peter Falke
is very interesting. It uses a a vertical rod of hexagonal shape that rotates continuously and actively mixes
two (or in this design up to six different colors) colors together:
Inline-Bild 1


2015-05-26 11:18 GMT+02:00 Peter Falke <[hidden email]>:
With the partly transparent PLA there doesnt seem to be a toothpaste effect.
But if you look at the print with (non-transparent) black and copper you`ll see it quiet clearly:
https://www.youtube.com/watch?v=cr88NUZ6XnY



2015-05-24 5:40 GMT+02:00 MichaelAtOz <[hidden email]>:
Peter Falke wrote
> b. multiple extruder with mixing hotend. (for this discussion say  Diamond
> Hotend &lt;http://reprap.org/wiki/Diamond_Hotend&gt;
>
>
> Please be aware that a nozzle like Diamond Hotend does not do a color
> mixing.
> There is no mixing chamber.

Actually have a look at  mixing
<https://www.youtube.com/watch?v=saryph9t9L8>   with the diamond head. Looks
promising.



-----
Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/
--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12739.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!



--
[hidden email]

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Semantics CSG ops with respect to color, materials

MichaelAtOz
Administrator
Yes. So what I'm trying to say is that this capability is incoming, so whatever internal mechanisms need to be designed with this as a future possibility, not necessarily now, but choosing an implementation now, needs to recognise that this will be a next step.

Although it may be Real-Soon-Now (TM).

I'm looking into slicers support, to be documented shortly, but so far, they seem to be single material only. But my searches are in early stages.

I note a comment at reprep.org from 2012, basically saying multi-stuff is chicken and egg, without support in slicers/firmware multi-stuff is not needed in OpenSCAD, while without support in OpenSCAD mutli-stuff, does not need to be supported in slicers/firmware.

So at least, slic3r, supports AMF with multi materials (details to follow), so to advance, we need OpenSCAD to support multi-materials in AMF export, soonish.
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
12