DXF for cut and engrave
That would be a great approach, except that we have control of the openscad
codebase(for varying definitions of both we and codebase) and we have no
control over the state of CAM software in the laser cutting industry. Plus,
it really wouldn't require that much to support it, compared to the effort
to create CAM software from scratch
On Wed, 30 Oct 2019, 11:54 Jean-Paul Louis via Discuss, <
discuss@lists.openscad.org> wrote:
All of you guys are shooting into the void. OpenSCAD is a 3D modeling
tool, not a CAM tool. So you need real CAM software to drive your laser
tool.
That's the way it is for 3D printing, and nobody complains. Why aren't
you bitching at laser manufacturers about their lousy CAM software instead
of complaining to OpenSCAD developers who have done a terrific job at what
they intended to do.
Just my two cents,
Jean-Paul
N1JPL
Sent from Yahoo Mail on Android
https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature
On Wed, Oct 30, 2019 at 9:56 AM, Tim V. Shaporev
tim.shaporev@auriga.ru wrote:
A good approximation to ideal word would be some tool to convert
OpenSCAD output to format suitable for existing laser cutter software.
What could it be? What would be the output and input formats?
On 10/30/2019 12:14 PM, A. Craig West wrote:
The essential problem is that there is currently no work flow for laser
cutters that allows you to use the output from openscad directly,
essentially there is no slicer. In an ideal world, you would be able to
use openscad to produce 3d shapes representing the material cut away by
the laser, and the 'slicer' program would calculate the required beam
paths and intensity levels, but as the that doesn't exist yet, it's not
a very useful approach to take. For better or worse, laser cutter
designs currently consist of 2d open or closed paths, generally with
colour used as a hint for beam intensity. If openscad was able to
produce output like this, it would be immensely useful to a LOT of
people almost immediately.
It also seems like far less work to modify openscad to support output
like this, than it would be to both create a slicer program for laser
cutters AND change the work flow of all of the people using laser cutters
On Wed, 30 Oct 2019, 04:30 Troberg, <troberg.anders@gmail.com
mailto:troberg.anders@gmail.com> wrote:
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.
With Parkinbot's solution you can do it all in OpenSCAD user code and post
process with a fairly simple program to make coloured vectors that laser
cutters will accept.
Adding native open vector paths to OpenSCAD would open a big can of worms
because they don't make sense in relation to its current 2D and 3D model.
It would be a whole new class of thing and operators.
On Wed, 30 Oct 2019 at 21:53, A. Craig West acraigwest@gmail.com wrote:
That would be a great approach, except that we have control of the
openscad codebase(for varying definitions of both we and codebase) and we
have no control over the state of CAM software in the laser cutting
industry. Plus, it really wouldn't require that much to support it,
compared to the effort to create CAM software from scratch
On Wed, 30 Oct 2019, 11:54 Jean-Paul Louis via Discuss, <
discuss@lists.openscad.org> wrote:
All of you guys are shooting into the void. OpenSCAD is a 3D modeling
tool, not a CAM tool. So you need real CAM software to drive your laser
tool.
That's the way it is for 3D printing, and nobody complains. Why aren't
you bitching at laser manufacturers about their lousy CAM software instead
of complaining to OpenSCAD developers who have done a terrific job at what
they intended to do.
Just my two cents,
Jean-Paul
N1JPL
Sent from Yahoo Mail on Android
https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature
On Wed, Oct 30, 2019 at 9:56 AM, Tim V. Shaporev
tim.shaporev@auriga.ru wrote:
A good approximation to ideal word would be some tool to convert
OpenSCAD output to format suitable for existing laser cutter software.
What could it be? What would be the output and input formats?
On 10/30/2019 12:14 PM, A. Craig West wrote:
The essential problem is that there is currently no work flow for
laser
cutters that allows you to use the output from openscad directly,
essentially there is no slicer. In an ideal world, you would be able to
use openscad to produce 3d shapes representing the material cut away by
the laser, and the 'slicer' program would calculate the required beam
paths and intensity levels, but as the that doesn't exist yet, it's not
a very useful approach to take. For better or worse, laser cutter
designs currently consist of 2d open or closed paths, generally with
colour used as a hint for beam intensity. If openscad was able to
produce output like this, it would be immensely useful to a LOT of
people almost immediately.
It also seems like far less work to modify openscad to support output
like this, than it would be to both create a slicer program for laser
cutters AND change the work flow of all of the people using laser
cutters
On Wed, 30 Oct 2019, 04:30 Troberg, <troberg.anders@gmail.com
mailto:troberg.anders@gmail.com> wrote:
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.
On 30.10.19 23:09, nop head wrote:
Adding native open vector paths to OpenSCAD would open a
big can of worms because they don't make sense in relation
to its current 2D and 3D model. It would be a whole new
class of thing and operators.
Big can of worms? Maybe. But I think it's something that
will give a number of additional opportunities.
https://github.com/openscad/openscad/pull/2796 uses 2D
shapes in 3D space as base for path extrusion.
Being able to defined a 3d point cloud and use 3d hull
would be a useful feature.
I'm sure there's lots of other things.
So while I'm not convinced there's a way to do generic
CAM and/or that would fit into OpenSCAD, this does not
mean there's no room for a much more flexible way to
handle 1D / 2D geometry.
ciao,
Torsten.
nophead wrote
Brilliant idea, except perhaps the other way up. Produce a 3D STL and
process it to 2D plus grayscale by removing all the vertices and edges
that
are at 0 and converting the remaining to 2D SVG paths with a colour value
derived from the Z coordinate.
Simpler, indeed!
--
Sent from: http://forum.openscad.org/