Introduction ============ 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. Today I work for Pixar, on USD and other technologies. Last-mile vs Interchange ======================== 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. Interchange formats do not allow interchange of application specific data, but may allow the embedding of application specific data so that information such as construction history may be retained when round-tripping from the same application. This facility is outside the scope of the current discussion. 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. "Preservation of artistic choice points" is a key distinguishing point between "interchange" and "last mile". If an artist's work is modified on export to a file format, such that special set ups used to create the model, alternative versions, work in progress elements, and so on are deleted, that's "last mile", because you can't get back to the artist's thought process or to the other possibilities that exist in the alternative versions, optional structures, even notes and annotations that were in the original file. A last mile format by definition therefore, doesn't allow going back to the artist's work in progress. Interchange you can, and clearly there are degrees from file format to file format to which you can actually go back. It isn't a value judgement to describe a file format to last mile or interchange. Rather, the distinction indicates whether an import/export cycle transforms the data. As an example, baking an arbitrary polygon mesh to triangles is a transformation and therefore last mile because it is not reversible. If an export preserves polygon topology, no information is lost, and the polygon mesh is therefore interchanged. In the discussion that follows, one may caveat the assignment of last-mile or interchange to one's own workflow. glTF (last-mile) ---------------- glTF is last mile because it has elided compositional 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 WebGPU, gltf will surely be displayable, but it will be via translation of WebGL concepts to WebGPU 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 physical shading model that meets modern needs for a metallic/dielectric material model. The roadmap for glTF post 2022 involves enhancing functionality of the format with behaviors, such as "show object on hotspot clicked", geospatial anchors, and other enhancements necessary for project metaverse style activities. glTF today commonly serves as an interchange format in circumstances where baking to glTF does not lose data. As an example, a triangle based polygon mesh would not lose information in an export/import cycle. Nonetheless, there is a general, opinionated, transformation of data that occurs on export, a polygon mesh must be triangulated, tangent spaces must be in Mikktspace, vertex weights must sort the largest values into the first four entries, and so on, all of which leaves glTF in the last-mile space. fbx (last mile) --------------- Autodesk's fbx format seems like it might be an interchange format, but is in fact a last mile format. It originated as a format holding data for real-time display in Kaydara's FiLMBOX. FiLMBOX was renamed Motion Builder after it's acquisition by Autodesk, and was subsequently leveraged for interchange between other Autodesk products.The FBX format reduces complex asset structure and choice points to the subset of functionality dictated by Motion Builder's realtime needs. 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 (last mile) ------------------- 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 thus qualifying it as last mile. 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 has a dynamic schema interperable at runtime and can be easily extended. Layering was introduced to move alembic more to the interchange side of the scale, but there's currently no activity on missing core semantics necessary for important data types such as skeletal-vertex weighting or blend shapes. USD (interchange/last mile) --------------------------- USD encodes a full scenegraph with the same complexity and expressiveness of Maya or Houdini hypergraphs. It extends general notions of scenegraphs with a deep layering system including a scene composition algebra. USD does not interchange computational dataflow graphs as found in programs such as Houdini and Maya. USD supports character and crowd models as first class citizens. USD supports shader graphs, and is a strict superset of graphs such as those in MaterialX, GLTF, MDL, Unreal, and so on. USD has schemas for positional audio, interactive physics, and several other application domains. USD can be leveraged as a high performance last mile format; this requires attention in pipeline processes to ensure that output usd files conform to some set of output requirements. USDZ is a formal last mile variant with defined semantics of what may or may not be in a valid file. USDZ (last mile) ---------------- USDZ is formal USD archival variant designed for delivery. It incorporates all USD features, but requires that all referenced textures, payloads, and referenced USD files are contained within the archive. Collada (interchange) --------------------- 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. Collada has not been updated since 2008. Antiques - obj, ply, stl, etc ----------------------------- These file types are historical and many 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. Version History =============== - 2020 Aug - add notes on FBX history, and app specific embedded blind data. h/t @gorlak - 2022 Jun - add USDZ. Removed list of engines and applications compatible with USD and GLTF as support for both is becoming ubiquitous.