Re: STL file format

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

From: Chuck Kirschman (Clemson  University)
To: Michael Brindley
Cc: RP-ML, Georges Fadel (Clemson  University)
Date: Wednesday, September 28, 1994
Subject: Re: STL file format
> 
> Chuck Kirschman writes:
> > 3 is not true.  The SLA requires that the part be in positive CAD space,
> > but the file doesn't care.  You get an entire float to do with as you
> 
> The file doesn't care about the part being in the first octant.  The
> official spec says that it must be in the first octant.  Thus, any
> file containing an object with a zero or negative coord does not 
> follow the spec.  Any software reading such a file is therefor
> quite within its rights to reject the file as invalid - possibly
> damaged or to act in some odd fashion (the old GIGO principle).

Your right - there it is on Page 21.  However, most CAD packages don't
enforce this, Autocad being one exception.  Further, most of us who read
in STL's try not to limit ourselves.
  
> 
> > wish, and you can have the part completely in negative space.  The reason
> > for the requirement for the SLA is that multiple parts need to be built
> > in relative proximity to each other, so the machine cannot arbitrarily
> > move them into the positive space.  And the positive space is required
> 
> The machine does not arbitrarily move them; the people have to create
> STL files that have the various parts positioned in space relative 
> to one another to properly fill up the build volume with multiple objects.
> As long as the parts are positioned with in a region of space which
> fits inside the build volume of the machine, why would the contoller
> software care that the objects are in a certain exact spot?  It is
> trivial for the software to move all those objects to the desired
> location for building (maintaining the positions of the objects
> relative to each other).

This goes back to the multiple STL file question.  The SLA can work
with many (well, 11) different STL's, including parts and supports
which are independantly sliced.  So, if the slicing algorithm moved
them to positive space, the result would be offset parts.  If the
sliced files are _not_ moved to positive space, then they would have
to use _signed_ shorts to hold them, effectively halving the resolution
grid.  Of course, the correct thing is to move them and store the
offsets in the SLI file for the merger program to use.  I don't know 
why they haven't.

> 
> > Another problem with the STL format is that it does not specify what
> > happens when multiple objects are containted in the same file.  Luckily,
> > the defacto use is that there is a comment at every object start, and
> > almost everyone seems to agree on this.  This makes it possible to 
> > simply concatenate multiple STL files.
> 
> Interesting ... a defacto extension to the STL file format.
> 
> > 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 haven't seen those other file formats.  Do you have any 
> references?  The only one I've seen discussed is Rock and Wozny's
> RPI format which is exceeding complex.  I could waste many electrons
> typing about what is wrong with the STL file format!  I have my own
> ideas about what would make a good format.

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.  

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.

chuck


Previous message | Next message
Back to 1994 index