原文： https://github.com/KhronosGroup/glTF-Tutorials/blob/master/gltfTutorial/gltfTutorial_001_Introduction.md
越来越多的应用程序和服务是基于3D内容的。在线商店提供具有3D预览的产品。博物馆通过三维扫描将其文物数字化，并允许游客在虚拟画廊中探索其收藏品。城市规划者使用三维城市模型进行城市规划和信息可视化。教育工作者创造了交互式的、动画的人体三维模型。其中许多应用程序直接在web浏览器中运行，因为所有现代浏览器都支持使用WebGL进行高效渲染。
各种应用对3D内容的需求与日俱增。在许多情况下，3D内容必须通过web传输，并且必须在客户端高效地呈现。但到目前为止，在运行时应用程序中，3D内容的创建和3D内容的高效渲染之间还存在差距。
在客户端应用程序中呈现的三维内容来自不同的软件，并以不同的文件格式存储。维基百科上的三维图形文件格式列表显示有70多种不同的三维数据文件格式，服务于不同的目的和应用案例。
例如，可以使用3D扫描器获得原始3D数据。这些扫描仪通常提供单个对象的几何数据，这些数据存储在OBJ、PLY或STL文件中。这些文件格式不包含有关场景结构或如何被渲染的信息。
更复杂的三维场景可以使用创作工具创建。这些工具允许用户编辑场景的结构、灯光设置、相机、动画，以及场景中出现的三维几何体。应用程序以自己的自定义文件格式存储这些信息。例如，Blender将场景存储在.blend文件中，LightWave3D使用.lws文件格式，3ds Max使用.Max文件格式，而Maya使用.ma文件。
为了呈现这样的3D内容，运行时应用程序必须能够读取不同的输入文件格式。必须分析场景结构，并将三维几何数据转换为图形API所需的格式。三维数据必须传输到图形卡存储器中，然后才能用图形API调用序列描述渲染过程。因此，每个运行时应用程序必须为支持的所有文件格式创建导入（importer）程序、加载程序（loader）或转换（loader），如图1b所示。
glTF的目标是以适合运行时应用程序的3D内容标准。当前存在的文件格式并不能满足场景传输条件，原因是有些不包含任何场景信息，而只包含几何数据；而有些则是艺术创作的3d格式，尽可能多地保留有关三维场景的信息，从而生成通常很大、复杂的文件，从而很难分析。除此以外，还必须对几何数据进行预处理才能在客户端渲染。
现有的文件格式都不是为在web上高效传输及高效渲染而设计的。但glTF并不是“另一种文件格式”，而是对3D场景的传输格式的定义：
• 场景结构是用JSON描述的，它非常紧凑，易于解析。
• 对象的3D数据以一种可由通用图形api直接使用的形式存储，因此没有解码或预处理3D数据的开销。
越来越多内容创作工具（软件）现在支持导出glTF。越来越多的客户端应用程序能够使用和呈现glTF。其中一些应用程序如图1a所示，因此glTF可能有助于弥补内容创作和渲染之间的差距，如图1c所示。
越来越多的内容创建工具将能够直接提供glTF。或者，可以使用Khronos glTF仓库中（repo）给出的开源代码，将其他文件格式转换为glTF格式。例如，几乎所有创作应用程序都可以以COLLADA格式导出其场景。因此COLLADA2GLTF工具可以用于将场景和模型从转换为glTF。OBJ文件可以使用obj2gltf转换为glTF。对于其他文件格式，可以使用自定义转换器创建glTF，从而使3D内容可用于各种运行时应用程序。