DXF for cut and engrave
@nophead
Yeah, I used an older snapshot ...
@tp
It can't be done within the 2D subsystem, as zero area objects are
extinguished. Therefore it needs adding a 1D subsystem with new primitives
like line() and polyline() and only the union() operator allowed collecting
them into a list. 1D objects should be allowed to coexist with 2D objects
within the xy-plane. Export into SVG or DXF is straight forward.
--
Sent from: http://forum.openscad.org/
Those would be 2d objects. 1d objects would be points on a line, which is
less useful
On Sat, 26 Oct 2019, 15:01 Parkinbot, rudolf@digitaldocument.de wrote:
@nophead
Yeah, I used an older snapshot ...
@tp
It can't be done within the 2D subsystem, as zero area objects are
extinguished. Therefore it needs adding a 1D subsystem with new primitives
like line() and polyline() and only the union() operator allowed collecting
them into a list. 1D objects should be allowed to coexist with 2D objects
within the xy-plane. Export into SVG or DXF is straight forward.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
@Parkinbot wrote:
It can't be done within the 2D subsystem, as zero area objects are
extinguished. Therefore it needs adding a 1D subsystem with new primitives
like line() and polyline() and only the union() operator allowed collecting
them into a list. 1D objects should be allowed to coexist with 2D objects
within the xy-plane. Export into SVG or DXF is straight forward.
I want to mention an alternative approach that is slightly more general.
In Curv, I can represent zero area objects in the 2D system. They aren't treated specially, there is no "1D subsystem". Objects like this are only extinguished during file export. I can make a circular path (the outline of a circle, rather than a solid circle) using
shell (0) circle(10)
Normally you would pass a positive value to shell, but this also happens to work.
Suppose you union a solid circle with some line segments embedded within the circle, to model some engraved lines on a circular lasercut object. That won't work, the line segments are absorbed into the circle by the union operation. That's the mathematically expected outcome. To make this work, you need the line segments to exist in a different layer from the circle.
Even though unioning engraved lines with a solid figure produces unhelpful results, differencing is still useful. For example, you could generate a lattice of line segments, then subtract a circular disc from the middle of the lattice to produce an artistic effect. This is an example of a set operation between lines and solid figures that produces a useful result, which might not be possible with the "1D subsystem" approach.
The lasercutter software I've used makes a distinction between engraving along a path, vs filling in a closed figure while engraving. To preview that visually in OpenSCAD, you would need to support solid 2D figures within the engraving layer.
Therefore, my suggestion is that for laser cutting, it would be useful to have a cutting layer and an engraving layer. Within the engraving layer, it is meaningful to have both zero-area paths, and solid (filled in) figures. An operation for converting a solid 2D figure to a path is useful.
A few years ago I proposed a general syntax for named layers in OpenSCAD. The part("layername") module is used to specify which layer a shape belongs to. Lasercutting might be a use case for this proposal. https://github.com/openscad/openscad/issues/1608
Doug Moen.
On 26.10.19 21:11, Parkinbot wrote:
It can't be done within the 2D subsystem, as zero
area objects are extinguished.
In it's current form, yes. But I think Clipper is capable
of handling open polygons just fine when told to do so.
(E.g. the SVG import uses it to generate closed polygons
by offsetting lines).
Therefore it needs adding a 1D subsystem with new primitives
like line() and polyline() and only the union() operator
allowed collecting them into a list.
Using union() feels a bit misleading as it does not make
it obvious that the result is expected to be closed. I'm
not sure if polygon() is the best idea, maybe something
else is needed. But that's pretty much what I meant with
it needs to have some design to fit into the existing
logic, mapping out the possibilities.
ciao,
Torsten.
Doug,
if you want so: Let 2D primitives (polygons) describe regions to be
engraved, and 1D primitives (polylines) describe cuts. To engrave a circle
use circle(), to cut a circle describe it with polyline() ... the difference
should map into the SVG or DXF description, if it doesn't there is no point
in discussing it. If it does, it is still up to the laser cutter, how it
interpretes 2D primitives.
I don't see any problem, why these primitives shouldn't live on the same
layer, since mixed unions of both object types produce meaningful results.
--
Sent from: http://forum.openscad.org/
On 10/26/2019 4:27 PM, Parkinbot wrote:
if you want so: Let 2D primitives (polygons) describe regions to be
engraved, and 1D primitives (polylines) describe cuts. To engrave a circle
use circle(), to cut a circle describe it with polyline() ...
So how would you engrave something that isn't a closed polygon?
Just to clarify, in my proposal the cutting layer only contains solid 2D objects with non-zero area. It does not contain zero-width paths. This is because we are modelling the solid objects that we are cutting out of a sheet of material using the laser cutter. When we preview our model, we see the solid objects that we are cutting out (from the cutting layer), overlaid with the objects in the engraving layer.
On Sat, Oct 26, 2019, at 11:27 PM, Parkinbot wrote:
Doug,
if you want so: Let 2D primitives (polygons) describe regions to be
engraved, and 1D primitives (polylines) describe cuts. To engrave a circle
use circle(), to cut a circle describe it with polyline() ... the difference
should map into the SVG or DXF description, if it doesn't there is no point
in discussing it. If it does, it is still up to the laser cutter, how it
interpretes 2D primitives.
I don't see any problem, why these primitives shouldn't live on the same
layer, since mixed unions of both object types produce meaningful results.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Doug,
introducing layers (or colored output) into OpenSCAD is for sure a good
idea, as it would serve many purposes, e.g. producing output for
multi-extruder machines. While it wouldn't solve the "living hinge problem"
without a CAM stage, it would bring severe changes into OpenSCAD.
But isn't it clumsy to describe cuts as solid 2D objects? I imagine this as
a 2D sweep - you input a path as 2D point list and a width and get a polygon
that kind of cycles around the path. So far so good, but what happens with
the union of several cuts, say a cross? Through the union operation start
and end points will probably get lost. Which path will the machine take?
My proposal was:
- use solid 2D objects like polygon() to describe engravements.
- use 1D objects like the new polyline() primitive to describe cuts with
zero-width path. - make sure a closed polyline() path is distingished from a polygon() in the
DXF and SVG output.
To have a line()/polyline() primitive would also be helpful to do simple
drawings. Implemented with a pathwidth parameter with a non-zero default, it
could also be extruded to 3D. Its semantics could further be extended to let
it live in 3D space, i.e. provide a 3D path and get a solid "pipe" with the
given path width - remember the discussion we had about sweeping along
arbitrary 3D paths.
Jordan,
its always up to the machine's preprocessor, how it interpretes things. As
the thread originator notes, he currently uses two exports one for cutting,
one for engraving. You could - in theory - also describe an engraving region
with a closed polyline.
--
Sent from: http://forum.openscad.org/
In the BOSL2 library, the stroke() module can let you draw lines of a given
width along a 2D polyline path, with optional arrows and/or endcaps for either
end. The code for it relies on a lot of other features of the BOSL2 library, though
so it'd be a bit of work to extract that module out.
https://github.com/revarbat/BOSL2/wiki/shapes2d.scad#stroke https://github.com/revarbat/BOSL2/wiki/shapes2d.scad#stroke
https://github.com/revarbat/BOSL2/ https://github.com/revarbat/BOSL2/
- Revar
On Oct 27, 2019, at 2:44 AM, Parkinbot rudolf@digitaldocument.de wrote:
Doug,
introducing layers (or colored output) into OpenSCAD is for sure a good
idea, as it would serve many purposes, e.g. producing output for
multi-extruder machines. While it wouldn't solve the "living hinge problem"
without a CAM stage, it would bring severe changes into OpenSCAD.
But isn't it clumsy to describe cuts as solid 2D objects? I imagine this as
a 2D sweep - you input a path as 2D point list and a width and get a polygon
that kind of cycles around the path. So far so good, but what happens with
the union of several cuts, say a cross? Through the union operation start
and end points will probably get lost. Which path will the machine take?
My proposal was:
- use solid 2D objects like polygon() to describe engravements.
- use 1D objects like the new polyline() primitive to describe cuts with
zero-width path. - make sure a closed polyline() path is distingished from a polygon() in the
DXF and SVG output.
To have a line()/polyline() primitive would also be helpful to do simple
drawings. Implemented with a pathwidth parameter with a non-zero default, it
could also be extruded to 3D. Its semantics could further be extended to let
it live in 3D space, i.e. provide a 3D path and get a solid "pipe" with the
given path width - remember the discussion we had about sweeping along
arbitrary 3D paths.
Jordan,
its always up to the machine's preprocessor, how it interpretes things. As
the thread originator notes, he currently uses two exports one for cutting,
one for engraving. You could - in theory - also describe an engraving region
with a closed polyline.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
RevarBat wrote
In the BOSL2 library, the stroke() module can let you draw lines of a
given
width along a 2D polyline path, with optional arrows and/or endcaps for
either
end. The code for it relies on a lot of other features of the BOSL2
library, though
so it'd be a bit of work to extract that module out.
The problem is that as soon as they have a width, the laser will cut twice.
--
Sent from: http://forum.openscad.org/