Re: STL file format

From: Michael Brindley
To: Chuck Kirschman (Clemson  University)
Cc: RP-ML
Date: Wednesday, September 28, 1994
Subject: Re: STL file format 
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.

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.

> 
> 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.

   --> Mike Brindley