Semantics CSG ops with respect to color, materials
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 :
- create models for 3D printing (output AMF, or multiple STL?)
- create models for kicad (VRML output)
- when taking a section through object, allow difference() to preserve
original colors
Constructive feedback welcome.
Regards
--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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.
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.
- A multi-material object is represented as a group of shapes, where
each shape in the group has a single material/colour. - 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. - 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. - 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. - 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@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@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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@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.
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.
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 oz.at.michael@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Note previous discussions (1)
http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-td8613.html
Lets talk practicality, not theory.
I'm building my second 3D printer, an Ordbot 300x300
http://3dtek.xyz/products/ordbot-3d-printer?variant=1016428807 , 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 http://reprap.org/wiki/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]);
http://forum.openscad.org/file/n12724/multi_a.jpg
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.
http://forum.openscad.org/file/n12724/multi_b.jpg
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
http://forum.openscad.org/file/n12724/multi_c.jpg
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)
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-tp12667p12724.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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.
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 biskero@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Ciao Doug,
thanks for the answer.
As I am approaching 3D printing I put my mind is thinking of "layers" more
than objects/volume as 3d printing is based on layers.
Now you could go further and say one layer can be done with multiple
color/material but that's more an extension. But the base are layers.
Here is a great example on why this "layer thinking" in 3D is important:
https://www.youtube.com/watch?v=nbuu7UD2GVk
Carbon Fiber, Nylon, Kevlar, Fiber Glass and more materials are printed to
get production parts.
I am working on a project that is based on using Carbon Fiber and Nylon
filaments and need to layer these materials in a logical way to achieve the
strength I want on different parts of the object.
Alessandro
--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12728.html
Sent from the OpenSCAD mailing list archive at Nabble.com.