A community specification for an improvement to STL files.
This page is for anyone with an interest in the matter to set out a File Format 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.
Is it possible to design the format so that conceptually "small" changes (usually) cause "diff" to detect only "small" changes to the file? Is it possible to give the same original CAD file to two people, let them independently make improvements, and then merge their results together into one version with both improvements? (comments about merging CAD files) In other words, rather than using a "Darwinian evolution" model, is it possible to design the format to support branching and merging ( "bacteria-style evolution" )?
Is it worth trying to specify that some edges are intended to be "sharp" edges, while others are merely approximations to what is intended to be a smooth curve?
If we can specify entire triangles are "entirely smooth" or "entirely sharp" (with edges rendered as sharp only when triangles on both sides are marked sharp), it is not necessary for the file format to allow us to independently specify, for each edge, which edges are sharp and which are smooth. Such a triangle can be stored as 3 smaller co-planar triangles, with the small triangle attached to the sharp edge stored as "entirely sharp" and the small triangles attached to the smooth edges stored as "entirely smooth".
possible ways to meet those criteria
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 T0 would be V1, V2, V3; T1, T2, T3.
The vertex order should be such that the vector product normal points from solid to air.
--Adrianbowyer 10:26, 24 November 2006 (UTC)
- Store the number of vertices and the number of facets
- Store a list of all of the unique vertices (as X,Y,Z triples) at the top of the file.
- 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:
- Only software that cares about edge adjacency need bother to compute that information.
- 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.
- 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)
A set of attributes could/should define the material properties of the model as well as colours. This is central for a future in which RepRap machines will be able to work with many materials and multiple colours. It is up to debate whether it would be a good idea to encode the actual material through a description (metal, ceramic) or if it would be better to define material properties and some ranges. Every RepRap machine would automatically use the material closest to the given properties and, if the RepRap printing the object has no material with the given properties at hand (considering the ranges allowed by the file), will give some sort of warning.
This is a list of important properties:
- Colour: Five components: CMYK + Alpha. This way it should be possible to define all colours and transparency.
- Material/Electrical properties: See this wikipedia site. Not all would need to be supported. In theory all could be added with the extra clause that if a property is not explicitly specified it is not considered by reprap.
As said before, such a file could be partially backwards compatible: even Darwin could print those files, but they would be white instead of coloured.
Is it worth trying to specify that some colored triangles are intended to have crisp transitions exactly at the edge to the color of the next triangle, while other triangles are merely approximations to a desired gradual gradient of color?
- Is there any significant difference in the above proposal and the Wikipedia: Additive Manufacturing File Format?
- Is there any significant difference in the above proposal and the Wikipedia: 3D Manufacturing Format? (See also "New 3MF file format").
- DRY SPOT: Wiki:DontRepeatYourself (aka Wiki:SinglePointOfTruth)
- "The STL 2.0 group is an ASTM-driven consortium interested in defining a new Additive-Manufacturing file format. The new format is to replace the current de-facto standard STL file format. This email group is open to anyone interested in shaping this specification." http://groups.google.com/group/stl2
- Wikipedia:STEP-NC: "STEP-NC was designed to replace ... G-codes ... adding tolerance data ... [with a] XML format."
- Can any standard Wikipedia: vector graphics markup language be used to replace STL? Perhaps with some minor tweaking?
A few people have developed software that completely bypasses STL files:
- Sylvain Lefebvre. "ICESL: A GPU accelerated CSG modeler and slicer". It directly slices and converts a constructive solid geometry (CSG) file to G-code, skipping the STL triangular mesh generation step entirely.
- Firmware/Alternative mentions converting 3D objects to one of several 2D formats (PostScript, splines, etc.), then converting directly from that format to "step, direction" pulses, bypassing STL files or G-code or both.