Re: [rp-ml] STL files

From: C. Brock Rooney <brock_at_mich.com>
Date: Wed Dec 06 2006 - 21:06:57 EET

Hi all. It has been a while since I've posted to rpml. But now my kids
are all in school and I have time to respond to one of my favorite topics.
As has been pointed out, the STL spec requires closed volume(s), with edges
and vertices that match exactly. A valid stl file does not have gaps.

One thing that I have not seen in this STL go-round is this: The STL spec
also says the ASCII form is for testing and debugging only. It still amazes
me that people would support the ASCII form, since it is much harder to code
and slower to process than the binary form.

Since the computer never forgets, I have included below a couple of my
postings to rpml from years gone by. Comments about VRML also mostly apply
to PLY:

>Date: Mon, 08 Jan 1996 19:47:57 +0000
>To: rp
>From: BROCK ROONEY <brockrooney@
>Subject: RE: vmrl, stl size, speed etc.
>
>As has been noted, when comparing files sizes, you should compare with
>Binary STL files. ASCII STL format is for testing and debugging. It is
>verbose. Real, production STL files are binary. It is much easier and
>faster to read and write Binary STL files. 50 bytes per triangle; done.
>ASCII STL files must be parsed, which is more complicated and error prone.
>
>I am always looking at new formats to support. I have added VRML output.
>It was an easy thing to do, because we already support Cubital CFL format,
>which is also a point list + connections format. If VMRL viewers improve
>and remain free, VMRL may be useful for Viewing STL files. (More below)
>
>To help you all get a handle on the size issues, I ran some tests on an
>IGES file that was passing through. In Summary:
>
>Source File Time Size (g)Zip Comment
>Program Type Min:Sec MB MB
>
>Pro Engineer IGES --- 15.7 3.70 1424 Trimmed Surfaces
>Cad File Binary 3.2-10 1.5-5 Approx: Depending on Cad system
>
> The IGES file was used to generate the BR&A .sth triangle file:
>
>BR&A IGtoSTH .sth 5:29 1.12 0.45 51478 Tri; CHTol .06MM (.0024 in)
>BR&A IGtoSTH .sth 6:00 1.62 0.68 81704 Tri; CHTol .03MM (.0012 in)
>
> The .03MM Chord Hgt .sth (81704 triangles) generated the following:
>
>BR&A sth2stl .stl 1:42 13.6 2.14 ASCII STL (sth2stl -a)
>BR&A STtoSTL .stl 0:08 4.09 1.78 Binary STL
>BR&A STtoCFL .cfl 0:24 3.75 1.19 ASCII Cubital CFL
>BR&A STtoWRL .wrl 0:21 2.81 0.93 ASCII VRML
>
>The times are from a low-end HP workstation. For reference, on a 486
>the time required would be 50% more; Pentium 50% less.
>
>The IGES file is for a real part. The part size: 11.2 x .8 x 4.8 Inches.
>This file is fairly typical of the files I see. The file size is just a
>little larger then average. (No one cares how long the small ones take.)
>
>Note that cutting the Chord Height Tolerance in half increased the
>number of triangles by 59%, the .sth file size by 45%, and time by 9%.
>
>STH format is BR&A's own triangle format. It contains more information
>than STL, and is more compact. Usually the size will be 30-50% of the
>(real, binary) STL file. Here it is 40% of the STL size, and is smaller
>than any of the alternatives.
>
>sth2stl is a free program (with source) we provide with .sth documentation
>as an example. It uses standard C file i/o and fprintf. As a result it
>is much slower in creating ASCII output than STtoXXX. But the time is
>probably representative of other ASCII STL output programs.
>
>STtoXXX is part of our STL generation package, and includes the usual
>performance tricks, so it is faster than sth2stl -a. STtoXXX accepts
>.sth or .stl files, and translates, rotates, scales, clips, calculates
>the volume and surface area, and outputs stl, cfl, or wrl files.
>
>The ASCII stl, cfl, and wrl files are within 5% of the smallest possible.
>Output from other programs may produce larger files.
>
>Note than the largest compressed file (ASCII STL) is only 3 times the
>size of the smallest (STH). (You DO compress your files for transfer
>and archiving don't you?) Not exactly earth shaking.
>
>A Point-List + Connection format with multiple large point/connection lists
>and with duplicate points removed and no normal storage, should be
>1/4 the size of the equivalent STL file. But ASCII files are usually
>about 3 times the size of binary. So a well done ASCII VMRL file should
>be 3/4 the size of a binary STL file. The example is in the right range.
>
>STtoCFL, STtoWRL sorts the point lists. This results in a more compressable
>file. A sorted STL file would compress more.
>
>
>On why VMRL is not a good replacement for STL:
>Definitions:
>STL file: File whose contents meets the requirements of the STL spec.
>VMRL file: File whose contents meets the requirements of the VMRL spec.
>
>The issue is not size, or speed, or ease of programming. The issue is
>the suitability of the file contents.
>
>If you get a file with the .stl extention that contains (for example)
unmatched
>triangle edges, it is NOT an STL file (see Definitions). You can then then
tell
>whoever sent it to stop sending you garbage, send a (valid) STL file. Or you
>can charge to fix it. Or you can mutter to yourself and look for a Real job.
>
>If you claim to accept VRML files (or other rendering type formats) you
>will get some perfectly valid VMRL files which are totally unsuitable for
>this application. The triangles might not match. There might not even Be
>any triangles. When you report back that the file is unusable, the source
>will (with some justification) say "Wadaya mean the file is no good! You said
>you could accept VMRL, and my file is a perfectly valid VMRL file."
>
>The software generating these files should be designed with the use in mind.
>The optimium tesselation for Rendering is different than the optimum
>tesselation for RP. A good VMRL generation program will generate files
>with good tesselation for rendering. A good STL generation program
>will generate good tesselation for RP.
>
>An STL file Always makes a valid VMRL file. A VMRL file May (but probably
>does not) make a valid STL file.
>
>On using VMRL views to view RP data:
>The VMRL viewers I have examined are oriented toward moving an Observer
>through a Scene. That is, like a video game. They lack CAD type functions
>like ZOOM WINDOW. This could be fixed however.
>
>The units in VMRL are Meters, which is appropropriate for the Architectural
>scale of the intended use. The viewers found our stuff too small, and so
>I had to fake them out by using millimeters as meters.
>
>Some worked on small files, but choked on the 80000 triangles.
>
>
>On Facets and the Performance of Slicing:
>
>Working with a faceted representation is not 10 to 20 Percent faster, it
>is 10 to 20 Times faster. This is why the curves on the CAD display
>and on the Plot are drawn with little straight lines. And why the shaded
>images are rendered using facets. And why 3-Axis NC toolpaths are
>composed of little straight moves. Many NC toolpath generation
>systems (the fast ones) work off of the faceted representation. This is
>why some NC programming systems can accept STL files as input. You may
>notice some similarity between Straight-Line NC toolpath generation and
>RP slicing.
>
>The trick is to keep the facet error small compared to other errors.
>Usually a Chord Height Tolerance of 1/4 the slice thickness will produce
>acceptable results.
>
>As I have mentiond previously, there ae other reasons besides performance
>to use the faceted model. In a BREP solid or surface model, the Surface
>is exact, but the Boundary is approximate. In a faceted model, the Surface
>is approximate, but the Boundary is exact.
>
>The problem with faceted models:
>1) Different applications need different facets: Rendering vs Rp vs NC.
>2) Modifications: Approximations of approximations of approximations
> leads to garbage.
>So the Engineering Design Marketplace has found Precise BREP modelers more
>useful, with Faceted output produced as needed for other aplpications.
>
>Lastly, STL is a CAD Output format, not a CAD Exchange format. It is a
>3D Plot file. It is no more appropriate to use STL to move between 3D CAD
>systems than it is to use HPGL between 2D CAD systems.
>
>Whew, I guess that will do for a while.

And this:
>Date: Wed, 10 Jan 1996 18:10:58 +0000
>To: rp
>From: BROCK ROONEY <brockrooney@
>Subject: Re: VRML, STL and other animals
>
>Regarding the "Legal STL File" comments of Yuval Roth of Imageware:
>
>The STL file specification is not just about file Structure, it also
>about file Content. Content that is appropriate and necessary for
>this application. It is the Content that makes the RP process work.
>
>Legal STL files make it possible to guarantee that, no matter
>how you slice it, you Always get Exactly Closed slice boundaries.
>This makes it possible to automate the slicing process, which in
>turn makes this industry possible.
>
>Legal STL files are Not rare. Many software companies have invested
>the Time, Talent, and Treasure necessary to create software capable
>of valid STL output.
>
>Unfortunately, there are also software companies who have Not made
>the necessary investments, but simply dump a bunch of triangles
>in a file and claim the file meets the STL specification, when in
>fact it does NOT.
>
>Perhaps we need a new format, call it SRT (Stupid Random Triangles).
>Or we could use an existing rendering format like VRML. Then software
>not capable of correct STL output could write to this format.
>This could be added to the software documentation:
>" Our SRT output requires additional processing to convert to STL
> for Rapid Prototyping use. Many of the STL fixer programs available
> can convert SRT to STL automatically. In more advanced cases, all
> you need is one of the popular Interactive Triangle Editors. You
> will need just an hour or two to select the desired SRT triangles
> and output a valid STL file."
>
>As Manufacturing Professionals, the participants in this mailing
>list know better than most the importance of meeting specifications.
>
>If you buy software that claims STL output, you have the Right to
>expect that it actually does so.
>
>Yes, sometimes in life you are forced to eat garbage. But you should
>know it is garbage you are eating. Demand better.
>
And this:

>Date: 03:42 PM 12/21/99 -0500
>To: rpml
>From: "C. Brock Rooney" <brock@mich.com>
>Subject: Re: STL for ever?
>
>My contribution to the annual STL replacement discussion:
>
>GAPS etc: This is the fault of the software creating the stl file, or the
>design of the model, not the STL specification. Files that meet the STL
>spec do not have gaps. Changing the Spec will not improve things. It is
>the implementation, not the specification, that is the problem.
>
>Single precision: For a model with x,y, and z within 1000 mm of 0, the
>positional error caused by rounding double precision locations to single
>is less than +/-0.00003 mm in x,y, or z. I think it will be a while before
>this becomes a problem. Single precision does not contribute to mismatched
>verticies. If two verticies match exactly, like they should, they will match
>exactly regardless of the precision used.
>
>Using IGES/STEP/VRML etc: Any valid STL file can be converted to these
>formats. But the Reverse is NOT true. The STL Spec requires that triangle
>verticies match exactly for exact closure. The other formats do not. Also,
>these other formats can contain info which is totally useless for RP. Say
>someone has a contract to supply you with an STL file. If the file has gaps,
>the file does not meet the Spec, and the contract has not been fulfilled.
>If you specify IGES or STEP brep info, the file WILL have gaps, and
>acceptability is a matter of interpretation. If you specify facet data,
>like vrml, the file Could have gaps. You could write a page or two of
>additional
>specs on the exact subset of facet files that are acceptable. Purchasing
>would Love that!
>
>STL Verification: This is not hard and need not take long. Many products
>are available to do this. One of the utilities that comes with our IGES to
>STL package (trtostl) verifies the triangle matching as part of the
>processing. The time to read a 160,000 triangle (8MB) file, merge the
>verticies and verify the edge matching, and write the file back to disk is
>less than one minute.
>
>FILE SIZE: The size savings from moving to a Point list+connection format
>is being overstated. The number of Points in a triangulated model is about
>1/2 the number of Triangles. P=T/2 (Why? 3 ways of looking at it: 1: Each
>point is shared by, on average, 6 triangles; or 2: Add a vertex to an
>existing model by sub-dividing one triangle, which turns into 3, so adding a
>vertex adds two triangles; or 3: See the Euler-Descartes formula
>verticies-edges+faces =2.)
>There are more compact ways than Point-list + Connection-list, but such
>methods are not generally proposed. So:
>To store a list of Triangles, you need 9*T*F bytes, where F is bytes per
>float. To store in the form of Points + connections, you need 3*T/2*F +
>3*T*I, where I is bytes per connection. For Binary files, using 4 byte
>values for
>F and I, You get 36*T for Triangles, and 6*T+12*T, or 18*T for Points. Or,
>the Point list method is 1/2 the size. But of course, STL is 50*T (because
>of the normal and attribute count), So the Point method is 36% of the size
>of an STL file. 1/3 the size. Great.
> But most of the proposed formats are ASCII, which are not only slower, but
>larger. For models in the 20,000 to 200,000 triangle range, figure 9 bytes
>per coordinate and 6 bytes per connection for an ASCII file. This gives a
size
>of 3*T/2*9 + 3*T*6 = 31.5*T, or 63% of the STL file size. Is reducing file
>size by 1/3 worth the effort required to define and implement a different
>spec?
>

C. Brock Rooney (President) Brock Rooney & Associates Inc.
915 Westwood, Birmingham, MI 48009 USA
(248) 645-0236 Fax (248) 645-9020 Email: brock@mich.com
Received on Wed Dec 06 20:06:46 2006

This archive was generated by hypermail 2.1.8 : Tue Jul 21 2009 - 10:27:52 EEST