How to get at individual children?
On Feb 24, 2015, at 15:53 PM, xenomachina from-openscad@xenomachina.com wrote:
Is there any workaround for this behavior? I tried rebuilding OpenSCAD in the issue350 branch and running it with the --enable=lazy-union flag, but it still gives me 7 cylinders.
One of the reasons why #350 isn’t merged yet is because we haven’t resolved this properly.
There’s a suggestion to make such unpacking of nodes explicit:
https://github.com/openscad/openscad/wiki/OEP4%3A-Unwrap-Operator
Suggestions are welcome.
-Marius
On Tue, Feb 24, 2015 at 7:07 PM, Chow Loong Jin [via OpenSCAD]
ml-node+s1091067n11753h96@n5.nabble.com wrote:
This doesn't work with arbitrary 3D objects, but will do what you want from one
child and a series of transformations:
Thanks! That's an interesting approach and solves my current problem.
That scad-utils library also looks extremely useful.
However, this raises some new questions for me...
I see "rotation" and "translation" are defined in
scad-utils/transformations.scad and are distinct from the built-in
rotate and translate modules. Are modules/functions not first-class?
Actually, I've been wondering why modules are even a separate kind of
thing from functions...
--
View this message in context: http://forum.openscad.org/How-to-get-at-individual-children-tp11738p11984.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
There is a detailed explanation of how shapes are passed as arguments to
modules, in this document:
https://github.com/openscad/openscad/wiki/OEP4%3A-Unwrap-Operator
This document explains the behaviour you are seeing with the 'for'
statement. There's currently no way to access individual shapes in the
Group returned by the 'for' statement; you'll have to write your program in
a different way. The OEP4 proposes a language extension that I call the
'unwrap operator' that directly solves the problem you encountered. If this
language extension were to be implemented, then your code could be made to
work by adding an '&' in front of the 'for' statement:
first() {
& for(i=[0:20:120]) {
rotate([0,0,i]) translate([10,0,0]) cylinder();
}
}
On 23 February 2015 at 18:02, xenomachina from-openscad@xenomachina.com
wrote:
Hello. I'm trying to write a module that will perform an operation on
subsets
of its children. I tried using children() with an index, but this still
seems to give me all of the children. I'm seeing this behavior both with
2013.01+dfsg-2.2 (the latest binary in the Ubuntu 14.04 repo) and a build I
did myself from git commit 0dd3f004dd66798faef42ab4edaa72c12dc0ad66.
Here's a simplified version of what I'm trying that illustrates the
problem:
module first() {
child(0);
}
first() {
for(i=[0:20:120]) {
rotate([0,0,i]) translate([10,0,0]) cylinder();
}
}
The for loop generates 7 cylinders in an arc. I would expect the "first"
module to then ignore all of them except the first, so I expect to see only
one cylinder. Instead I see all 7.
I have tried using children() instead of child() and I have also tried
using
index=0 instead of just 0 as the parameter. Either way, the result is the
same (except some don't compile on the older OpenSCAD binary).
Any ideas what I'm doing wrong?
--
View this message in context:
http://forum.openscad.org/How-to-get-at-individual-children-tp11738.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
How easily could render() be enhanced to output children? That could be
useful in other cases as a general-purpose "children generator", e.g. such
as when importing 2D and 3D source material with a view to processing the
sub-areas/volumes instead of the whole.
render(children=true) import("my_pile_of_volumes.stl");
Andrew.
--
View this message in context: http://forum.openscad.org/How-to-get-at-individual-children-tp11738p11987.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Tue, Feb 24, 2015 at 11:06 PM, kintel [via OpenSCAD]
ml-node+s1091067n11757h20@n5.nabble.com wrote:
There’s a suggestion to make such unpacking of nodes explicit:
https://github.com/openscad/openscad/wiki/OEP4%3A-Unwrap-Operator
Suggestions are welcome.
Thanks for the link. After reading OEP4, a number of things are
clearer to me. An explicit unwrap/unpack operator does seem like the
right approach.
On Fri, Mar 13, 2015 at 5:40 AM, doug moen doug@moens.org wrote:
There is a detailed explanation of how shapes are passed as arguments
to modules, in this document:
https://github.com/openscad/openscad/wiki/OEP4%3A-Unwrap-Operator
Thanks. I finally got around to reading this carefully from beginning to
end. (I now get why you mentioned the JS-style "arguments" thing).
Overall, this idea seems great to me. Is there a timeline for
implementing it? (I'm pretty new to OpenSCAD, so I don't know the
process for OEPs.)
A few questions:
In one place it says,
"A module is a kind of function that takes shapes as arguments, and
returns a shape as a result."
Does a module really return one shape, or a group of shapes?
Also, it talks about the two argument lists of modules,
"The inner argument list is surrounded by parentheses, and the
arguments are values. The outer argument list is surrounded by
braces, and the arguments are shapes."
Are shapes also values? That is, is it possible to have an inner
argument that I pass a shape to? Can I create an array/list of shapes?
As an aside, one thing I found a bit confusing when reading OEP4 was
that a few times it mentioned functions I've never heard of and could
not find documentation for, like flatten and append. It might be nice
to link to further info about each of these the first time they are
mentioned.
Overall, this idea (OEP4) seems great to me. Is there a timeline for
implementing it? (I'm pretty new to OpenSCAD, so I don't know the
process for OEPs.)
There's a conflict between OEP2 and OEP4, and Marius indicated that
this is still an unresolved issue.
In one place it says,
"A module is a kind of function that takes shapes as arguments, and
returns a shape as a result."
Does a module really return one shape, or a group of shapes?
A module returns a single object, which is either a shape or a group (I
consider a group to be a special kind of shape).
Also, it talks about the two argument lists of modules,
"The inner argument list is surrounded by parentheses, and the
arguments are values. The outer argument list is surrounded by
braces, and the arguments are shapes."
Are shapes also values? That is, is it possible to have an inner
argument that I pass a shape to? Can I create an array/list of shapes?
No. Shapes and values live in disjoint universes. The two kinds of objects
are computed during different phases of evaluation. I understand it would
take a significant refactoring of the OpenSCAD internals to change this.
As an aside, one thing I found a bit confusing when reading OEP4 was
that a few times it mentioned functions I've never heard of and could
not find documentation for, like flatten and append. It might be nice
to link to further info about each of these the first time they are
mentioned.
append() is a built-in function, and should be in the user manual.
flatten() is an auxiliary function that I have seen people define in some
source files to work around a deficiency in array comprehensions. I'm not
sure if anybody has ever put flatten() into a library.
Doug Moen.
append() is a built-in function
I don't think so in the latest release. Are you thinking of concat?
On 13 March 2015 at 20:42, doug moen doug@moens.org wrote:
Overall, this idea (OEP4) seems great to me. Is there a timeline for
implementing it? (I'm pretty new to OpenSCAD, so I don't know the
process for OEPs.)
There's a conflict between OEP2 and OEP4, and Marius indicated that
this is still an unresolved issue.
In one place it says,
"A module is a kind of function that takes shapes as arguments, and
returns a shape as a result."
Does a module really return one shape, or a group of shapes?
A module returns a single object, which is either a shape or a group (I
consider a group to be a special kind of shape).
Also, it talks about the two argument lists of modules,
"The inner argument list is surrounded by parentheses, and the
arguments are values. The outer argument list is surrounded by
braces, and the arguments are shapes."
Are shapes also values? That is, is it possible to have an inner
argument that I pass a shape to? Can I create an array/list of shapes?
No. Shapes and values live in disjoint universes. The two kinds of objects
are computed during different phases of evaluation. I understand it would
take a significant refactoring of the OpenSCAD internals to change this.
As an aside, one thing I found a bit confusing when reading OEP4 was
that a few times it mentioned functions I've never heard of and could
not find documentation for, like flatten and append. It might be nice
to link to further info about each of these the first time they are
mentioned.
append() is a built-in function, and should be in the user manual.
flatten() is an auxiliary function that I have seen people define in some
source files to work around a deficiency in array comprehensions. I'm not
sure if anybody has ever put flatten() into a library.
Doug Moen.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yes I'm thinking of concat. Sorry, I got OpenSCAD and Lisp mixed up in my
head when I was writing OEP4. I'll need to update it now. Thanks for
pointing out my error.
On 13 March 2015 at 16:53, nop head nop.head@gmail.com wrote:
append() is a built-in function
I don't think so in the latest release. Are you thinking of concat?
On 13 March 2015 at 20:42, doug moen doug@moens.org wrote:
Overall, this idea (OEP4) seems great to me. Is there a timeline for
implementing it? (I'm pretty new to OpenSCAD, so I don't know the
process for OEPs.)
There's a conflict between OEP2 and OEP4, and Marius indicated that
this is still an unresolved issue.
In one place it says,
"A module is a kind of function that takes shapes as arguments, and
returns a shape as a result."
Does a module really return one shape, or a group of shapes?
A module returns a single object, which is either a shape or a group (I
consider a group to be a special kind of shape).
Also, it talks about the two argument lists of modules,
"The inner argument list is surrounded by parentheses, and the
arguments are values. The outer argument list is surrounded by
braces, and the arguments are shapes."
Are shapes also values? That is, is it possible to have an inner
argument that I pass a shape to? Can I create an array/list of shapes?
No. Shapes and values live in disjoint universes. The two kinds of
objects are computed during different phases of evaluation. I understand it
would take a significant refactoring of the OpenSCAD internals to change
this.
As an aside, one thing I found a bit confusing when reading OEP4 was
that a few times it mentioned functions I've never heard of and could
not find documentation for, like flatten and append. It might be nice
to link to further info about each of these the first time they are
mentioned.
append() is a built-in function, and should be in the user manual.
flatten() is an auxiliary function that I have seen people define in some
source files to work around a deficiency in array comprehensions. I'm not
sure if anybody has ever put flatten() into a library.
Doug Moen.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
items being compared:
item (a): round heatsink model
item (b): rectangular bar with lettering
item (c): round heatsink backer with a 1/4-20 screw thread
in all cases, $fn was set to 360
item (b) uses write.scad, which (iirc) i glommed off thingiverse
item (c) uses thread.scad, which (iirc) i glommed off thingiverse
on 2015.03.14:
item (a) renders in 15 seconds
item (b) renders in 33 seconds
item (c) did not render on first run (info @ end of email);
i "tweaked" the scad and then it ran in 2 min 9 sec.
on 2014.03:
item (a) renders in 16 seconds (1 second slower than 2015.03.14)
item (b) renders in 42 seconds (9 seconds slower than 2015.03.14)
item (c) renders in 4 minutes 11 seconds.
so, to summarize, 2015.03.14 is faster and perhaps a bit "touchier".
the rulers are fab, and i'll be using 2015.03.14 from now on (unless
something doesn't render...)
hth and THANK YOU ALL for this product!
yvette
detail on item (c) go/nogo follows.
proper rendering of item (c) on 2015.03.14:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
Geometries in cache: 249
Geometry cache size in bytes: 576296
CGAL Polyhedrons in cache: 10
CGAL cache size in bytes: 99127184
Total rendering time: 0 hours, 2 minutes, 9 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 10993
Halfedges: 33594
Edges: 16797
Halffacets: 11474
Facets: 5737
Volumes: 2
Rendering finished.
proper rendering of item (c) on 2014.03:
Compiling design (CSG Tree generation)...
Rendering Polygon Mesh using CGAL...
PolySets in cache: 13
PolySet cache size in bytes: 332792
CGAL Polyhedrons in cache: 25
CGAL cache size in bytes: 98274176
Top level object is a 3D object:
Simple: yes
Vertices: 10993
Halfedges: 33594
Edges: 16797
Halffacets: 11474
Facets: 5737
Volumes: 2
Total rendering time: 0 hours, 4 minutes, 11 seconds
Rendering finished.
NB: first run of item (c) using 2015.03.14 that did not render:
"Module cache size: 1 modules
Compiling design (CSG Tree generation)...
Compiling design (CSG Products generation)...
Geometries in cache: 13
Geometry cache size in bytes: 230888
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
WARNING: Normalized tree is growing past 4000 elements. Aborting
normalization.
WARNING: Normalized tree is growing past 4000 elements. Aborting
normalization.
Normalized CSG tree has 599 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 0 seconds"