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.

Disclosure: These notes are biased by the fact that I wrote a great deal of the production 3d interchange code for LucasArts, ILM, and Apple, and was lead on Apple's ModelIO which handles all 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.

What last mile means is that the formats have imposed an opinion on the contents of the input data and conformed it to that opinion. The richness and complexity of the original asset, including raw scans and artist choice points, have been flattened away at best, and completely deleted at worst. 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, not interchange formats.

gltf has elided structure and choice points in order to prepare OpenGL ready buffer data ideal for the most common class of shader programs which render a model, and incorporates a PBR shading model that is for all intents and purposes a hybrid of the Disney and Unreal PBR shading models.

It's important to recognize that 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.

fbx seems like it might be an interchange format, but in fact, it is 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, Motion Builder -> fbx -> Maya will typically be used to bring animation data back to Maya, 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.

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.

gltf - Blender, online fbx converter

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

usd - Pixar supplies plugins for Maya, Houdini, Katana. Sketchup, Modo and many others are independently available. all Apple apps, including Preview and Quicklook

gltf - web viewers, exporters for Blender exist, many others in various states of development

fbx - Unity, Unreal, most hobby engines

alembic - Unity, Unreal plugins exist, CryEngine

usd - Import shipped native with Unreal, a full C# binding is available for Unity.