Why STL format is BAD

If you have ever played with a 3D printer, you have probably heard of, used or created a few STL files. Roughly speaking, these are files used to encode 3D shapes. The acronym “STL” stands for STereoLithography. It was created by 3D Systems back in 1989 for their CAD software [1]. Today, it is one of the most popular input formats to 3D printers and sometimes the only format accepted. Despite its success, the 26 years old format is actually poorly designed (by today’s standard) and it starts to become a bottle neck that severely limits the rapid development of 3D printing technologies.

Problem 1: STL format stores (a lot of) redundant information.

Perhaps the easiest way of illustrating this problem is through an example. Here is a comparison table for the disk space needed to represent the same shape (~63,000 faces) in some common 3D formats:

PLY (binary): 1.1M
X3DB (binary): 1.3M
OBJ (ascii): 2M
OFF (ascii): 2M
PLY (ascii): 2M
X3D (ascii): 2.1M
VRML (ascii): 2.7M
STL (binary): 3M
STL (ascii): 11M

As one can see, STL formats, both ascii and binary versions, are the worst format to encode 3D geometries. The ineffective use of disk space will only be exacerbated for more complex input shapes.

Problem 2: STL format is slow to process.

One would assume, given the amount of space it occupies, that STL files must contain all the essential information necessary for efficiently processing the encoded shape. Unfortunately, this cannot be further from the truth. STL format actually stores less information than other file formats despite using more space.

One of the essential information missing is the connectivity of the geometry primitives (i.e. which triangles are connected to a given triangle or vertex). Without connectivity, the geometry encoded is essentially a bunch of triangles floating in 3D space (which is known as “triangle soup” in computer graphics community). Common tasks such as checking if the geometry represents a solid 3D volume cannot be carried out robustly without correct connectivity information. Thus, attempting to recover (guess) the connectivity is typically the first thing any 3D software does after loading a STL file. This step is tedious, error prone and often slow.

Problem 3: STL format is very rigid.

Besides basic geometric information, a good format would allow its user to optionally include additional information such as face normal, vertex normal, colors, textures, etc. In contrast, STL format encodes triangles with normals. That is it. Nothing more and nothing less. One cannot add additional information and one must, and I repeat, must specify face normals. A common practice is to specify 3 zeros as face normal for every face where normal information is not available, which adds more useless information to the already bloated file.

Summary

I hope the drawbacks listed above is enough to convince you that STL format is a very ineffective and inefficient way of encoding 3D geometry. The 26 years old format should have retired long ago. Unfortunately, with the revived interest in 3D printing, this format is gaining popularity again. As the de facto file format for 3D printing, STL format, in my opinion, is becoming the bottleneck that deters better processing of 3D shapes and efficient allocation of computing resources. The next time when you are submitting a shape to be printed, I urge you to consider other formats.