something I've been thinking of
I'm not really sure why we deal with meshes/triangles, other than
perhaps ease of rendering a 3d object in two dimensions. Ultimately, in
many cases manufacturing of the final object we design requires paths,
very few of which follow the edges of the triangular meshes. Why not
model directly in the tool paths? It is pretty easy to do that in 2.5d 3
axis milling, and simple enough, but maybe tedious, for 3d printing, for
simple shapes.
I feel, that in many instances, say fillet an edge, I fight the drawing
to get it to show correctly, but when making the part it is more simple,
just use the correct tool, offset the required distance.
I have relatively recently tried openscad, freecad, angelcad, and all of
them seem to fail in similar areas, due to not handling converging
meshes correctly, such as a couple of cylinders joining at a slight
angle, filleting/chamfers, and so forth. 'Undo is important! How they
fail, can be unpredictable in some cases. Often the whole drawing object
fails, whereas in the final physical object, the error is insignificant,
in many cases.
Probably, it's a question of using the right tool for a specific job, it
seems that the current state is that these tools are being pushed in
directions beyond their original design spec - I guess one size does not
fit all. These fundamental problems are nothing to do with the
programming language.
Best wishes,
Ray
Ray West raywest@raywest.com wrote:
I'm not really sure why we deal with meshes/triangles, other than
perhaps ease of rendering a 3d object in two dimensions. Ultimately, in
many cases manufacturing of the final object we design requires paths,
very few of which follow the edges of the triangular meshes. Why not
model directly in the tool paths? It is pretty easy to do that in 2.5d 3
axis milling, and simple enough, but maybe tedious, for 3d printing, for
simple shapes.
I've been trying that --- the problem is it creates complex models with many triangles and performance drops off and rendering takes a long time:
http://forum.openscad.org/Managed-to-model-a-finger-joint-box-with-relieved-fingers-now-how-to-actually-cut-it-Allow-OpenSCAD--td29878.html
and
https://community.carbide3d.com/t/modeling-and-cutting-out-a-hemisphere/25092 (which has a follow up discussion here and see: https://github.com/openscad/openscad/issues/2017 )
Some links at:
https://wiki.shapeoko.com/index.php/OpenSCAD#CAM_options_for_OpenSCAD
William
The problem with going to tool paths is that you need to support the full
functionality of a slicer to do it.
I do think that openscad is currently overly targeted to 3d printing. It is
an excellent tool for laser cutting design, for example, except it has no
way of producing 2d shapes, both closed and open. The language itself lends
itself well for such objects...
On Fri, 27 Nov 2020, 10:37 William F. Adams via Discuss, <
discuss@lists.openscad.org> wrote:
Ray West raywest@raywest.com wrote:
I'm not really sure why we deal with meshes/triangles, other than
perhaps ease of rendering a 3d object in two dimensions. Ultimately, in
many cases manufacturing of the final object we design requires paths,
very few of which follow the edges of the triangular meshes. Why not
model directly in the tool paths? It is pretty easy to do that in 2.5d 3
axis milling, and simple enough, but maybe tedious, for 3d printing, for
simple shapes.
I've been trying that --- the problem is it creates complex models with
many triangles and performance drops off and rendering takes a long time:
and
https://community.carbide3d.com/t/modeling-and-cutting-out-a-hemisphere/25092
(which has a follow up discussion here and see:
https://github.com/openscad/openscad/issues/2017 )
Some links at:
https://wiki.shapeoko.com/index.php/OpenSCAD#CAM_options_for_OpenSCAD
William
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
A. Craig West acraigwest@gmail.com wrote:
The problem with going to tool paths is that you need >to support the full functionality of a slicer to do it.>I do think that openscad is currently overly targeted to >3d printing. It is an excellent tool for laser cutting design, >for example, except it has no way of producing 2d shapes, >both closed and open. The language itself lends itself well for such objects...
Uh, you can get 2D shapes by using projection() and then exporting to an SVG or DXF --- the limitations are:
- curves aren't modeled as curves but as polylines - no intersecting/overlapping shapes (merged to a single outline) - all shapes must be closed
See:
https://willadams.gitbook.io/design-into-3d/fingerjoints
If folks want to do full-on toolpaths, then that's what Tool Path Language:
https://tplang.org/
in CAMotics is for --- for my part I find JavaScript hard to work in, and the interface of CAMotics doesn't suit me.
William
It must be 8 or 9 years ago, I was writing c# code to directly produce
Gcode to control a 3d print head. Not much different than driving a
milling machine. Of course, 3d printing (FDM) has improved since then. I
had no heated bed, nor fan cooling, but it worked fine in pla and abs.
The algorithm for laying down a filament was not very complicated. This
was printing specific shapes, 0.4mm at a time. I have written plenty of
similar things for milling. I was thinking, that whereas in openscad we
generate a cube, convert it to stl, slice and 3d print, or from stl to
cam to mill out, it is just as easy to directly generate the g code for
a shape, either specifying/tool/nozzle size at this early stage, or make
a late decision. If a late decision is made, then an MVC paradigm could
be used, the model being in some form other than a mesh. In the final
object, a mesh is not often needed (Could be useful for more organic
shapes that blender is more suited to, however.)
There are probably a number of reasons that it appears that openscad
(and others) seem to be targeted towards 3d printing, you can 3d print
most shapes that are designed, 3d printing is cheap and easy to use, the
drawing is a description of the final object, which can readily be
checked by 3d printing, and so forth. Of course, plenty of exceptions -
pipework, metal sheets, maybe civil engineering work. For 2d or 2.5d
(laser cutting/3 axis milling, etc) then a 2d cad program, exporting
dxf, or hpgl/whatever format, is probably more suitable.
wrt polygons/circles, in the 3 axis digital world, circles do not exist.
It is only recently that Marlin (a common 3d printer firmware) is going
to be able to handle G2,G3 commands (and then a circle will be a number
of micro-steps...)
It's a wonder any of this stuff works!
Best wishes,
Ray
On 27/11/2020 15:59, A. Craig West wrote:
The problem with going to tool paths is that you need to support the
full functionality of a slicer to do it.
I do think that openscad is currently overly targeted to 3d printing.
It is an excellent tool for laser cutting design, for example, except
it has no way of producing 2d shapes, both closed and open. The
language itself lends itself well for such objects...
On 27.11.20 20:13, Ray West wrote:
It is only recently that Marlin (a common 3d printer firmware) is
going to be able to handle G2,G3 commands (and then a circle will
be a number of micro-steps...)
That's 2015: https://github.com/MarlinFirmware/Marlin/pull/2469
and G2/G3 support for cartesian printers goes back to maybe 2011
or so.
It's probably not used a lot as the earlier parts of the tool
chain rarely generate those. In my totally personal opinion that
is not a critical issue. I've always saw much more potential
gain in other topics and that is still the case.
ciao,
Torsten.
That’s what slicers are for and there are plenty of compatibility across
different design workflows (arts, animation, engineering, virtualisation,
etc) where collaborative works need components shared in a lingua franka.
Eg, a friend is an animator, she might ask me to design a bicycle for her
latest character (“steve knows bikes” she’d say) the common format between
her adobe wares and my openSCAD is STL.
It’s one thing to see that most OS users might be modelling for printing or
milling solids, but the mesh formats exist for collaborative work.
Make things, travel and tell stories.
Sent from: http://forum.openscad.org/
crunchysteve bandmassa@gmail.com wrote:
That’s what slicers are for and there are plenty of compatibility across
different design workflows (arts, animation, engineering, virtualisation,
etc) where collaborative works need components shared in a lingua franka.
Eg, a friend is an animator, she might ask me to design a bicycle for her
latest character (“steve knows bikes” she’d say) the common format between
her adobe wares and my openSCAD is STL.
It’s one thing to see that most OS users might be modelling for printing or
milling solids, but the mesh formats exist for collaborative work.
The problem I'm having with that is CAM for subtractive design is much more complex, and there are many endmill designs and toolpath options which just aren't supported by the readily available tools.
It would be nice if it were easier to (mis)use OpenSCAD for this sort of thing, but I keep hitting performance or interface issues in attempting it.
William