RE: vmrl, stl size, speed etc.

Date: Tue Jan 09 1996 - 04:02:25 EET

-- [ From: Al Hastbacka * EMC.Ver #2.10P ] --

I really appreciated your effort in explaining the
advantages/disadvantages of VRML and STL. We see enough crappy files
to fill a warehouse full of models without being inundated with lots of
VRML models that can't hold water.

  Many people seem to forget that a VRML visual displayed via most
display techniques has a resolution of 30 mils at best. A visual model
that appears closed at 30 mils may have gaping holes when made in an RP
machine that has a resolution that is at least 10 times better than

Al Hastbacka
-------- REPLY, Original message follows --------

> Date: Monday, 08-Jan-96 06:46 PM
> From: Brock Rooney \ Internet: (
> To: Al Hastbacka \ PRODIGY: (KHVD07A)
> Subject: RE: vmrl, stl size, speed etc.
> As has been noted, when comparing files sizes, you should compare
> Binary STL files. ASCII STL format is for testing and debugging. It
> verbose. Real, production STL files are binary. It is much easier
> faster to read and write Binary STL files. 50 bytes per triangle;
> ASCII STL files must be parsed, which is more complicated and error
> I am always looking at new formats to support. I have added VRML
> It was an easy thing to do, because we already support Cubital CFL
> which is also a point list + connections format. If VMRL viewers
> and remain free, VMRL may be useful for Viewing STL files. (More
> To help you all get a handle on the size issues, I ran some tests on
> 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
> 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
> 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
> 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
> Note that cutting the Chord Height Tolerance in half increased the
> 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
> than STL, and is more compact. Usually the size will be 30-50% of
> (real, binary) STL file. Here it is 40% of the STL size, and is
> than any of the alternatives.
> sth2stl is a free program (with source) we provide with .sth
> as an example. It uses standard C file i/o and fprintf. As a result
> 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
> 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
> Output from other programs may produce larger files.
> Note than the largest compressed file (ASCII STL) is only 3 times the
> 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
> 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
> be 3/4 the size of a binary STL file. The example is in the right
> 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
> VMRL file: File whose contents meets the requirements of the VMRL
> The issue is not size, or speed, or ease of programming. The issue is
> 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
> 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)
> will get some perfectly valid VMRL files which are totally unsuitable
> this application. The triangles might not match. There might not
even Be
> any triangles. When you report back that the file is unusable, the
> will (with some justification) say "Wadaya mean the file is no good!
> said you could accept VMRL, and my file is a perfectly valid VMRL
> The software generating these files should be designed with the use
> mind. The optimium tesselation for Rendering is different than the
> tesselation for RP. A good VMRL generation program will generate
> with good tesselation for rendering. A good STL generation program
> generate good tesselation for RP.
> An STL file Always makes a valid VMRL file. A VMRL file May (but
> 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
> 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
> 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,
> is 10 to 20 Times faster. This is why the curves on the CAD display
> 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
> (the fast ones) work off of the faceted representation. This is why
> NC programming systems can accept STL files as input. You may notice
> similarity between Straight-Line NC toolpath generation and RP
> 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
> acceptable results.
> As I have mentiond previously, there ae other reasons besides
> to use the faceted model. In a BREP solid or surface model, the
> 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
> 2) Modifications: Approximations of approximations of approximations
> leads to garbage.
> So the Engineering Design Marketplace has found Precise BREP modelers
> useful, with Faceted output produced as needed for other
> Lastly, STL is a CAD Outout format, not a CAD Exchange format. It is
> 3D Plot file. It is no more appropriate to use STL to move between
> 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

-------- REPLY, End of original message --------

This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:37:05 EEST