Multi-material support (was Re: OpenSCAD 3000)

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Multi-material support (was Re: OpenSCAD 3000)

kintel
Administrator
On Jun 18, 2014, at 11:05 AM, PolyVinalDistillate <[hidden email]> wrote:
>
> I also note that many modelling packages have been able to support different
> 'materials' and suchlike for a long time, however the developers of the
> slicers, at least for home-user FDM printers, have chosen not to implement
> such features as yet.
>
Do slicers for professional FDM printers do this?

On the topic of multi-material modeling, the primary challenge is (as discussed) to have well-defined volumes for each material. There are some pretty tricky aspects of making that easy to describe.
I’ve put some initial ideas here, hoping that something would crystallize that’s within reach:
https://github.com/openscad/openscad/wiki/Multi-material-support

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

PolyVinalDistillate
kintel wrote
Do slicers for professional FDM printers do this?
I don't know... Quite possibly not! We need someone with plenty of professional 3D printing experience to answer that. I just added 'at least not home-user' as a qualifier, as that's the only 3D printing I have exposure to.
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

RGH
I've definitely seen at home FDM printers use different materials in a print. Not least of which is using soluble material for support structures. However I don't know how they integrate the 3D modelling software with slicers i.e. perhaps you need two different STL files which the slicers integrate. I'm not sure how this works in practice, since you obviously need very close tolerances. How they integrate would also have to be done by the user, not automatically with the slicer. Obviously there also needs to be instructions in the G-Code for which head to use.


On Wed, Jun 18, 2014 at 11:37 AM, PolyVinalDistillate <[hidden email]> wrote:
kintel wrote
> Do slicers for professional FDM printers do this?

I don't know... Quite possibly not! We need someone with plenty of
professional 3D printing experience to answer that. I just added 'at least
not home-user' as a qualifier, as that's the only 3D printing I have
exposure to.



--
View this message in context: http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-tp8613p8615.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



--
----------------------------------------------------

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

Oskar
In reply to this post by kintel
kintel wrote
On the topic of multi-material modeling, the primary challenge is (as discussed) to have well-defined volumes for each material. There are some pretty tricky aspects of making that easy to describe.
The simplest way would probably be to not try to union volumes with different properties. When combining two volumes (a + b) with properties A and B, you would get three distinct volumes with properties "A", "A&B" and "B" respectively. This could be handled by OpenSCAD automatically in 3D (the three parts would be a-b, a&b, b-a), but could much more efficiently be handled by a slicer in 2D layer space. Volume properties in OpenSCAD would become area properties in the slicer, (and potential surface properties would correspond to polygon outline properties in the slicer).

A simple first approach would be to export a separate STL for each distinct property-set.
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

doug.moen
I imagine it would often be convenient to specify a material ordering
to control how union works. If material A has priority over material
B, then during a union, A+B volumes will be assigned material A.

For example, imagine that A is the object material and B is the
support material.

On 18 June 2014 11:55, Oskar <[hidden email]> wrote:

> kintel wrote
>> On the topic of multi-material modeling, the primary challenge is (as
>> discussed) to have well-defined volumes for each material. There are some
>> pretty tricky aspects of making that easy to describe.
>
> The simplest way would probably be to not try to union volumes with
> different properties. When combining two volumes (a + b) with properties A
> and B, you would get three distinct volumes with properties "A", "A&B" and
> "B" respectively. This could be handled by OpenSCAD automatically in 3D (the
> three parts would be a-b, a&b, b-a), but could much more efficiently be
> handled by a slicer in 2D layer space. Volume properties in OpenSCAD would
> become area properties in the slicer, (and potential surface properties
> would correspond to polygon outline properties in the slicer).
>
> A simple first approach would be to export a separate STL for each distinct
> property-set.
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-tp8613p8620.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

szabi
Though I guess in your example material A would be only assigned for the intersecting parts of the union, the part, which in B but not in A would still be made of B?

This sounds pretty reasonable.

If material A > B, (as ordered by priority), And shape X is defined to have material A, shape Y material B, then
X would be in material A and Y \ X in material B...

Well, the only problem is, that OpenCSG (or was it GCAL?) does not allow coplanar faces which were necessary here...

Szelp, André Szabolcs

+43 (650) 79 22 400


On Thu, Jun 19, 2014 at 3:10 AM, doug moen <[hidden email]> wrote:
I imagine it would often be convenient to specify a material ordering
to control how union works. If material A has priority over material
B, then during a union, A+B volumes will be assigned material A.

For example, imagine that A is the object material and B is the
support material.

On 18 June 2014 11:55, Oskar <[hidden email]> wrote:
> kintel wrote
>> On the topic of multi-material modeling, the primary challenge is (as
>> discussed) to have well-defined volumes for each material. There are some
>> pretty tricky aspects of making that easy to describe.
>
> The simplest way would probably be to not try to union volumes with
> different properties. When combining two volumes (a + b) with properties A
> and B, you would get three distinct volumes with properties "A", "A&B" and
> "B" respectively. This could be handled by OpenSCAD automatically in 3D (the
> three parts would be a-b, a&b, b-a), but could much more efficiently be
> handled by a slicer in 2D layer space. Volume properties in OpenSCAD would
> become area properties in the slicer, (and potential surface properties
> would correspond to polygon outline properties in the slicer).
>
> A simple first approach would be to export a separate STL for each distinct
> property-set.
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-tp8613p8620.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

Alan Cox
On Thu, 19 Jun 2014 10:19:03 +0200
"Szelp, A. Sz." <[hidden email]> wrote:

> Though I guess in your example material A would be only assigned for the
> intersecting parts of the union, the part, which in B but not in A would
> still be made of B?
>
> This sounds pretty reasonable.
>
> If material A > B, (as ordered by priority), And shape X is defined to have
> material A, shape Y material B, then
> X would be in material A and Y \ X in material B...
>
> Well, the only problem is, that OpenCSG (or was it GCAL?) does not allow
> coplanar faces which were necessary here...

Is that actually needed. Do you not end up building a separate CSG tree
for each "colour/type" anyway ?

So if you do union redball bluehox you do

red = union(red.ball, blue.hox);
blue = difference(blue.box, red.ball);

while putting a hole in it would then do (assuming it simply cut a hole
in all the materials)

red = difference(red, blue.hole);
blue = difference(blue, blue.hole);

and intersection would be similar.

At the end you then get a set of CSG trees to write to

ball-red.stl
ball-blue.stl

or perhaps simply output a zip file of stls for each material as an easy
standard file format people could work with ?

Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

kintel
Administrator
On Jun 19, 2014, at 05:45 AM, Alan Cox <[hidden email]> wrote:
>
> Is that actually needed. Do you not end up building a separate CSG tree
> for each "colour/type" anyway ?
>
That would be my approach as well.

> or perhaps simply output a zip file of stls for each material as an easy
> standard file format people could work with ?
>
Yes, or OBJ, or AMF.
Not sure if anyone standardized packaging STL’s for multi-material printing yet.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

clothbot
I'd be happy with something explicit in the source:

--snip--

export(file="material1.stl") {
  MyGeometry();
}
export(file="material2.stl"){
  MyOtherGeometry();
}
export(file="drawing.dxf",layer="cut"){
  CutLayerGeometry();
}
export(file="drawing.dxf",layer="text"){
  Some2DText();
}

OtherGeometry();

--end-snip--

Then you get the export() to their respective files, and dump non-wrapped geometry (if there is any) to the catch-all user-named export file.

Andrew

Sent from my iPhone

> On Jun 19, 2014, at 11:34 AM, Marius Kintel <[hidden email]> wrote:
>
>> On Jun 19, 2014, at 05:45 AM, Alan Cox <[hidden email]> wrote:
>>
>> Is that actually needed. Do you not end up building a separate CSG tree
>> for each "colour/type" anyway ?
> That would be my approach as well.
>
>> or perhaps simply output a zip file of stls for each material as an easy
>> standard file format people could work with ?
> Yes, or OBJ, or AMF.
> Not sure if anyone standardized packaging STL’s for multi-material printing yet.
>
> -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

MichaelAtOz
Administrator
clothbot wrote
export(file="material1.stl") {
  MyGeometry();
}
export(file="material2.stl"){
  MyOtherGeometry();
...
OtherGeometry();
+1
Also allows the like of
for(i=["part1","part2"...])
  export(file=str("Widget-",i,".stl"))
    makePart(i);
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: Multi-material support (was Re: OpenSCAD 3000)

kintel
Administrator
In reply to this post by clothbot
On Jun 19, 2014, at 12:45 PM, Andrew Plumb <[hidden email]> wrote:

>
> export(file="material1.stl") {
>  MyGeometry();
> }

The question is if export() should synchronously export as a side effect, or merely tag the subtree with a filename and export when the appropriate action is performed (GUI or cmd-line).
Also, should export() still produce geometry, or consume it?

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

tjhowse
I would suggest that it only tag the subtree by default, as exporting to an STL is a part of many people's workflow and might unintentionally overwrite earlier versions of the STL. Possibly an optional argument would force the export at render time? I'd also suggest that an exported block still produce geometry, for the case of subtracting an insert of one material from another.


On 20 June 2014 09:22, Marius Kintel <[hidden email]> wrote:
On Jun 19, 2014, at 12:45 PM, Andrew Plumb <[hidden email]> wrote:

>
> export(file="material1.stl") {
>  MyGeometry();
> }

The question is if export() should synchronously export as a side effect, or merely tag the subtree with a filename and export when the appropriate action is performed (GUI or cmd-line).
Also, should export() still produce geometry, or consume it?

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

doug.moen
In reply to this post by kintel
It would be better if we make export tagging purely functional, ie no
side effects.

On 19 June 2014 19:22, Marius Kintel <[hidden email]> wrote:

> On Jun 19, 2014, at 12:45 PM, Andrew Plumb <[hidden email]> wrote:
>
>>
>> export(file="material1.stl") {
>>  MyGeometry();
>> }
>
> The question is if export() should synchronously export as a side effect, or merely tag the subtree with a filename and export when the appropriate action is performed (GUI or cmd-line).
> Also, should export() still produce geometry, or consume it?
>
>  -Marius
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

MichaelAtOz
Administrator
doug.moen wrote
It would be better if we make export tagging purely functional, ie no
side effects.
Import() is a side effect. Both import() and output() by definition interact with exernalities.

On 19 June 2014 19:22, Marius Kintel <[hidden email]> wrote:

> The question is if export() should synchronously export as a side effect, or merely tag the subtree with a filename and export when the appropriate action is performed (GUI or cmd-line).
> Also, should export() still produce geometry, or consume it?
>
>  -Marius

However, as F5 doesn't have geometry yet, it makes sense to tag it. You wouldn't want to pollute F6 with exports *every* time you use it.

So yes, tag and export with F7/cmd-line.

However,you would not be able to export() then import() what you just exported later in the same program? I can't immediately see a need for that...

---
Back to multi-material. (I have yet to read  Marius's linked doc)

The last thing you want is to poison OpenSCAD with slicer specifics.

However, it think szabi, had it earlier, you need to 'materialise', tag objects with material properties.

A simple hack at this time would be color(), BUT it would need to stop attributing the negative surface of an object with the subtracted color(). Which indicates how it is not straight forward.

Also note you need to clearly separate the design from the production.
There are many ways to do multiple material on the production side.
Current 'domestic' scale, (higher end) FDM printers use two (or more) nozzles.
Simple approach where support material is used, the slicer does it all, you don't include the support in the model.
But where you want two colours or material properties (ABS v's Nylon) they need to be tagged.
More advanced printers work like a multi-colour ink jet printer-heads.
Other prototypes I've seen have tried extruding multiple filaments from the one nozzle, like red/blue/green and control the speed of each to produce various colours.

So colour is a separate concept to material, you can have green ABS with blue nylon, or a rainbow along a surface in a ceramic powder laser sintering machine.

I would suggest focusing on material as a hack to support either multi-materials and/or colours (mono-chrome - ie one colour not a rainbow). ie material=blueABS.

Getting into surface rendering of multi-colours/images is probably for the future. (?)

(I have not done any multi{material/colour} stuff yet, but have done some reading)

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: Multi-material support (was Re: OpenSCAD 3000)

tjhowse
Looking into the (far) future, it may one day be possible to have gradients of different materials in one solid, with decreasing percentage of one material and increasing percentage(s) of (an)other material(s). This being distinct from colours. The analogy to 2D printing starts to break down when you consider the extra dimensions of space and material. Does anyone know how high-end print shops handle definition of different inks for printing? This is vaguely analogous to print materials.

Perhaps we could look to SVG for an example of a way of defining the properties of a given point within a geometric construct?




On 20 June 2014 10:44, MichaelAtOz <[hidden email]> wrote:
doug.moen wrote
> It would be better if we make export tagging purely functional, ie no
> side effects.

Import() is a side effect. Both import() and output() by definition interact
with exernalities.

On 19 June 2014 19:22, Marius Kintel &lt;marius@&gt; wrote:

> The question is if export() should synchronously export as a side effect,
> or merely tag the subtree with a filename and export when the appropriate
> action is performed (GUI or cmd-line).
> Also, should export() still produce geometry, or consume it?
>
>  -Marius

However, as F5 doesn't have geometry yet, it makes sense to tag it. You
wouldn't want to pollute F6 with exports *every* time you use it.

So yes, tag and export with F7/cmd-line.

However,you would not be able to export() then import() what you just
exported later in the same program? I can't immediately see a need for
that...

---
Back to multi-material. (I have yet to read  Marius's linked doc)

The last thing you want is to poison OpenSCAD with slicer specifics.

However, it think szabi, had it earlier, you need to 'materialise', tag
objects with material properties.

A simple hack at this time would be color(), BUT it would need to stop
attributing the negative surface of an object with the subtracted color().
Which indicates how it is not straight forward.

Also note you need to clearly separate the design from the production.
There are many ways to do multiple material on the production side.
Current 'domestic' scale, (higher end) FDM printers use two (or more)
nozzles.
Simple approach where support material is used, the slicer does it all, you
don't include the support in the model.
But where you want two colours or material properties (ABS v's Nylon) they
need to be tagged.
More advanced printers work like a multi-colour ink jet printer-heads.
Other prototypes I've seen have tried extruding multiple filaments from the
one nozzle, like red/blue/green and control the speed of each to produce
various colours.

So colour is a separate concept to material, you can have green ABS with
blue nylon, or a rainbow along a surface in a ceramic powder laser sintering
machine.

I would suggest focusing on material as a hack to support either
multi-materials and/or colours (mono-chrome - ie one colour not a rainbow).
ie material=blueABS.

Getting into surface rendering of multi-colours/images is probably for the
future. (?)

(I have not done any multi{material/colour} stuff yet, but have done some
reading)





--
View this message in context: http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-tp8613p8667.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

doug.moen
In reply to this post by MichaelAtOz
import("object.stl") is not a side effect, for the same reason that
include <object.scad> is not a side effect.

There are real advantages to preserving the declarative nature of
OpenSCAD; I wouldn't be hasty about turning it into an imperative
language.

On 19 June 2014 20:44, MichaelAtOz <[hidden email]> wrote:

> doug.moen wrote
>> It would be better if we make export tagging purely functional, ie no
>> side effects.
>
> Import() is a side effect. Both import() and output() by definition interact
> with exernalities.
>
> On 19 June 2014 19:22, Marius Kintel &lt;marius@&gt; wrote:
>
>> The question is if export() should synchronously export as a side effect,
>> or merely tag the subtree with a filename and export when the appropriate
>> action is performed (GUI or cmd-line).
>> Also, should export() still produce geometry, or consume it?
>>
>>  -Marius
>
> However, as F5 doesn't have geometry yet, it makes sense to tag it. You
> wouldn't want to pollute F6 with exports *every* time you use it.
>
> So yes, tag and export with F7/cmd-line.
>
> However,you would not be able to export() then import() what you just
> exported later in the same program? I can't immediately see a need for
> that...
>
> ---
> Back to multi-material. (I have yet to read  Marius's linked doc)
>
> The last thing you want is to poison OpenSCAD with slicer specifics.
>
> However, it think szabi, had it earlier, you need to 'materialise', tag
> objects with material properties.
>
> A simple hack at this time would be color(), BUT it would need to stop
> attributing the negative surface of an object with the subtracted color().
> Which indicates how it is not straight forward.
>
> Also note you need to clearly separate the design from the production.
> There are many ways to do multiple material on the production side.
> Current 'domestic' scale, (higher end) FDM printers use two (or more)
> nozzles.
> Simple approach where support material is used, the slicer does it all, you
> don't include the support in the model.
> But where you want two colours or material properties (ABS v's Nylon) they
> need to be tagged.
> More advanced printers work like a multi-colour ink jet printer-heads.
> Other prototypes I've seen have tried extruding multiple filaments from the
> one nozzle, like red/blue/green and control the speed of each to produce
> various colours.
>
> So colour is a separate concept to material, you can have green ABS with
> blue nylon, or a rainbow along a surface in a ceramic powder laser sintering
> machine.
>
> I would suggest focusing on material as a hack to support either
> multi-materials and/or colours (mono-chrome - ie one colour not a rainbow).
> ie material=blueABS.
>
> Getting into surface rendering of multi-colours/images is probably for the
> future. (?)
>
> (I have not done any multi{material/colour} stuff yet, but have done some
> reading)
>
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-tp8613p8667.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

doug.moen
In reply to this post by tjhowse
Multimaterial 3D printing with continuously varying material
properties sounds like something MIT released a press release about
last year. Can't find the original web page that I read, but I found
this:

http://www.csail.mit.edu/node/2060

On 19 June 2014 21:05, tjhowse <[hidden email]> wrote:

> Looking into the (far) future, it may one day be possible to have gradients
> of different materials in one solid, with decreasing percentage of one
> material and increasing percentage(s) of (an)other material(s). This being
> distinct from colours. The analogy to 2D printing starts to break down when
> you consider the extra dimensions of space and material. Does anyone know
> how high-end print shops handle definition of different inks for printing?
> This is vaguely analogous to print materials.
>
> Perhaps we could look to SVG for an example of a way of defining the
> properties of a given point within a geometric construct?
>
>
>
>
> On 20 June 2014 10:44, MichaelAtOz <[hidden email]> wrote:
>>
>> doug.moen wrote
>> > It would be better if we make export tagging purely functional, ie no
>> > side effects.
>>
>> Import() is a side effect. Both import() and output() by definition
>> interact
>> with exernalities.
>>
>> On 19 June 2014 19:22, Marius Kintel &lt;marius@&gt; wrote:
>>
>> > The question is if export() should synchronously export as a side
>> > effect,
>> > or merely tag the subtree with a filename and export when the
>> > appropriate
>> > action is performed (GUI or cmd-line).
>> > Also, should export() still produce geometry, or consume it?
>> >
>> >  -Marius
>>
>> However, as F5 doesn't have geometry yet, it makes sense to tag it. You
>> wouldn't want to pollute F6 with exports *every* time you use it.
>>
>> So yes, tag and export with F7/cmd-line.
>>
>> However,you would not be able to export() then import() what you just
>> exported later in the same program? I can't immediately see a need for
>> that...
>>
>> ---
>> Back to multi-material. (I have yet to read  Marius's linked doc)
>>
>> The last thing you want is to poison OpenSCAD with slicer specifics.
>>
>> However, it think szabi, had it earlier, you need to 'materialise', tag
>> objects with material properties.
>>
>> A simple hack at this time would be color(), BUT it would need to stop
>> attributing the negative surface of an object with the subtracted color().
>> Which indicates how it is not straight forward.
>>
>> Also note you need to clearly separate the design from the production.
>> There are many ways to do multiple material on the production side.
>> Current 'domestic' scale, (higher end) FDM printers use two (or more)
>> nozzles.
>> Simple approach where support material is used, the slicer does it all,
>> you
>> don't include the support in the model.
>> But where you want two colours or material properties (ABS v's Nylon) they
>> need to be tagged.
>> More advanced printers work like a multi-colour ink jet printer-heads.
>> Other prototypes I've seen have tried extruding multiple filaments from
>> the
>> one nozzle, like red/blue/green and control the speed of each to produce
>> various colours.
>>
>> So colour is a separate concept to material, you can have green ABS with
>> blue nylon, or a rainbow along a surface in a ceramic powder laser
>> sintering
>> machine.
>>
>> I would suggest focusing on material as a hack to support either
>> multi-materials and/or colours (mono-chrome - ie one colour not a
>> rainbow).
>> ie material=blueABS.
>>
>> Getting into surface rendering of multi-colours/images is probably for the
>> future. (?)
>>
>> (I have not done any multi{material/colour} stuff yet, but have done some
>> reading)
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-tp8613p8667.html
>> Sent from the OpenSCAD mailing list archive at Nabble.com.
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

MichaelAtOz
Administrator
In reply to this post by doug.moen
>> OpenSCAD can open and import files.  If the file changes during execution, does
>> a second invocation of a module which uses “import” give the same, or different,
>> results?  Does it depend on the ambition of the optimizer?  
>
>OpenSCAD expands a filename to an absolute path + a last changed timestamp. If any of those change, >you’ll get different results.
>
> -Marius
>

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: Multi-material support (was Re: OpenSCAD 3000)

doug.moen
I would call this behaviour of import a bug, but I'm not sure if it's
an important bug that affects many people. The same bug probably
exists with include <object.scad>.

It's a bug because it's reasonable to assume that if you call the same
module twice with identical arguments, you will get identical results.
This behaviour of import is a weird edge case, based on the exact time
when a file changes, where that might not happen. If the program does
screw up, you can fix the problem by running it again.

If we can rely on a module returning the same result for the same
arguments, with no side effects (for some particular run of the
program, of course), then module calls are referentially transparent.
That means they are easier to understand, and it's a property that
most people will unconsciously rely on while programming, but it's
also a property that is very valuable for compile time optimizations.

On 19 June 2014 22:06, MichaelAtOz <[hidden email]> wrote:

>>> OpenSCAD can open and import files.  If the file changes during execution,
> does
>>> a second invocation of a module which uses “import” give the same, or
>>> different,
>>> results?  Does it depend on the ambition of the optimizer?
>>
>>OpenSCAD expands a filename to an absolute path + a last changed timestamp.
> If any of those change, >you’ll get different results.
>>
>> -Marius
>>
>
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/Multi-material-support-was-Re-OpenSCAD-3000-tp8613p8671.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Multi-material support (was Re: OpenSCAD 3000)

kintel
Administrator
On Jun 19, 2014, at 22:29 PM, doug moen <[hidden email]> wrote:

> I would call this behaviour of import a bug, but I'm not sure if it's
> an important bug that affects many people. The same bug probably
> exists with include <object.scad>.
>
Well, yes, since most objects are cached, include<>, use<>, surface() and import() will all have similar behavior.
I’m not sure why you think it’s a bug. Ideally, we’d read the entire external file for each compile and recompile only if the contents changed. However, doing timestamp-based evaluation of dependencies is common, ref. makefiles.

I suspect you’re referring to a slightly more complex issue though, so if you could clarify I’d be able to get that straight.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
123