On STL generation:
The problems are usually in one of two areas: tessellation quality, and failure
to match adjacent triangle vertices. Tessellation of trimmed nurb surfaces can
be tricky business.
Most STL generation software is developed one of two ways:
1) Modify the shading software. The cad vendor already has routines to produce
polygons for display purposes. Unfortunatly the optimum tessellation
for Image Generation is somewhat different from the optimum tessellation
for RP. And the triangles from adjacent surfaces still need to be
matched up.
2) Quick and dirty. Little thought is given to the tessellation quality. Be
glad you got everything tessellated at all.
Brock Rooney & Assoc. customers report that our STL generation products
usually produce better tessellation than does ProE. This is because our
routines were developed specifically for this application, and generally
work harder at
getting the optimum number of triangles for a particular condition.
On Direct Slicing of Cad Models:
It seems this idea has reared its ugly head again.
So at the risk of boring some:
Direct slicing of the CAD model is a Bad Idea for a Lot of reasons. A Few are:
1) Performance
Time to generate a STL file and slice it should be less than 1/10 th the
time to slice the Cad model. Take a moderate size CAD file with 500 faces
and tell your favorite CAD system to section it 5 times.
Note the time. Multiply by 1000.
In general, intersecting a plane and a surface is a highly iterative
procedure, which requires a lot of computations. The STL Generating and
Slicing procedures are not iterative, and so run much faster.
Of course, the cad system could slice a faceted representation, but this
would produce a similar result to slicing the STL (at best).
2) File size
For the vast majority of models, the slice data is much larger than the
STL data. Unless the STL file is REALLY over-tessellated.
(By the way, experience indicates that a decent STL file will usually be
about the same size as the CAD database.)
3) Vertical accuracy
By manipulating the STL vertices, the slice software can produce a Max
vertical error of 1/2 the slice thickness. In addition, upward and
downward triangles can be manipulated as needed by the process to produce
the best part. Slicing the CAD model produces a Max vertical error equal to
the slice thickness, since a feature could be just below or just above the
slice plane.
4) Slice Closure
In general, the adjacent surfaces in BREP Solid Models do not match exactly.
There are cracks and overlaps. Eventually, the Cutting Plane WILL hit a
seam, resulting in an incomplete boundary, or duplicate pieces.
Because the triangles in a valid STL file match EXACTLY, this cannot happen.
The slice software can ALWAYS produce exact closed boundarys.
5) Slice Accuracy
Intersecting a plane and a surface has numerical problems when the surface
normal is nearly perpendicular to the cutting plane. It can be difficult
to the follow the the intersection curve in these cases, and indeed the
curve can split into 2 paths. This eventually WILL happen in your parts.
There are no such problems slicing a STL file.
6) Slicing is Process dependent; STL generation is not.
To slice, you need to know at least the build orientation and slice
thickness. These are things the CAD modeler does not want to know about.
This information is not needed to generate a STL file.
(I could go on, but enough for now)
STL format follows the KISS dictum of good engineering design.
Any beginning computer programmer can create a program to read binary
stl files in less than 20 lines of code. Alternative CAD standards
(perhaps STEP) are much more complex.
STL is in the top 3 CAD data formats (with DXF and IGES) because of this
simplicity. It is being used in several other areas besides RP. STEP, on the
other hand, has been in development for longer than this industry has existed.
C. Brock Rooney, Pres., Brock Rooney & Associates Inc. (Brockware)
268 George St. Birmingham Michigan 48009 USA
(810) 645-0236 fax/bbs (810) 645-9020 email brockrooney@delphi.com
At 11:12 AM 11/25/95 -0500, gfadel@eng.clemson.edu wrote:
>Lee Humphrey in
>From: Lee_Humphrey@ccmail.orl.mmc.com
>Subject: Attn. Pro/Engineer users!!
>To: rp-ml@cs.hut.fi
>
>wrote:
>>
>> We have recently converted from CATIA to ProE. Normal ProE translations are
>> several levels above the best of CATIA models. I have not had a bad ProE
>> translation in the 6 months since the changeover.
>> There are several things you can do to make the ProE translations better.
First
>> is increase accuracy during setup and also during translation set the chord
>> height to 0. The system then comes back with the minimum chord height
allowable
>> within the accuracy parameter of setup. Also radius chord to 0. Be
prepared
>> for files with many triangles. 50-100k triangles are usual for complex
curved> surfaces
>>
>
>I would like to bring this point up for discussion.
>
>I have seen files with over 100k triangles that were completely useless. The
>STL converter, when setting up the smallest tolerance which is typically
>machine precision, could take a perfectly planar surface and tessellate it
>in many hundreds or thousands of triangles when just a few should have been
>necessary. Machine precision would create holes, disjointed triangles, and
>all the problems associated with such a model. Furthermore, it took too much
>space to store, and an inordinate amount of time to slice.
>
>The user should use common sense and understand what the translator does. Such
>problems occur because of the inadequacy of some translators. A common
>mistake done by many users is to try use the maximum capabilities of the
>software. Double precision is used, minimum chordal tolerance is used
>without too much concern over what happens next with such files.
>
>In some cases, these are the necessary parameters, but must they always be
>the rule?
>
>One solution is to have better STL translators. Another is to get rid of such
>translators and directly slice the CAD model. This would require the RP
>manufacturers to release their proprietory file slice formats, or the CAD
>vendors to write translators to each RP format. A third method would consist
>in deriving from the RP machine parameters the minimum tesselation
>parameters for the models.
>
>Comments? discussion?
>Some of these issues are presented in a paper that will be posted at the
>Internet conference next month.
>
>---
>Georges M. Fadel
>Associate Professor
>Mechanical Engineering Department Tel: (803) 656-5620
>Clemson University Fax: (803) 656-4435
>Clemson SC 29634-0921 USA
>e-mail: gfadel@eng.clemson.edu
>mosaic: http://www.eng.clemson.edu/dmg/people/fadel.html
>
>
>
>
C. Brock Rooney, Pres., Brock Rooney & Associates Inc. (Brockware)
268 George St. Birmingham Michigan 48009 USA
(810) 645-0236 fax/bbs (810) 645-9020 email brockrooney@delphi.com
This archive was generated by hypermail 2.1.2 : Wed Jun 20 2001 - 12:57:29 EEST