STL file format / Good files?!

From: Chuck Kirschman (Clemson University)
Date: Wednesday, September 28, 1994

From: Chuck Kirschman (Clemson  University)
To: RP-ML
Date: Wednesday, September 28, 1994
Subject: STL file format / Good files?!
> From: newton@rrm.org (Dick Newton - Ford)
> >From: ckirsch@eng.clemson.edu (Chuck Kirschman)
> >Another problem with the STL format is that it does not specify what
> 
> Not everyone agrees on this. Helisys and Imageware will not handle 
> concatentated STL files. Packages such as 3D systems View and partman
> and Solid Concepts STLTRANS will destroy this extra header information if
> you read the file in, manipulate the file, and write it out.  
> 

I think this is where somebody has to step in and ask them to preserve
the string.  One of the problems here is that there is no "governing
body" to try to nail down what is right and wrong.  At the time of
slicing, all of the vendors should have the right to do what they want,
since everything downstream is proprietary.  But, everyone above this
who is manipulating an STL file should be forced to handle things in a 
consistant manner.  I wish I knew how to implement this...

I don't understand why Helisys and Imageware can't handle a concat
STL - what is the problem?  Is it both in ASCII and Bin?


> >One other thing to think about is that there are typically one half as
> >many point as facets, so each point is listed in the file multiple times.
> >Several smaller files based on meshing have been proposed, and I'd like
> >to see one of them come into use.
> 
> I agree. A format like wavefront's object format would more space efficient.
> A list of point coordinates at the start of the file, followed by a list 
> of triangles (or polygons) that reference those points. It might also have
> the benefit of making software vendors check to see if their stl files
> are well connected. 
> 

This is the type of format I would like.  I've written several STL I/O
as well as SLI and V I/O routines and that is a much more convenient format.
Not only does it save disk space, it also reduces the amount of memory 
needed to store the file and the processing time to calculate this
information.  

> What is the purpose of the normals? The normal information is
> redundant. Why not base the normal on the order of the facets in the
> triangle? All it takes is a dot product to calculate it. (BTW, Helisys
> pretty much totally ignores the normal information, and running a file
> thru their software will totally mess up the normals and makes the file
> unusable on other (ie SLA, DTM) machines).
> 

The normals are redundant information.  The specification says that
the triangles must follow the right-hand rule, and a simple cross
product calculates the normal from there.  They should be trashed from
the file.

However, the treatment differs.  3D assumes the normals are correct.
I always assume they are wrong and completely recalculate them every
read.  This gets into problems with "flipped" triangles, those which
do not follow the right-hand rule.  It is not difficult to ensure
consistant direction for all facets, but it often is not done by the
CAD package.

> Also, what is the purpose of the two bytes of pad on the end of the
> triangles?  Is this wasted space? It makes every other triangle
> un-aligned on 32 bit machines that require 4 byte boundry alignment
> on structures. 

And appendix, I think...

> 
> Why do CAD vendors output files that are not well connected, (ie
> each triangle shares all its edges with other triangles and each edge
> is only connected to one other edge)? A closed volume that meets these
> connectivity requirements MUST have an EVEN number of triangular
> facets. Why do I see stl files that the CAD vendors insist are "good"
> with ODD numbers of facets?

Absolutely!  Some CAD packages always produce excellent parts - I have
never received a bad ProE file (your milage may vary).  Aries is also
good.  On the flip side is Autocad 12, which produces holes, midlines,
flipped triangles, and operator misery.  What have y'all found in CAD
packages?  Who is "making it"?  This question is a bit cloudy since the
SLA can build a bad STL.  For instance, the "stitchers", those packages 
like Unigraphics that are surface modellers stitched together, often do
not close.  The imporvements in recent years has been to make sure the
stiches overshoot, that is become extra walls inside the part rather than 
holes.  This may build correctly, but it may not.

Other problems include midline nodes, line facets and collpsed facets.
Collapsed facets have one edge smaller than the resolution of the
machine, even though the spec claims 0.00028 inch as a minimum.  Line
facets have the third vertex exactly on the line between the first
and second vertices.  This is no information.  Midline nodes are where
the vertex-vertex rule is broken.

> 
> The STL file format does work but it does have it's problems. Maybe this
> forum could work to clarify and document some of these inconsistencies. 
> 
> Dick Newton
> 

Okay, so we have a forum.  Elaine Persall (persall@eng.clemson.edu) has
already told me that the STL format should become part of our mosaic
site, so that's on the way unless someone beats us to it.  How
about we add to it a new format that suits the needs of the community
as a drop-in replacement for STL?  If there is enough interest, I
can probably hack together a translator to and from the new format to
the STL format and make that available, too.

So, let's hear it - what are the best of the ideas?  What should / should
not be in the files?  What platforms need to be supported?

chuck


Previous message | Next message
Back to 1994 index