Sustainability of Digital Formats: Planning for Library of Congress Collections

The formats in the GL Transmission Format (glTF) Family have been designed as efficient, extensible, interoperable asset delivery formats for the transmission and loading of 3D content. Development and maintenance of glTF is through an open project by Khronos, an industry consortium focused on cooperatively creating open standards for royalty-free use, particularly standards to take advantage of hardware acceleration for computation or graphics. For more detail on Khronos as an organization and the motivation behind glTF, see Notes below. glTF is intended as a vendor-neutral distribution format for 3D content, bridging the gap between 3D content creation tools and applications displaying 3D graphics. Its originators described it as the "JPEG of 3D" or as a 3D content format for "the last mile." glTF minimizes both the size of 3D assets and the runtime processing needed by 3D applications. An early objective was to support applications built using the WebGL API, another open specification developed by Khronos. Based on the HTML5 Canvas element, WebGL has been implemented by most browsers as of June 2019. However, for broader applicability, glTF 2.0 is intended for use in any runtime environment or API.

Conceptually, a glTF asset contains zero or more scenes, the set of objects to render visually. Physically, a glTF asset is a collection of related files, comprising a JSON file and supporting external data files, as illustrated in the glTF basics figure from the specification. In particular, a glTF asset comprises:

• A JSON-formatted file (.gltf) containing a full scene description using a node hierarchy and also descriptions and links for materials, cameras, mesh geometry, animations, and other constructs.
• Binary files (.bin) containing geometry and animation data, and other buffer-based data.
• Image files (.jpg, .png) for textures. These are the only image formats supported for textures. As for most JPEG images on the web, the .jpg files are expected be in the JPEG File Interchange Format (JFIF_1_02), a wrapper format for image data in the JPEG encoding.

glTF assets can include: scene and model data; geometry; skins; shaders; texture files; and animation data. glTF 2.0 can include PBR (Physically Based Rendering) descriptions for metallic materials.

As of 2019, there are two chronological versions of glTF and a binary variant:

• glTF 1.0: Released in October 2015 following a period of development starting in 2012. See glTF Briefing from September 2016. This release was received enthusiastically, but some potential adopters asked Khronos to adapt glTf to be less tied to WebGL. For example, in glTF 1.0, a material was defined with a GLSL shader, which suited WebGL, but was problematic when importing a glTF model into an application based on Direct3D, a graphics API for Microsoft Windows, or Metal from Apple. Judging from glTF Tools from Khronos, most tools now support glTF 2.0. glTF 1.0 is not described separately on this website.
• glTF 2.0: Released in June 2017. A significant upgrade to glTF 1.0, designed to support practical runtime implementations for many graphics APIs. Support for Physically Based Rendering (PBR) was added for portable, consistent description of materials. See the Khronos press release for glTF 2.0.
• Binary glTF: A binary option for storing the content for a glTF asset was introduced as an extension to glTF 1.0 and incorporated into the glTF 2.0 specification. See GLB File Format Specification section in the specification for glTF 2.0. It consists of a 12-byte header, a JSON chunk, and an optional binary chunk. The binary chunk may contain all, or only some, of the image and other binary files that comprise the glTF asset. This format is not described separately on this website.

glTF defines an extensibility mechanism. See About glTF Extensions. Extensions can introduce new properties, new parameter semantics, reserved IDs, and new container formats. Extensions can define new properties that reference external data, and the extension can define the format of such data. Extensions are written against a specific version of glTF and may be promoted to core glTF in a later glTF version. Some extensions are ratified as Khronos (KHR) extensions; others can be vendor-specific. All extensions used in a model must be listed the top-level extensionsUsed array; required extensions are listed in the extensionsRequired array. KHR extensions are designed to allow safe fallback consumption in tools that do not recognize an extension in the extensionsUsed array.

An openly documented, royalty-free specification. Developed and maintained by Khronos, an industry consortium focused on cooperatively creating open, royalty-free, API specifications that exploit hardware acceleration for graphics, computation, and vision processing.

glTF has been rapidly adopted by a large number of applications related to 3D content. As made clear on a list of tools supporting glTF compiled by Khronos, most support is for glTF 2.0. glTF 1.0 appears to be obsolete and tools developed to import or render glTF 2.0 may well not load or properly render files conforming to glTF 1.0. Comments welcome.

See glTF_2_0 for information relating to the adoption of glTF 2.0

Khronos describes glTF as a royalty-free specification. Software developers are free to use Khronos standards to program software tools, applications, and middleware with no restrictions. Under limited circumstances, Khronos allows reproduction of the unmodified specifications without fee or royalty.

See Appendix B: Full Khronos Trademark Statement in the specification of glTF 1.0 and Appendix D: Full Khronos Copyright Statement in the specification for glTF v 2.0. for statements relating to patents. The Khronos Intellectual Property Rights Policy is Attachment A of the Khronos Group Membership Agreement available at www.khronos.org/files/member_agreement.pdf.

According to Appendix D: Full Khronos Copyright Statement in the specification for glTF 2.0, "Parties desiring to implement the specification and make use of Khronos trademarks in relation to that implementation, and receive reciprocal patent license protection under the Khronos IP Policy must become Adopters and confirm the implementation as conformant under the process defined by Khronos for this specification; see https://www.khronos.org/adopters."

The JSON-formatted file that acts as a manifest and describes the structural hierarchy of a glTF asset is a plain text resource and easily read with a text editor. However, a special-purpose editor that understands the structure of a glTF asset and can render the hierachy as a navigable tree is much more convenient for a human reader. Most of the 3D content is in binary form; often in the form of arrays of numbers. With full understanding of the form of each array type, the data is intentionally straightforward to parse by computer program; but needs appropriate tools to interpret.

For information about transparency of images that can be used in glTF assets, see JPEG/JFIF and PNG.

Application of compression for data chunks in a glTF asset, e.g., using the optional Draco mesh compression (supported as a Khronos-ratified extension to glTF 2.0) to compress mesh geometry data, yields a file that requires more sophisticated tools to render the 3D visualization.

glTF supports vertex skinning, which allows the geometry (vertices) of a mesh to be deformed based on the pose of a skeleton. This is essential in order to give animated geometry, for example of virtual characters, a realistic appearance. A texture is defined using an image in PNG or JPEG/JFIF format, with optional specification of filtering or sampling to be applied. The primary structure for defining materials varies between glTF 1.0, which only supports glSL to define shaders, and glTF 2.0 which introduced support for PBR for specifing materials.

A glTF asset can define an entire scene with many objects placed in the scene.

The glTF spec is designed to allow applications to choose different lighting implementations based on their requirements. A camera property for a node can position a viewing device in the scene. This feature of glTF possibly corresponds to a "view" in some other 3D formats. Comments welcome.

glTF supports animation using skeleton structures (assemblies of bones and joints). Note: These structures do not have to represent actual bones and skeletons. See Wikipedia entry on skeletal animation. glTF also supports skinned meshes, allowing the geometry (vertices) of a mesh to be deformed based on the pose of a skeleton. This can be used to give animated characters in games a realistic appearance when they walk, run.shoot, etc. Such skinned meshes and associated animation sequences can be created using several modeling programs (such as Blender). See Skinned Mesh Animation Using Matrices by Bruce J. Veazie.

glTF also supports animation using keyframes and matrices that specify changes through translation, rotation, and scale. glTF 2.0 introduced support for animation via instantiated Morph Targets. See Morph target animation.

About the Khronos Group: Khronos is an industry consortium focused on cooperatively creating open standards for 3D graphics, virtual and augmented reality, parallel computing, neural networks, and vision processing that are available for royalty-free use. Khronos was formed in 2000 and has around 120 member companies. In addition to glTF, Khronos governs specifications such as OpenGL, OpenGL ES, WebGL, and COLLADA. For more on membership, see Khronos Members and Member List.

Motivation for creating glTF. The specification provides the following motivation for creating a new format for 3D models:

"Traditional 3D modeling formats have been designed to store data for offline use, primarily to support authoring workflows on desktop systems. Industry-standard 3D interchange formats allow for sharing assets between different modeling tools, and within the content pipeline in general. However, neither of these types of formats is optimized for download speed or fast loading at runtime. Files tend to grow very large, and applications need to do a significant amount of processing to load such assets into GPU-accelerated applications. With the advent of mobile- and web-based 3D computing, new classes of applications have emerged that require fast, dynamic loading of standardized 3D assets. glTF solves these problems by providing a vendor- and runtime-neutral format that can be loaded and rendered with minimal processing. The format combines an easily parseable JSON scene description with one or more binary files representing geometry, animations, and other rich data. Binary data is stored in such a way that it can be loaded directly into GPU buffers without additional parsing or other manipulation. Using this approach, glTF is able to faithfully preserve full hierarchical scenes with nodes, meshes, cameras, materials, and animations, while enabling efficient delivery and fast loading."

3D Model Characteristics: The quality and functionality factors used above are based on an analysis from 2008 in An Overview of 3D Data Content, File Formats and Viewers, a technical report (ISDA08-002) from the National Center for Supercomputing Applications (NCSA). According to this analysis, the key aspects of a 3D model are: geometry, appearance, scene, and animation. For brief descriptions of these factors, see the table for 3D model formats under Quality and functionality factors. The descriptions there are drawn from the 2008 report and from 8 Most Common 3D File Formats of 2018 (an article from C|net), which uses the same factors to distinguish formats.

All 3D formats support some method for representing the geometry (the shape) of an object; support for other aspects is optional depending on the primary use of the format. Table 3 in the 2008 report, An Overview of 3D Data Content, File Formats and Viewers, compares nine popular 3D formats in use in 2008 based on these four aspects of 3D models. See also 8 Most Common 3D File Formats of 2018 for discussion of an overlapping set of formats.