elegant export to G-code from w/in OpenSCAD?

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

elegant export to G-code from w/in OpenSCAD?

William Adams-2
Would this be feasible?

I was quite thrilled w/ OpenSCAD until the following exchange:

http://www.shapeoko.com/forum/viewtopic.php?f=6&t=204

wherein I learned that it is limited to an internal polygonal representation.

Would it be possible to turn a part inside out, and create G-code for milling away, matching circles and arcs &c. elegantly?

William

--
William Adams
senior graphic designer
Fry Communications
Sphinx of black quartz, judge my vow.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

kolergy

The answer to the exchange you mention in the link is "$fn=xx" this function allows you to set the number of vertex in you circle, by default it is small for the small circles but you can increase it until you are happy with the result.




On 15 avr. 2013, at 21:07, William Adams <[hidden email]> wrote:

> Would this be feasible?
>
> I was quite thrilled w/ OpenSCAD until the following exchange:
>
> http://www.shapeoko.com/forum/viewtopic.php?f=6&t=204
>
> wherein I learned that it is limited to an internal polygonal representation.
>
> Would it be possible to turn a part inside out, and create G-code for milling away, matching circles and arcs &c. elegantly?
>
> William
>
> --
> William Adams
> senior graphic designer
> Fry Communications
> Sphinx of black quartz, judge my vow.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Taylor Alexander
I still wish it supported arcs. If it did, it could export to IGES and DXF and the files would actually be useful for real engineering and machining, not just tinkering and 3D printing. Apparent IGES is a CSG based format or whatever, so some chatter back when I joined the list seemed to think it's possible. True arcs could be defined by setting facets to zero or by leaving out that parameter (though I think that's already used?).


On Mon, Apr 15, 2013 at 2:50 PM, kolergy <[hidden email]> wrote:

The answer to the exchange you mention in the link is "$fn=xx" this function allows you to set the number of vertex in you circle, by default it is small for the small circles but you can increase it until you are happy with the result.




On 15 avr. 2013, at 21:07, William Adams <[hidden email]> wrote:

> Would this be feasible?
>
> I was quite thrilled w/ OpenSCAD until the following exchange:
>
> http://www.shapeoko.com/forum/viewtopic.php?f=6&t=204
>
> wherein I learned that it is limited to an internal polygonal representation.
>
> Would it be possible to turn a part inside out, and create G-code for milling away, matching circles and arcs &c. elegantly?
>
> William
>
> --
> William Adams
> senior graphic designer
> Fry Communications
> Sphinx of black quartz, judge my vow.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

kintel
Administrator
On 2013-04-15, at 18:55 , Taylor Alexander wrote:

> I still wish it supported arcs. If it did, it could export to IGES and DXF and the files would actually be useful for real engineering and machining, not just tinkering and 3D printing. Apparent IGES is a CSG based format or whatever, so some chatter back when I joined the list seemed to think it's possible. True arcs could be defined by setting facets to zero or by leaving out that parameter (though I think that's already used?).
>
The issue is not the format used, but the geometry engine which does the calculations.
We're using an engine called CGAL, which operates on a polygonal level.
There are other engines out there, but most such engines are commercial and not possible to license for use in an Open Source program like OpenSCAD (in addition to being prohibitively expensive). One free alternative is OpenCascade, but as far as I understand, they also do all CSG operations on triangle meshes, not smooth curves and surfaces.

We're constantly on the lookout for better engines (this is the holy grail of CAD software), so any suggestions are welcome!

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

nophead
I use the DXF export to route things so it is possible to do "real engineering and machining". You just have to set the $fa small enough so the facets aren't noticeable.


On 16 April 2013 00:18, Marius Kintel <[hidden email]> wrote:
On 2013-04-15, at 18:55 , Taylor Alexander wrote:

> I still wish it supported arcs. If it did, it could export to IGES and DXF and the files would actually be useful for real engineering and machining, not just tinkering and 3D printing. Apparent IGES is a CSG based format or whatever, so some chatter back when I joined the list seemed to think it's possible. True arcs could be defined by setting facets to zero or by leaving out that parameter (though I think that's already used?).
>
The issue is not the format used, but the geometry engine which does the calculations.
We're using an engine called CGAL, which operates on a polygonal level.
There are other engines out there, but most such engines are commercial and not possible to license for use in an Open Source program like OpenSCAD (in addition to being prohibitively expensive). One free alternative is OpenCascade, but as far as I understand, they also do all CSG operations on triangle meshes, not smooth curves and surfaces.

We're constantly on the lookout for better engines (this is the holy grail of CAD software), so any suggestions are welcome!

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Taylor Alexander
Marius - thanks for explaining the issue! Now that I have some understanding, it may be easier to solve. I have a friend who has a vested interest in improving FLOSS CAD, so maybe I'll run that by him.

One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.

On Mon, Apr 15, 2013 at 4:22 PM, nop head <[hidden email]> wrote:
I use the DXF export to route things so it is possible to do "real engineering and machining". You just have to set the $fa small enough so the facets aren't noticeable.

It's possible to do "real engineering" with OpenSCAD, but not as convenient as it could be if we had arcs. Technically it's possible to do "real engineering' with popsicle sticks too. OpenSCAD is a 3D modeller and for you it's useful for 2D stuff, so that's not the most reassuring. If you actually want to use OpenSCAD as a real 3D modelling program and hope to have any interoperability with other CAD or CAM systems, it's a PITA. And interoperability is pretty important in "real" CAD systems. Not day to day, but sometimes - and it can be a huge issue when it's not easy.

I made a modification to Wade's extruder using OpenSCAD and Solidworks mixed together (did the whole Wades mod in OpenSCAD and built the rest of the assembly in Solidworks, importing the Wades part), and only being able to import STL is *awful*. When you import an STL into Solidworks versus an IGES file of the same part, here's what you can't do without partially re-drawing the part in solidworks:

- select the center or any quadrant of an arc
- select an entire face in one click
- select an entire edge with one click
- draw a line tangent to an arc
- mate two concentric arcs in an assembly (used ALL THE TIME for assemblies that screw together)
- mate two arcs as tangent in an assembly

Doing any of the above requires that you first draw some construction geometry, set reference planes/axes, or in many cases tediously select many facets of something in order to convert it to features that solidworks can use. What's worse, all that construction geometry that you had to take time drawing just to work with the part usually all has to be recreated from scratch if you need to make a change to the OpenSCAD part and re-import it.

Those same limitations above also mean it's often a PITA if you want to CNC machine something designed in OpenSCAD.

If your CAD system can't interoperate with professional engineering CAD systems on at least a basic level (the current state of affairs means interoperability is still just dumb solids like IGES or STEP, but IGES is worlds better to work with than STL), it's hard to take all the great open source stuff people have done with OpenSCAD and actually use it in a professional setting, even if the creator allows or even wanted this to be the case.

Basically, OpenSCAD shares at least one of the major drawbacks of mesh-based modelling programs that solid-based modelling programs like OpenSCAD aren't supposed to have. Meshes are for art, solids are for engineering (generally). A solid CAD modeller that can only export meshes is not going to be *nearly* as useful in a professional setting as one that can export solids.

Which is too bad - there's a lot of great stuff done in OpenSCAD that is open source, and it would be great if anyone in the community could use it, not just people who have learned OpenSCAD (I can dabble but *man* is solidworks easier for me).





On 16 April 2013 00:18, Marius Kintel <[hidden email]> wrote:
On 2013-04-15, at 18:55 , Taylor Alexander wrote:

> I still wish it supported arcs. If it did, it could export to IGES and DXF and the files would actually be useful for real engineering and machining, not just tinkering and 3D printing. Apparent IGES is a CSG based format or whatever, so some chatter back when I joined the list seemed to think it's possible. True arcs could be defined by setting facets to zero or by leaving out that parameter (though I think that's already used?).
>
The issue is not the format used, but the geometry engine which does the calculations.
We're using an engine called CGAL, which operates on a polygonal level.
There are other engines out there, but most such engines are commercial and not possible to license for use in an Open Source program like OpenSCAD (in addition to being prohibitively expensive). One free alternative is OpenCascade, but as far as I understand, they also do all CSG operations on triangle meshes, not smooth curves and surfaces.

We're constantly on the lookout for better engines (this is the holy grail of CAD software), so any suggestions are welcome!

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

kintel
Administrator
On 2013-04-15, at 19:51 , Taylor Alexander wrote:

> One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.
>
I've been thinking in that direction - my idea was to keep as much geometry as possible in an as exact form as possible and perform a lazy evaluation to a polygonal level when needed. That way we could store primitives as implicit objects and render them in high resolution until it's needed for e.g. CSG, and only then respect the $fn parameter. Same could go for curves, and eventually things like NURBS.

I'm slowly refactoring my way to having a more flexible backend...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Whosawhatsis
I would really love to get support for smooth circles, even if it only works in 2d (for DXF export), but I understand the difficulties involved.

On Monday, April 15, 2013 at 5:00 PM, Marius Kintel wrote:

On 2013-04-15, at 19:51 , Taylor Alexander wrote:

One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.
I've been thinking in that direction - my idea was to keep as much geometry as possible in an as exact form as possible and perform a lazy evaluation to a polygonal level when needed. That way we could store primitives as implicit objects and render them in high resolution until it's needed for e.g. CSG, and only then respect the $fn parameter. Same could go for curves, and eventually things like NURBS.

I'm slowly refactoring my way to having a more flexible backend...

-Marius


_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Kevin Crowley
In reply to this post by Taylor Alexander
I just googled floss cad and seem to have multiple choices.


On Mon, Apr 15, 2013 at 6:51 PM, Taylor Alexander <[hidden email]> wrote:
Marius - thanks for explaining the issue! Now that I have some understanding, it may be easier to solve. I have a friend who has a vested interest in improving FLOSS CAD, so maybe I'll run that by him.

One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.

On Mon, Apr 15, 2013 at 4:22 PM, nop head <[hidden email]> wrote:
I use the DXF export to route things so it is possible to do "real engineering and machining". You just have to set the $fa small enough so the facets aren't noticeable.

It's possible to do "real engineering" with OpenSCAD, but not as convenient as it could be if we had arcs. Technically it's possible to do "real engineering' with popsicle sticks too. OpenSCAD is a 3D modeller and for you it's useful for 2D stuff, so that's not the most reassuring. If you actually want to use OpenSCAD as a real 3D modelling program and hope to have any interoperability with other CAD or CAM systems, it's a PITA. And interoperability is pretty important in "real" CAD systems. Not day to day, but sometimes - and it can be a huge issue when it's not easy.

I made a modification to Wade's extruder using OpenSCAD and Solidworks mixed together (did the whole Wades mod in OpenSCAD and built the rest of the assembly in Solidworks, importing the Wades part), and only being able to import STL is *awful*. When you import an STL into Solidworks versus an IGES file of the same part, here's what you can't do without partially re-drawing the part in solidworks:

- select the center or any quadrant of an arc
- select an entire face in one click
- select an entire edge with one click
- draw a line tangent to an arc
- mate two concentric arcs in an assembly (used ALL THE TIME for assemblies that screw together)
- mate two arcs as tangent in an assembly

Doing any of the above requires that you first draw some construction geometry, set reference planes/axes, or in many cases tediously select many facets of something in order to convert it to features that solidworks can use. What's worse, all that construction geometry that you had to take time drawing just to work with the part usually all has to be recreated from scratch if you need to make a change to the OpenSCAD part and re-import it.

Those same limitations above also mean it's often a PITA if you want to CNC machine something designed in OpenSCAD.

If your CAD system can't interoperate with professional engineering CAD systems on at least a basic level (the current state of affairs means interoperability is still just dumb solids like IGES or STEP, but IGES is worlds better to work with than STL), it's hard to take all the great open source stuff people have done with OpenSCAD and actually use it in a professional setting, even if the creator allows or even wanted this to be the case.

Basically, OpenSCAD shares at least one of the major drawbacks of mesh-based modelling programs that solid-based modelling programs like OpenSCAD aren't supposed to have. Meshes are for art, solids are for engineering (generally). A solid CAD modeller that can only export meshes is not going to be *nearly* as useful in a professional setting as one that can export solids.

Which is too bad - there's a lot of great stuff done in OpenSCAD that is open source, and it would be great if anyone in the community could use it, not just people who have learned OpenSCAD (I can dabble but *man* is solidworks easier for me).





On 16 April 2013 00:18, Marius Kintel <[hidden email]> wrote:
On 2013-04-15, at 18:55 , Taylor Alexander wrote:

> I still wish it supported arcs. If it did, it could export to IGES and DXF and the files would actually be useful for real engineering and machining, not just tinkering and 3D printing. Apparent IGES is a CSG based format or whatever, so some chatter back when I joined the list seemed to think it's possible. True arcs could be defined by setting facets to zero or by leaving out that parameter (though I think that's already used?).
>
The issue is not the format used, but the geometry engine which does the calculations.
We're using an engine called CGAL, which operates on a polygonal level.
There are other engines out there, but most such engines are commercial and not possible to license for use in an Open Source program like OpenSCAD (in addition to being prohibitively expensive). One free alternative is OpenCascade, but as far as I understand, they also do all CSG operations on triangle meshes, not smooth curves and surfaces.

We're constantly on the lookout for better engines (this is the holy grail of CAD software), so any suggestions are welcome!

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

nophead
In reply to this post by kintel
I personally think it is good that OpenScad doesn't interop with conventional 3D CAD. If it did people who don't like code would take opensource scad projects and convert them into formats for closed source CAD programs. Once manipulated in a 3D CAD program it would not convert back to openscad source code again. 


On 16 April 2013 01:00, Marius Kintel <[hidden email]> wrote:
On 2013-04-15, at 19:51 , Taylor Alexander wrote:

> One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.
>
I've been thinking in that direction - my idea was to keep as much geometry as possible in an as exact form as possible and perform a lazy evaluation to a polygonal level when needed. That way we could store primitives as implicit objects and render them in high resolution until it's needed for e.g. CSG, and only then respect the $fn parameter. Same could go for curves, and eventually things like NURBS.

I'm slowly refactoring my way to having a more flexible backend...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Triffid Hunter
I put

$fa = 0.01;
$fs = 2; // change me to 0.5 for export render

at the top of all my scad files. I know it's not quite what you're after, but for 3d printing 0.5mm segmented curves are indistinguishable from smooth ones.

I only use $fn for nut traps and octagons, setting the segment length directly makes far more sense to me.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

donbright
In reply to this post by nophead

For 2d, IMHO it might be theoretically possible to add a secondary engine that is based on the 'circular traits' feature of CGAL 2d code:

http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Boolean_set_operations_2/Chapter_main.html

This would in theory allow the user to directly export DXF 'circle' or 'arc' entities.

However certain operations will require conversion to line-segment form. All 3d stuff is in line-segments so projection() to 2d will never produce arcs/circles. Any extrude() to 3d also forces the data into line-segment form. Some 2d operations like 2d minkowski sum probably would force it into line-segment form.

There is also a requirement that anything in the circle-traits engine would have to 'render' the same as the line-segment engine, for example with issues like non-simple polygons (self intersecting polygons, polygons with holes, holes that meet at a single vertex, holes that intersect, etc etc).

-DB


On Mon, Apr 15, 2013 at 7:13 PM, nop head <[hidden email]> wrote:
I personally think it is good that OpenScad doesn't interop with conventional 3D CAD. If it did people who don't like code would take opensource scad projects and convert them into formats for closed source CAD programs. Once manipulated in a 3D CAD program it would not convert back to openscad source code again. 


On 16 April 2013 01:00, Marius Kintel <[hidden email]> wrote:
On 2013-04-15, at 19:51 , Taylor Alexander wrote:

> One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.
>
I've been thinking in that direction - my idea was to keep as much geometry as possible in an as exact form as possible and perform a lazy evaluation to a polygonal level when needed. That way we could store primitives as implicit objects and render them in high resolution until it's needed for e.g. CSG, and only then respect the $fn parameter. Same could go for curves, and eventually things like NURBS.

I'm slowly refactoring my way to having a more flexible backend...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Taylor Alexander
Anyone interested in using script-like languages to generate DXF files might be interested in:
(I've never used it, just googled for it. Also Python is super easy to learn. I avoided it for a while but recently spent a day learning it and it's really simple. http://www.learnpython.org/ )

Still, the rendering given by OpenSCAD would be nice. You could set your python script to save the DXF file, then re-save an .scad file with the SCAD editor set to auto compile and load, where the scad file just loads the DXF and extrudes it. Then you'd get a preview upon running your script. Though that's assuming DXF extrude in OpenSCAD works with complex DXF files.

You could also just have python open the resulting DXF in whatever viewer you want, actually.


On Mon, Apr 15, 2013 at 6:14 PM, Don Bright <[hidden email]> wrote:

For 2d, IMHO it might be theoretically possible to add a secondary engine that is based on the 'circular traits' feature of CGAL 2d code:

http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Boolean_set_operations_2/Chapter_main.html

This would in theory allow the user to directly export DXF 'circle' or 'arc' entities.

However certain operations will require conversion to line-segment form. All 3d stuff is in line-segments so projection() to 2d will never produce arcs/circles. Any extrude() to 3d also forces the data into line-segment form. Some 2d operations like 2d minkowski sum probably would force it into line-segment form.

There is also a requirement that anything in the circle-traits engine would have to 'render' the same as the line-segment engine, for example with issues like non-simple polygons (self intersecting polygons, polygons with holes, holes that meet at a single vertex, holes that intersect, etc etc).

-DB


On Mon, Apr 15, 2013 at 7:13 PM, nop head <[hidden email]> wrote:
I personally think it is good that OpenScad doesn't interop with conventional 3D CAD. If it did people who don't like code would take opensource scad projects and convert them into formats for closed source CAD programs. Once manipulated in a 3D CAD program it would not convert back to openscad source code again. 


On 16 April 2013 01:00, Marius Kintel <[hidden email]> wrote:
On 2013-04-15, at 19:51 , Taylor Alexander wrote:

> One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.
>
I've been thinking in that direction - my idea was to keep as much geometry as possible in an as exact form as possible and perform a lazy evaluation to a polygonal level when needed. That way we could store primitives as implicit objects and render them in high resolution until it's needed for e.g. CSG, and only then respect the $fn parameter. Same could go for curves, and eventually things like NURBS.

I'm slowly refactoring my way to having a more flexible backend...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Elmo Mäntynen
In reply to this post by Taylor Alexander
You could try the OpenSCAD import in FreeCAD. It's still one way (making
it two way would be hard but maybe doable), and FreeCAD is young, but It
exports to IGES and/or STEP etc.

Elmo

On 04/16/2013 02:51 AM, Taylor Alexander wrote:

> Marius - thanks for explaining the issue! Now that I have some
> understanding, it may be easier to solve. I have a friend who has a
> vested interest in improving FLOSS CAD, so maybe I'll run that by him.
>
> One question - would it be plausible to partially implement arcs? For
> example, could the code be designed so that unsupported operations
> with curved surfaces simply fail, leaving it up to the user to get it
> right? That could be useful for introducing arcs as an alpha feature
> for testing.
>
> On Mon, Apr 15, 2013 at 4:22 PM, nop head <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I use the DXF export to route things so it is possible to do "real
>     engineering and machining". You just have to set the $fa small
>     enough so the facets aren't noticeable.
>
>
> It's possible to do "real engineering" with OpenSCAD, but not as
> convenient as it could be if we had arcs. Technically it's possible to
> do "real engineering' with popsicle sticks too. OpenSCAD is a 3D
> modeller and for you it's useful for 2D stuff, so that's not the most
> reassuring. If you actually want to use OpenSCAD as a real 3D
> modelling program and hope to have any interoperability with other CAD
> or CAM systems, it's a PITA. And interoperability is pretty important
> in "real" CAD systems. Not day to day, but sometimes - and it can be a
> huge issue when it's not easy.
>
> I made a modification to Wade's extruder using OpenSCAD and Solidworks
> mixed together (did the whole Wades mod in OpenSCAD and built the rest
> of the assembly in Solidworks, importing the Wades part), and only
> being able to import STL is *awful*. When you import an STL into
> Solidworks versus an IGES file of the same part, here's what you can't
> do without partially re-drawing the part in solidworks:
>
> - select the center or any quadrant of an arc
> - select an entire face in one click
> - select an entire edge with one click
> - draw a line tangent to an arc
> - mate two concentric arcs in an assembly (used ALL THE TIME for
> assemblies that screw together)
> - mate two arcs as tangent in an assembly
>
> Doing any of the above requires that you first draw some construction
> geometry, set reference planes/axes, or in many cases tediously select
> many facets of something in order to convert it to features that
> solidworks can use. What's worse, all that construction geometry that
> you had to take time drawing just to work with the part usually all
> has to be recreated from scratch if you need to make a change to the
> OpenSCAD part and re-import it.
>
> Those same limitations above also mean it's often a PITA if you want
> to CNC machine something designed in OpenSCAD.
>
> If your CAD system can't interoperate with professional engineering
> CAD systems on at least a basic level (the current state of affairs
> means interoperability is still just dumb solids like IGES or STEP,
> but IGES is worlds better to work with than STL), it's hard to take
> all the great open source stuff people have done with OpenSCAD and
> actually use it in a professional setting, even if the creator allows
> or even wanted this to be the case.
>
> Basically, OpenSCAD shares at least one of the major drawbacks of
> mesh-based modelling programs that solid-based modelling programs like
> OpenSCAD aren't supposed to have. Meshes are for art, solids are for
> engineering (generally). A solid CAD modeller that can only export
> meshes is not going to be *nearly* as useful in a professional setting
> as one that can export solids.
>
> Which is too bad - there's a lot of great stuff done in OpenSCAD that
> is open source, and it would be great if anyone in the community could
> use it, not just people who have learned OpenSCAD (I can dabble but
> *man* is solidworks easier for me).
>
>
>
>
>
>     On 16 April 2013 00:18, Marius Kintel <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         On 2013-04-15, at 18:55 , Taylor Alexander wrote:
>
>         > I still wish it supported arcs. If it did, it could export
>         to IGES and DXF and the files would actually be useful for
>         real engineering and machining, not just tinkering and 3D
>         printing. Apparent IGES is a CSG based format or whatever, so
>         some chatter back when I joined the list seemed to think it's
>         possible. True arcs could be defined by setting facets to zero
>         or by leaving out that parameter (though I think that's
>         already used?).
>         >
>         The issue is not the format used, but the geometry engine
>         which does the calculations.
>         We're using an engine called CGAL, which operates on a
>         polygonal level.
>         There are other engines out there, but most such engines are
>         commercial and not possible to license for use in an Open
>         Source program like OpenSCAD (in addition to being
>         prohibitively expensive). One free alternative is OpenCascade,
>         but as far as I understand, they also do all CSG operations on
>         triangle meshes, not smooth curves and surfaces.
>
>         We're constantly on the lookout for better engines (this is
>         the holy grail of CAD software), so any suggestions are welcome!
>
>          -Marius
>
>         _______________________________________________
>         OpenSCAD mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://rocklinux.net/mailman/listinfo/openscad
>         http://openscad.org - https://flattr.com/thing/121566
>
>
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://rocklinux.net/mailman/listinfo/openscad
>     http://openscad.org - https://flattr.com/thing/121566
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
ds
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

ds
In reply to this post by donbright
To my way of thinking, the fact that arcs are not supported is mostly irrelevant to getting output to CNC.  If you look at the whole chain of events associated with getting the cutter to move the right way, the controller is still outputting a series of x, y, z movements to the servos on a very small scale to get smooth curves. 

Once your $fn is an arbitrarily large number, the only difference is that your G-Code would be much more compact with arcs.  So, it would seem that if you have to load a cache of G-Code to a machine to run your program you might care, but otherwise it doesn't seem like it would matter at all.


On 04/15/13 18:14, Don Bright wrote:

For 2d, IMHO it might be theoretically possible to add a secondary engine that is based on the 'circular traits' feature of CGAL 2d code:

http://www.cgal.org/Manual/latest/doc_html/cgal_manual/Boolean_set_operations_2/Chapter_main.html

This would in theory allow the user to directly export DXF 'circle' or 'arc' entities.

However certain operations will require conversion to line-segment form. All 3d stuff is in line-segments so projection() to 2d will never produce arcs/circles. Any extrude() to 3d also forces the data into line-segment form. Some 2d operations like 2d minkowski sum probably would force it into line-segment form.

There is also a requirement that anything in the circle-traits engine would have to 'render' the same as the line-segment engine, for example with issues like non-simple polygons (self intersecting polygons, polygons with holes, holes that meet at a single vertex, holes that intersect, etc etc).

-DB


On Mon, Apr 15, 2013 at 7:13 PM, nop head <[hidden email]> wrote:
I personally think it is good that OpenScad doesn't interop with conventional 3D CAD. If it did people who don't like code would take opensource scad projects and convert them into formats for closed source CAD programs. Once manipulated in a 3D CAD program it would not convert back to openscad source code again. 


On 16 April 2013 01:00, Marius Kintel <[hidden email]> wrote:
On 2013-04-15, at 19:51 , Taylor Alexander wrote:

> One question - would it be plausible to partially implement arcs? For example, could the code be designed so that unsupported operations with curved surfaces simply fail, leaving it up to the user to get it right? That could be useful for introducing arcs as an alpha feature for testing.
>
I've been thinking in that direction - my idea was to keep as much geometry as possible in an as exact form as possible and perform a lazy evaluation to a polygonal level when needed. That way we could store primitives as implicit objects and render them in high resolution until it's needed for e.g. CSG, and only then respect the $fn parameter. Same could go for curves, and eventually things like NURBS.

I'm slowly refactoring my way to having a more flexible backend...

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

William Adams-2
On Apr 16, 2013, at 1:10 PM, ds wrote:

> To my way of thinking, the fact that arcs are not supported is mostly irrelevant to getting output to CNC.  If you look at the whole chain of events associated with getting the cutter to move the right way, the controller is still outputting a series of x, y, z movements to the servos on a very small scale to get smooth curves.  

 - bloated filesize
 - longer send-time
 - longer run-time
 - more complex file which is well-nigh impossible to edit by hand.
 - faceted surface finish

For that last, look at:

http://mae.engr.ucdavis.edu/~farouki/ijmtm99a.pdf

in particular, Fig. 9.

William


--
William Adams
senior graphic designer
Fry Communications
Sphinx of black quartz, judge my vow.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
ds
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

ds
I'll take a look. Thanks.

Don

On 04/16/13 10:39, William Adams wrote:

> On Apr 16, 2013, at 1:10 PM, ds wrote:
>
>> To my way of thinking, the fact that arcs are not supported is mostly irrelevant to getting output to CNC.  If you look at the whole chain of events associated with getting the cutter to move the right way, the controller is still outputting a series of x, y, z movements to the servos on a very small scale to get smooth curves.
>   - bloated filesize
>   - longer send-time
>   - longer run-time
>   - more complex file which is well-nigh impossible to edit by hand.
>   - faceted surface finish
>
> For that last, look at:
>
> http://mae.engr.ucdavis.edu/~farouki/ijmtm99a.pdf
>
> in particular, Fig. 9.
>
> William
>
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

nophead
Perhaps my eyes are dim but I can't see any facets on the things I mill. Run time should be the same as long as the comms link keeps up with the extra data and the motion controller has lookahead like Marlin and LinuxEMC.



On 16 April 2013 18:41, ds <[hidden email]> wrote:
I'll take a look. Thanks.

Don

On 04/16/13 10:39, William Adams wrote:
> On Apr 16, 2013, at 1:10 PM, ds wrote:
>
>> To my way of thinking, the fact that arcs are not supported is mostly irrelevant to getting output to CNC.  If you look at the whole chain of events associated with getting the cutter to move the right way, the controller is still outputting a series of x, y, z movements to the servos on a very small scale to get smooth curves.
>   - bloated filesize
>   - longer send-time
>   - longer run-time
>   - more complex file which is well-nigh impossible to edit by hand.
>   - faceted surface finish
>
> For that last, look at:
>
> http://mae.engr.ucdavis.edu/~farouki/ijmtm99a.pdf
>
> in particular, Fig. 9.
>
> William
>
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

Taylor Alexander

Many of the main issues I listed up above are issues when CNCing something (where I reference CAM software).
You can't pick the center of a hole to drill it without first adding some construction geometry - okay, not too big of a deal. Wait, you have 100 holes in your plate? Eek. My CAM program can auto select the center of all arcs of a certain size in a window with a few clicks - can't do that if they aren't arcs.
And let's say I want to cut a contour around the edge of the part - wait, no continuous edge? Every time you try to specify an edge, it will run along that line and any others after it as long as there are no intersections. With every STL facet I have to click a million times to specify the whole perimeter of a part, a problem I don't have to deal with normally.

I'm talking about doing CNCing in a business environment, so I was more time sensitive, but really once you've done it the right way, you realize how bad STL is. I did all the machine programming for a small shop with 2 Haas mills and a Haas lathe so trust me when I say this: compared to any alternative, STL is an awful, awful format to machine from. IGES would be a huge improvement.

And the aforementioned lack of editability in a Solids based program after it leaves the OpenSCAD is a real problem.

I love open scad. I use solid works because I actually have a license and its "the Cadillac of CAD" in many ways, but I hate how exclusive it is and I wish my friends would easily learn CAD so they could 3d print with me - so I really love the idea of OpenSCAD and this isn't ignorance or a dislike for the program, its just genuinely bad compared to an engineering CAD environment, and polygonal geometry is largely to blame (and syntax, but we know that one).

On Apr 16, 2013 11:05 AM, "nop head" <[hidden email]> wrote:
>
> Perhaps my eyes are dim but I can't see any facets on the things I mill. Run time should be the same as long as the comms link keeps up with the extra data and the motion controller has lookahead like Marlin and LinuxEMC.
>
>
>
> On 16 April 2013 18:41, ds <[hidden email]> wrote:
>>
>> I'll take a look. Thanks.
>>
>> Don
>>
>> On 04/16/13 10:39, William Adams wrote:
>> > On Apr 16, 2013, at 1:10 PM, ds wrote:
>> >
>> >> To my way of thinking, the fact that arcs are not supported is mostly irrelevant to getting output to CNC.  If you look at the whole chain of events associated with getting the cutter to move the right way, the controller is still outputting a series of x, y, z movements to the servos on a very small scale to get smooth curves.
>> >   - bloated filesize
>> >   - longer send-time
>> >   - longer run-time
>> >   - more complex file which is well-nigh impossible to edit by hand.
>> >   - faceted surface finish
>> >
>> > For that last, look at:
>> >
>> > http://mae.engr.ucdavis.edu/~farouki/ijmtm99a.pdf
>> >
>> > in particular, Fig. 9.
>> >
>> > William
>> >
>> >
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: elegant export to G-code from w/in OpenSCAD?

nophead
I wrote a simple Python script to calculate drill centres from DXF files made by OpenScad. I am surprised a commercial CAM program can't do it.. 


On 16 April 2013 19:35, Taylor Alexander <[hidden email]> wrote:

Many of the main issues I listed up above are issues when CNCing something (where I reference CAM software).
You can't pick the center of a hole to drill it without first adding some construction geometry - okay, not too big of a deal. Wait, you have 100 holes in your plate? Eek. My CAM program can auto select the center of all arcs of a certain size in a window with a few clicks - can't do that if they aren't arcs.
And let's say I want to cut a contour around the edge of the part - wait, no continuous edge? Every time you try to specify an edge, it will run along that line and any others after it as long as there are no intersections. With every STL facet I have to click a million times to specify the whole perimeter of a part, a problem I don't have to deal with normally.

I'm talking about doing CNCing in a business environment, so I was more time sensitive, but really once you've done it the right way, you realize how bad STL is. I did all the machine programming for a small shop with 2 Haas mills and a Haas lathe so trust me when I say this: compared to any alternative, STL is an awful, awful format to machine from. IGES would be a huge improvement.

And the aforementioned lack of editability in a Solids based program after it leaves the OpenSCAD is a real problem.

I love open scad. I use solid works because I actually have a license and its "the Cadillac of CAD" in many ways, but I hate how exclusive it is and I wish my friends would easily learn CAD so they could 3d print with me - so I really love the idea of OpenSCAD and this isn't ignorance or a dislike for the program, its just genuinely bad compared to an engineering CAD environment, and polygonal geometry is largely to blame (and syntax, but we know that one).

On Apr 16, 2013 11:05 AM, "nop head" <[hidden email]> wrote:
>
> Perhaps my eyes are dim but I can't see any facets on the things I mill. Run time should be the same as long as the comms link keeps up with the extra data and the motion controller has lookahead like Marlin and LinuxEMC.
>
>
>
> On 16 April 2013 18:41, ds <[hidden email]> wrote:
>>
>> I'll take a look. Thanks.
>>
>> Don
>>
>> On 04/16/13 10:39, William Adams wrote:
>> > On Apr 16, 2013, at 1:10 PM, ds wrote:
>> >
>> >> To my way of thinking, the fact that arcs are not supported is mostly irrelevant to getting output to CNC.  If you look at the whole chain of events associated with getting the cutter to move the right way, the controller is still outputting a series of x, y, z movements to the servos on a very small scale to get smooth curves.
>> >   - bloated filesize
>> >   - longer send-time
>> >   - longer run-time
>> >   - more complex file which is well-nigh impossible to edit by hand.
>> >   - faceted surface finish
>> >
>> > For that last, look at:
>> >
>> > http://mae.engr.ucdavis.edu/~farouki/ijmtm99a.pdf
>> >
>> > in particular, Fig. 9.
>> >
>> > William
>> >
>> >
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://rocklinux.net/mailman/listinfo/openscad
>> http://openscad.org - https://flattr.com/thing/121566
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
1234