数十億のトライアングル再訪

ビット、ピクセル、サイクル、そしてもっと多くのもの Arseny Kapoulkine (メール, , ) 著者 Arseny Kapoulkine (メール, , ) 仕事、プロジェクト、出版物 投稿 このブログが気に入ったら、RSSでフォローして古い投稿を読んでください。 最近の投稿: 数十億のトライアングル再訪 AVX-512によるジグザグデコーディング タンジェントフレームの量子化 meshoptimizer 1.0リリース 数分で数十億のトライアングル フラクタルを軽視しないでください ロードストア競合 加速構造の測定 独立の年 メトリクスとアルゴリズムの学習解除 « AVX-512によるジグザグデコーディング 数十億のトライアングル再訪 2026年9月30日 9月初旬、NVIDIAはオープンソースサンプルvk_lod_clustersのアップデートをリリースしました。このアップデートには、特に新しい印象的なZorahシーンがglTFファイルとして含まれていました。このデモは、クラスタリングされたレイトレーシングという新しいドライバー公開レイトレーシング機能と、NaniteのようなクラスタリングされたLODパイプラインの組み合わせを応用し、フルパストレーシングで非常に詳細なシーンをストリーミングおよび表示することを可能にしました。当然、これは私の好奇心をそそり、meshoptimizerでの階層的クラスタリングLODのサポートを改善するために時間を費やすことになりました。 …待て、これは聞き覚えがある。実際、スタンドアロンのZorahシーンの最初のバージョンと、クラスタリングされたRTの基盤となるドライバーコンポーネントは、昨年リリースされました！私は、そのシーンを「数分で数十億のトライアングル」で迅速に処理するための道のりについて書きました。しかし、vk_lod_clustersサンプルは昨年から大幅に進歩しており、シーンは完全な属性セットとテクスチャデータで更新され、レンダラーはパストレーシングを使用しており、美しく見えます。そして、処理の大部分はmeshoptimizerのclusterlod.hを使用しています。meshoptimizerでこの側面を改善するために時間を費やしたので、今回は処理時間よりも他の側面に焦点を当てて、書き直すのが理にかなっていると思いました。前の記事を読むことは必須ではありませんが、この記事をよりよく理解するのに役立つでしょう。 glTF圧縮 最初に気づくのは、新しいシーンが同規模（16億トライアングル）であり、かなりの70GBのダウンロードサイズであるということです。これは、多くのテクスチャが含まれているため予想されることですが、glTFシーンデータだけを見ると、2025年版は約36GB、2026年版は約32GBでした。ジオメトリの総量はあまり変わっていないので、古いシーンにはほとんどのメッシュに位置データしかなく、明らかに小さくなるはずだったことを考えると、これは驚くべきことです。 実際、NVIDIAは現在、元の属性なし、テクスチャなしの新しいバージョンのシーンを提供しており、これはわずか9GBです。この削減は、新しいglTFシーンがmeshoptimizer圧縮拡張機能、特にEXT_meshopt_compressionを使用しているためです。この拡張機能は、頂点とインデックスの圧縮をサポートしています。頂点データは古い「v0」頂点フォーマットを使用して圧縮されていることに注意してください。頂点コーデックはv1にアップグレードされており、圧縮率と解凍パフォーマンスがさらに向上し、新しい拡張機能KHR_meshopt_compressionでサポートされています。KHRバリアントは2026年初頭に標準化されたばかりなので、アセットが前のバージョンを使用しているのは理にかなっていますが、完全性のために両方を見ていきます。 これらの拡張機能は、頂点とインデックスの圧縮を公開しますが、処理ツールがデータを整理したり、圧縮特性を選択したりするための多くの余地を残しています。ブラックボックスの「1メッシュあたり」フォーマットとは異なり、meshoptimizerフォーマットは、頂点またはインデックスデータを表すバイト配列に基づいて定義されています。頂点データの場合、コンプレッサー自体はロスレスであり、元のバイトシーケンスを完全に再現します。ただし、その下にさらにレイヤーを追加してロスありにすることもできます。glTFジオメトリアクセサがそれをサポートしている場合は、事前に量子化されたデータを使用するか、「フィルター」を使用して、わずかな精度損失でデータを圧縮して、さらに圧縮率を高めることができます。 メッシュが配列を参照する方法も、データを準備するツール次第です。一部のツールは個々のメッシュに別々のバッファを使用することを決定するかもしれませんが、一部はそれらを結合することを選択するかもしれません。通常、ラストマイル配信シナリオ、つまり直接レンダリングされるglTFファイルを生成する場合、ロスあり圧縮（末尾の付録を参照）を使用して、表示に必要なレベルに精度を調整したいでしょう。これにより、出力ファイルが最小になります。しかし、Zorahシーンの場合、対象のシーンは単なる中間ファイルです。実際のクラスタリングLOD処理は、後で調整可能な精度特性を大幅に変更します。そのため、Zorah glTFシーンはロスレスオプションのみを使用しているのは理にかなっています。 その有効性を見てみましょう。ファイルはv0（EXT）圧縮を使用しているため、シーンの統計情報と、v1に切り替えた場合に達成される結果を計算しました。以下は、その結果です。「v0」は現在ダウンロードファイルに保存されているもの、「raw」はシーンが解凍されたときの状態です。 カテゴリ | Raw | v0 | v1 (再圧縮) ---|---|---|--- Positions | 14.3 GB | 9.1 GB (63.5%) | 8.9 GB (62.1%) Attributes | 30.1 GB | 21.6 GB (71.8%) | 20.5 GB (68.2%) Indices | 18.9 GB | 1.9 GB (10.1%) | 1.9 GB (10.1%) Total | 63.3 GB | 32.6 GB (51.5%) | 31.3 GB (49.5%) 全体として、ジオメトリ全体で約2倍の圧縮が得られます。インデックスはかなりうまく圧縮され、位置と属性はそれほどうまく圧縮されません。v1頂点フォーマットを使用すると、圧縮率が数パーセント向上し（デコードも高速になります）。 さて、これは最終的な配信フォーマットではないのに、このファイルを圧縮する必要があるのかと疑問に思うかもしれません。ダウンロードしたファイルは汎用ロスレス圧縮で圧縮されているので、なぜ気にする必要があるのでしょうか？これについては2つのことが言えます。 第一に、処理時間という点から、これは生のファイルや、ディスク上でファイルを圧縮されたままにするためにZstandardのようなコンプレッサーを使用した仮説的な表現と比較して、ディスクからシーンを読み取るコストを削減できます。頂点またはインデックスデータのデコードは、シングルコアで毎秒数ギガバイトの出力データで実行されます。前の記事で書いたように、処理は大幅にマルチコアであり、16コアでの集約デコードスループットは「大量」です。これが処理に統合される方法は、各メッシュの頂点/インデックスストリームは個別に圧縮され、各メッシュを処理する前に解凍されることです。その結果、解凍は総処理時間の1％未満を占め、完全に並列で実行され、ディスクから読み取る必要があるサイズを2倍に削減します。 第二に、汎用コンプレッサーを使用した場合よりも小さいファイルになる可能性があります。代わりにZstandard（この場合はレベル6）を使用した場合、より大きなファイルになり、デコードも遅くなります。どちらのデコーダーもZstandardより明らかに高速です。さらに、ファイルサイズをさらに削減したい場合は、エンコードされたバイトを再度Zstandardで圧縮することもできます。これにより、さらに小さなサイズになります！ファイルを2回解凍する必要があります。まずZstandardを使用してエンコードされたバイトを解凍し、次にmeshopt_decode*を使用して元のバイトを解凍します。ただし、Zstandardはより少ないデータを解凍する必要があるため、通常、結果のデコードはZstandard単独で使用するよりも依然として高速になります。 Raw | v1 | Raw + Zstd | v1 + Zstd ---|---|---|--- 63.3 GB | 31.3 GB (49.5%) | 38.0 GB (60.1%) | 27.4 GB (43.3%) これは奇妙な特性のように思えます。通常、圧縮された表現をさらに圧縮することはできないはずです！しかし、これは明示的な設計ポイントです。最新のロスレスコンプレッサーの完全な機能セットを実装する代わりに、meshoptimizerコーデックは、ロスレスコンプレッサー、特に高速なものがモデル化しないことが多い部分に焦点を当てますが、出力ストリームを高速デコードとさらなる後圧縮の両方に適した形式に保ちます。これは汎用性の点から良いです。例えば、LZMAを後圧縮レイヤーとして使用したい場合、それはインプラクティカルです。