双方向に扱えることが肝心
glTFをDracoで圧縮できるツールは山ほどありますが、それを元に戻せるものはほとんどありません。そして人が詰まるのは、たいてい戻す側です。古いBabylon.jsのビルド、Unityのいくつかのimporter、そして少なからぬDCCツールはKHR_draco_mesh_compressionを単純に読めません。クライアントから圧縮済みGLBが届き、自分のパイプラインが受け付けないとき、必要なのはさらなる圧縮ではなく解凍です。
このツールはその両方を、ブラウザ内で、何もアップロードせずに行います。
DracoとMeshoptの違い
同じ問題を別のやり方で解いており、どちらが正解かは何を最適化したいかで決まります。
Dracoは接続情報を活かしたエントロピー符号化を用い、ファイルサイズは最小になります。生の頂点データに対して通常80〜95%削減できます。代償はデコード時間です。デコーダーはそれなりに大きなWebAssemblyモジュールで、大きなメッシュの展開には実際に数十ミリ秒かかり、その間ユーザーは何もない画面を見つめることになります。
Meshoptはバイト単位のフィルターとはるかに単純なコーデックを使います。ファイルはDracoよりわずかに大きくなりますが、デコードは約1桁高速で、フォーマット自体がデコードとストリーミングを重ねられるよう設計されています。転送量よりも最初の1ピクセルが表示されるまでの時間が重要なWebサイトでは、たいていMeshoptが有利です。
単体の.drcはglTFのラッパーを一切持たないDracoです。ジオメトリのみで、マテリアルもテクスチャも階層もありません。研究用パイプラインや独自ローダーには有用ですが、テクスチャ付きアセットの配信フォーマットとしては使い物になりません。
画質が失われるのは量子化
どちらのコーデックも量子化します。浮動小数点の属性が、指定したビット深度の固定小数点整数になります。これは仕組み上ロスがあり、許容範囲は属性ごとに異なります。
- 位置 — 14ビットならほぼすべてのケースで見た目に劣化はありません。12ビットでは大きなモデルで頂点がグリッドに吸着するのが見え始め、10ビットでは明らかです。
- 法線 — 10ビットが安全です。不足するとスムーズシェーディング面にバンディングとして現れます。
- テクスチャ座標 — 12ビット。 10ビットを下回るとUVがずれ、テクスチャが表面を泳ぐのがはっきり分かります。
- カラー — 8ビットは、もともと多くの頂点カラーデータが持っていた精度と同じです。
二重圧縮は避ける
すでにDracoのファイルを再エンコードするとは、デコードし、量子化済みの値をもう一度量子化し、また符号化するということです。1周ごとに失われた精度は二度と戻りません。このツールは読み込み時に既存の圧縮を検出して警告します。設定を変えたい場合は、まず解凍し、きれいになった結果から一度だけ圧縮してください。
小さくならないもの
ジオメトリコーデックはテクスチャには何もしません。40MBのGLBのうち38MBが4KのPNGなら、Dracoで減るのは数百KB程度で、「圧縮なんて効かない」と結論づけたくなるはずです。結果パネルではジオメトリのバイト数だけを切り出して表示するので、ファイルの他の部分と切り離して、コーデックが実際に何を達成したのかを確認できます。
プライバシー
DracoもMeshoptも、ブラウザ内でWebAssemblyとして動作します。アップロードは一切ありません。
Tiny Online Tools






