Re: [rp-ml] STL files

From: Wesley Brooks <wesbrooks_at_gmail.com>
Date: Wed Dec 06 2006 - 14:02:41 EET

Just to clarify what I ment by the listing of points and IDs to make
triangles;

Here is a simple file format using trangles to make a box:

List of Points:
0.0, 0.0, 0.0
10.0, 0.0, 0.0
10.0, 0.0, 10.0
0.0, 0.0, 10.0
0.0, 10.0, 0.0
10.0, 10.0, 0.0
10.0, 10.0, 10.0
0.0, 10.0, 10.0

List of Triangles: (ID 0 = first point in point list)
0 1 3
1 2 3
1 5 2
5 6 2
5 4 6
4 7 6
4 0 3
0 3 7
1 0 4
4 5 1
2 7 3
6 7 2

...or the STL version:
solid
facet normal 1.000000 0.000000 0.000000
outer loop

vertex 5.000000 5.000000 -5.000000
vertex 5.000000 5.000000 5.000000
vertex 5.000000 -5.000000 -5.000000
endloop

endfacet
facet normal 1.000000 0.000000 0.000000
outer loop

vertex 5.000000 -5.000000 5.000000
vertex 5.000000 -5.000000 -5.000000
vertex 5.000000 5.000000 5.000000
endloop

endfacet
facet normal 0.000000 -1.000000 0.000000
outer loop

vertex 5.000000 -5.000000 -5.000000
vertex 5.000000 -5.000000 5.000000
vertex -5.000000 -5.000000 -5.000000
endloop

endfacet
facet normal 0.000000 -1.000000 0.000000
outer loop

vertex -5.000000 -5.000000 5.000000
vertex -5.000000 -5.000000 -5.000000
vertex 5.000000 -5.000000 5.000000
endloop

endfacet
facet normal -1.000000 0.000000 0.000000
outer loop

vertex -5.000000 -5.000000 -5.000000
vertex -5.000000 -5.000000 5.000000
vertex -5.000000 5.000000 -5.000000
endloop

endfacet
facet normal -1.000000 0.000000 0.000000
outer loop

vertex -5.000000 5.000000 5.000000
vertex -5.000000 5.000000 -5.000000
vertex -5.000000 -5.000000 5.000000
endloop

endfacet
facet normal 0.000000 1.000000 0.000000
outer loop

vertex -5.000000 5.000000 -5.000000
vertex -5.000000 5.000000 5.000000
vertex 5.000000 5.000000 -5.000000
endloop

endfacet
facet normal 0.000000 1.000000 0.000000
outer loop

vertex 5.000000 5.000000 5.000000
vertex 5.000000 5.000000 -5.000000
vertex -5.000000 5.000000 5.000000
endloop

endfacet
facet normal 0.000000 0.000000 -1.000000
outer loop

vertex 5.000000 5.000000 -5.000000
vertex 5.000000 -5.000000 -5.000000
vertex -5.000000 -5.000000 -5.000000
endloop

endfacet
facet normal 0.000000 0.000000 -1.000000
outer loop

vertex -5.000000 -5.000000 -5.000000
vertex -5.000000 5.000000 -5.000000
vertex 5.000000 5.000000 -5.000000
endloop

endfacet
facet normal 0.000000 0.000000 1.000000
outer loop

vertex 5.000000 5.000000 5.000000
vertex -5.000000 -5.000000 5.000000
vertex 5.000000 -5.000000 5.000000
endloop

endfacet
facet normal 0.000000 0.000000 1.000000
outer loop

vertex -5.000000 -5.000000 5.000000
vertex 5.000000 5.000000 5.000000
vertex -5.000000 5.000000 5.000000
endloop

endfacet
endsolid

Cheers,

Wesley Brooks

On 06/12/06, Wesley Brooks <wesbrooks@gmail.com> wrote:
>
> Good morning (here anyhow!) all,
>
> Here's my two pence worth, developed from using RP machines and coding
> software for bespoke applications relating to RP machines.
>
> The structure of the STL file is not great, for example there is not a
> list of shared points and a list of IDs linking the points to make
> triangles.
>
> instead of this in STL files each triangle is separate and further
> opperations (and asumptions) have to be made to figure out which points and
> edges are shared. In addition to single points being listed many times there
> is redundant data in that the order of the points is enough to tell the
> orientation of the triangle, but normals are also needlessly included in the
> file.
>
> Cheers,
>
> Wesley Brooks
>
> On 06/12/06, Delft Spline Systems <info@spline.nl> wrote:
> >
> > Hi to all,
> >
> > As a countermovement to all STL bashing on this list:
> > the STL format is the best CAD data exchange format I have ever worked
> > with (and I am active in the field for over 20 years).
> >
> > Positive points:
> > - all 3D CAD programs can export STL
> > - no incompatible variations do exist (I do not use color). Compare this
> > to DXF, where the specification is changed with every new Autocad release,
> > and to IGES, where every CAD system has its own flavour, often incompatible.
> >
> > - there is no choice in entities (like a sphere being described OR as a
> > center + radius OR as or NURBS surface OR as polygon data OR ...). All
> > geometry is described using the same trangle entity. I think this is in fact
> > the best point of STL.
> > - the specification is so very simple that there is not much room for
> > error (it is also inefficient, however large files are not a large problem).
> > - it allways works, at least for me: our STL processing software does
> > not care about cracks, gaps or orphan surfaces ( www.deskproto.com). I
> > would say that refusing to build is a problem of the RP software, not of the
> > STL data format.
> >
> > The only limitation is that STL can be used for downstream processes
> > only, like RP and rendering. Modelling polygon data is not a good option.
> > Since I am in model building this does not bother me.
> >
> > Best Regards,
> >
> > Lex Lennings.
> >
> > At 20:11 05-12-2006, Adrian Bowyer wrote:
> > >Quoting Todd Pederzani <tpederzani@protocam.com>:
> > >>steve wrote:
> > >>>I strongly urge all software vendors
> > >>>to support (at a minimum) PLY and COLLADA and to try to wean
> > >>>their customers off of STL as fast as they can run away!
> > >>You and I may agree, as programmers, that the STL format has
> > >>shortcomings, but from a user's perspective it "works."
> > >No it doesn't. I've lost count of the number of people coming to me
> > with STL files that simply won't build because they do not obey the Euler
> > formula for a solid.
> > >
> > >> What are the
> > >>"killer app" features of PLY or COLLADA that would motivate vendors to
> > >>implement support for those formats?
> > >That you can check it against the Euler-Poincaré formula - simple (and
> > fundamental) as that.
> >
> > ----------------------------------------------------------------------
> > Delft Spline Systems, The Netherlands.
> > We offer DeskProto: affordable Rapid Prototyping using CNC milling.
> >
> > mailto: info_at_spline.nl --- website: http://www.deskproto.com
> >
> >
> >
>
Received on Wed Dec 06 12:43:12 2006

This archive was generated by hypermail 2.1.8 : Tue Jul 21 2009 - 10:27:52 EEST