Re: STL file format

From: Chuck Kirschman (Clemson  University)
To: RP-ML
Date: Sunday, October 2, 1994
Subject: Re: STL file format
> From brindley@ECE.ORST.EDU Thu Sep 29 01:48:53 1994
> Chuck Kirschman writes: 
> > I'd love to see your format.  I have seen Rock's, and I agree, it is 
> > unnecessarily complex.  They want to greatly reduce processing time
> > at the expense of storage.  But calculating all of the information
> > is not that difficult with good alogrithms.  
> i
> I thought that the RPI format was doing just the opposite; by using
> primary representations of the object (CSG, NURBS, etc.) they condensed
> they file while increasing the calculation burden on the RP machine
> software (slicing, etc.) by a few orders of magnitude.  The paper
> makes a big point of how much smaller thier files are.

I can't find it right now - I have a ps version around here somewhere...
As I recall, the big space savings were completely based on ASCII 
representations.  Most of that cound be accounted for by the fact
that they do not use words in the file, such as FACET and VERTEX.  As
I recall it, it was points, edges, and facets, an extra level of 
abstraction not altogether needed, but very convenient for the work
he was doing.

> 
> My format hasn't been used (yet).  All I did was take an STL file
> and reformat it in a "sane" way. (Implying, that STL files are
> insane :) ).  It uses the common practice of unique vertex list
> with the facets referncing into the vertex list.  No normals, of
> course.  Just doing that takes it down to 40% or less than the
> original STL file size.  It is also a tagged data format, taking
> care of the issue of adding multiple objects in a file.  The tagging
> also makes it easily extendable, so in the future it could include
> more complicated things like NURBS and CSG.  Adding support for
> polygonal (planar) faces instead of just triangles is easy and
> I have some notes on it.

This makes a lot of sense

> 
> > 
> > Don't discount Rock's ideas for slicing, though - very fast.  
> > But they do depend on a _good_ STL file, and need some repair
> > functions for todays files.  I'll bring this up in another
> > message so it doesn't dissapear in this thread.
> > 
> 
> I don't discount Rock's slicing ideas - they are nearly identical
> to mine!  I developed the same ideas (independently) as the only
> reasonable approach to slicing.  I was amazed and horrified by
> the descriptions I saw of what 3D Systems was doing to slice files.

Ah, but this makes them more tolerant to "evil" stl files.  Marching
algorithms require good STL files - planar cut algorithms are not
so demanding.  You get most of your file, one way or another.

chuck