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 Outout 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.
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 : Tue Jun 05 2001 - 22:37:05 EEST