A community specification for an improvement to STL files.

This page is for anyone with an interest in the matter to set out a specification that is an improvement on STL files. To get the ball rolling here are my initial ideas:

The file should be XML.

It should record one or more triangulated manifold solids plus extra data.

The primary data structure should be a list of vertices in 3D as triples of double-precision floats, followed by a list of triangles using them as follows: each triangle points to three vertices, and to the three other triangles on the edges opposite those vertices as here (note the relation between vertex number and triangle number in the triangle record):

Thus the record for triangle T₀ would be V₁, V₂, V₃; T₁, T₂, T₃.

The vertex order should be such that the vector product normal points from solid to air.

--Adrianbowyer 10:26, 24 November 2006 (UTC)

Alternatively

1. Store the number of vertices and the number of facets
2. Store a list of all of the unique vertices (as X,Y,Z triples) at the top of the file.
3. Store a list oftriangles as a list of three indices of the vertices in the vertex list.

By all means, use XML to structure the document so that additional fields and properties can be added later without breaking either forwards or backwards compatibility.

eg: For a triangular pyramid (XML tags omitted for clarity):

4 4                     (4 vertices and 4 triangles in this file)
-1.000 -1.000  0.000    (1st vertex)
 1.000 -1.000  0.000    (2nd vertex)
 0.000  1.000  0.000    (3rd vertex)
 0.000  0.000  2.000    (4th vertex)
0 1 2                   (1st triangle)
0 3 1                   (2nd triangle)
1 3 2                   (3rd triangle)
2 3 0                   (4th triangle)

In general, this will also result in a smaller file since vertices typically need to be stored to 8 places of decimals, with a decimal point and a space or a comma to separate the X,Y,Z components. So a vertex is typically 30 characters or more. But the index of a vertex in the list probably only needs 4 or 5 digits. Since there are typically twice as many facets as there are unique vertices in a manifold mesh, storing each vertex only once (rather than maybe 6 times) more than pays for the additional cost of the index value in the triangle description.

Also, effectively storing the topology of the manifold (ie the list of triangle indices) separately from the geometry (ie the actual positions of the vertices) also helps to avoid breaking the topological properties when merely manipulating the geometric size, rotation, etc.

With each triangle identified by the indices of the vertices it's described by, it is very simple for the file loader to generate a list of unique edges as the file is loaded and to associate pointers-to-facets with those edges as the file is loaded. There are many benefits to doing this rather than storing edge adjacency information directly into the file:

1. Only software that cares about edge adjacency need bother to compute that information.
2. It is actually faster to create a list of edges from a short XML file than it is to read that information from the disk drive or over the network and parse it out using an XML parser.
3. There are times when it is desirable to store a file with holes in the manifold in our chosen file format in order that a dumb modelling tool that doesn't know how to fix these kinds of error can export a legal file - and then have some other program fix up the holes later. If the file format is designed around the presumption that there are no holes to start with then that difficult step of checking and fixing holes (and overlaps and other nastinesses) has to be put into every single file 'export' function. Since these sometimes have to be written in Java, sometimes in Python and sometime in C/C++, our development effort in writing exporters would be greatly magnified by our inability to share implementation of that code.

SteveBaker 07:58, 25 November 2006 (UTC)