On Tue, Jul 14, 2015 at 05:42:32AM -0700, L Boyd wrote:
> CSG has the promise to bypass STL for generating printer G code.
> What programs actually do this?
Huh, what? CSG as I know it is Constructional Solid Geometry, which is a
technique of creating 3D models by combining solids, implemented by libcgal and
libopencsg for openscad. Do you mean something else?
Also, generating G-code is a non-trivial thing. I don't really think
it should be part of a CAD program.
I think the bigger challenges with G-code generation (for 3d printers)
are things like support structures, bridge handling and similar stuff.
It might be nice to skip STL but on my totally personal wishlist for
slicer improvements, that would be very much at the bottom (just below
support for G2/G3 ;-)
> There's a suggestion there that Marius added Export to CSG to make this
> easier. It seems that printing from a CSG model was the "way of the future"
> back then, but doesn't seem to have caught on.
I guess it hasn't because it's only easy at the first glance and the
benefit is quite limited for a big selection of models.
The article also says...
> > At the moment the supported OpenSCAD primitives are cubes, cylinders
> > (including frustums and cones), and spheres. I will add extruded polygons,
> > extruded imported DXFs, polyhedra, and imported STL files later (in that
> > order, which is also the order of difficulty of doing them...).
...and looking at the change history, that adding of more things never
happened. So the supported feature set is going to work for probably
3% of my own models.
There would be a number of nice benefits of using some higher level
interface between modeler and slicer (or more advanced file formats).
The most interesting one surely the possibility to retain the ideal
information for longer (e.g. leaving a circle a circle instead of
converting to a polygon early).
Getting this to work is not going to be easy, but it might happen
eventually. We'll see what the future brings :-).
Theoretically a raytracer like POVRay - which does evaluate CSG objects natively - could be used to help create G-Code but its an open problem and the slicing approach seems to be much more prevalent at this stage. There is little advantage to traversing the CSG tree directly to generate slice based g-code. You might as well tessellate to STL and then us the same slicer as everyone else. (IMHO)
Thanks for the replies. What started me on this path is knowing that most printer firmware has very good circle routines to implement G02 and G03. Going the triangle route loses the knowledge that you wanted a circle.
Thanks for the replies. What started me on this path is knowing that most
printer firmware has very good circle routines to implement G02 and G03.
Going the triangle route loses the knowledge that you wanted a circle.