Semantics CSG ops with respect to color, materials
AMF does not have a defined "density" property for volumes, although it has
an "elastic modulus" property which could be similar. A user defined
metadata attribute could be used to specify fill/density, this would be
non-standard. Slic3r are already using non-standard attributes in the AMF
files they generate; I suspect we might need different export profiles for
specific programs. Messy, unless some general agreement can be made.
I have been wondering on how to introduce new properties in OpenSCAD
language. I think color() is a precedent, it effectively tags child geometry
with the color attribute. So a new keyword like "meta()" or "property()"
could be used to keep it generic and minimise impact on the namespace.
Therefore to specify something like density, syntax like
property (name="density", value=1) {...}
or perhaps
property (density = 1) {...}
could be used. Similar syntax could be used to specify DXF layers etc.
Generation of "modifier" meshes could then performed from the overall model
if required.
--
View this message in context: http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12868.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 06/13/2015 05:54 PM, bobc wrote:
I have been wondering on how to introduce new properties in OpenSCAD
language. I think color() is a precedent, it effectively tags child geometry
with the color attribute. So a new keyword like "meta()" or "property()"
could be used to keep it generic and minimise impact on the namespace.
Therefore to specify something like density, syntax like
I think meta data should not be part of the model description itself.
As always there is a gray area like the current use of color() which
is not part of the final model, but used in preview context.
But especially things tied to a specific output format might make
more sense to have a clear distinction from the object tree making
up the model, but could attached to the nodes.
This is similar to the discussion about having meta data for
variables (e.g. for customizer) or modules (e.g. for part libraries).
See https://github.com/openscad/openscad/issues/722#issuecomment-69521189
for examples of those.
ciao,
Torsten.
The point is we want properties like color etc to be in the final model, so
your assumption is incorrect.
I really don't see how your GUI based parameter customizer idea has any
application here. It only works if the parameters being adjusted are
actually part of the model.
For the CSG operators to handle properties correctly, the properties must
be in the CSG tree. Fiddling solely with the AST tree doesn't help at all,
because the CSG backend doesn't see that. Your customizer is nice, but
doesn't help with the underlying problem.
On 13 June 2015 at 18:10, Torsten Paul Torsten.Paul@gmx.de wrote:
On 06/13/2015 05:54 PM, bobc wrote:
I have been wondering on how to introduce new properties in OpenSCAD
language. I think color() is a precedent, it effectively tags child
geometry
with the color attribute. So a new keyword like "meta()" or "property()"
could be used to keep it generic and minimise impact on the namespace.
Therefore to specify something like density, syntax like
I think meta data should not be part of the model description itself.
As always there is a gray area like the current use of color() which
is not part of the final model, but used in preview context.
But especially things tied to a specific output format might make
more sense to have a clear distinction from the object tree making
up the model, but could attached to the nodes.
This is similar to the discussion about having meta data for
variables (e.g. for customizer) or modules (e.g. for part libraries).
See https://github.com/openscad/openscad/issues/722#issuecomment-69521189
for examples of those.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 06/13/2015 07:38 PM, Bob Cousins wrote:
The point is we want properties like color etc to be in the final
model, so your assumption is incorrect.
Ok, wrong words then. Of cause they are in the AST but may not end
up in the exported 3d-model (e.g. when using STL). Using the modifier
mesh example from slic3r to define an area with different fill
root-node
|
+-union-node <- assuming lazy union, so it's just logical grouping
|
+--cylinder-node
|
+--parameter-node (having the fill information)
|
+--cube-node (the modifier mesh)
Attaching meta data to the node itself
root-node
|
+-union-node <- assuming lazy union, so it's just logical grouping
|
+--cylinder-node
|
+--cube-node <- attach meta data here / used by the export
Attaching multiple meta information values to a single node is
pretty natural. When fitting this into the normal tree representation
that will create:
root-node
|
+-meta1-node
|
+-meta2-node
|
+-meta3-node
|
+-cube
which makes handling the tree much more awkward.
Similar logic could be applied to other things, e.g. for 2D/DXF
(https://github.com/openscad/openscad/issues/1044)
I really don't see how your GUI based parameter customizer idea
has any application here. It only works if the parameters being
adjusted are actually part of the model.
Ignore the GUI part, I'm just talking about the language part
which defines a way to attach meta data to different things of
the model/script.
ciao,
Torsten.
This is awesome, Bob.
Thanks for working on this.
Looking forward to eventually using it to print multi-material objects.
On 13 June 2015 at 11:40, bobc bobcousins42@googlemail.com wrote:
Some examples.
A color test piece from RepRapPro.
https://github.com/bobc/csg_tool/blob/master/samples/various/original/simple-test.scad
The model is built by differencing components to create non-overlapping
volumes. With new semantics, this becomes unnecessary. The simplified
version is
https://github.com/bobc/csg_tool/blob/master/samples/various/simple-test.scad
The union() operator acts more like "append". This also means that the
operator is now non-commutative, which may be a problem. Internally, a
union() can create >1 objects as a result, if the internal properties are
to
be maintained.
Output for files for VRML, STL, and AMF are at
https://github.com/bobc/csg_tool/tree/master/samples/various
Truncated cube from thingiverse : http://www.thingiverse.com/thing:19168.
I
had to modify the code slightly to fix some inside out polyhedra. The
modified source and output files are in the above github repo.
Tests with slicers.
I loaded up the files (STL and AMF) into a few slicers to check for
compatibility. (I didn't try any printing yet). KissSlicer only handles
STL.
Slic3er and Cura can read AMF, as well as STL. They all loaded OK, but the
CSG library I am using does not produce a good output mesh.
Summary
- Handling of multi-color models does not require extra syntax in the
language, although it would be useful - the semantics of CSG union () operator changes significantly
- to retain color properties through CSG ops requires a new internal
representation of objects. - there is a straightforward mapping from internal objects to STL or AMF
files for 3D printing.
--
View this message in context:
http://forum.openscad.org/Semantics-CSG-ops-with-respect-to-color-materials-tp12667p12867.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
On 2015-06-13 17:54, bobc wrote:
AMF does not have a defined "density" property for volumes, although it has
an "elastic modulus" property which could be similar.
That sounds more like Young's Modulus
https://en.wikipedia.org/wiki/Young%27s_modulus
If so, it isn't the same as density.
Carsten Arnholm