Re: stl's and such

From: Michael Brindley
To: Elaine Hunt (Clemson  University)
Cc: RP-ML
Date: Monday, September 26, 1994
Subject: Re: stl's and such 
> >>>2 is noteworthy.  I believe that we (the RP community) should take
> >>>advantage of the 80 characters of header information to state this
> >>>and other information, such as if it is a non-closed solid (support),
> >>>which CAD pkg, and so on.

I am leary of doing this.  It is not 80 characters of header information - 
it is a comment.  It is for people to read, not machines.  A better way
to address some of these issues would be to create a new file format.

> >>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.
> >
> Good idea.. Anybody using it?????

I got upset enough with STL files one day that I sketched out a basic
format which used the list of vertices followed by the faces referencing
the vertex list.  This idea was common practice even in the mid 80's
when 3D systems was developing the STL file format, but they chose to
ignore it.

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

Any software which wants to be somewhat portable has to have provisions
for the egg-sucking problem (converting between big and little endian
machines).  So, it won't be reading the data directly into structures;
it will be doing plenty of byte accesses.  This removes alignment
as a significant concern.  Besides, the reading in of the file is
the smallest part of the work; recreating the topology/geometry
and the rest of the processing takes much more time.

> 
> YES   maybe the nap is over and we can find meaning for our existence.....
> 
> Elaine

Just who are you saying was asleep? :) :) :)

  --> Mike Brindley