空間コンピューティング向けに3Dアセットを最適化

こんにちは Scott Wadeです Apple Vision Pro Apps and Contentの テクニカルアーティストです 「空間コンピューティング向けに 3Dアセットを最適化」セッションへようこそ

このセッションでは こちらのサンプルシーンを使い コンテンツを最適な形で表示するための 手順について説明します このセッションのリンク先から サンプルをダウンロードできます Apple Vision Proの 高解像度ディスプレイと高フレームレートは ユーザーに素晴らしい体験をもたらしますが それにより Apple Vision Pro向け コンテンツの開発は 他のプラットフォームとは 異なるものになります このセッションではまず 3Dコンテンツの作成を始める前に 知っておくべき重要な考慮事項を説明します その後 ポリゴン数の 目標設定について説明します さらに 任意のコンテンツ作成ツールから エクスポートする際の注意事項 テクスチャメモリの効率的な使用方法 マテリアルとシェーダの最適化 スカイドームのセットアップのポイント イメージベースライティングの 効率的なカスタマイズ方法を紹介します

まずは覚えておくべき 基本知識から始めましょう アセットを作成するにあたり 最も重要な考慮事項は そのコンテンツをどのように表示するかです 多数のアセットを使用する イマーシブアプリでしょうか スペースのボリューム内に 表示するのでしょうか 共有スペースに配置して 他のアプリケーションも 同時にレンダリングするのでしょうか 特に重要なのは ユーザーの入力に応じて コンテンツ表示が 変わるかどうかです これらすべての選択が アプリのパフォーマンスに影響し 場合によってはコンテンツの最適化を 見直す必要が生じます このようにビューアのビューが重要なのは Apple Vision Proの場合 GPUは実際に レンダリングするピクセルのみを処理し パススルービデオは処理しないからです そのためGPUのワークロードはビューアに 表示されるアプリの大きさに比例します つまり 非イマーシブなシーンは レンダリングを高速化できる可能性があります

一方 イマーシブなシーンでは 毎フレームごとに全体のビューが 対象となるため GPUは膨大な数のピクセルを レンダリングする必要があります

この点を考慮すると テストなしで具体的なパフォーマンス目標を 設定するのは難しいので 早期にテストを行う必要があります アプリを共有スペースに配置して 他のアプリも同時に実行する場合 イマーシブアプリは使う画面エリアが大きく フレーム時間も増える可能性があります そのため ほとんどのイマーシブアプリは 大幅な最適化が必要になります 三角形で測定される シーンのポリゴン数は 注意すべき重要なパフォーマンス指標です 一般的なガイドラインとして イマーシブシーンでは三角形の数を 50万個以下とし 共有スペースのアプリでは25万個以下 とすることを推奨します この上限は ビューアに表示される内容に 常に左右されることに注意してください 地形などの大きいオブジェクトは 複数に分割し カメラに映らない部分を 省略してください 安全な目標値を定める場合 ビュー内の三角形の数は 上限まで十分余裕のある 10万個程度にすることをお勧めします コンテンツ制作を始める前に これらの事項に留意することで 予算内に収めることができるでしょう

次は コンテンツの作成や編集に 使用できるアプリについてです

幸いなことに 多数の選択肢があります というのも 最も重要なのは 制作物をUSD形式で 保存できることだからです つまり Blnder Autodesk Maya SideFX Houdiniなど多数のアプリが 有望な選択肢となります USDエコシステムの詳細については openusd.orgをご覧ください 今回はBlender 4.1を使用します 画面を切り替えましょう

まず 大きなシーンに含まれるいくつかの アセットに注目しましょう ビューアからの距離を考慮した 適切なポリゴン数で これらのアセットのモデルを 作成しています 少しわかりにくいので これからシーン内に カメラを作成し ビューアの視点で コンテンツが どのように映るのかをお見せします シーンの中心にカメラを配置し 平均的な目の高さである 1.5mに高さを設定します カメラをぐるりと回転させて コンテンツのサイズがビューアに どう映るのかを確認しましょう

アセットをUSDでエクスポートする準備は できていますが USDファイル形式は 複数存在するので 1つを選ぶ必要があります 各形式が適している用途を 簡単に説明します USDAはASCII形式であり プレーンテキストとして読み取れます USDAは共同で作業するファイルに適しており 例えば 複数人で編集する シーンなどに向いています そのためReality Composer Proの シーン形式に使われています テキスト形式なので 一度に複数人で同じファイルを 処理する場合にマージの不整合を 解決しやすいという特徴もあります USDCはバイナリ形式です 任意のUSD対応アプリで 開くことができますが プレーンテキストとしては読み取れません ただし ジオメトリなど 大量のデータを保存する際には 非常に効率的です

USDZはzip圧縮形式です ARアセットを使用した経験がある方は 既にご存知かもしれませんが USDZはテクスチャなどのアセットの 依存関係をすべて処理し それぞれに適した 内部ファイル構造を作成します そのため USDZはアセットの 公開や配布に最適です ただし 解凍しない限り編集できません

今回のアセットは主にジオメトリなので USDC形式で保存しましょう

マテリアルは既にBlenderで 用意していますが のチェックは外します Reality Composer Proの Shader Graph機能を活用したいからです をクリックします これをReality Composer Proの プロジェクトブラウザに読み込み シーンに追加すると 2つの点に気づくでしょう

1つ目は色がマゼンタであることです これはReality Composer Proでマテリアルが 割り当てられていないためであり 想定通りの結果です 2つ目はオブジェクトの向きが 変わっていることです

ここで 座標系について 説明しておきましょう

RealityKitの座標系では Z軸の負方向が前 Y軸の正方向が上 X軸の正方向が右になります 一方 BlenderではZ軸が上 Y軸が前を表します また スケールの単位もアプリによって 異なることがあります RealityKitはメートル単位であり スケールが設定されたコンテンツを インポートすると問題になることがあります こうした差異に一貫して対処できるよう アセットのインポートについて早めに テストしておくことをお勧めします

今年 macOSの新機能として プレビューで座標とスケールを 変更できるようになりました 詳細については 「What’s new in USD and MaterialX」 をご覧ください アセットをReality Composer Proに インポートする際 X軸方向に-90度の回転を加えましょう

次は テクスチャを適用しながら テクスチャの最適化方法を説明します Reality Composer Proの Shader Graphを使用して マテリアルとテクスチャを設定します Shader Graphでのマテリアルの 設定方法について詳しくは 2023年のセッション 「Explore materials in Reality Composer Pro」 をご覧ください このアセットには基本的な PBRマテリアルを既に適用しているので 後はテクスチャを適用するだけです プロジェクトブラウザで このマテリアルを選択し 参照ファイルを選択して ベースカラーを追加します

カラーイメージを追加する場合は 色空間も選択する必要があります

色空間とテクスチャとの関係について ざっと触れておきましょう Reality Composer Proでは 色空間は ダッシュ区切りの2つの項で表されます 例えば「sRGB - Display P3」です

最初の項は伝達関数を表し 値のエンコードの基準となる 曲線を定義します 「sRGB」はレンダラに直接表示される 知覚的なテクスチャに適しています ベースカラーやunlitカラーなどです 「Linear」はデータやHDR画像向けです 2つ目の項は広色域を表し 色空間の最大範囲を定義します Vision Proのネイティブディスプレイの 広色域はDisplay P3ですが 他の広色域を使用するテクスチャは Xcodeでアプリをビルドする際に Display P3に変換されます 結果の一貫性を確保できるように テクスチャの制作意図に 合うものを選んでください このテクスチャは「sRGB - Display P3」 なので これを選択します

次は 粗さとアンビエントオクルージョン用の テクスチャを追加します

ご覧のように グレースケールの テクスチャには 色空間を選択するオプションがありません これらのテクスチャは 変換が不要なデータであると Shader Graphによって 適切に認識されているためです ただ これらのグレースケールテクスチャは アプリのビルド時に圧縮されないので 必要以上に大きなサイズになってしまいます この問題を解決する方法が テクスチャパッキングです

この手法では カラーテクスチャの 複数のチャネルを利用し 別々のファイルのテクスチャデータを 1つの大きなファイルにまとめます 例えば 粗さ メタリック アンビエント オクルージョンのテクスチャがある場合 それぞれを赤 緑 青の チャネルとして使い これらのデータを1つの テクスチャファイルに結合します この手法には 結合したRGBテクスチャが アプリのビルド時に圧縮される というメリットもあります グレースケールテクスチャを 1つにまとめるだけでも PBRアセットの合計サイズを 最大40%削減できます パッキングしたテクスチャを 読み込む際は Shader Graphに データと認識されるよう ノード型でvector3を選択します

これで色空間の変換は適用されません RGBテクスチャを個々の チャネルに分割するため 「Separate 3」を使用します

そして 粗さとAOのテクスチャを 各入力から接続します

次は法線マップを追加しましょう 法線マップはデータとみなされるので 今回もvector3型を使用します

しかし このテクスチャを接続すると アセットの見た目が変になりました 心配はいりません 法線マップがこうなる主な原因は 形式またはデータ範囲が 不適切であることです 法線マップの一般的な形式には OpenGLとDirectXがあります RealityKitではOpenGL形式の 法線マップを使用します 見た目は似ていますが DirectX形式では 緑チャネルが反転されます 今回はテクスチャの形式が OpenGLとわかっているので データ範囲が原因と考えられます

このマテリアルには範囲が-1から1の 法線マップが必要です しかし 画像には0から1までの値しか 含まれていません 画像の範囲を調整するには 少し計算が必要です まず 範囲に2を掛けて 0から2に広げます

その後 1を引いて 範囲を-1から1にします

これで解決できました 幸い RealityKitにはこうした操作を 1つの手順で行える 「Normal Map Decode」ノードがあります

軽く補足すると Shader Graphには NormalMapというノードもありますが Blenderの同名のノードとは異なり このノードはテクスチャの範囲を変更しません アプリごとの違いに備えて 必ずノードのツールチップを確認してください ノードの追加によりアセットの 見た目が良くなりました

この設定をすべてのアセットで行う 必要がなければ最高ですね 幸い Reality Composer Proには マテリアルインスタンスがあります マテリアルインスタンスでは マテリアルのロジックを再利用しながら 公開パラメータを変更することもできます アセットの設定時間を短縮できるだけでなく エンジンで同じシェーダグラフを何度も 読み込まずに済むので アプリのパフォーマンスも向上します 現時点ではどのマテリアルにも 公開パラメータがないので すべてのインスタンスは同一です そこで すべてのファイル参照を選択し 右クリックして を選択します

右側のパネルで これらの入力に アクセスできるようになりました 次は メインのマテリアルを右クリックし を選択します

ベースグラフ自体は編集できませんが ご覧のように テクスチャ入力が 編集可能になっています 次のアセットを追加しましょう

目的のアセットがすぐわかるように マテリアルインスタンスの名前を変更します

適用後も古いテクスチャが 引き続き使われていますが

このインスタンスを選択すると ベースカラー 法線 パッキング済みの テクスチャを変更できます

アセットを作成するたびに パッキングしたテクスチャを分解したり 法線マップの範囲を変更したりする 必要はありません これで2つ目のアセットの準備を 1つ目のアセットの用意にかかった時間の ほんのわずかな時間で済みました 次はシーンを確認しながら マテリアルの最適化とシェーダの選択 について説明します 先ほどお見せしたシーンでは 個別のアセットを使用していました

シーン全体でunlitマテリアルを使用し ほとんどのアセットのテクスチャは 1つだけです これを実現するために Blenderなど外部のツールで ライティングを設定し オブジェクトごとに全シェーディング情報を ベイクし 1つのテクスチャにまとめました RealityKitでリアルタイムのライトを使うと パフォーマンスに影響するため ダイナミックライトは控え できるだけベイクすることをお勧めします ご覧のように このシーンは複数の チャンクに分割されています

こうすることで カメラに映っていない エンティティを 間引くことができます

Blenderでチェッカーボードのマテリアルを シーンに適用してみると テクスチャの解像度が距離に応じて 下がっていることもわかります 実際 テクスチャ解像度の半分以上は ビューアの周囲5～10メートル の距離に合わせています ビューアがあまり移動しないのであれば 画面上での距離とサイズに応じて テクスチャの解像度を 調整することを強くお勧めします

陰影のないシーンでも考慮すべきなのは アルファ透明度の使用率です アルファ透明度の使用は できる限り控えてください

GPUで透明のレイヤーごとに 同じピクセルを複数回計算する必要があり 透明なマテリアルは負荷が大きいためです この計算はオーバードローと呼ばれ 透明のレイヤーが複数存在し 重なり合っている場合 特に問題になります

例えば この草原には透明なテクスチャを 使用しているように見えますが

実際には草の葉のジオメトリを 使用しています 低木も同様です

不透明なコアに透明なカードを追加し エッジ部分で 最も効果が強まるように設定しただけです こうするとポリンゴン数は増えますが 経験上 透明なピクセルが減るのであれば 三角形の数を増やしたほうが適切です ただし 三角形数の上限を 超えないように注意してください シーンの用意ができたので 次はスカイドームです スカイドームがないと シーンの端を超えた先まで 環境を見通せてしまいます

この例では Blenderで自作した 反転球を使用しますが 任意のジオメトリを使用できます ただし サイズを十分に大きくするか ユーザーから十分に離してください この球は直径を約500メートルに 設定しています

スカイドームやスカイボックスには かなり高解像度のテクスチャが必要です このようにディテールに富んだ画像では 水平方向の解像度を8,000以上に設定し ぼかしを抑える場合はさらに高くしましょう

このテクスチャサイズの場合 ユーザーから見えない部分は トリミングすることをお勧めします 今回は 水平線より下の部分を トリミングすることにします 先ほどのシーンにスカイドームを 表示してみましょう このアセット1つだけで 画面の大部分が覆われる様子を 確認できます スカイドームやスカイボックスには unlitマテリアルを使うことが重要です まず これらのアセットを最適化しましょう

スカイボックスを設置すると シーンに一体感が出ますが

先ほどのPBRアセットを見てみると 見た目があまり良くありません ライティングがシーンの他の部分と 異なっているようです 背後には太陽があるはずですが このハイライトは明らかに 太陽のものではありません このスカイドームが単なるメッシュであり PBRアセットのライティングに 影響していないためです 独自のイメージベースライティングの 実装方法を考える必要があります イメージベースライティング(IBL)について 大まかに説明すると 環境の基準となる2D画像を使用して アセットにシェーディングを 追加する手法です RealityKitでは このシェーディング手法を PBRマテリアルに採用しています イメージベースライティングを使う 一番の理由は ユーザーが部屋の明かりを点けた時など 現実世界の環境の変化に マテリアルを動的に反応させることです これは素晴らしい効果をもたらしますが 今回のシーンでは アセットの光源として 現実世界の環境ではなく 作成した環境を使用します そのためにいくつかのコンポーネントを 追加する必要があります まず Transformコンポーネントを作成して

用途がわかるように「IBL」と名付けます

次に Image Based Lightコンポーネントを アタッチします

ここで シーンを事前にレンダリングした 高ダイナミックレンジの画像を追加します

一部のテクスチャは 見た目を良くするため HDRにする必要があります

IBLテクスチャは エクイレクタングラーとも呼ばれる 緯度／経度の形式にします HDRテクスチャは読み込みとレンダリングの 負荷が大きいのですが このシーンでは反射率の高いオブジェクトを ほとんど使用しないので ごく小さなテクスチャを使うことにします このテクスチャの横幅は 512ピクセルで十分です スカイドームテクスチャより はるかに小さいサイズです 表面を鏡のようにしないのであれば ほとんどの場合 解像度も それほど必要ありません

この画像は まだアセットに 反映されていません

1つ足りないものがあるからです それがImage Based Light Receiverです PBRオブジェクトの親ノードを選択して Receiverを適用します

これはすべての 子エンティティに適用されます 先ほど作成したIBLエンティティを選択し 関連付けます ラベルを付けたのは このためです

アセットにシーンのライティングと 反射が表示されるようになりました

まとめると スカイボックスにはダイナミック レンジの低い大きなテクスチャが適しており unlitマテリアルが理想的です IBLには緯度／経度形式の HDRテクスチャが適しており 低解像度が理想的です その効果を表示するには Image-Based Lightingコンポーネントと Receiverを追加する必要があります マテリアルによっては unlitカラー以外の色も必要なものの PBRシェーダは不要な場合があります その場合 Shader Graphの Environment Radianceノードを 使うと良いでしょう この車輪のリムは金属製のはずですが ベイクされているので あまり金属らしく見えません

遠くから見ると良さそうですが 近づくと 反射がないことがわかります 先ほどのアセットのように unlitマテリアルではなく PBRマテリアルを使うべきだと 考える方もいるでしょうが Unlitシェーダを使ったまま 反射を実現する方法もあります 事前に分離していたこのアセットの マテリアルグラフで EnvironmentRadianceノードを 使用します

このノードでは unlitグラフ内のIBLから得た シェーディング情報を使用できます EnvironmentRadianceノードの 出力を見ると 見る角度によってシーンの反射が 変わることがわかります

拡散ライティングも使用できますが 今回は必要ありません 既にテクスチャにベイク済みだからです 今回は 鏡面反射輝度と ベイク済みのテクスチャを 合算してみましょう

これにより 視点によって変化する 鏡面反射を実現し マテリアルの見た目を金属らしくできます

Environment Radianceノードは 通常のunlitマテリアルより 使用負荷が大きいですが 完全なPBRマテリアルを使うよりは 負荷を抑えられます 動的なライティング効果は欲しいものの 完全なPBRを使いたくない場合に このノードを使うと良いでしょう 設定が完了し シーンの見た目が良くなりました

最終チェックとして Reality Composer Proの パネルでバジェットの 消費状況を確認しましょう 三角形の数は10万8,000個程度なので ポリゴン数の目標は問題ありません むしろ10万8,000個は上々です シーンをチャンクに分割しているので ユーザーが一度に見る三角形の数は その半分程度になるからです メッシュ テクスチャ マテリアルの 総数はごくわずかです テクスチャは1.2GBありますが まだテクスチャを圧縮していません Xcodeでこのアプリをコンパイルすると テクスチャは圧縮され サイズが約300MBにまで減ります また 透明マテリアルの量を最小限に抑え 可能な限りunlitシェーディングを 使用しました 最後に アプリのパフォーマンスと レンダリングをプロファイルする場合は RealityKit Traceがお勧めです シーン内のエンティティの デバッグだけを行いたい場合や 問題の原因となっているコードを 特定したい場合は 新しいRealityKit Debuggerが良いでしょう これらのツールの詳細については 画面のセッションをご覧ください

空間コンピューティング向けに 3Dコンテンツを 最適化する 様々な方法を紹介しました おさらいです ポリゴンの数を減らし 一度に表示される三角形の数に 着目しましょう アセットは画面上での 表示サイズに応じて最適化しましょう テクスチャパッキングでメモリを節約し 圧縮も利用しましょう unlitマテリアルとベイク済みテクスチャを できるだけ使用しましょう unlitマテリアルでは 足りない場合には EnvironmentRadianceノードを使います 最後に スカイボックスのテクスチャは 大きいサイズにし IBLテクスチャは小さくしましょう

イマーシブアプリ向けの リアルなカスタム環境の作成について 興味がある方は こちらのセッションをご覧ください 今回の内容を念頭におけば Apple Vision Pro向けの パフォーマンスが高く 高品質な 3Dコンテンツを作成することができます 皆さんが空間コンピューティングの世界に もたらすものを楽しみにしています ご視聴ありがとうございました