discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Re: Any other TeX users here? Processing lists and analyzing geometry

JB
Jordan Brown
Fri, Apr 16, 2021 9:16 PM

On 4/16/2021 12:34 PM, William F. Adams via Discuss wrote:

Am I dense, or does OpenSCAD lack the programming constructs to
readily and directly put all the parts into a list, and then parse
each object in the list for its geometry and then work out how to fit
them together so as to efficiently cut them out of a wooden board? (In
particular, in retrospect I should have rotated one of the ends 180
degrees so that they could have fit more closely together).

OpenSCAD has decent, perhaps not great, list support.

What it doesn't have is any way to extract geometry information out of
constructed objects.

That is, you can describe a cube like so:

 c = [
    [       // points
        [0,0,0],
        [0,0,1],
        [0,1,0],
        [0,1,1],
        [1,0,0],
        [1,0,1],
        [1,1,0],
        [1,1,1]
    ], [    // faces
        [0,2,3,1],  // left
        [0,4,6,2],  // bottom
        [0,1,5,4],  // front
        [1,3,7,5],  // top
        [4,5,7,6],  // right
        [2,6,7,3],  // back
    ]
];

polyhedron(points=c[0], faces=c[1]);

and do whatever you like to the points before you hand them to
polyhedron(), but if you use a primitive to construct your cube:

cube(1);

then you can't get any information whatsoever about it.

For the kind of project you're talking about, I would define each slab
as a module, and then I would assemble those modules twice, once to form
the finished object (so as to check fit and look) and once to form the
as-printed components.  (Or, in your case, as-cut.)

There are other similar techniques.  One that I've used is to have two
translations and two rotations for each piece, where one
position/rotation is the as-assembled position, and the other is the
as-printed position.  It's then not too hard to animate between the two,
so that the pieces fly from the print bed to the constructed model and
back again.

On 4/16/2021 12:34 PM, William F. Adams via Discuss wrote: > Am I dense, or does OpenSCAD lack the programming constructs to > readily and directly put all the parts into a list, and then parse > each object in the list for its geometry and then work out how to fit > them together so as to efficiently cut them out of a wooden board? (In > particular, in retrospect I should have rotated one of the ends 180 > degrees so that they could have fit more closely together). OpenSCAD has decent, perhaps not great, list support. What it doesn't have is any way to extract geometry information out of constructed objects. That is, you can describe a cube like so: c = [ [ // points [0,0,0], [0,0,1], [0,1,0], [0,1,1], [1,0,0], [1,0,1], [1,1,0], [1,1,1] ], [ // faces [0,2,3,1], // left [0,4,6,2], // bottom [0,1,5,4], // front [1,3,7,5], // top [4,5,7,6], // right [2,6,7,3], // back ] ]; polyhedron(points=c[0], faces=c[1]); and do whatever you like to the points before you hand them to polyhedron(), but if you use a primitive to construct your cube: cube(1); then you can't get any information whatsoever about it. For the kind of project you're talking about, I would define each slab as a module, and then I would assemble those modules twice, once to form the finished object (so as to check fit and look) and once to form the as-printed components.  (Or, in your case, as-cut.) There are other similar techniques.  One that I've used is to have two translations and two rotations for each piece, where one position/rotation is the as-assembled position, and the other is the as-printed position.  It's then not too hard to animate between the two, so that the pieces fly from the print bed to the constructed model and back again.
JB
Jordan Brown
Fri, Apr 16, 2021 9:34 PM

On 4/16/2021 2:16 PM, Jordan Brown wrote:

There are other similar techniques.  One that I've used is to have two
translations and two rotations for each piece, where one
position/rotation is the as-assembled position, and the other is the
as-printed position.  It's then not too hard to animate between the
two, so that the pieces fly from the print bed to the constructed
model and back again.

Like so, if I've got the attachment right:

On 4/16/2021 2:16 PM, Jordan Brown wrote: > > There are other similar techniques.  One that I've used is to have two > translations and two rotations for each piece, where one > position/rotation is the as-assembled position, and the other is the > as-printed position.  It's then not too hard to animate between the > two, so that the pieces fly from the print bed to the constructed > model and back again. > Like so, if I've got the attachment right:
NH
nop head
Sat, Apr 17, 2021 9:10 AM

I don't make lists of parts in scad, I form then into structured assemblies
using modules to represent each level:

[image: image.png]

Since all the panels are created parametrically I always have access to
their dimensions, so laying them out for cutting is just a matter of
translating using those dimensions and rotating. When I press F6 I draw the
laid out dxfs instead of the assembly view using $preview:

[image: image.png]

Python scripts then export all the dxfs and stls, etc. In this case
the framework makes spine.dxf and table.dxf by calling spine.scad and
table.scad that it finds in a panels folder. It gets a list of dxfs from
the BOM information emitted by echo statements and can work out that, for
example, table.dxf covers z_table.dxf, brace.dxf and spar.dxf, so they get
removed from the folder of files to be routed and replaced by table.dxf.

There is nothing automatic about the layout because how I group things for
cutting depends on my stock sizes as well as build order, etc, but once
coded everything adjusts itself if the dimensions change.

On Fri, 16 Apr 2021 at 22:34, Jordan Brown openscad@jordan.maileater.net
wrote:

On 4/16/2021 2:16 PM, Jordan Brown wrote:

There are other similar techniques.  One that I've used is to have two
translations and two rotations for each piece, where one position/rotation
is the as-assembled position, and the other is the as-printed position.
It's then not too hard to animate between the two, so that the pieces fly
from the print bed to the constructed model and back again.

Like so, if I've got the attachment right:


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

I don't make lists of parts in scad, I form then into structured assemblies using modules to represent each level: [image: image.png] Since all the panels are created parametrically I always have access to their dimensions, so laying them out for cutting is just a matter of translating using those dimensions and rotating. When I press F6 I draw the laid out dxfs instead of the assembly view using $preview: [image: image.png] Python scripts then export all the dxfs and stls, etc. In this case the framework makes spine.dxf and table.dxf by calling spine.scad and table.scad that it finds in a panels folder. It gets a list of dxfs from the BOM information emitted by echo statements and can work out that, for example, table.dxf covers z_table.dxf, brace.dxf and spar.dxf, so they get removed from the folder of files to be routed and replaced by table.dxf. There is nothing automatic about the layout because how I group things for cutting depends on my stock sizes as well as build order, etc, but once coded everything adjusts itself if the dimensions change. On Fri, 16 Apr 2021 at 22:34, Jordan Brown <openscad@jordan.maileater.net> wrote: > On 4/16/2021 2:16 PM, Jordan Brown wrote: > > There are other similar techniques. One that I've used is to have two > translations and two rotations for each piece, where one position/rotation > is the as-assembled position, and the other is the as-printed position. > It's then not too hard to animate between the two, so that the pieces fly > from the print bed to the constructed model and back again. > > > Like so, if I've got the attachment right: > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >