discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Attributes on objects.

MM
Michael Möller
Sat, Sep 11, 2021 11:34 PM

IMHO,

As far as OpenSCAD goes, it is surface as you dont see the "insides" of a
F5 render, but a 3D printer only prints "insides" (with one side of the
outer shell being the surface,  so to speak.) Further, a STL file is only
infinitly thin triangles defing the surface/boundary. In an intersection
between two "solids", which object defines the properties of the middle?

I'll gladly admit it's a mess, defenition wise. A standard will make an
arbitary decision, but it would be an nonambigous standard one can refer to
or work around/with.

søn. 12. sep. 2021 01.12 skrev Jordan Brown openscad@jordan.maileater.net:

On 9/11/2021 3:52 PM, Michael Möller wrote:

lør. 11. sep. 2021 23.02 skrev Jordan Brown <openscad@jordan.maileater.net

:

:
On the one hand, if I have a multi-color printer and I have

color("red") cube(10);
color("blue") sphere(5);

then I definitely want the color information carried through to the
slicer.

That is a surface attribute, so what everything inside should be, is
ambigous, especially where they intersect. (I have a dual head printer and
am aware of workarounds and further problems)

It is today an attribute of the surfaces.  But is that truly right?

It sure seems to me that it would be best, in the long run, for it to be a
volumetric attribute, with rules about what that means for the various
operations.  I would not want to have to invent a different mechanism to
support multicolor printing.

IMHO, As far as OpenSCAD goes, it is surface as you dont see the "insides" of a F5 render, but a 3D printer only prints "insides" (with one side of the outer shell being the surface, so to speak.) Further, a STL file is only infinitly thin triangles defing the surface/boundary. In an intersection between two "solids", which object defines the properties of the middle? I'll gladly admit it's a mess, defenition wise. A standard will make an arbitary decision, but it would be an nonambigous standard one can refer to or work around/with. søn. 12. sep. 2021 01.12 skrev Jordan Brown <openscad@jordan.maileater.net>: > On 9/11/2021 3:52 PM, Michael Möller wrote: > > lør. 11. sep. 2021 23.02 skrev Jordan Brown <openscad@jordan.maileater.net > >: > >> : >> On the one hand, if I have a multi-color printer and I have >> >> color("red") cube(10); >> color("blue") sphere(5); >> >> then I definitely want the color information carried through to the >> slicer. >> > That is a surface attribute, so what everything inside should be, is > ambigous, especially where they intersect. (I have a dual head printer and > am aware of workarounds and further problems) > > > It is today an attribute of the surfaces. But is that truly right? > > It sure seems to me that it would be best, in the long run, for it to be a > volumetric attribute, with rules about what that means for the various > operations. I would not want to have to invent a different mechanism to > support multicolor printing. > >
JB
Jordan Brown
Sun, Sep 12, 2021 12:15 AM

On 9/11/2021 4:34 PM, Michael Möller wrote:

As far as OpenSCAD goes, it is surface as you dont see the "insides"
of a F5 render, but a 3D printer only prints "insides" (with one side
of the outer shell being the surface,  so to speak.) Further, a STL
file is only infinitly thin triangles defing the surface/boundary.

All of that can be viewed as implementation detail.

In an intersection between two "solids", which object defines the
properties of the middle?

Indeed.  And in a union, what defines the properties of the common volume?

But one can standardize an answer for those questions, and we should. 
The obvious fundamental answers are "first wins" and "last wins".

The result will necessarily be incompatible with current F5 behavior,
because current F5 behavior produces multi-color objects for
intersection and difference.  But current F5 behavior is undocumented,
deliberately so - I started, a while back, to document it, and was told
"no, we don't want to commit to that, because we might want to do
something different".

In a choice between preserving compatibility for an undocumented and
mildly obscure case, and defining straightforward support for
multi-color printing, I know which way I'd go.

On 9/11/2021 4:34 PM, Michael Möller wrote: > As far as OpenSCAD goes, it is surface as you dont see the "insides" > of a F5 render, but a 3D printer only prints "insides" (with one side > of the outer shell being the surface,  so to speak.) Further, a STL > file is only infinitly thin triangles defing the surface/boundary. All of that can be viewed as implementation detail. > In an intersection between two "solids", which object defines the > properties of the middle? Indeed.  And in a union, what defines the properties of the common volume? But one can standardize an answer for those questions, and we should.  The obvious fundamental answers are "first wins" and "last wins". The result will necessarily be incompatible with current F5 behavior, because current F5 behavior produces multi-color objects for intersection and difference.  But current F5 behavior is undocumented, deliberately so - I started, a while back, to document it, and was told "no, we don't want to commit to that, because we might want to do something different". In a choice between preserving compatibility for an undocumented and mildly obscure case, and defining straightforward support for multi-color printing, I know which way I'd go.
RW
Rogier Wolff
Sun, Sep 12, 2021 6:31 AM

On Sat, Sep 11, 2021 at 09:02:12PM +0000, Jordan Brown wrote:

I see that PrusaSlicer, which stores its "projects" as 3MF files, has a
Metadata directory with "Slic3r_PE.config" and
"Clic3r_PE_model.config".  One is a straight textual name=value
structure; the other is XML.  For a straight name=value scheme, perhaps
we could have

 annotate("Metadata/Slic3r_PE.config", "fill_density", "20%");

For the XML file... don't know.  It's object-specific, whatever an
"object" means.

Ohh. Nice!

So this means I can do:

module infill (v=100)
{
annotate("Metadata/Slic3r_PE.config", "fill_density", str (v, "%"))
children ();
}

p=12;
for (i=[1:1:10])
translate ([ip, 0,0]) infill (i10) cube (10);

This would allow me to test different infill settings in one printjob.
Also note that with just the "annotate" primitive, a simple include
can make things "userfriendly".

Now if the slicer can already handle the per-object infill setting,
that would be nice. If not, I would really recommend that we just
start outputting that option and make it "their fault" for not being
able to handle it....

But even just the "infill" tag that provides a default for the slicer
is nice. People are "sharing" STL files of things they make, but I
consider those "intermedate files". I keep and backup the .scad files
the STLs can be regenerated.

So in my current project an infill of 5% works nice. Adding that tag
to the object in openscad would mean that in the future when I go back
to this project, I don't need to figure this out again.

On the slicer of course I could save the current config under the name
of this project, so that I can go back to these settings later on. But
in my experience my skills in configuring the slicer slowly improve,
so next time I'll have found and improved a generic setting that
improves all prints and going back to what I used last year is not an
option.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Sat, Sep 11, 2021 at 09:02:12PM +0000, Jordan Brown wrote: > I see that PrusaSlicer, which stores its "projects" as 3MF files, has a > Metadata directory with "Slic3r_PE.config" and > "Clic3r_PE_model.config".  One is a straight textual name=value > structure; the other is XML.  For a straight name=value scheme, perhaps > we could have > > annotate("Metadata/Slic3r_PE.config", "fill_density", "20%"); > > For the XML file... don't know.  It's object-specific, whatever an > "object" means. Ohh. Nice! So this means I can do: module infill (v=100) { annotate("Metadata/Slic3r_PE.config", "fill_density", str (v, "%")) children (); } p=12; for (i=[1:1:10]) translate ([i*p, 0,0]) infill (i*10) cube (10); This would allow me to test different infill settings in one printjob. Also note that with just the "annotate" primitive, a simple include can make things "userfriendly". Now if the slicer can already handle the per-object infill setting, that would be nice. If not, I would really recommend that we just start outputting that option and make it "their fault" for not being able to handle it.... But even just the "infill" tag that provides a default for the slicer is nice. People are "sharing" STL files of things they make, but I consider those "intermedate files". I keep and backup the .scad files the STLs can be regenerated. So in my current project an infill of 5% works nice. Adding that tag to the object in openscad would mean that in the future when I go back to this project, I don't need to figure this out again. On the slicer of course I could save the current config under the name of this project, so that I can go back to these settings later on. But in my experience my skills in configuring the slicer slowly improve, so next time I'll have found and improved a generic setting that improves all prints and going back to what I used last year is not an option. Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
DM
Doug Moen
Sun, Sep 12, 2021 8:59 AM

On Sat, Sep 11, 2021, at 8:15 PM, Jordan Brown wrote:

In an intersection between two "solids", which object defines the properties of the middle?

Indeed.  And in a union, what defines the properties of the common volume?

But one can standardize an answer for those questions, and we should.  The obvious fundamental answers are "first wins" and "last wins".

Curv is a volumetric solid modelling language, where colour is applied to each point in the interior of a solid, as well as on the surface. I use it for colour 3D printing. After some experimentation, I settled on what felt like the most natural model:

In a union, the last shape in the union wins (for determining colours in the result). For unioning a list of 2D shapes, this means that each successive shape appears to be "painted" on top of previous shapes.

In an intersection, the first shape in the intersection wins. Successive shapes after the first do not contribute any colour to the result, they are only used for subtracting their volumes from the first shape argument.

So I would recommend this design for a future version of OpenSCAD that supports colour printing.

On Sat, Sep 11, 2021, at 8:15 PM, Jordan Brown wrote: > >> In an intersection between two "solids", which object defines the properties of the middle? > > Indeed. And in a union, what defines the properties of the common volume? > > But one can standardize an answer for those questions, and we should. The obvious fundamental answers are "first wins" and "last wins". Curv is a volumetric solid modelling language, where colour is applied to each point in the interior of a solid, as well as on the surface. I use it for colour 3D printing. After some experimentation, I settled on what felt like the most natural model: In a union, the last shape in the union wins (for determining colours in the result). For unioning a list of 2D shapes, this means that each successive shape appears to be "painted" on top of previous shapes. In an intersection, the first shape in the intersection wins. Successive shapes after the first do not contribute any colour to the result, they are only used for subtracting their volumes from the first shape argument. So I would recommend this design for a future version of OpenSCAD that supports colour printing.
NH
nop head
Sun, Sep 12, 2021 10:06 AM

Why not the first shape for union as well?  I most often start with the
main body of an object and then union on the twiddly bits. For example a
case panel with added screw pillars.

[image: image.png]

It would seem a bit odd having to colour the last pillar.

On Sun, 12 Sept 2021 at 10:01, Doug Moen doug@moens.org wrote:

On Sat, Sep 11, 2021, at 8:15 PM, Jordan Brown wrote:

In an intersection between two "solids", which object defines the
properties of the middle?

Indeed.  And in a union, what defines the properties of the common volume?

But one can standardize an answer for those questions, and we should.  The
obvious fundamental answers are "first wins" and "last wins".

Curv is a volumetric solid modelling language, where colour is applied to
each point in the interior of a solid, as well as on the surface. I use it
for colour 3D printing. After some experimentation, I settled on what felt
like the most natural model:

In a union, the last shape in the union wins (for determining colours in
the result). For unioning a list of 2D shapes, this means that each
successive shape appears to be "painted" on top of previous shapes.

In an intersection, the first shape in the intersection wins. Successive
shapes after the first do not contribute any colour to the result, they are
only used for subtracting their volumes from the first shape argument.

So I would recommend this design for a future version of OpenSCAD that
supports colour printing.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

Why not the first shape for union as well? I most often start with the main body of an object and then union on the twiddly bits. For example a case panel with added screw pillars. [image: image.png] It would seem a bit odd having to colour the last pillar. On Sun, 12 Sept 2021 at 10:01, Doug Moen <doug@moens.org> wrote: > On Sat, Sep 11, 2021, at 8:15 PM, Jordan Brown wrote: > > > In an intersection between two "solids", which object defines the > properties of the middle? > > > Indeed. And in a union, what defines the properties of the common volume? > > But one can standardize an answer for those questions, and we should. The > obvious fundamental answers are "first wins" and "last wins". > > > Curv is a volumetric solid modelling language, where colour is applied to > each point in the interior of a solid, as well as on the surface. I use it > for colour 3D printing. After some experimentation, I settled on what felt > like the most natural model: > > In a union, the last shape in the union wins (for determining colours in > the result). For unioning a list of 2D shapes, this means that each > successive shape appears to be "painted" on top of previous shapes. > > In an intersection, the first shape in the intersection wins. Successive > shapes after the first do not contribute any colour to the result, they are > only used for subtracting their volumes from the first shape argument. > > So I would recommend this design for a future version of OpenSCAD that > supports colour printing. > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
DM
Doug Moen
Sun, Sep 12, 2021 1:15 PM

In 3D, with full colour objects that have volumetric colour, the only difference between "first wins" and "last wins" in a union is the colour of the points inside the shape. The surface colours are the same in both cases, so you don't see any visible difference in a model like this (where all the shapes are opaque).

That's why I focussed on the 2D case in deciding what design feels most natural. In 2D graphics APIs, it is most common that the last shape you painted on the canvas is the one that "wins", just like applying brush strokes to a canvas in a physical painting.

Doug Moen.

On Sun, Sep 12, 2021, at 6:06 AM, nop head wrote:

Why not the first shape for union as well?  I most often start with the main body of an object and then union on the twiddly bits. For example a case panel with added screw pillars.

image.png

It would seem a bit odd having to colour the last pillar.

On Sun, 12 Sept 2021 at 10:01, Doug Moen doug@moens.org wrote:

__
On Sat, Sep 11, 2021, at 8:15 PM, Jordan Brown wrote:

In an intersection between two "solids", which object defines the properties of the middle?

Indeed.  And in a union, what defines the properties of the common volume?

But one can standardize an answer for those questions, and we should.  The obvious fundamental answers are "first wins" and "last wins".

Curv is a volumetric solid modelling language, where colour is applied to each point in the interior of a solid, as well as on the surface. I use it for colour 3D printing. After some experimentation, I settled on what felt like the most natural model:

In a union, the last shape in the union wins (for determining colours in the result). For unioning a list of 2D shapes, this means that each successive shape appears to be "painted" on top of previous shapes.

In an intersection, the first shape in the intersection wins. Successive shapes after the first do not contribute any colour to the result, they are only used for subtracting their volumes from the first shape argument.

So I would recommend this design for a future version of OpenSCAD that supports colour printing.


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

In 3D, with full colour objects that have volumetric colour, the only difference between "first wins" and "last wins" in a union is the colour of the points *inside* the shape. The surface colours are the same in both cases, so you don't see any visible difference in a model like this (where all the shapes are opaque). That's why I focussed on the 2D case in deciding what design feels most natural. In 2D graphics APIs, it is most common that the last shape you painted on the canvas is the one that "wins", just like applying brush strokes to a canvas in a physical painting. Doug Moen. On Sun, Sep 12, 2021, at 6:06 AM, nop head wrote: > Why not the first shape for union as well? I most often start with the main body of an object and then union on the twiddly bits. For example a case panel with added screw pillars. > > image.png > > It would seem a bit odd having to colour the last pillar. > > On Sun, 12 Sept 2021 at 10:01, Doug Moen <doug@moens.org> wrote: >> __ >> On Sat, Sep 11, 2021, at 8:15 PM, Jordan Brown wrote: >>> >>>> In an intersection between two "solids", which object defines the properties of the middle? >>> >>> Indeed. And in a union, what defines the properties of the common volume? >>> >>> But one can standardize an answer for those questions, and we should. The obvious fundamental answers are "first wins" and "last wins". >> >> Curv is a volumetric solid modelling language, where colour is applied to each point in the interior of a solid, as well as on the surface. I use it for colour 3D printing. After some experimentation, I settled on what felt like the most natural model: >> >> In a union, the last shape in the union wins (for determining colours in the result). For unioning a list of 2D shapes, this means that each successive shape appears to be "painted" on top of previous shapes. >> >> In an intersection, the first shape in the intersection wins. Successive shapes after the first do not contribute any colour to the result, they are only used for subtracting their volumes from the first shape argument. >> >> So I would recommend this design for a future version of OpenSCAD that supports colour printing. >> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >
JB
Jordan Brown
Sun, Sep 12, 2021 10:13 PM

On 9/12/2021 6:15 AM, Doug Moen wrote:

In 3D, with full colour objects that have volumetric colour, the only
difference between "first wins" and "last wins" in a union is the
colour of the points inside the shape.

And in particular, the points inside the intersection of the two
objects, where it's not totally obvious which one should win.


I'd been thinking about union and intersection, and I agree that the two
rules you suggest (for union, last wins; for intersection, first wins)
individually produce the most obvious results.  I'm unhappy with the
fact that they have different rules, but maybe the obviousness argument
is compelling there.

Comments on other operations:

projection - heck if I know, in particular if there are two different
colors stacked in Z.

linear_extrude, rotate_extrude - seems like the 2D colors should
propagate into the third dimension.

offset (of two different-colored regions) - don't know.  Maybe
offset(A,B) is equivalent to union (offset(A), offset(B)), so that B's
color wins in the new overlap.  But I don't know whether offset(A,B) is
really equal to union(offset(A), offset(B)).

hull() - don't know.  Probably either first-wins or last-wins.  Or maybe
input colors are ignored.

minkowski() - maybe last-wins.  Or maybe the volume added matches the
object that added it, so that minkowski(A,B) has A in its original color
and anything additional in B.

Note that union(A,B) where A and B are different colors would still
produce one object, from an OpenSCAD child POV.  It would only be
considered to be multiple objects when exported to a multi-color-capable
format.

On 9/12/2021 6:15 AM, Doug Moen wrote: > In 3D, with full colour objects that have volumetric colour, the only > difference between "first wins" and "last wins" in a union is the > colour of the points *inside* the shape. And in particular, the points inside the intersection of the two objects, where it's not totally obvious which one should win. --- I'd been thinking about union and intersection, and I agree that the two rules you suggest (for union, last wins; for intersection, first wins) individually produce the most obvious results.  I'm unhappy with the fact that they have different rules, but maybe the obviousness argument is compelling there. Comments on other operations: projection - heck if I know, in particular if there are two different colors stacked in Z. linear_extrude, rotate_extrude - seems like the 2D colors should propagate into the third dimension. offset (of two different-colored regions) - don't know.  Maybe offset(A,B) is equivalent to union (offset(A), offset(B)), so that B's color wins in the new overlap.  But I don't know whether offset(A,B) is really equal to union(offset(A), offset(B)). hull() - don't know.  Probably either first-wins or last-wins.  Or maybe input colors are ignored. minkowski() - maybe last-wins.  Or maybe the volume added matches the object that added it, so that minkowski(A,B) has A in its original color and anything additional in B. Note that union(A,B) where A and B are different colors would still produce one object, from an OpenSCAD child POV.  It would only be considered to be multiple objects when exported to a multi-color-capable format.
JB
Jordan Brown
Sun, Sep 12, 2021 10:19 PM

On 9/11/2021 11:31 PM, Rogier Wolff wrote:

On Sat, Sep 11, 2021 at 09:02:12PM +0000, Jordan Brown wrote:

I see that PrusaSlicer, which stores its "projects" as 3MF files, has a
Metadata directory with "Slic3r_PE.config" and
"Clic3r_PE_model.config".  One is a straight textual name=value
structure; the other is XML.  For a straight name=value scheme, perhaps
we could have

 annotate("Metadata/Slic3r_PE.config", "fill_density", "20%");

For the XML file... don't know.  It's object-specific, whatever an
"object" means.

Ohh. Nice!

So this means I can do:

module infill (v=100)
{
annotate("Metadata/Slic3r_PE.config", "fill_density", str (v, "%"))
children ();
}

Maybe.  I'm just working from looking at the file, not from looking at a
spec, but the file that includes fill_density appears to be project-global.

Indeed if we were to do something like this it should be capable of
doing either project-global attributes or object-specific attributes (or
even finer-grain than that, maybe).  Exactly what that would look like I
don't know.  Maybe there are two different calls for project-global
attributes and object-specific attributes, or maybe specifying an
attribute without any children makes it global.  (Which would be
convenient, but inelegant.)

People are "sharing" STL files of things they make, but I
consider those "intermedate files". I keep and backup the .scad files
the STLs can be regenerated.

Absolutely.  People who don't share their CAD files are closed-source.

On the slicer of course I could save the current config under the name
of this project, so that I can go back to these settings later on. But
in my experience my skills in configuring the slicer slowly improve,
so next time I'll have found and improved a generic setting that
improves all prints and going back to what I used last year is not an
option.

Well, yeah, but that's just as much a problem if your settings are in
your OpenSCAD source file as if they are in your slicer-specific project
file.

But, in theory, if slicers could learn to accept the same attributes,
for at least some subset, it would make it easier to move from one
slicer to another.

On 9/11/2021 11:31 PM, Rogier Wolff wrote: > On Sat, Sep 11, 2021 at 09:02:12PM +0000, Jordan Brown wrote: >> I see that PrusaSlicer, which stores its "projects" as 3MF files, has a >> Metadata directory with "Slic3r_PE.config" and >> "Clic3r_PE_model.config".  One is a straight textual name=value >> structure; the other is XML.  For a straight name=value scheme, perhaps >> we could have >> >> annotate("Metadata/Slic3r_PE.config", "fill_density", "20%"); >> >> For the XML file... don't know.  It's object-specific, whatever an >> "object" means. > Ohh. Nice! > > So this means I can do: > > > module infill (v=100) > { > annotate("Metadata/Slic3r_PE.config", "fill_density", str (v, "%")) > children (); > } Maybe.  I'm just working from looking at the file, not from looking at a spec, but the file that includes fill_density appears to be project-global. Indeed if we were to do something like this it should be capable of doing either project-global attributes or object-specific attributes (or even finer-grain than that, maybe).  Exactly what that would look like I don't know.  Maybe there are two different calls for project-global attributes and object-specific attributes, or maybe specifying an attribute without any children makes it global.  (Which would be convenient, but inelegant.) > People are "sharing" STL files of things they make, but I > consider those "intermedate files". I keep and backup the .scad files > the STLs can be regenerated. Absolutely.  People who don't share their CAD files are closed-source. > On the slicer of course I could save the current config under the name > of this project, so that I can go back to these settings later on. But > in my experience my skills in configuring the slicer slowly improve, > so next time I'll have found and improved a generic setting that > improves all prints and going back to what I used last year is not an > option. Well, yeah, but that's just as much a problem if your settings are in your OpenSCAD source file as if they are in your slicer-specific project file. But, in theory, if slicers could learn to accept *the same* attributes, for at least some subset, it would make it easier to move from one slicer to another.
JB
Jordan Brown
Sun, Sep 12, 2021 11:20 PM

On 9/12/2021 6:15 AM, Doug Moen wrote:

In 3D, with full colour objects that have volumetric colour, the only
difference between "first wins" and "last wins" in a union is the
colour of the points inside the shape. The surface colours are the
same in both cases, so you don't see any visible difference in a model
like this (where all the shapes are opaque).

I agreed with you, but on reflection I think you might be mis-stating
something here.  I expect that you understand it correctly, but wrote
something a little wrong.

For nophead's case where the two colors are the same, agreed, there's no
difference.

But when you have the union of two different colors, there's ambiguity
not only in the interior but also at any shared surfaces.

union() {
    color("red") cube(10);
    color("blue") cube(10);
}

And today F5 will give you Z-fighting there.

On 9/12/2021 6:15 AM, Doug Moen wrote: > In 3D, with full colour objects that have volumetric colour, the only > difference between "first wins" and "last wins" in a union is the > colour of the points *inside* the shape. The surface colours are the > same in both cases, so you don't see any visible difference in a model > like this (where all the shapes are opaque). I agreed with you, but on reflection I think you might be mis-stating something here.  I expect that you understand it correctly, but wrote something a little wrong. For nophead's case where the two colors are the same, agreed, there's no difference. But when you have the union of two different colors, there's ambiguity not only in the interior but also at any shared surfaces. union() { color("red") cube(10); color("blue") cube(10); } And today F5 will give you Z-fighting there.
RW
Rogier Wolff
Mon, Sep 13, 2021 7:01 AM

On Sun, Sep 12, 2021 at 10:19:38PM +0000, Jordan Brown wrote:

On 9/11/2021 11:31 PM, Rogier Wolff wrote:

module infill (v=100)
{
annotate("Metadata/Slic3r_PE.config", "fill_density", str (v, "%"))
children ();
}

Maybe.  I'm just working from looking at the file, not from looking at a
spec, but the file that includes fill_density appears to be project-global.

When microsoft decides they want to add a feature to the
spreadsheet-import of Word. And that feature requires work on both
sides, they just tell a bunch of people to go and do the work on each
side.

With Open source it's not that simple. So to get to the point where
openscad can specify the infill of each separate object, and for that
to get printed that way we need support both in openscad and in the
slicer.

What we can't do is to tell the slicer guys to go build that at the
same time as that the openscad side is working on outputting the data
with the objects.

What I propose is that openscad starts being able to handle such
attributes internally, then output them with the export.

Now if the 3MF standard does not specify that you can add "infill" to
"object instances", that's too bad. The 3MF standard uses XML, that
language is meant to be extensible in that you can add tags that
readers can ignore. I expect that you can find a place to add the
"infill=30%" to an object instance where readers will accept it and
continue.

Now it is simply that the slicer guys haven't implemented a useful
feature! They are ignoring information that is presented to them!
Now they can see immediate benefits to implementing the feature.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On Sun, Sep 12, 2021 at 10:19:38PM +0000, Jordan Brown wrote: > On 9/11/2021 11:31 PM, Rogier Wolff wrote: > > module infill (v=100) > > { > > annotate("Metadata/Slic3r_PE.config", "fill_density", str (v, "%")) > > children (); > > } > > Maybe.  I'm just working from looking at the file, not from looking at a > spec, but the file that includes fill_density appears to be project-global. When microsoft decides they want to add a feature to the spreadsheet-import of Word. And that feature requires work on both sides, they just tell a bunch of people to go and do the work on each side. With Open source it's not that simple. So to get to the point where openscad can specify the infill of each separate object, and for that to get printed that way we need support both in openscad and in the slicer. What we can't do is to tell the slicer guys to go build that at the same time as that the openscad side is working on outputting the data with the objects. What I propose is that openscad starts being able to handle such attributes internally, then output them with the export. Now if the 3MF standard does not specify that you can add "infill" to "object instances", that's too bad. The 3MF standard uses XML, that language is meant to be extensible in that you can add tags that readers can ignore. I expect that you can find a place to add the "infill=30%" to an object instance where readers will accept it and continue. Now it is simply that the slicer guys haven't implemented a useful feature! They are ignoring information that is presented to them! Now they can see immediate benefits to implementing the feature. Roger. -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.