[jaru-eri]

I saw this on a web site:

Using STL is perfectly fine for objects that have only flat surfaces.
Anything curved can't be exactly represented. So whereas a G2 line can
exactly describe an arc segment, an STL file can only represent a
piecewise linear representation of that curve. Additionally, the
software that converts STL to G-code doesn't know what the underlying
feature is really meant to be - it can't necessarily "look at" the shape
and generate G-code for "what you meant". (what if you design something
with a 300-facet near-curve, not an arc?)

STL causes the surface to be sampled three times: first when the
original parametric model is converted to triangles, second when the
triangles are converted to G-code, and third when the G-code is executed
(the machine resolution and timing of the trajectory planner do this).

That's one more than without STL, since the G-code and machine sampling
will aways take place.

As to how bad that makes it, well - you're a better judge than me if
you've used a CNC for more than a few hours

Unfortunately, I don't know of any other formats that could be used in
the near future. There's STEP, which seems to require several
appendages to get the spec for, and it would be really cool if someone
could just make a machine controller that could read parasolid files (or
IGES, or ACIS ...).
- Steve

[ger21]

There are plenty of CAM programs that can read native CAD formats, or formats where they can detect features of the models. But the issue for hobbiests, is that these CAM package stypically start around $5000 and go up quickly.

[awerby]

I saw this on a web site:

Using STL is perfectly fine for objects that have only flat surfaces.
Anything curved can't be exactly represented. So whereas a G2 line can
exactly describe an arc segment, an STL file can only represent a
piecewise linear representation of that curve. Additionally, the
software that converts STL to G-code doesn't know what the underlying
feature is really meant to be - it can't necessarily "look at" the shape
and generate G-code for "what you meant". (what if you design something
with a 300-facet near-curve, not an arc?)

[Yes, STL is a "dumb" format; it doesn't have any rules that define what a surface or solid must be. But that makes it good for defining odd geometries that don't conform to any rules, including wildly curvy forms. There's a reason it's the preferred file format for rapid prototyping - it represents any geometry you tell it to, no matter what the topography, as rows of edge-joined triangles of whatever granularity you define. Whether it's curves or flats doesn't matter, although the former will take up less memory.]

STL causes the surface to be sampled three times: first when the
original parametric model is converted to triangles, second when the
triangles are converted to G-code, and third when the G-code is executed
(the machine resolution and timing of the trajectory planner do this).

That's one more than without STL, since the G-code and machine sampling
will aways take place.

[And your point is? How else are you proposing to store your complex models, which won't require translation from whatever data format you choose?]

As to how bad that makes it, well - you're a better judge than me if
you've used a CNC for more than a few hours

[I guess I qualify there - but I think STL is the greatest thing since sliced bread (with which it has some things in common...)]

Unfortunately, I don't know of any other formats that could be used in
the near future. There's STEP, which seems to require several
appendages to get the spec for, and it would be really cool if someone
could just make a machine controller that could read parasolid files (or
IGES, or ACIS ...).
- Steve

[Those formats (some proprietary) all are much more picky about what they'll represent than STL. Usually you have to define their parameters in advance, in a certain program that deals with them (which is why they're called "parametric"). STL is non-proprietary and non-parametric, which has made it the 3d file transfer format of choice for the RP industry. Sure, it's bulkier than it really needs to be, but until we come up with something that shares its advantages but not its disadvantages, it's the best choice we've got for communicating 3d models across various platforms.]

Andrew Werby
www.computersculpture.com

[Harryman]

Is there a point to the original post? A question in there? Or is it just a repost of somebody's random statement from somewhere in cyberspace?

[jaru-eri]

Is there a point to the original post? A question in there? Or is it just a repost of somebody's random statement from somewhere in cyberspace?

Now I understand why you took the name "Harryman".. ::--))