让我们用流行的 3D 文件格式“glTF/glb”来增强 WebGL 的表现力吧！

简介 - 什么是 glTF -

glTF（GL 传输格式）是一种用于运行时应用程序的资产格式，它与类似 OpenGL 的 API（WebGL、OpenGL ES、OpenGL）具有高度相关性。 特别是对于 WebGL，它是不依赖于任何特定库的权威的成熟通用 3D 格式。

最初，它是以 COLLADA2jSON 的名义开发的。 这个名字出现在这里，但大约在 10 年前，也就是 Playstation 3 时代，CG 技术行业标准化组织 Khronos 试图推广一种 COLLADA 格式。 由于它是作为 COLLADA 和 DCC（Maya 和 Blender 等生产工具）之间的数据交换格式而设计的，因此不太适合运行时的动态加载（由于解析的速度和创建加载器时首先规范的复杂性）。1

glTF 是运行时加载性能和（对 COLLADA 的反思？ 正在进行的开发重点是格式本身的简单性。 目前，1.0 版本已经发布，并且已经进入实用阶段。 我们还热衷于支持新技术，例如即将推出的 1.1 版和下一个版本中的 PBR（基于物理）材质。 此外，正如我在开头所写的那样，它与 OpenGL 具有很高的亲和力，它可以毫无问题地与 Direct3D 一起使用。

Khronos 将 glTF 格式描述为“MP3 用于音频，H.264 用于视频，Jpeg 用于图像，3D 用于 3D...... glTF！」我们的目标是实现一个我们可以这么说的情况，并且对此的热情是非凡的。 最近，glTF 已被注册为“MIME 类型”，用于识别 Internet 等文件中包含的信息类型，并且加速丰富了导出器、转换器和相应的 3D 库等周围环境。 现在，可以说它是未来最有前途的格式之一。

glTF 支持的元素

更不用说静态模型，还支持动画蒙皮。 它还吐出着色器代码，因此您可以将用于渲染和蒙皮的特定着色器实现留给 glTF（当然，您可以自己更改它）。

但是，版本 1.0 尚不支持混合变形（变形顶点）。

坐标系和单位

• glTF 使用右手坐标系。 也就是说，x 和 y 的叉积产生 z。

• glTF 将 y 轴定义为向上。

• 所有角度均以弧度表示。

• 假设逆时针旋转为正。

嗯，这正是 OpenGL 系统。 也

• 所有直线距离均以米为单位。

因此，当您使用 DCC 工具（如 Maya）创建模型以预期输出到 glTF 时，应始终将长度单位系统设置为“米”。 否则，Maya 默认为“厘米”，因此它将显示为建模者假设的 1/100。

最后

• 它是一个平移、旋转和缩放（所谓的 TRS）值，被设置为节点的变换值，但是当从它创建变换矩阵时，它被视为 T * R * S 的序列并从后面乘以。 换句话说，顶点首先乘以刻度矩阵，然后乘以旋转矩阵，最后乘以平移矩阵。

glTF 的组成

glTF 的具体描述格式是带有元信息作为概述的 JSON 文件，包含顶点数据、动漫数据等的二进制文件，带有 GLSL 着色器代码的 .glsl 文件（如果使用纹理，则为普通图像文件）。 换句话说，它由这些多个文件组成。 事实上，这是一个基本形式，并且有一个版本，其中着色器代码、顶点数据和动漫数据、图像数据等作为数据URL嵌入到JSON中，而.glb格式中的所有内容包括原始JSON部分都是一个二进制文件。 glTF 格式有几种变体（就特定数据在文件中的存储方式而言）。

也就是说，可以将其视为 JSON + 二进制文件 + .glsl 文件（+ 图像文件）。 即使您编写了自己的 loader，也最好从这个基本形式开始。

JSON 段描述格式

首先，在开始之前，让我们先看一下文件的内容。 这是简单立方体的最简单模型。 以下是里面内容的摘录...... （为了便于理解，数据表示法的顺序已部分更改。

"scene": "defaultScene", "scenes": { "defaultScene": { "nodes": [ "node_1" ] } }, "nodes": { "node_1": { "children": [ "Geometry-mesh002Node" ], "matrix": [ 1, 0, 0, 0, 0, 0, -1, 0, 0, 1, 0, 0, 0, 0, 0, 1 ], "name": "Y_UP_Transform" }, "Geometry-mesh002Node": { "children": [], "matrix": [ 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 ], "meshes": [ "Geometry-mesh002" ], "name": "Mesh" } }, "meshes": { "Geometry-mesh002": { "name": "Mesh", "primitives": [ { "attributes": { "NORMAL": "accessor_25", "POSITION": "accessor_23" }, "indices": "accessor_21", "material": "Effect-Red", "mode": 4 } ] } },

　総じて言うと、

• まず各データ種類（nodeやmesh）ごとに、それらを連想配列でまとめたやといったものが、JSONの第一階層に存在します。例えばの中には、連想配列で複数のの具体的なメタ情報が定義されています。nodesmeshesnodesnode

• 各データ項目（など）は、自身が保持する情報として、具体的な即値（行列値など）を保持している場合もあれば、他のデータ項目のを指し示している場合もあります。nodeキー文字列

• あるデータ項目の定義（例えば、ある）を見ている時に、それが持つあるデータが他のデータ項目のを指し示している（例えば）場合は、JSONの第一階層のその対応するデータ種類の連想配列を、先ほどの（"Geometry-mesh002"）でアクセスすることで、その具体的な情報（そのが持つの具体的な情報）を得ることができます。nodeキー文字列"meshes": [ "Geometry-mesh002"],キー文字列nodemesh

• 基本的に、glTFのJSONファイルの読み込み手続きは、その参照の繰り返しです。

　また、glTFの公式Githubページでは、非常にわかりやすいチートシートが用意されています。

　これをベースに私の方でも即興で図を作ってみました。

图片上传中

glTFファイルの作成方法

　仕様はだいたいわかった。でも実際にglTFファイルを作れないと話になりませんね。 　方法は幾つかあります。今の所、もっとも確実な方法は、一度DCCツールから３DシーンをCOLLADA形式として出力し、それをCOLLADA2GLTFコンバーターでglTFファイルに変換する方法です。

　「え、なんでここでCOLLADAが入ってくんのよ！」そう思いますよね？　私も最初それ脳内でツッコみましたw

　でも、もともとCOLLADA2jSONとして開発されていた経緯や、できたてほやほやのglTFと違い、すでに各種DCCツールで出力環境が整っているのがCOLLADAであることを考えてみてください。 　各種DCCにglTF用のエクスポーターが実装されるのを首を長くして待つより、すでにある各種DCCのCOLLADAエクスポータでCOLLADA出力したものをglTFに変換した方が「現時点では」確実、という判断だったのかな？　と私は想像しています。（実際のところの経緯は分かりません^^;）

　ここでは、このコンバーターの導入と使用方法について説明します。

glTFリポジトリのクローン

COLLADA2GLTFのページに行きます。 　このリポジトリをクローンして、このWikiの手順に従って、COLLADA2GLTFコンバーターをビルドしてください。 （ビルド、と聞いて「面倒だなぁ」と感じた方は、オンラインで変換できるサービスがありますので、そちらの利用を検討してください。） 　少なくとも、私はMac環境でこの手順で問題なくコンバーターがビルドでき、利用できていることを確認しています。 　（万一、リビジョンによってはビルドやcmakeに失敗する場合があるかもしれません。少なくとも、私のMacOS El Capitan環境では、 で導入に成功したことを確認しています。Mac環境でハマった人はこのリビジョンを試してみましょう。）6779c09

コンバーターがビルドできたら、早速使ってみましょう。COLLADA（）ファイルを用意して、下記のようにしてコンバーターで変換します。collada2gltf.dae

$ collada2gltf foo.dae

すると、下記４つのファイルができるはずです。

foo.gltf foo.bin foo0FS.glsl foo0VS.glsl

ちなみに、には様々なオプションがあります。 （オプションによっては、出力の形式が変わり、出力されるファイル群が異なる場合があります） いろいろ調べて試してみてください。collada2gltf

　なお、このアプローチではCOLLADAファイルをまず出力しなければなりませんが、Blenderの場合は標準でCOLLADAエクスポーターが搭載されています。 　Maya/3dsMaxの場合は、ここからCOLLADAエクスポーターをダウンロードし、導入してください。

　ちなみに私はメインツールがMayaなのですが、このCOLLADAエクスポーターとCOLLADA2GLTFコンバーターを使って生成したスキニングアニメーションglTFファイルが、自作のWebGLライブラリで問題なく再生できるところまでは確認しています。

バイナリデータへのアクセス

　さて、大体のデータ構造はわかりましたが、実際にglTFのモデルをWebGLなどの3D APIで画面に表示するためには、JSON部分のメタデータだけでは情報が足りません。 　実際のモデルの頂点データなどは、.binファイルにバイナリデータとして収められています。つまり、バイナリデータへのアクセスが必要なわけですね。

　じゃあ、具体的にどうやってアクセスすんの、という部分については、.gltfファイルの、、の項目が教えてくれます。 　（先ほどの私のチートシートにも書いてありますので、ご覧ください！）buffersbufferViewsaccessors

buffers

　まずは、について見てみましょう。以下にサンプル例を示します。buffers

"buffers": { "Box": { "byteLength": 648, "type": "arraybuffer", "uri": "Box.bin" } },

という実際の.binバイナリファイルが指定されており、またそのデータ長が648バイトであると書かれていますね。まぁ、ここは難しくないですね。Box.bin

bufferViews

　次に、を見てみます。サンプルを示します。bufferViews

"bufferViews": { "bufferView_29": { "buffer": "Box", "byteLength": 72, "byteOffset": 0, "target": 34963 }, "bufferView_30": { "buffer": "Box", "byteLength": 576, "byteOffset": 72, "target": 34962 } },

这定义了上面显示的原始二进制数据的子集区域。 “buffer” 表示对原始二进制数据的引用，“ byteLength” 表示此子集区域的字节长度， “byteOffset” 表示从原始二进制数据开头开始的字节 数。 此外，of 引用 OpenGL 宏常量，这意味着它用作索引缓冲区。 这意味着它将用作顶点缓冲区。bufferViewbuffer"target": 3496334963ELEMENT_ARRAY_BUFFER"target: ": 3496234962ARRAY_BUFFER

（列）：glTF 的值中有时出现的神秘整数值是什么？

例如，

"bufferViews": { "bufferView_29": { "buffer": "Box", "byteLength": 72, "byteOffset": 0, "target": 34963 },

换句话说，不是吗？ 在 glTF 中，这些神秘的整数值会砰砰地出现。 如果您发现类似的东西，请参考这里。 右。 换句话说，这些是 WebGL （OpenGL） 中的宏常量。34963

例如，如果您抬头查找 ，您会发现它的意思是 。 一目了然的可见性很差，但是当你在程序中实际解析它时，它是一个整数值而不是字符串，因此可以直接区分，因此这比头部的字符串要好。 但是，在 GL 系列以外的 3D API 处理系统中处理 glTF 时，需要在程序中准备类似的对应表或包含 gl.h 等 OpenGL 头文件，这可能会有点不方便。34963ELEMENT_ARRAY_BUFFER

安静的交谈。

访问

现在，让我们来看看。 下面是一个示例：accessors

"accessors": { "accessor_21": { "bufferView": "bufferView_29", "byteOffset": 0, "byteStride": 0, "componentType": 5123, "count": 36, "type": "SCALAR" }, "accessor_25": { "bufferView": "bufferView_30", "byteOffset": 288, "byteStride": 12, "componentType": 5126, "count": 24, "max": [ 1, 1, 1 ], "min": [ -1, -1, -1 ], "type": "VEC3" }

　は、前述の“bufferViews”で定義されているバッファのサブ領域内から、具体的にどのような形で、１つ１つのデータ（例えば頂点座標など）を読んでいけばいいかを定義しています。accessor

　"accessor_25"を見てみると、 "bufferView": で参照するバイナリデータのサブセット領域を指定しています。 そして、 "byteOffset"で、そのサブセット領域の先頭から何バイト目から読み込みを開始すべきかを指定しています。 "byteStride"では「１つ分」のデータと、次の「1つ分」のデータとの間の、読み取り場所の移動バイト長を示しています。 どういうことかというと、この"byteOffset"と"byteStride"、それぞれ、OpenGL/WebGLの関数で指定する、オフセットとストライドに対応すると思ってください。 　（なので、今の所ほとんどのデータはそうなっていないですが、もしかしたらそのうちインターリーブなデータレイアウトのファイルも出てくるかもしれませんね。） はOpenGL/WebGLマクロ定数でいうところの型を意味しています。 "count"は、何個分データが入っているか、ですね。 "type": は、データがスカラー型なのか、ベクトル型（VEC2/VEC3/VEC4）なのかを示しています。 "max"と"min"は、このaccessor内の全データでの最大値と最小値ですね。 "accessor_21"の方も見てみましょう。 　"byteStride"が0となっていますが、0は特別扱いで、１つ１つのデータはぴったり隣り合っていることを意味しています。 　はを意味しており、"type": "SCALAR"なので、これは頂点インデックスの情報なのでしょうね。 　と、まぁこんなところです。ここまで情報が提示されていれば、ちゃんとバイナリデータからデータを取ってくることができます。そして、今まで見て分かる通り、かなりOpenGL系を意識した構造になっていることがわかりますね。 　（まぁ、Direct3Dで扱う場合も、概念は似たようなものなのでなんとかなると思いますが。）gl.vertexAttribPointer"componentType": 5126FLOAT"componentType": 5123UNSIGNED_SHORT

マテリアルの扱い

　さて、glTFではマテリアルの扱いはどんな感じなのでしょうか。拡張を使う場合と、標準の場合があり、標準だと以下のような感じです。

"materials": { "blinn-1": { "technique": "technique1", "values": { "ambient": [ 0, 0, 0, 1 ], "diffuse": "texture_file2", "emission": [ 0, 0, 0, 1 ], "shininess": 38.4, "specular": [ 0, 0, 0, 1 ] } "name": "blinn1" } }, "techniques": { "technique1": { // parameter definitions "parameters": { "ambient": { "type": 35666 }, "diffuse": { "type": 35678 }, "light0Color": { "type": 35665, "value": [ 1, 1, 1 ] }, "light0Transform": { "semantic": "MODELVIEW", "node": "directionalLight1", "type": 35676 } // more parameters }, // program, attributes and uniforms definitions "attributes": { "a_normal": "normal", "a_position": "position", "a_texcoord0": "texcoord0" }, "program": "program_0", "uniforms": { "u_ambient": "ambient", "u_diffuse": "diffuse", "u_emission": "emission", "u_light0Color": "light0Color", "u_light0Transform": "light0Transform", "u_modelViewMatrix": "modelViewMatrix", "u_normalMatrix": "normalMatrix", "u_projectionMatrix": "projectionMatrix", "u_shininess": "shininess", "u_specular": "specular" }, // render states "states": { "enable": [ 2884, 2929 ] }

在上面的 glTF 数据中，有一个名为 Below 的材质。 它有数据进一步指出： 这是充当材质和着色器之间桥梁的数据。materialsblinn-1technique1techniquetechnique

具体而言， 指定在其他位置定义的着色器程序， 定义要用作输入的顶点数据类型，定义 所需的 uniform 变量，并在 绘制此 3D 对象时启用。 禁用 WebGL 状态（例如 gl.enable（gl. BLEND） 并 定义 中指定的各种统一变量的数据类型和值（可选）等参数。programattributesuniformsstatesparametersuniforms

请注意，在上面的材料中，定义了特定的材料参数，例如 和 ，它们对应于 下的一个项目。 对于没有特定值（除此之外）的项目，在实际着色期间将使用该材质的项目的值。 如果 following 和 following 中都有同名的项目，则 side 上该项目的参数值优先。blinn-1valuesambientdiffuseshininesstechniqueuniformsuniformslight0Colorblinn-1valuestechnique.uniformsmaterial.valuesmaterial

如果你的直觉很好，你可能已经注意到，光的具体颜色是在技术端指定的，而光的具体信息是在材料端没有指定的。 从这个意义上说，材质应该与光照信息分开。 在这方面，情况是很自然的。light0Colorvalues

此外，由于 glTF 规范，item 属性是可选的，而不是强制性的。 如果此属性不存在，并且还有一个定义单独材质的 glTF 扩展（如下所述），则 3D 对象将使用 50% 的灰色辐射色进行渲染。 请参阅 glTF 规范的附录 A。 嗯，它只是一个灰色填充（0.5、0.5、0.5、1.0）。 在实践中，大多数 glTF 资产都具有按属性或按属性划分的材质信息。 （灰色）最初提供，以便资产不必在每次使用扩展材质时定义任何显式技术。 materialtechniquetechnieqeデフォルトのマテリアルデフォルトのマテリアルtechniqueマテリアル系のglTF拡張デフォルトのマテリアル

KHR_materials_common关于 Material Extensions

正如你们中的一些人在阅读了上面的材质描述后可能已经猜到的那样，glTF 没有指定特定的着色模型（例如，Lambert、Blinn、Cook-Torrance 等）。 正如我在上面的 glTF 数据示例中提到的，那只是一个带有“该名称”的项目名称，并且指定了实际的 Blinn 着色模型，因为它被指定了（看起来很长）着色器程序中有一个实现作为实际的 GLSL 着色器代码。 换句话说，glTF 本身对着色模型没有任何特别的了解，并将大量细节放入附件中指定的着色器代码中。blinn-1blinn-1techniquetechnique-1programprogram_0

但是，在大多数情况下（基于物理的现代 CG 游戏除外），您有一个要使用的特定经典着色模型。 每次在着色器代码中编写这么多内容是可以的。

这就是 KHR_materials_common Material Expansion 的用武之地。

glTF 的这种扩展描述格式结合了众所周知的经典材料，如 Blinn、Phong、Lambert 和 Constant，以及以下描述：

"materials": { "lambert1": { "extensions": { "KHR_materials_common" : { // one of CONSTANT, // BLINN, // PHONG, // LAMBERT "technique" : "LAMBERT", "values": { "diffuse": [ 0.5, 0.5, 0.5, 1 ] } } } } }

您可以使用以下描述指定光源类型，例如环境光、平行光、点光源或聚光灯。

"extensions": { "KHR_materials_common" : { "lights": { "light1": { "directional": { "color": [ 1, 1, 1 ] }, "type": "directional" } } } }

那么，它与上面提到的 glTF 标准材料技术有何不同呢？ 对于 glTF 的标准材质技术，着色器代码中描述了特定光照（着色）过程的详细信息。 “要提供给着色器的参数在 glTF 材质技术中指定，但特定的照明和着色处理（算法）可以在 GLSL 代码中读取！”

另一方面，在材料扩展中，如官方 Github 页面的 README 所述，Blinn 等着色模型的算法（计算公式）和聚光灯参数的处理都是预先确定的（请阅读官方 README）。KHR_materials_common

因此，处理 glTF 的 DCC 导出器和渲染引擎可以根据材质扩展的规则（承诺）交换和解释数据，并且可以在不需要着色器代码的情况下构建紧凑的照明工作流程。KHR_materials_common

无论是否高级，便利就是方便。

glTF 之后的 PBR（物理基础材料） 下一页

顺便说一句，截至 2016 年 11 月 15 日撰写本文时，glTF 的 PBR 资料仍在官方 Github（暂称）上讨论中。 因此，虽然它还没有达到本文可以具体介绍的状态，但我想介绍一个有趣的问题交流。 就在这里。glTF Next

首先写入。

glTF 中 PBR 的目标是将高质量的 3D 模型传输到外部引擎，同时保持与这些引擎中现有光源、相机、对象和环境的关注点分离.

“glTF 的 PBR 目标是将高质量的 3D 模型引入外部引擎，同时保持与现有轻型摄像机对象和这些外部引擎环境的分离。”

有。 如果你继续阅读，它似乎大致是这样的（可能包括我的@emadurandal解释）。

“它是 glTF 文件的着色器代码，或者更确切地说，当前实时 CG 技术的着色器代码不仅与材质有关，还与周围环境（灯光、环境贴图）等有关，没有得到适当的分离。

“普通材质模型通常与最初创建它们的环境密切相关，例如最初创建它们的环境中的光线，但 PBR 没有这种情况，而且因为它是按照物理属性的通用标准构建的，所以其他环境中的光源很容易看起来一样。”

“换句话说，通过使用 PBR，我们可以解耦 glTF 模型与周围环境（例如灯光）之间的依赖关系。”

“我们可以交换模型数据，而不必太担心每个引擎的照明环境差异，我认为这就是 glTF 采用 PBR 的动机。 你们怎么看？ 这似乎是本期的议程。

下面的段落特别有趣。

KHR_materials_common 设置的栏杆不仅躺在地板上，还沉入了防水坑中，伴随着一些固定功能的恐龙骨骼。

“材料膨胀带来的 [技术] 水平不仅仅是在地面上爬行，而是与一些固定的恐龙骨骼一起沉入焦油坑。”KHR_materials_common

（*恐龙有过时的含义。

这是英语独有的诙谐笑话，而且是材料扩展 diss，不是吗？ 万维网KHR_materials_common

嗯，我认为材料膨胀是有用的，这取决于它的使用位置（事实上，本期表达了这样的观点）。KHR_materials_common

无论如何，我希望未来的 glTF PBR 支持将大大改善模型数据在不同 DCC 和渲染引擎之间路由的方式。 一旦规范最终确定，我将在另一篇 Qiita 文章中再次总结它们。 【2016/12/30 更新】 关于 glTF，PBR 还在讨论中，但似乎已经有通过独立扩展 glTF 提前实现 PBR 的情况。 正如你所看到的，如果你从上面的站点删除 glTF 文件并打开里面，具体来说，定义了一个名为 FRAUNHOFER_materials_pbr 的扩展，PBR 似乎是使用此扩展和 PBR 相关纹理（金属度、粗糙度纹理等）实现的。 此扩展已被 glTF 正式拉下，可能会对采用或作为官方 glTF 的规范产生重大影响。

让我们正确阅读随附的 GLSL 着色器代码！

这是我沉迷的体验，但是在不忽略 glTF 附带的 GLSL 着色器代码（或嵌入在 glTF 中带有数据 URI 等）的情况下正确加载它更安全。

起初，我心想：“不管怎么说，这只是一个简单的光照计算，对吧？

我有很多空间，但有一些数据适合。 就是这样。

如果仔细观察，可以看到 UV 坐标值是一个很大的整数值，即使它是二维纹理，也有三个元素 （Vec3）。 当我按原样使用自己的加载器加载它时，纹理没有按预期显示。 当我研究它时，似乎数据是基于将 x 和 y（u 和 v）除以 z 元素的前提。 当我在Cesium.js论坛上询问这个问题时，似乎 “这是因为 短类型（2 字节）vec3 每个 UV 节省 2 个字节，而不是浮点类型（4 字节）vec2 表示纹理坐标。 明白了。。。。

我当时想，“即使未经允许就做了这样的默契，对阅读文件的人来说也会是个问题”，但当我仔细观察时，我发现这个带有 Data URI 的 glTF 文件中嵌入的顶点着色器包含了做得很好的代码。

因此，请务必注意，glTF 的数据部分只是数据块，除非将其作为一个集合读取，包括包含的 GLSL 着色器代码，否则可能无法正确处理（除非它遵循预先确定的数据解释安排，例如扩展）。KHR_materials_common

但我不认为这是一个好主意。 这是 GLSL 代码。 如果是 DirectX 等 GL 以外的处理系统，则无法按原样处理，因此您必须选择播放环境。 考虑到 3D API 处理系统之外的可移植性，最好尝试创建不太依赖着色器代码的 glTF 数据。

P.S.： 看来这个问题在官方 Github 上也有讨论。 从现在开始，他们似乎将目标对准了 GLSL，这是一种不依赖于特定 3D API 的格式。glTF Next

各种工具介绍

现在，让我们看一下支持 glTF 的各种工具。

非 COLLADA2GLTF glTF 转换器

obj2gltf

Obj 格式到 glTF 转换器。 如果难以输出到 COLLADA，最好使用它。

COLLADA|OBJ 到 glTF

前面提到的 和 是命令行工具。 特别是，需要您先构建一个转换器，这对某些人来说可能很麻烦。 这不是一个命令行工具，而是一个 Web 服务，允许您简单地将 COLLADA 或 Obj 文件拖放到此页面上，它会自动下载转换为 glTF 的文件。 此外，拖放文件的内容也会显示在页面上的查看器中，因此也建议将其作为简单的查看器。COLLADA2GLTFobj2gltfCOLLADA2GLTFCOLLADA|OBJ to glTF

JavaScript製のglTFローダー（WebGLライブラリ）

　まぁ、Three.jsとかBabylon.jsとかは定番ですね。 　ここでは４日目の @cx20 さんの記事「glTF 対応 WebGL ライブラリを比較してみる」の紹介をすることで、説明と代えさせていただきます。 　スキニングアニメーションも含めたglTFのサポートレベル、何気に私の自作WebGLライブラリGLBoost と @kyasbal さんたちが開発する Grimoire.js といった、国産ライブラリ勢が結構頑張ってますよ！

典型的非 JavaScript glTF 加载程序

爪哇岛

JglTF

目前，Java 中的 glTF 似乎是唯一的选择（截至 2016 年 11 月 6 日）。 我也摸了摸，印象中作为装载机的精度相当高。 特别是，很少有库能健壮地支持 glTF 的皮肤动画，但这个 JglTF 是完美的。 顺便说一句（对不起，我个人的故事），我使用了这个 JglTF 的实现和作作为 emadurandal 的 WebGL 库“GLBoost”中动画支持皮肤的参考。 虽然许多其他库只能正确播放我在 Maya 中创建的 glTF 数据或 glTF 官方 glTF 示例数据，但这个 JglTF 是当时唯一可以正确播放两种蒙皮动画的库。

C++

Tiny glTF 加载器

这是由以后期训练技术而闻名的 @syoyo 先生开发的装载机。 很抱歉，但我还没有真正尝试过，但我敢肯定，如果它是 syoyo 制造的，你可以期待它的质量。 由于它是仅标头的，因此似乎您只需包含它而无需构建即可使用它。 由于它在 TODO 列表中显示 “Parse skin”，因此它还不支持对动漫进行皮肤化...... 我想知道？ （截至 2016 年 11 月 6 日）

此处无法介绍的其他支持环境

glTF Github 页面上的 README.md 列出了许多其他支持 glTF 的库、转换器、导出器等。

最后

你觉得怎么样？ glTF 是最流行的 3D 文件格式之一，因为它支持大量功能（蒙皮、支持未来基于物理的材质、扩展规范等）和易于加载。 特别是就目前而言，glTF 似乎将继续是唯一具有如此多功能并且可以普遍用于 WebGL 应用程序的 3D 文件格式。 我们已经拥有了丰富的生态系统（播放环境、导出器、转换器等），并且我们已经处于实践阶段。

WebGL 本身最近才完成了 1.0 版本执行环境的传播，但直到现在我还没看到很多使用复杂模型的 Demo（尤其是那些具有复杂动漫皮肤的模型）。 并不是说没有，但在这种情况下，它可能已经以自己的格式完成（或者我觉得 Three.js 能够使用专用文件格式做很多事情，但当然它只能在 Three.js 中使用......

但现在有了 glTF。 glTF 不依赖于任何特定的库，并支持许多功能。 未来，它将用于许多 WebGL 项目，我们预计 Web3D 中的表达范围将扩大。 请以本文为起点，越来越多地挑战 glTF！ 哦，最后。 作为实际作的例子，我给大家举一个例子，用我的 WebGL 库 “GLBoost” 读取官方的 Khronos 样例 glTF 文件。 我只是在玩皮肤动画，但我可以正常地这样做。

我想在另一篇文章中写更多关于在 glTF 上播放皮肤动漫的信息。 祝您 WebGL & glTF 生活愉快！