-- [ 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
this.
Al Hastbacka
-------- REPLY, Original message follows --------
> Date: Monday, 08-Jan-96 06:46 PM
>
> From: Brock Rooney \ Internet: (brockrooney@delphi.com)
> To: Al Hastbacka \ PRODIGY: (KHVD07A)
>
> 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 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
>
>
>
-------- REPLY, End of original message --------
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:37:05 EEST