Very interesting discussion. I don’t like STL file format either and very surprised that is is still so widely used. However, I find most consumer/gaming mesh formats about equally bad for medical image computing. Yes, STL is the most basic format, and yes, OBJ is better in a couple of things (it supports polygon cells, surface normals, textures), but it has some disadvantages, too, even compared to STL.
Some of the problems with OBJ:
- it is not possible to specify unit (mm/inches/m) or coordinate system (LPS/RAS/…) in a standard way (same as STL)
- no way to store arbitrary metadata (same as STL)
- it is ASCII only, so files are larger and/or lose precision and much slower to parse than binary STL (worse than STL)
- we cannot claim to be fully compatible with OBJ, as it has some features that would be very difficult to fully support, such as NURBS curves and surfaces, or multi-texture (worse than STL)
VTK clean polydata filter can merge coincident points and compute surface normals in negligible time, so computation time should not be an issue.
We’ve been planning to add an optional normal computation step into the model display pipeline. This could be enabled by default for STL files or for any other surface mesh files that did not happen to have the normals available.
Standard OBJ format is text only, so file sizes are larger than binary STL.
Adding “deprecated” there sounds too harsh to me (and as @pieper pointed out not even accurate). But even if we could find a better word: I would not single out STL as the bad guy. Is PLY any better? Would you always recommend OBJ over STL? We should probably just try to educate users on the forum, documentation, etc. where there is a room for explaining our rationale for preferring one file format over another.