This document has a more accessible location, here:
http://nickporcino.com/posts/last_mile_interchange.html
I'll maintain a copy here too, this is a nice place to support discussion.
This document discusses a taxonomy of 3d file formats based on the intent of the format. It groups them broadly into file formats matched to delivery and transmission operations, and file formats intended to exchange asset structure and artist intent between content creation applications.
This document does not attempt to compare explicit feature sets, performance and efficiency, or adoption, unless it is to illustrate a point.
Disclosure: These notes are biased by the fact that I wrote a great deal of production 3d interchange code for LucasArts, ILM, and Apple, and was lead on Apple's ModelIO which handles the OS level treatment of 3d file formats. I worked with some of the gltf architects and debated issues with them, and worked with Pixar for several years to help get Universal Scene Description shipped.
I hope you find these notes somehow useful.
An interchange format is characterized by an expectation that asset structure, and artist choice points, including overrides and variations, are preserved wherever the asset is imported, and that the straight import/export of the data is round trip loss-less.
A last mile format has imposed an opinion on the contents of the input data and conformed it to that opinion. The complexity of the original asset, including raw scans and artist choice points, has been flattened away, or completely deleted. Characteristically however, a last mile format is ideal for a particular process or step in a production pipeline.
I will say up front that there are no pure interchange formats, although there are many pure last-mile formats.
gltf and fbx are last-mile formats.
gltf has elided structure and choice points in order to prepare buffer data ideal for the most common class of shader programs which render a model. It contains other data commonly required by real time previewers and game engines.
The 1.0 version of gltf specifically encapsulates WebGL objects for the Web. It is not forward looking in the sense that if a new paradigm arrives, such as WebVulkan, gltf will surely be displayable, but it will be via translation of WebGL concepts to WebVulkan concepts.
The 2.0 version of gltf moves beyond that, providing an API-neutral runtime asset delivery format. It still retains some of its WebGL heritage, but more broadly encodes information required by previewers and game engines, such as a material encoding scheme incorporating a phyical shading model that meets modern requirements in being, roughly speaking, a hybrid of the Disney and Unreal PBR shading models.
Autodesk's fbx format seems like it might be an interchange format, but is in fact a last mile format. It takes complex asset structure and choice points, and reduces it to the strict subset of functionality supported by Motion Builder. It only feels like an interchange format because of the deceptive complexity of the format. Nonetheless, the correct use of an fbx file is Maya -> fbx -> { Motion Builder, Unreal, etc. } A backwards workflow from an endpoint such as Motion Builder through fbx will typically be used to bring animation data back to a content creation tool, but will not be used for purposes such as geometry edits.
It's important to recognize that fbx is a proprietary, closed format. Third party reverse engineered parsers exist, but this is not a robust path.
Alembic is also on the last mile side of the balance. Although it can interchange geometry data and scene structure, in general, it is commonly used as a cached format holding the outputs of a simulation. In that sense Alembic holds an opinionated rendering of a simulation sampled over time. It is much more general than gltf and fbx in that it is schema based and can be easily extended. Layering is currently being introduced to move alembic more to the interchange side of the scale, but it's not clear to me how to move forward on missing core semantics necessary for important asset types such as characters; there is no standardized schema for skeletal bindings or blend shapes.
USD is last mile as well, but its last mile is complex enough that it can be coerced into general interchange. What I mean by that, is that USD encodes a full scenegraph with the same complexity and expressiveness of the Maya or Houdini hypergraphs, including the equivalent of a full scene composition algebra, as is implemented by tools such as Unreal, or Katana. Where USD diverges from the Houdini or Maya hypergraphs is that USD does not encode the dataflow graph of Maya, or the operator graph of Houdini. That is what biases USD to interchange rather than last mile, as a strict encoding of an operator graph would be a fully implemented and opinionated end point and would require that users of USD conform to that computational model.
Unlike Alembic, USD supports character models as first class citizens. Unlike gltf, USD supports shader graphs, and is a strict superset of graphs such as Unreal's, gltf's, or that of MaterialX.
Collada is an XML based interchange format. It has an expressive structure, and data contents which much be heavily transformed to suit one engine or another. Collada has strongly specified types, but suffers from under-specified structure, resulting in inconsistent results when moving a Collada file from application to application. For this reason, Collada works best when going through a matched import/export pair.
Apple's SceneKit is a prominent Collada consumer.
These file types are historical and were developed to address interchange and last mile issues simultaneously. They are largely ad hoc and underspecified. Even ply which is highly specified is underspecified in that it defines a general schema but specifies only limited semantics.
A very incomplete list, doesn't include antique formats.
gltf 1.0 - Blender, online fbx converter
gltf 2.0 - Wide availability of import; many exporters arriving.
fbx - just about everything. Autodesk has moved fbx to maintenance mode; not a forward looking option.
alembic - all high end DCC's, blender coming online slowly all Apple apps, including Preview and Quicklook
Collada - plug ins or native support available for all high end DCC's, quality and format consistency varies
usd - Pixar supplies plugins for Maya, Houdini, Katana. Sketchup, Modo and many others are independently available. all Apple apps, including Preview and Quicklook
A very incomplete list, doesn't include antique formats.
gltf 1.0 - web viewers, limited native support
gltf 2.0 - ubiquitous import for game engines is arriving.
fbx - Unity, Unreal, most hobby engines
alembic - Unity, Unreal plugins exist, CryEngine, Apple runtimes
Collada - Apple runtimes, Unity and Unreal via plugins
usd - Import shipped native with Unreal, a full C# binding is available for Unity. Apple runtimes.