レンダリングとライティング
※ 翻訳には「Google AI Studio」を利用し、「Gemini Experimental 1206」のモデルを使用しています。
このガイドラインは、Khronos Groupの「3DC-Asset-Creation」で公開されている「Rendering and Lighting」を日本語に翻訳したものです。
原文のライセンス: Creative Commons Attribution 4.0 International License
レンダリングとライティング
バージョン 1.0.0
最終更新日: 2020年10月20日
ライティング
最良の結果を得るには、IBLを使用し、製品に内部照明がある場合はエミッシブを追加します。
(C)2020, Wayfauir. License: CC BY 4.0 International 図6.4: ライティング方法の比較
イメージベースドライティング (IBL)
これは、スペキュラー反射（光沢のある表面）とソフトディフューズライティング（粗い表面）の両方に使用されるパノラマ環境画像です。IBLは、パノラマハイダイナミックレンジ写真から作成することも、コンピュータグラフィックスシーンからレンダリングすることもできます。
解析ライト
これらは、シーン内で移動および回転できるライトです。これらはモデルの端に明確な輪郭を作成し、法線バンプテクスチャとうまく反応し、リアルタイムの影を落とすことができます。
解析ライトは、分析的、動的、または時間厳守とも呼ばれます。一般的なタイプは、ダイレクト、スポット、およびポイントです。
エミッシブ
表面の一部を、内部から照らされているかのように光らせることができます。エミッシブは通常、他の表面に光を投射しません。現在の表面が光っているように見えるだけです。エミッシブはライティングの影響を受けません。モデル上で完全に明るく表示され、加算的です。エミッシブは、テクスチャまたは単なる単色の値にすることができます。
アンビエント
単一のアンビエントカラーライティング値を使用できますが、使用しないことをお勧めします。これは物理ベースではなく、モデルを平坦化します。IBLを使用して、方向性と忠実度の高いアンビエントライティングを提供することをお勧めします。
影
特定の状況で必要とされる場合を除き、製品モデルの下に事前にベイクされたドロップシャドウを追加することはお勧めしません。
ビューアは動的に影を作成できます。モデルファイルに影の平面が含まれている場合、影が二重になったり、ちらついたりするなどの視覚的な競合が発生する可能性があります。3Dコマースアセットを作成するときは、モデルを多くの異なるビューアで再利用できるように、影の平面を含めないことをお勧めします。
モデルに影の平面を追加できる例の1つは、Facebook ARエフェクトで使用する場合です。ドロップシャドウ平面は、アセットが床を横切って移動するために持ち上げられていることを示すのに役立ちます。https://sparkar.facebook.com/ar-studio/learn/articles/3D/simple-shadows#choosing-an-occluder-object
(C)2020, Wayfauir. License: CC BY 4.0 International 図6.5: FacebookのSpark AR Studioで影の平面が追加されています（左）。ユーザーのデバイスのARでどのように表示されるか（右）。
アンビエントオクルージョン
現在、アンビエントオクルージョンを事前に計算し、マテリアルのテクスチャに保存することをお勧めします。（マテリアルのセクションを参照）
デバイスの性能が向上するにつれて、リアルタイムのアンビエントオクルージョンを使用することが可能になります。リアルタイムの動的オクルージョンには、スクリーンスペースアンビエントオクルージョン（SSAO）など、多くの種類があります。ただし、現時点では、モバイル、AR、VRデバイスは、フレームレートを十分なインタラクティブ速度に保ちながら動的オクルージョンを作成するのに十分な性能を備えていません。
ドローコール
一般に、モデルの個別のパーツが少ないほど、レンダリングが高速になります。マテリアルの数を最適化することは、コンテンツクリエーターにとって重要なタスクです。ドローコールの上限については、パブリッシングターゲットのセクションを参照してください。
「ドローコール」とは、グラフィックス処理ユニット（GPU）が3Dモデルをレンダリングする方法です。同じマテリアルを共有する頂点のバッチが一緒にロードされ、レンダリングされます。ドローコールが多すぎると、レンダリングAPIはドローコール間で同じモデル状態を再利用できず、フレームレートが低下します。
ただし、各ドローコールのオーバーヘッドはAPIごとに異なります（例：OpenGLとVulkan）。アプリケーションの許容制限を評価するには、ケースバイケースでパフォーマンスを評価する必要があります。
(C)2020, Wayfair. License: CC BY 4.0 International 図6.1: 4つのマテリアルを使用した椅子
上記の椅子の例では、4つのマテリアルが使用されています。これは、ほとんどのリアルタイムデバイスで問題なく動作します。メモリが限られているか、GPUが遅いデバイスでモデルをレンダリングする必要がある場合は、モデル全体に単一のマテリアルが必要になる場合があります。
(C)2020, Wayfair. License: CC BY 4.0 International 図6.2: 4つのマテリアル（左）が1つのマテリアル（右）に結合されています
単一のマテリアルを使用することには、利点と欠点があります。最善の方法を見つけるには、状況に応じてトレードオフを比較する必要があります。
-
複数のマテリアルを1つのマテリアルに結合すると、一般的にモデルのレンダリング速度が向上し、ファイルサイズが小さくなり、消費者の待ち時間が短縮されます。
-
単一のマテリアルに結合すると、テクスチャがぼやける傾向があります。各パーツのテクスチャスペースが少なくなり、結合されたテクスチャでタイリングを使用できません。モデルは、小さいデバイスではまだ問題なく見える場合があります。
-
マテリアルのバリエーションは、結合されたマテリアルではうまく機能しません。椅子に異なるファブリックの色がある場合、大きなマルチサーフェスマテリアルをスワップするよりも、ファブリックの変更のみを含むマテリアルをスワップする方が一般的に効率的です。マテリアルのバリエーションを、テクスチャを変更するのではなく、単色または値で表すことができる場合、ファイルサイズを非常に小さくすることができ、ダウンロード速度を向上させることができるため、さらに優れています。値または色のパーツごとの変更には、個別のマテリアルが必要です。
-
複数のパーツに独自のバリエーションがある場合、複雑さは指数関数的に増加します。たとえば、椅子にファブリック、木材、金属のマテリアルがあり、それぞれに独自のバリエーションのセットがある場合、バリエーションの組み合わせごとに1つずつ、多数の結合されたマテリアルを生成する必要があります。
ドローコールとオーバードロー
オブジェクト上の各メッシュと、そのメッシュ上の各マテリアルについて、レンダラーは、画面のピクセルに変換するために表示される三角形を計算する必要 があります。これをドローコールと呼びます。ドローコールごとに、三角形とマテリアルをロードして処理する必要がありますが、これはAPIの実装によって異なる場合があります。これはWebGLとGLESで発生しますが、Vulkanまたはそれ以降のバージョンのDirectXでは異なります。オーバーヘッドのコストは、コマンド構造とこれらの新しいAPI実装のドライバーのチェックの削除により大幅に削減されます。ただし、ロードプロセスには常にオーバーヘッドがあるため、より多くのメッシュを単一のオブジェクトに結合する方が効率的です。
複数のメッシュが必要な例外は、透明なコンポーネントの場合です。各ドローコールは、Photoshopのレイヤーのようなものと考えることができます。単一のメッシュに透明度がある場合、単一のドローコールでは、透明な領域の背後に何も表示されません。その透明な部分が別のメッシュである場合、レンダラーは一方をもう一方の上に描画し、透明な部分がソリッドメッシュの上にレイヤーされ、マテリアルを通して見ることができるようになります。
メッシュ数とパフォーマンス
静的アセットに関する推奨事項は、モデルを簡素化し、ビューアで表示される可能性のあるアーティファクトの量を削減するために、可能な場合はすべてのソリッドメッシュをすべての透明メッシュから分離することです。モデル全体を簡素化する必要があ る場合は、すべてのソリッドメッシュを単一のオブジェクトに結合できます。必要に応じて、すべての透明メッシュを1つ以上の個別のオブジェクトに分離できます。
(C)2020, Khronos. License: CC BY 4.0 International 図6.3: バギーのサンプルモデルの149のドローコール、BabylonJSサンドボックス
上の図は、Babylon.js Sandbox Webアプリケーション内でレンダリングされたバギーglTFファイルを示しています。右側のパネルに示されているように、このレンダリングエンジン内では、このアセットは149のドローコールになります。
実行時アプリケーションでそれらを分離する必要がない場合（たとえば、パーツを個別に非表示/表示できるようにするため）、アセット作成中にいくつかのパーツを一緒にバッチ処理することで、ドローの量を大幅に削減できます。
カラースペース
sRGBカラースペースは、ベースカラーやエミッシブテクスチャなど、写真から派生することが多いカラー画像を保存および表示するためによく使用されます。色は、コンピューターディスプレイの2.2ガンマ応答曲線に似た非線形値曲線を使用して保存され、人間の視覚システムが色の値に応答する方法に似ています。値は、人間が識別できる光レベルをより適切に保存および表示するために、曲線を使用してバイアス されます。
他のすべてのテクスチャは、線形値を使用して保存する必要があります。sRGB線形で保存するには、ガンマ値1.0を使用します。これにより、値は曲線を含まない純粋に線形の進行で保存され、ソースコンテンツの元の数学的進行を維持するのに役立ちます。sRGB線形は、アルファカバレッジ、メタルネス、ラフネス、ノーマル、オクルージョンなど、純粋に数学的な機能を制御するテクスチャを保存するために使用する必要があります。
ベースカラーとエミッシブテクスチャは、常にsRGBカラースペースで保存する必要があります。他のすべてのテクスチャは、sRGB線形で保存する必要があります。線形テクスチャは、常にsRGB線形で作成、編集、および使用する必要があります。そうしないと、画像とレンダリングエラーが発生します。
ほとんどのリアルタイムシェーダー、マテリアル、ビューアはこれを処理します。ただし、多くのコンテンツ作成ソフトウェアツールは、カラースペースを正しく処理しません。