DXF for cut and engrave
One of my requests from a while ago was to be able to "draw" or render an elevation (or designated plane) of a 3-D model into a 2-D line art (SVG?). I could use this in two practical ways. First for documentation purposes, and secondly to be able to print "proof of fit" paper shapes to quickly check if things work.
A third way this thread reveals (unfortunately I don't own a laser) is CAM packages could be developed from this format to control various forms of cutting tools. Just like there are many STL to Gcode "slicers" around to choose from, a similar ecosystem could spring from this feature in OpenSCAD.
Whether an edge is considered a line around a shape or how a colour is interpreted, layers etc etc is left up to the CAM interpreter, of which there could be many flavours. However at least a standardized OpenSCAD approach to a 2-D rendering system would be a major step in focussing efforts to progress in this area.
Just viewing this discussion as a very basic, but most appreciative, OpenSCAD User.
Cheers, RobW
On 25 October 2019 1:37:03 am AEDT, Torsten Paul Torsten.Paul@gmx.de wrote:
On 24.10.19 15:22, Troberg wrote:
OpenSCAD does 2D fairly good, so usually it works out,
but there are two missing primitives which would help
a lot: line and point.
That question does come up now and again, but nobody
really took the plunge to design something that fits
into OpenSCAD.
It's not as simple as just adding line() as that
would break some of the current assumptions. However
I believe having a state with unclosed polygons is
not a problem in general as for example this happens
inside of text() too.
Just to highlight what I mean, here's some dummy code
that could model something resembling the letter L
p = [
[36,-5],[12,-5],[12,-48)],[6,-48],[6, 0],[36, 0]
];
polygon() {
point(p[0]);
for (a = [1:len(p)])
line(p[a - 1], p[a]);
}
Now that looks not very impressive as this would
work with just polygon(p) too, but text() also uses
quadratic and cubic splines. At that point it gets
much more interesting I think.
In the example above, the polygon() would also mean
that at this point the polygon is closed and could
be extruded to 3D. Without that guaranty it would be
still exportable to DXF or SVG.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
You can project 3D shapes onto a 2D plane and export them as SVG or DXF
files using projection().
On Thu, 24 Oct 2019 at 22:20, Rob Ward rl.ward@bigpond.com wrote:
One of my requests from a while ago was to be able to "draw" or render an
elevation (or designated plane) of a 3-D model into a 2-D line art (SVG?).
I could use this in two practical ways. First for documentation purposes,
and secondly to be able to print "proof of fit" paper shapes to quickly
check if things work.
A third way this thread reveals (unfortunately I don't own a laser) is CAM
packages could be developed from this format to control various forms of
cutting tools. Just like there are many STL to Gcode "slicers" around to
choose from, a similar ecosystem could spring from this feature in OpenSCAD.
Whether an edge is considered a line around a shape or how a colour is
interpreted, layers etc etc is left up to the CAM interpreter, of which
there could be many flavours. However at least a standardized OpenSCAD
approach to a 2-D rendering system would be a major step in focussing
efforts to progress in this area.
Just viewing this discussion as a very basic, but most appreciative,
OpenSCAD User.
Cheers, RobW
On 25 October 2019 1:37:03 am AEDT, Torsten Paul Torsten.Paul@gmx.de
wrote:
On 24.10.19 15:22, Troberg wrote:
OpenSCAD does 2D fairly good, so usually it works out,
but there are two missing primitives which would help
a lot: line and point.
That question does come up now and again, but nobody
really took the plunge to design something that fits
into OpenSCAD.
It's not as simple as just adding line() as that
would break some of the current assumptions. However
I believe having a state with unclosed polygons is
not a problem in general as for example this happens
inside of text() too.
Just to highlight what I mean, here's some dummy code
that could model something resembling the letter L
p = [
[36,-5],[12,-5],[12,-48)],[6,-48],[6, 0],[36, 0]
];
polygon() {
point(p[0]);
for (a = [1:len(p)])
line(p[a - 1], p[a]);
}
Now that looks not very impressive as this would
work with just polygon(p) too, but text() also uses
quadratic and cubic splines. At that point it gets
much more interesting I think.
In the example above, the polygon() would also mean
that at this point the polygon is closed and could
be extruded to 3D. Without that guaranty it would be
still exportable to DXF or SVG.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I have been eying LightBurn, and have been thinking that I would buy it after
changing out my m2nano board. BUt this is the first time I've heard that it
offsets by half the kerf. Which direction is the offset? Generally, when I
want to cut or engrave line, I want it where I put it.
I also wonder why a cut out circle and an engraved X need to be in different
layers. The software I use, Inkscape, allows me to colour the strokes and to
set the greyscale values of the fill. Because the control software I use
(K40 Whisperer), will cut a red line, vector engrave a blue line, and raster
engrave a grey-scale area, it means I don't have to mess with layers. I also
don't have to mess with line thicknesses, as any red or blue line is
considered a 'stroke' and will only cut or vector engrave once, right down
the middle.
I do agree that a line() would be nice in OpenSCAD. I do a fair bit of
design work in OpenSCAD that targets a laser.
Troberg wrote
Actually, most laser software (LightBurn, RDWorks...) do offset by half
the
kerf. Not only that, they do a lot of other stuff associated with a tool
path, such as which order to do things in (fastest, inside out, all at
once,
one object at the time...), burnthrough (remain still after igniting the
laser for a short while to get a clean burn through), slowing down in
corners (to avoid bounce), using less power in corners/starting/stopping
to
avoid overburn, adapting to acceleration limitations of the cutter and so
on.
They don't start from a 3D model, though, for obvious reasons. Lasers
don't
get 3D, they get X, Y, power, speed and that's all (slightly simplified).
So, If I want to, say, cut out a circle with an engraved X, I need to
model
a circle, then two crossing lines. These needs to be in different layers
in
2D.
OpenSCAD does 2D fairly good, so usually it works out, but there are two
missing primitives which would help a lot: line and point.
--
Sent from: http://forum.openscad.org/
I use SVG only. DXF has way too many flavours, I think. If I get a DXF file
from somewhere, it's about a 50/50 chance that Inkscape will load it. If it
doesn't I convert it to SVG using one of the online file converters.
cacb wrote
Constructive Solid Modelling cannot use points and lines in the main
process. But points and lines could be the result of postprocessing in
some cases.
What is the typical file format you feed your laser cutter? Plain DXF?
--
Sent from: http://forum.openscad.org/
cacb wrote
Constructive Solid Modelling cannot use points and lines in the main
process.
So, have them outside the modelling logic. They are quite useful for
markings, measurement lines and so on. They are very useful for laser
cutting. But, neither of those applications need for them to interact with
other objects, they can easily be considered as a separate "layer" which
does not interact with anything else.
cacb wrote
What is the typical file format you feed your laser cutter? Plain DXF?
Doesn't matter much, any 2D vector format works. I often use SVG, as it's an
understandable format that's easy to edit by hand if needed, but pretty much
anything can work.
--
Sent from: http://forum.openscad.org/
lar3ry wrote
I have been eying LightBurn, and have been thinking that I would buy it
after
changing out my m2nano board. BUt this is the first time I've heard that
it
offsets by half the kerf. Which direction is the offset? Generally, when I
want to cut or engrave line, I want it where I put it.
You can offset in either direction. It decides what is "inside" and
"outside", and then it adjusts so that the "inside" gets the correct
dimensions. The algorithm for that is basically "count from the outside,
every time you cross a shape border, it switches "inside"/"outside".
Anything which isn't a closed object isn't offset, so a single line isn't
offset, neither is a point.
--
Sent from: http://forum.openscad.org/
Thanks nop head, I have looked it up and tried it. It has been a
blind-spot of mine.
projection() will be useful, especially for the printing of templates
for various sections to try for a fit.
However the resulting drawing is one plane (cross section or profile at
one depth), rather than an elevation (the complete model as viewed from
the side or from the top) and also has to be rendered by F6 before the
projection() which eliminates any colour information.
I am not up with the technicalities of how OpenSCAD differs in preview
(F5) as opposed to render (F6), but it would be more useful, I think, if
the projection() worked on the preview stage and collapsed coloured
sides on to a profile as an elevation. It would also be handy to be able
to define a vector space to crop how much of the model is depicted. I am
wondering if this would allow new tool path designers (like Cura for
STL->GCODE) to be developed for OpenSCAD-> SVG -> GCode.
I suspect what I am wishing for is probably not technically trivial and
maybe not worth the effort. Comments? Explanations?
RobW
On 25/10/19 8:24 am, nop head wrote:
You can project 3D shapes onto a 2D plane and export them as SVG or
DXF files using projection().
On Thu, 24 Oct 2019 at 22:20, Rob Ward <rl.ward@bigpond.com
mailto:rl.ward@bigpond.com> wrote:
One of my requests from a while ago was to be able to "draw" or
render an elevation (or designated plane) of a 3-D model into a
2-D line art (SVG?). I could use this in two practical ways. First
for documentation purposes, and secondly to be able to print
"proof of fit" paper shapes to quickly check if things work.
A third way this thread reveals (unfortunately I don't own a
laser) is CAM packages could be developed from this format to
control various forms of cutting tools. Just like there are many
STL to Gcode "slicers" around to choose from, a similar ecosystem
could spring from this feature in OpenSCAD.
Whether an edge is considered a line around a shape or how a
colour is interpreted, layers etc etc is left up to the CAM
interpreter, of which there could be many flavours. However at
least a standardized OpenSCAD approach to a 2-D rendering system
would be a major step in focussing efforts to progress in this area.
Just viewing this discussion as a very basic, but most
appreciative, OpenSCAD User.
Cheers, RobW
On 25 October 2019 1:37:03 am AEDT, Torsten Paul
<Torsten.Paul@gmx.de <mailto:Torsten.Paul@gmx.de>> wrote:
On 24.10.19 15:22, Troberg wrote:
OpenSCAD does 2D fairly good, so usually it works out, but
there are two missing primitives which would help a lot:
line and point.
That question does come up now and again, but nobody
really took the plunge to design something that fits
into OpenSCAD.
It's not as simple as just adding line() as that
would break some of the current assumptions. However
I believe having a state with unclosed polygons is
not a problem in general as for example this happens
inside of text() too.
Just to highlight what I mean, here's some dummy code
that could model something resembling the letter L
p = [
[36,-5],[12,-5],[12,-48)],[6,-48],[6, 0],[36, 0]
];
polygon() {
point(p[0]);
for (a = [1:len(p)])
line(p[a - 1], p[a]);
}
Now that looks not very impressive as this would
work with just polygon(p) too, but text() also uses
quadratic and cubic splines. At that point it gets
much more interesting I think.
In the example above, the polygon() would also mean
that at this point the polygon is closed and could
be extruded to 3D. Without that guaranty it would be
still exportable to DXF or SVG.
ciao,
Torsten.
------------------------------------------------------------------------
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website http://www.laketyersbeach.net.au
Ubuntu Mate - A great OS https://ubuntu-mate.org/
Thorsten, I am with you. It might be quite easy to implement. Look at the
following code
square([100, 0]);
square([0, 100]);
it passes F5 and F6 without any warning or error. But when trying to export
it you get an
UI-ERROR: Current top level object is empty.
So, does it make sense in terms of 2D export to enforce something like a 2D
manifoldness?
--
Sent from: http://forum.openscad.org/
I get a warning about zero size in OpenSCAD 2019.05
WARNING: square(size=[100, 0], ...), in file ./, line 1
TRACE: called by 'square', in file Test, line 1.
Rendering Polygon Mesh using CGAL...
UI-WARNING: No top level geometry to render
On Sat, 26 Oct 2019 at 09:43, Parkinbot rudolf@digitaldocument.de wrote:
Thorsten, I am with you. It might be quite easy to implement. Look at the
following code
square([100, 0]);
square([0, 100]);
it passes F5 and F6 without any warning or error. But when trying to export
it you get an
UI-ERROR: Current top level object is empty.
So, does it make sense in terms of 2D export to enforce something like a 2D
manifoldness?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 26.10.19 10:53, Parkinbot wrote:
square([100, 0]);
square([0, 100]);
it passes F5 and F6 without any warning or error. But> when trying to export it you get an
This produces pretty much what is written... nothing, no
geometry as both are closed polygons with zero area so
the Clipper processing removes them.
I'm don't know if there's an easy way to warn about this,
but it should be doable as line numbers are now passed
down into the processing.
So, does it make sense in terms of 2D export to enforce
something like a 2D manifoldness?
I'm not sure what you mean. It might be possible to have
some checks/warning at export time like in 3D case, but
the challenge of implementing those primitives is probably
more a clear definition of where they are allowed and how
to get more guaranties which then allows further operations
to be applied.
Pretty much like extrude does 2D->3D there would be
operations that do Open-2D -> Solid-2D and only after
that the CSG operations would be able to produce sensible
results.
All that is probably not hugely complicated but still
requires some dedication to work out the details.
ciao,
Torsten.