Re: Attn. Pro/Engineer users!! Attn. Pro/Engineer users!!

From: BROCK ROONEY (brockrooney@delphi.com)
Date: Fri Dec 01 1995 - 02:26:59 EET


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