物理ベースレンダリングーーHaarウェーブレット基底に基づくグローバルイルミネーション

前回は、球面調和関数(Spherical Hamonies、略してSH)に基づく動的グローバルイルミネーションアルゴリズムを紹介しました。そのアイデアは、オブジェクト間の光の複雑な伝達プロセスを伝達関数と見なすことです。伝達関数は、事前にシミュレートおよび計算され、SH基底関数によって近似されます。同時に、リアルタイム照明計算では、入射環境光はSH基底関数で近似されるため、照明レンダリング結果は、2つのSH基底関数の内積で計算できます。このアルゴリズムは、事前計算シミュレーションによるリアルタイム計算の複雑さを大幅に軽減するため、リアルタイム動的光源のグローバルイルミネーションレンダリングをサポートできます。ただし、このアルゴリズムには欠点があります。つまり、低周波数のレンダリングしか取得できません。したがって、SHベースのPRTは、AO(Ambient Occlusion)と同様のソフトシャドウのみをレンダリングでき、明確な輪郭や境界を持つ実際のシャドウをレンダリングすることはできません。

 

本日紹介したい記事は、2003年のSiggraphカンファレンスでRen Ng他によって発表され、現在400回以上引用されていた『All-Frequency Shadows Using Non-linear Wavelet LightingApproximation』です。この論文では、著者は線形SH変換の代わりに非線形ウェーブレット変換を使用するPRTアルゴリズムを提案します。実験結果により、以前のSH関数と比べ、同じ数のウェーブレット関数を使用した場合は、グローバルイルミネーションの高周波情報をより適切にキャプチャできます。従って、アルゴリズムは、鋭いエッジを持つリアルタイムの影など、よりリアルなGI効果をレンダリングできます。

まず、上記のように、この論文の効果図を見てみましょう。その中で、左図はSHベースのPRTのレンダリング結果で、右図はウェーブレットに基づくPRTのレンダリング結果です。両方の図は同じ数の基底関数項を使用しています。左図では100個のSH基底関数が使用され、右の画像では100個のウェーブレット基底関数が使用されています。中央の6つの正方形のテクスチャは、環境光のスタンプです。左右図のシャドウレンダリング効果を比較すると、右図のシャドウエッジがより鮮明になり、左図がぼやけていることがわかります。したがって、同じ数の基底関数を使用する場合、ウェーブレット変換はSH変換よりも高い周波数の照明情報をキャプチャでき、レンダリング結果は実際の状況に近くなります。次に、本論文のアルゴリズムの主な内容を詳細に紹介します。


 

一、アルゴリズムと実装

 

すべてのレンダリングの問題は、実際にはレンダリング方程式の計算の問題を解決しています。この論文も例外ではないので、レンダリング方程式から始めましょう。オブジェクトの表面上の点xを考え、その法線方向がnである場合、その点からωoの方向に反射された光P(x、ωo)は次のように表すことができます。

 

このうち、Lは入射光強度、Vは可視性関数、frはBRDF関数、nは法線方向、ωは入射光方向です。

論文のアルゴリズムは2つの状況に適用できます:1)視点が変化し、材質がDiffuseに制限されます。2)視点は変更されず、材質は任意です。次に、これら2つのケースのそれぞれのソリューションを紹介します。

 

1.1視点は可変で、材質はDiffuse拡散に制限されてい

材質がDiffuseに制限されている場合、伝達関数は次のように表すことができます。

 

1.2視点は変わらず、材質は任意

材質が任意の場合、伝達関数は次のように表すことができます。

 

その中で、視点が固定されているため、ωoはxにのみ関係します。

 

レンダリング方程式の積分は、入射光の強度Lと、入射光の方向ωに関する他の項の畳み込みとして見ることができます。離散化後、対応する項が乗算されてから合計されます。したがって、各点xiについて、その照明計算は次のように表すことができます。

 

行列とベクトルの形式で表現すると、次のように簡略化できます。P = T・L。その概略図を次の図に示します。

1.3事前計算

事前計算段階では、論文の著者は2つの方法を使用しました。1番目の方法は、伝達行列Tの1列の計算を一度にシミュレートすること、つまり、入射光ベクトルLの各方向ωを計算することです。計算方法はレイトレーシングです。したがって、Tの各列ベクトルは、環境光スタンプの各ピクセルのシーンを照らした結果を表します。この方法は比較的単純で、さまざまなグローバルイルミネーション効果をサポートしますが、固定視点の場合のみをサポートします。

 

2番目の方法は、伝達行列Tの1行の計算をシミュレートすることです。この方法は、直接照明部分のみを計算します。したがって、伝達行列の各行は、次の図に示すように、オブジェクトの表面上の点xの可視性立方体スタンプに、BRDFおよびCosine項の重みを加えたものを表します。

上図は、シーン内のいくつかの頂点の事前計算結果です。その中で、1番目の図はシーンの下部パッチ上の特定の点の事前計算結果であり、2番目の図は植物の下の特定の点の事前計算結果であり、3番目の図は植物の葉の上の特定の点の事前計算結果です。このアプローチは、ラスター化されたグラフィックハードウェアで実装できます。論文の著者は、最初に各点xの高解像度半立方体可視性スタンプをレンダリングします。次に、BRDFおよびCosine項の重み値を計算し、環境スタンプと同じ解像度にダウンサンプリングします。

 

1.4リアルタイムレンダリング

リアルタイムレンダリングでは、論文の著者はまず、2Dハールウェーブレット変換を介して環境光スタンプの対応する係数ベクトルLを計算します。次に、入射光の一部を選択して計算します。その主な目的は、エネルギーが低い入射光を削除することにより、計算量を減らすことです。この論文の著者は、3つのフィルタリング方法を使用しました。 1つ目は、Haarウェーブレット係数のサイズで直接フィルタリングすること、2つ目は、伝達行列の対応する列を使用して重みを計算すること、3つ目は、光源の面積でフィルタリングすることです。次に、LとTの積を計算して、最終的なレンダリング結果を取得します。ウェーブレット変換後の係数ベクトルと行列は非常に大きなスパースベクトルと行列であり、当時のGPUは一般的なスパース行列の乗算演算をサポートできなかったため、計算プロセス全体がCPU側で実行されます。


 

二、効果の比較

 

論文の著者は、SH基底関数とウェーブレット基底関数をそれぞれ使用して環境光スタンプをシミュレートし、異なる数の基底関数を使用した場合の結果と元の環境テクスチャの違いを比較します。次の図のように示します。

その中で、左と右の図は、2つの異なる環境光スタンプのシミュレーション結果です。左と右の図で、左の列はそれぞれ100、4096、10000のSH基底関数項を持つ環境光スタンプのシミュレーション結果であり、右の列の2つの図は100と4096のウェーブレット基底関数を持つ環境光スタンプのシミュレーション結果です。3番目は元の環境光スタンプを示しています。SHとウェーブレットのシミュレーション結果を比較すると、比較的単純な環境光スタンプの場合、ウェーブレット基底関数は高周波情報をキャプチャするために100項しか必要としないのに対し、SHは同様の結果を達成するために4096項を必要とすることがわかります。複雑な環境光スタンプの場合、ウェーブレット基底関数は元のテクスチャを復元するために4096項しか必要としませんが、SHは10000項を使用しても元のテクスチャをうまく復元できません。

 

ウェーブレット変換が非常に少ない項で全周波数照明情報をキャプチャできる理由は、次の図に示すように、ウェーブレット変換後、ほとんどの項の係数がゼロまたはゼロに近くなるためです。

実験を通じて、ウェーブレット変換後の非ゼロ項の割合はわずか0.1%〜1%であることがわかりました。ウェーブレット変換は、完全な周波数情報を圧縮することと同じです。したがって、ウェーブレット変換は、同じ項数でSHよりも多くの照明情報をキャプチャできます。ただし、ウェーブレット変換にも制限があります。 SHの回転不変性がないため、伝達関数では法線方向nは位置変数xの関数として扱われます。これは、ウェーブレット変換に基づくPRTは、オブジェクトを回転させた結果をリアルタイムでレンダリングできないことを意味します。SHにはこの制限はありません。これは、その後の研究でウェーブレット変換に基づくPRTの開発が限られている主な理由の1つでもあります。

 

論文の著者は、次の図に示すように、異なる項数のSH基底関数とウェーブレット基底関数の環境光スタンプに対する近似結果と元の図の間のL2誤差を比較します。

項の数が増えると、SHとウェーブレットの両方の近似誤差が減少することがわかります。ただし、ウェーブレットはより速く収束し、1000では10000項でのSHの誤差よりも小さくなります。


 

三、より多くのレンダリング結果

 

論文の著者は、実験用にさらに多くのシーンをレンダリングします。次の表は、さまざまなシーンでの環境光スタンプのサンプリングの解像度、スパース行列内の非ゼロ項の割合、およびメモリ使用量を示しています。

より多くのレンダリング結果が下の図に示されています。上の行はSHレンダリング結果であり、下の行はHaarウェーブレットレンダリング結果です。左から右にとられる基底関数の項は徐々に増加します。Haarウェーブレットは、同じ数の基底関数項の下でSHによってレンダリングされたシャドウの結果よりも高周波の詳細を持っていることがわかります。


 

四、まとめ

 

論文では、Haarウェーブレット関数をPRTの基底関数として使用し、全周波数情報を保存できるグローバルイルミネーション効果をリアルタイムでレンダリングすることを提案します。球面調和関数の基底関数と比較して、Haarウェーブレットの基底関数も標準的な直交性を持っています。同時に、圧縮率が高いため、非常に少ないパラメーターでレンダリング効果の高周波情報を保持できるため、完全な周波数照明のレンダリング効果を実現できます。Haarウェーブレットは、独自の特性のため、その後のグローバルイルミネーションレンダリングでは広く使用されていませんが、グローバルイルミネーションのリアルタイムレンダリングの研究分野に消えることのない貢献をしています。


 

五、論文情報

 

参考ビデオURL:https://v.qq.com/x/page/n0384trr1va.html

 

著者について:

レン・ン、現在UC Berkeleyに所属

個人のホームページ:https://www2.eecs.berkeley.edu/Faculty/Homepages/yirenng.html

 

有名なコンピュータグラフィックス学者であるRaviRamamoorthiは、現在、UCSDの教授です。コンピュータグラフィックスの大物で、数多くの論文を発表しました

個人のホームページ:https://cseweb.ucsd.edu/~ravir/

 

有名なコンピュータグラフィックス学者であるPat Hanrahanは、現在スタンフォード大学の教授です。コンピューターグラフィックスの大物で、かつてPixarで働いていて、RenderMan Shading Languageの開発者の1人です。

個人のホームページ:https://graphics.stanford.edu/~hanrahan/

 

ダウンロードリンク:

https://graphics.stanford.edu/papers/allfreq/allfreq.pdf


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com

おすすめのAIプラグイン

1)おすすめのAIプラグイン

2)VideoPlayerはAndroidでビデオを再生したら黒画面になる

3)Renderer.GetPropertyBlockの問題

4)RectMask2Dの問題


 

AI

Q:新しいプロジェクトにはいくつかのAIがあり、それを実装するためにいくつかのプラグインを使用したいと思います。推奨するAIプラグインはありますか?私の知る限り、Behavior Designer、Playmaker、Boltなどがあります。いくつかの機能とパフォーマンスが良いものを推奨してくれませんか?

 

A1:NodeCanvasをお勧めします。

優れた点:

  • 3つの完全に切り替え可能なグラフィックモジュールから選択できます。
  • 期待されるすべてのプロフェッショナル機能を備えた、スタイリッシュで直感的なビジュアルノードエディタ。

(すべて元に戻す・やり直し、ズームイン・アウト(拡大・縮小)、ミニマップ、複数選択、コピー、コピー・貼り付け、JSONインポート・エクスポート、グループとコメントなど)

  • 再利用可能でエージェント中心のパラメトリック動作を作成するためのグラフィックス、GameObject、およびグローバル黒板変数。
  • インスタンスまたは静的プロパティとフィールドを持つデータバインド変数。
  • UNETのネットワーク同期変数を使用します。

(UNETは現在廃止されているため、新しいネットワーキングソリューションに置き換えられます)

  • プレハブでオーバーライドできる変数。
  • さまざまな変数データ型の自動変換。
  • すぐに使用できるすべての変数タイプをサポートします。
  • すべての数のエージェント(Agent)にわたる再利用可能な動作グラフ。
  • 3つのグラフィックモジュールすべての間のシームレスなサブグラフィックネスト。

(動作サブツリー、サブステートマシン、サブダイアログツリー)

  • 完全なサブグラフ変数のパラメーター化とスタンプ。
  • モジュラーアクションと条件付きタスクの設計。
  • 条件付き応答動作ツリーの評価。
  • 条件付きおよびスタックベースのFSM遷移。
  • カラフルで有益なランタイムビジュアルデバッグ。
  • 内蔵ドキュメントを検索、お気に入りに登録、および読み取るためのノード/タスクブラウザ。
  • プロジェクトのニーズに応じてタイプ関連のメニューをカスタマイズするための優先タイプコンフィギュレータ。
  • グラフィックを楽に閲覧するためのグラフィカルミニマップ。
  • グラフィカルコンソール。マウスをクリックすることで、障害のあるノードを自動的に見つけることができます。
  • グラフブラウザを使用して、グラフ内のノード、タスク、およびパラメータを検索します。
  • 欠落しているノード、タスク、およびリフレクション参照をバッチで再構築するためのグラフ再構築機能。
  • 設計目標をより素早く完了するためのリアルタイムのランタイム編集。
  • 既存のコードAPIを自動的に統合するために最適化されたリフレクションタスク。
  • グラフィックスでデータを通信および転送するための内蔵イベントシステム。
  • NodeCanvasフレームワークを拡張し、独自のアクション、条件、ノード、さらにはまったく新しいグラフィックモジュールを作成するための明確で十分に文書化されたAPI。
  • あらゆる方法でインスペクターをカスタマイズするためのオブジェクトおよびプロパティペインタ。
  • 多数のサードパーティアセットと統合します。
  • FlowCanvasflowScriptsとのシームレスな統合。
  • ユーザーフレンドリーで軽量、設定は不要です。
  • 安定したパフォーマンス、初期化後のゼロ割り当て、非同期グラフの読み込み。
  • すぐに使用できるすべてのプラットフォームをサポートします。
  • すべてのC#ソースコードが含まれています。

詳細なリンクは次のとおりです。

https://assetstore.unity.com/packages/tools/visual-scripting/nodecanvas-14914

Behaviacも優れていますが、残念ながらTXはあまり維持されていません。

https://github.com/Tencent/behaviac/

A2:Baracudaをお勧めします。

https://github.com/Unity-Technologies/barracuda-release

A3:ゲームAIフレームワークの選択についての投稿を:《What A.I technique is most suited to my game, FSM, BT, GOAP》

AI関連のブログを添付する:AI共有ステーション

http://www.aisharing.com/sitemap

 

A4:Tencentオープンソースプロジェクト:behaviac

behaviacは、ゲームAIの開発フレームワークコンポーネントであり、ゲームプロトタイプの迅速な設計ツールです。すべてのプラットフォームをサポートし、クライアントとサーバーの両方に適しており、ゲームの迅速な反復型開発を支援します。

エディターはPC上で実行でき、操作は便利で直感的で信頼性が高く、リアルタイムおよびオフラインのデバッグをサポートします。エディターはxml、bson、その他の形式をエクスポートでき、C ++、C#ソースコードもエクスポートできて効率が向上します。

ランタイムは、C ++とC#の2つのバージョンを含むすべてのプラットフォームをサポートし、Unityをネイティブにサポートします。


 

Video

Q:この問題はプロジェクトAでのみ発生します。同じビデオとコードを新しいプロジェクトにコピーしてから、ビデオファイルをAddressables Groupに入れ、非圧縮に設定します。携帯電話でビルドすると、通常どおり再生できます。ただし、プロジェクトAでは、ビデオをAddressables Groupに入れ、非圧縮に設定しましたが、それでも再生できず、エラーが報告されます。

 

AndroidVideoMedia::OpenExtractor could not translate archive:/CAB-abafc77eff58910e7bc5f69ce62a4ed7/CAB-abafc77eff58910e7bc5f69ce62a4ed7.resource to local file. Make sure file exists, is on disk (not in memory) and not compressed.

 

このような問題が発生したことがありますか?

A:Addressables Groupで非圧縮と設定していますが、携帯電話でビデオを再生することはできません。したがって、どこでBundleを圧縮したのかと考え、やはりbuild.gradleで見つかりました。次のように、gradleのnoCompressに「.bundle」を追加する必要があります。

aaptOptions {
noCompress ‘.unity3d’, ‘.ress’, ‘.resource’, ‘.obb’, ‘.meta’, ‘.wem’, ‘.bnk’, ‘.txt’, ‘.xml’,’.bundle’ //ADD_NoCompress_TAG
}

 

Rendering

Q:コード印刷ログから、GetPropertyBlockは最初に取得したのは何でしょうか?何の用もないようです:

public MeshRenderer mr;
    [Button]
    void DOTest()
    {
        MaterialPropertyBlock block = new MaterialPropertyBlock();
        mr.GetPropertyBlock(block);
        Debug.Log(block.isEmpty);      //trueをプリントする
        Color baseColor = block.GetColor("_Color");
        Debug.Log(baseColor.ToString());      //オリジナルは白で (0,0,0,0)をプリントしたら何も取得されていない

        block.SetColor("_Color", Color.red);    //色を設定する
        mr.SetPropertyBlock(block);

        mr.GetPropertyBlock(block);        //再取得する
        Debug.Log(block.isEmpty);  // falseをプリントする
        baseColor = block.GetColor("_Color");
        Debug.Log(baseColor.ToString());    //(1,0,0,1)をプリントする

    }

 

もともと、Renderer.GetPropertyBlock(block)を介してRendererのマテリアルプロパティがBlockに格納されたと考え、その後内部の値を変更すると思っていましたが、そうではありません。たとえば、Alphaだけを変更したいと思いますが、元の色を取得できません:

MaterialPropertyBlock block = new MaterialPropertyBlock(); 
meshRenderer.GetPropertyBlock(block); 
Color baseColor = block.GetColor("_Color"); 
block.SetColor("_Color", new Color(baseColor.r, baseColor.g, baseColor.b, alpha)); 
meshRenderer.SetPropertyBlock(block);

 

A1:まず、Propertyにプロパティを追加しなかったため、Emptyであるはずです。つまり、プロパティシートは空のリストです。次に、Setcolorを使用して、プロパティフィールドをプロパティシートに追加してから、リストは空ではなくなります。プリントされたのは白である理由については、これがデフォルト値だと思います。つまり、存在しないプロパティにアクセスしてnullが返されないようにすると、デフォルト値が与えられます(これは推測です)。

元の色を取得するには、メティリアルから直接取得します。

var mat = renderer.material;//renderer.sharedMaterial; Color c = mat.GetColor("_Color"); Debug.Log(c.ToString());

A2:Renderer.HasPropertyBlock()を使用して、RendererがすでにPropertyBlockを持っているかどうかを判断できます。通常、SetPropertyBlockを呼び出す前に、GetPropertyBlockは「null」の結果を取得します。特殊なケースがあります。アニメーションでシェーダーを制御するために使用された後(シェーダーの色を制御するなど)、GetPropertyBlockを使用してMaterialPropertyBlockを取得すると、得られる結果は「空」ではありません。理論的には、アニメーションコントロールシェーダーでは、SetPropertyBlockで色の変更を実現したのです。

 


 

UGUI

 

Q:RectMask2dを使用してScrollviewノードの下にいくつかのアイコンを動的に作成しましたが、ページを開いたときにアイコンが正常に表示されず、スワイプした後にのみ表示されることがわかりました。アイコンオブジェクトが表示されていないときに作成されていることを確認しました。対応するInspectorウィンドウにはDefault UI Shaderというコンポーネンがなくなります。理由を知っている人はいますか?

 

Debugにより、アイコンオブジェクトをRectMask2dのクリッピングHashsetに通常どおり追加できることがわかりました。Frame Debugでアイコンが表示および表示されない場合、Batchが1つ少なくなります。

 

A:動的作成が完了した後、Canvas.ForceUpdateCanvasesを呼び出すことを試して下さい。このインターフェイスは、すべてのUI要素を時間内に更新するためのものです。

https://docs.unity3d.com/ScriptReference/Canvas.ForceUpdateCanvases.html


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com

物理ベースレンダリング-球面調和基底に基づくリアルタイムのグローバルイルミネーション

この記事の主な内容であるPRTを紹介する前に、まずゲームエンジンレンダリングパイプラインでよく見られる一つのステップであるIBLを紹介します。Disneyは、2012 Siggraphカンファレンスで公開されたPBR courseで、レンダリング結果をよりリアルにするためにPBRレンダリングパイプラインにIBL(Image Based Lighting)を追加したと述べました。現在、IBLはPBRレンダリングパイプラインのほぼ不可欠な部分になっています(たとえば、多くのエンジンはSkyBoxを環境光スタンプとして提供するか、シーンの環境光スタンプを取得するためのサンプリングツールを提供し、このスタンプを使用してシーンの物体をレンダリングします。)。

 

IBLとは何ですか?なぜそれを使用する必要がありますか?実際、初期のリアルタイムレンダリングでは、方向光を使用して無限の太陽光をシミュレートし、光源を使用して近くのライトをシミュレートしました。しかし実際には、物体がシーン内にある場合、物体はすべての方向からの入射光によって照らされます。これらの入射光は、光源から取得するだけでなく、物体の表面の拡散反射、鏡面反射、屈折、さらには霧の中の散乱光からも取得できます。四方八方からのリアル的な入射光をシミュレートするために、IBLのアイデアは次のとおりです:シーン内の物理が閉じた立方体に囲まれていると仮定すると、シーン内でそれに当たる光は必ず、立方体6つの面からに違いない。物体の周囲のシーンを6つの面にレンダリングして入射光にすれば、これらの6つのは、光源、物体表面反射、霧の散乱などからのあらゆる種類の光をカバーします。

 

IBLは、実際に撮られた環境光スタンプを入射光として使用するため、実際の環境で物体がどのように照らされるかをより現実的にシミュレートできます。ただし、このアルゴリズムでは、立方体の環境スタンプをサンプリングし、環境スタンプのすべての方向からの入射光から物体の照明情報を計算する必要があります。このプロセスは非常に時間がかかり、GPUの並列処理でさえもリアルタイム完了できません。したがって、入射光と半球表面の材質の畳み込み計算を球面調和関数(Spherical Harmonic Function、SHと略称)の内積に変換して、リアルタイム計算のコストを削減することを提案しました。本日紹介する論文はIBLに基づいており、これに基づいてグローバルイルミネーションを導入し、リアルタイムのグローバルイルミネーションの効果を実現しています。

 

この記事は、2002年のSiggraphカンファレンスでPeter-PikeSloanが発表した論文です。グローバルイルミネーション計算にある不変の事前計算を保存し、リアルタイムレンダリング中に変更された部分を計算するだけでよい事前計算方法を提案します。これにより、リアルタイムレンダリングの時間コストが大幅に削減されます。この論文のアルゴリズムは、リアルタイムのグローバルイルミネーションを実現する最初のレンダリングアルゴリズムであり、その後、有名なPRT(Precomputed Radiance Transfer)である研究が盛んになってきます

 

次の図に示すように、まずこの論文のレンダリング結果を見てみましょう。

 

その中で、左図はグローバルイルミネーションなしの結果であり、右図はグローバルイルミネーションありの結果です。左側と右側を比較すると、右図にAO(AmbientOcclusion)が追加されているため、右側のモデルサーフェスのくぼんだ部分が左側よりも暗いことがわかります。同時に、右の図は、表面の多重反射照明の計算も追加しています。これらの効果はリアルタイムで計算されますが、モンテカルロレイトレーシング、ラジオシティ、マルチパスポイントライトなどの従来のグローバルイルミネーションアルゴリズムでは実現できません。

 

グローバルイルミネーション効果をリアルタイムでレンダリングするには、3つの難点があります。1)複雑なBRDFをシミュレートする必要がある、2)入射光の半球積分を計算する必要がある、3)オクルージョンを計算する必要がある。物体の表面に多重反射がある。

この論文の著者は、これらの複雑な照明計算プロセスを光伝達関数(Transfer Function)と見なし、入射光情報を関数の入力と見なしています。また、球面調和関数、光線伝達の線形性と事前計算を使用して、入射光が物体間での多重反射という複雑な計算を、簡単で高速な内部積計算に変更ます。著者は低次の球面調和関数を使用して表示しているため、低周波の照明情報のみが考慮されます(環境光のスタンプはあまり変化しません)。 PRTアルゴリズムのフローチャートを次の図に示します。

上図はDiffuse材質のフローチャート、下図はGlossy材質のフローチャートです。上図からわかるように、PRTアルゴリズムは最初に環境光スタンプをSHに投影し、SH係数ベクトルを計算します。次に、オフライングローバルイルミネーションアルゴリズムを使用して物体のグローバルイルミネーションをシミュレートし、伝達関数を計算します。また、伝達関数をSHに投影して、係数ベクトルを取得します。最後に、リアルタイム計算では、物体の表面の光は、光のSH係数ベクトルと事前に計算された伝達関数のSH係数ベクトルの内積をとることによって計算できます。Diffuse材質は視線の方向に依存しないため、伝達関数は1つのベクトルだけで表せます。ただし、Glossy材質の場合、異なる視点から物体の表面の同じ点を観察するには、異なる照明を持ちます。したがって、Glossy材質の伝達関数は、異方向の視線次元を増やしてマトリックスにする必要があります。リアルタイム計算では、Diffuseと同じように、光ベクトルに伝達関数行列を掛けて、伝達された入射光ベクトルを取得します。次に、このベクトルを物体材質BRDFと畳み込み、すべての方向の反射光を表すベクトルを取得します。最後に、このベクトルから、視線の方向の反射光線が計算されます。次に、本稿の主な内容をご紹介します。


 

一、球面調和基底関数の紹介

 

PRTアルゴリズムは、重要な数学的ツールである球面調和基底関数を利用します。SHは、フーリエ変換が1次元変数で定義され、SHが2次元球面で定義されることを除いて、フーリエ変換に似ています。レンダリング方程式の積分は2次元球面の方向に定義されるため、SHはレンダリング方程式の計算問題を解決するのに非常に適しています。同様に、2次元球面で定義された関数は、SH基底関数と係数で近似できます。lとmを使用してSHの2つのパラメーターを表す場合、f(s)は球で定義された関数であり、ylmは基底関数である場合、SHでのf(s)の投影係数は次のように表すことができます。

 

f(s)は、おおよそ次のように表すことができます。

 

PRTは、SHの2つの特性、1)回転不変性と2)直交性を利用します。回転不変性により、環境光スタンプをSHに投影した後、物体の表面に対する任意の法線方向を回転してサンプルできます。直交性は、球面で定義された任意の2つの関数について、畳み込み計算を対応するSH係数の内積に変換できることを保証します。


 

二、伝達関数の紹介

 

2.1Diffuse材質

物体の表面での多重反射を考慮せずに、材質がDiffuseである物体Oの場合、その表面上の点p∈Oでのレンダリング方程式は次のように表すことができます。

 

このうち、HNP(s)= max(Np。s、0)は余弦項、Npはp点の法線方向、ρpはp点の色、Lpは入射光、可視性関数Vp(s)→{0,1}、オクルージョンされている場合は0を取り、それ以外の場合は1を取ります。したがって、伝達関数MpDSは次のように表すことができます。

 

その中で、LpとMpはそれぞれSHに投影され、TDSの積分計算はSH係数ベクトルの内積になります。

物体の表面での複数の反射を考慮する場合、点pのレンダリング方程式は次のように表すことができます。

 

ここで、L’P(s)は、s方向から点pに入射する物体Oからの光を表します。TDIの伝達関数MpDIの場合、完全な式で表現することは困難です。ただし、実装では、表面反射を複数回繰り返すことでMpDIを計算できます。

 

2.2 Glossy材質

Diffuse材質と同様に、Glossy材質のレンダリング方程式は次のように表すことができます。

 

ここで、G(s、R、r)は点pでのBRDF、Rは反射光の方向、rはGlossyのパラメータです。Glossy材質は、光の入射方向sだけに関わっているだけではないため、その伝達関数をベクトルだけで表すことはできません。論文の著者によって提案された方法は、入射光LP(s)を伝達後の入射光L’P(s)に変換することです。GがRに関して対称であると仮定すると、最終結果は、L’P(s)をG(s、(0,0,1)、r)で畳み込むことによって計算できます。したがって、LP(s)からL’P(s)への伝達関数は次のように表すことができます。


 

三、事前計算とリアルタイムレンダリング

 

この論文の著者は、複数回シミュレーション方法で伝達関数を事前に計算しています。最初は、物体Oの点pについて、直接照明の結果のみが計算されます。そして、物体によって遮られる光線について、その方向から反射された光線を繰り返し計算し続けます。そして、その後の反復計算では、以前の照明結果がそれに追加されます。各点での伝達関数を計算するとき、論文の著者は10k〜30kの方向をサンプリングします。照明の計算と同時に、オクルージョン情報も計算されます。反復回数の増加に伴い、エネルギーが特定のしきい値に減衰したら、反復を停止して計算を終了します。

 

リアルタイムでレンダリングする場合、次の手順が実行されます。

1)物体Oの入射光Lpを計算します。

2)LpをO法線方向のローカル座標に回転させます。

3)LpベクトルとMpベクトルの内積を行うか、Mp行列を乗算します。

4)Glossy物体の場合、伝達後の入射光L’pをBRDFで畳み込み、R方向の反射光を計算します。

 

異なる物体間で複数の反射光線を計算する必要がある場合は、単一の物体と同じ反復計算が使用されますが、反復中に、それ自体からの反射光だけでなく、他の物体からの反射光も計算されます。


 

四、実験結果

 

論文の著者は、さまざまなシーンを使用して実験を行い、そのすべてがリアルタイムのフレームレートを達成できます。実験データを下図に示します。

 

より多くのレンダリング結果の比較を以下に示します。

 


 

まとめ

 

この論文の著者は、SHの回転不変性と直交性を利用して、事前計算で物体を照らすときの光伝達のプロセスをシミュレートし、このプロセスの伝達関数をSHに投影します。リアルタイムレンダリングでは、SH上の光源の投影係数を計算し、伝達関数のSH投影を使用して内積を実行して照明情報を計算するだけで済みます。このアルゴリズムは、グローバルライトをリアルタイムで計算する効果を実現します。

 

PRTは、リアルタイムのグローバルイルミネーションの方法を提供するだけでなく、さらに重要なことに、リアルタイムのレンダリングパフォーマンスを最適化するためのアイデア、つまり事前計算を提供します。どのレンダリング計算でも、事前計算とリアルタイム計算のバランスを見つけることができます。リアルタイムの要件が高く、ハードウェアのパフォーマンスが要件を満たしていない場合は、事前にいくつかの計算を行ってから、少量な必要な変数をいくつか保持することができます。リアルタイム計算では、テーブルを検索して事前計算結果を読み取り、簡単なフィッティングで最終結果を計算します。もちろん、事前計算方式を使用する場合は、サンプリングが必要であり、ストレージ容量が増加することを意味します。さらに、入力環境が変化しても、事前に計算された変数は変化しないため、必然的に制約が生じます。たとえば、この記事で紹介した論文のPRTは、伝達関数を使用して物体間の光線の伝達プロセスを事前に計算するため、静的物体のグローバルイルミネーションのみをリアルタイムで計算できます。物体間の幾何学的関係が変化すると、事前計算された伝達関数は無効になります。


 

六、論文情報

 

参考ビデオURL:https://v.qq.com/x/page/x0382thpc7b.html

 

著者について:

有名なコンピュータグラフィックス学者であるPeter-PikeSloanは、かつてMicrosoft Researchでグラフィックスの研究に従事し、現在はActivisionBlizzardでグラフィックスの研究を行っています。

有名なコンピュータグラフィックス学者であるJanKautzは、かつてmax planck institut informatik Instituteで学び、現在はNvidiaでグラフィックスの研究を行っています。

有名なコンピュータグラフィックス学者であるJohn Snyderは、かつてマイクロソフト研究院でグラフィックス研究に従事していました。

 

ダウンロードリンク:

www-inst.eecs.berkeley.edu/~cs283/fa10/lectures/p527-sloan.pdf

 


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com

iOSでAssetBundleをエクスポートするには30時間かかる

1)iOSでAssetBundleをエクスポートするには30時間かかる

2)Unityメインプロセスがナレッジツリーを構築する方法

3)TMPでCullTransparentを設定すると、Alphaが0であるTextをCullingにすることはできない

4)Spineアニメーションスタンプは線形空間に黒い境界線が表示される

5)Spineが多すぎると、Updateのパフォーマンスが大幅に低下する


 

AssetBundle

 

Q:現在、ゲームアセットは約870MB(すべてのAssetBundleAndroidプラットフォームからエクスポートされます)で、Windowsi5-7500 CPU @ 3.40GHzGTX105016GBメモリ、SSDハードディスク)でAndroidアセットの全量をエクスポートするには約2時間かかります。i9では約1時間かかります。6年前のi3ではほぼ4時間かかります。

 

同じエクスポートコードで、Mac Mini2018i5 @ 3GHzIntel63016GB DDR4メモリ、SSDハードドライブ)で約38時間かかります。Macbook Pro2018i9 @ 2.9GHzRedeon560X 4G16GB DDR4メモリ、SSDハードディスク)、)でも30時間かかります。これはPVRTCの問題だと考え、すべてのアセットをASTCに再エクスポートしても全然改善されていません。問題はどこにあるのか?

 

A:次のリンクを確認してください。

https://forum.unity.com/threads/case-1192489-building-asset-bundles-decompresses-textures.742757/

簡単に言えば、-nographicsパラメーターパッケージを追加します。

問題主がテストしたところ、Mac Pro i9にエクスポートしては40分以内かかります。


 

Unity

QMMORPGゲームの場合、Unityメインプロセスはどのような知識ツリーを構築しますか?

 

A1:この質問は複雑なので、あえて答えません。海外内には先輩さんがたくさんいます。メインプログラムには、知識システムを除いて、管理システム、プログラム分析、人件費管理、運営および製品管理システムもあります。知識ツリーなら、Milo Yipの知識ツリーツリー+御三家(Unreal、Unity、Frost)のいずれのエンジンソースコードの完読をお勧めします:https://cloud.tencent.com/developer/article/1005446

 

A2:この質問は非常に広範で、MMORPGに絞り込んでも多くのことが含まれています。Miloのスタンプは基本的にコアテクノロジーの内容をカバーし、A1は非常によい答えでした。そして、【UWAアカデミー】に起業時に行った経営についての記事があります。興味のある方は「起業家チームの技術経営」(中国語注意)をご覧ください。

MMORPGゲームのメインプロセスで習得する必要があると思われる技術コンテンツの一部を共有します。

1.プログラミング言語

これは理解しやすく、プログラムの基本です。

よく使用される静的言語:C ++、C#、Go

よく使用される動的言語:Lua、Python

通常、ゲーム開発には複数の言語が必要なため、プログラミングの概念とスキルを組み合わせる必要もあります。

これらの各言語の文法と機能を理解する必要があり、一般的にメモリ管理と関わっています。

2.プログラミング仕様

言うまでもなく、メインプロセスとして、チームのプログラミング仕様を策定する必要があります。また、仕様をより適切に実行および保証するには、LuaCheckなどの静的テストツールを使用する必要があります。

3.プログラミングパラダイム

これは2つの部分で構成されていると思います。1つはGamePlayフレームワークの構築です。従来のEntity継承、コンポーネント化、ECSの三つは従来のものです。もう1つはデザインパターンとそのアプリケーションです。

4.データ構造とアルゴリズム、および3次元数学

デフォルトは3Dゲームですが、この部分の基本知識は必要です。

5.ゲームエンジン

クライアントやサーバーなど、使い慣れたマスターのゲームエンジンが必要と思います。

  1. GamePlayの基本

前述のプログラミングパラダイムに加えて、GamePlayにはさらに多くのことがあります。

3C

ゲームの状態管理

一般的なスキル構造など。

7.物理システム

衝突検出、プレーヤーコントロール、車両システム、ラグドール、ソフトボディエフェクトの設計方法。

8.アニメーションシステム

スケルタルアニメーションの原則、スキニングの基本概念、モーションフュージョン、Rootmotion、アニメーションのリターゲティング、キャラクターモデル、アニメーション制作仕様など。

9.特殊効果システム

10.レンダリング

基本的なレンダリングパイプラインを理解する

PBRに精通する

非現実的なレンダリングを理解する

さまざまな後処理効果

11.オーディオテクノロジー

FMOD、Wwise、およびエンジンのプリインストールオーディオ機能の使用

材質の音響効果の区別、P1/P3の区別

ミックスや残響などの機能のサポート

12.ビッグワールドシーンの制作と管理のプロセス

MMORPGの場合、ビッグワールドの制作技術が必要となります。World MashineやHoudiniなどのPCGをベースにした生産パイプラインの構築方法、シーンの同時編集のサポート方法、ビッグワールドでのシーンアセットのロードとアンロード、および超長距離視線の影を実現する方法、昼と夜の気象システム、HLODなどの技術が必要になるかもしれません。

13.パフォーマンスの最適化

従来のパフォーマンス最適化方法、および継続的に監視してパフォーマンスの問題を特定して解決策を見つけます。CPU、GPU、帯域幅、メモリ、ディスク容量などが含まれます。

14.ゲーム更新メカニズム

クライアントPatchシステム

サーバーのHot Update

クライアントコードのHotfix

15.ネットワーク

通信プロトコルの定義方法

ネットワークトラフィックを最適化する

弱いネットワークの下でゲームのパフォーマンスを最適化する

暗号化

ネットワークトラフィックの制限

16.サーバーメモリ

MySQLやMongoなどの従来のデータベースの使用

17.ゲームAI

クライアント側またはサーバー側にある可能性があり、便利な編集機能を提供する必要がある

ディープラーニングに基づくAIソリューション

18.サーバーの安定性とセキュリティ

並行性の安全性

プロセス監視

一般的な操作とメンテナンスの知識

負荷分散

19.従来のサーバーテクノロジー

AOI管理

サーバー物理

ボクセル

同期スキーム

20.IDEおよびデバッグツール

VSCodeやVisualStudioなどの一般的に使用されるIDEと、対応する開発モードの対応するデバッグツール。

21.バージョン管理ソフトウェア

22.エディター開発

少し面倒で、技術的な内容自体が非常に複雑です。分割し続けると非常に細かくなります。たとえば、3Cでは、ホストレベルのエクスペリエンスを実現する方法は、1人で完全に理解できるものではありません。

もちろん、私がリストした技術的なポイント以上のものが確かにあります、ゲームタイプに関連する他の多くの技術的な内容があります。

MMORPGプロジェクトのメインプロセスでは、上記の技術内容のうち、80%以上を理解することが合格だと言えます。もちろん、誰もが独自の専門分野を持っています。十分な学習能力があり、適切な人材を見つけることができれば、技術的な内容を学び、補うことができます。メインプロセス自体がプロジェクトの技術的な問題の根底にあり、技術的な解決策を決定することであるというだけなので、技術的な幅には依然として高い要件があります。

私自身の経験は次のとおりです。メインプロジェクトの仕事では、一日中コミュニケーションと会議だらけで、30%〜40%のコード時間があれば有難いです。したがって、メインプロセスの観点からは、「もの」だけでなく「人」も必要がとなります。チームの活力を維持すること、チームの戦闘力を刺激することなどは、テクノロジーの以外に考える必要がある問題です。

 

A3:とても勉強になりました。Respect!!!ここにもう少しの補足をさせて頂きます。参考になれば嬉しいです。

1.技術面

まず、ソフトウェア開発とコンピューター関連の基本的な知識を持った高級Unity開発者や熟練者が必要となります。

Unityに精通し、モジュールの使用や基本原則をある程度理解する必要があります。例えば、アクション、特殊効果、GUI、Avatar、シーン、Timeline、アセット管理など。

特定のMMO開発経験があり、シーン、プレーン、ブランチライン、AOI、属性同期、AI、Entity、スキル、Buff、ボクセルなど、MMOゲームの一般的な概念と実装スキームを理解しています。

一般的なパフォーマンス最適化ツールと最適化ソリューションについて知っています。

技術的ビジョンを継続的に拡大することは、技術的ソリューションの選択と意思決定に役立ちます。

2.管理面

ランディングコード仕様を策定し、どのようなコード仕様が適切な仕様であり、プロジェクト仕様に適しているかを理解します。

ランディングアセットの仕様を策定し、プロジェクトのニーズとパフォーマンス予算に応じてアーティストに認められるアセット仕様を策定し、プロセスとツールを提供してランディングを支援します。

開発プロセスを策定し、継続的に最適化して、出力効率を向上させます。

技術的な側面はたくさんありますが、結局のところ、人のエネルギーは限られており、すべてをカバーすることは困難です。したがって、人を採用し、人を知り、人を雇用し、適切な人を見つけることも非常に重要です。

技術職から昇進した場合は、基本的な管理知識を知ることも必要となります。

3.製品面

融通のきかない要件ではありませんが、プロジェクトと同じ種類の競合ゲームを、ある程度体験することをお勧めします。

ゲームの一般的なゲームプレイについて理解します。

ゲームのさまざまなレベルのプレーヤーの気持ちを体験し、彼らのニーズを理解します。

このタイプのゲームの技術的な突破点を考えます。

このようにして、プランナーと製品要件や最適化計画について相談するのは、合意に達することがより簡単になり、はるかに効率的になります。

たとえば、問題主がおっしゃったMMORPGについては、現在『天涯明月刀』、『天諭 Revelation(レボリューション) 』、『倩女幽魂』と『一夢江湖』などをすべて体験することができます。

最後に、良い態度も非常に重要だと思います。プロジェクトの開発中は、困難、挫折、さらには失敗さえあります。これらの状況に遭遇したときは、前向きな姿勢を維持すると同時に、チームメンバーにポジティブな影響を与えて、全員に自信を与え、より良い結果の達成に導きます。


 

UGUI

 

QUnity 2020では、CanvasRendererCullTransparentMeshプロパティを設定すると、Alpha0の要素がメッシュを描画できないようにすることができますが、TMPはそれをできないのはなぜですか?

 

UGUIのソースコードとTextMeshProのソースコードを確認したところ、メッシュが設定されていて、どれも空ではないことがわかりました。

UGUIでは、canvasRenderer.SetMeshworkerMesh;

TMPでは、m_canvasRenderer.SetMesh(m_mesh) ;しかし

CanvasRendererのソースコードは

public extern bool cullTransparentMesh { [MethodImpl(MethodImplOptions.InternalCall)] get; [MethodImpl(MethodImplOptions.InternalCall)] set; }

のように表示されています。

TMP要素が透明な場合、Textのようにメッシュをカリングするにはどうすればよいですか?

 

A:TMPメッシュに未使用の頂点の色が0ではありません。つまり、[Color]設定の[Alpha]で未使用の頂点を設定できないため、下位階層に描画されたMeshに色が0でない頂点があり、削除できなくなります。さらに、頂点情報をクリアできないため、TMPに100文字と400頂点情報が含まれていることになります。一文字に再割り当てすると、相変わらず400頂点情報のままで、396頂点は描画に使用されないにすぎません。要するに、TMPは慎重に使用し、ソースコードを変更するか、公式の修正を待ちます。


 

Spine

 

QUnityのバージョンは2017.4.3f1で、Gamma空間の下のSpineアニメーションに問題はありません。現在、Linear空間の下になると、Spineアニメーションにおける小さな継ぎ目には黒い境界線がたくさんあります。下図の鼻のように、Spineに鼻は顔に取り付けられて小さな画像ですが。Linearにはぼやけた黒い境界線が表示されます。これは、周囲のAlpha値の影響を受けると予想されます。ノーズスタンプですが、具体的な理由はまだ不明です。しかし、両方ともガンマ空間の下で正しいです。

 

Gammaスペースの下の写真では、鼻は正常です。

 

 

線形空間の下には、鼻の周りに黒い境界線があります。

 

 

比較のために、2つのより明確な部分画像を次に示します。

 

 

A:まず、Spineは事前乗算Alphaをオフにして再エクスポートします。

次に、ShaderはStraight Alpha Textureを選択しました。

次の情報を参照してください:http://zh.esotericsoftware.com/forum/Spine-JSON-12274?p = 54752#p54752


 

Spine

 

QSpineの数が多すぎるため、Updateのパフォーマンスが大幅に低下します。次の図に示すように、SkeletonAimation.Updateに時間がかかりすぎます。効果的な解決策はありますか?

 

A1:GPUに移動します。

 

A2:以下を参照してください。

Spineが多いのはフリーズを意味するわけではありません。主に頂点の数と関連しています。

UnityにはC#コードもあります。この関数によったフリーズはよく見られます。実に、Spineがクリッピングを行うときのマスクの頂点が多すぎるため、最適化をSpineアニメーターに任せます。

要約すると、マスクされるべきではない頂点はカバーされるべきではなく、頂点の数は可能な限り少なくなければなりません。

 


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com

微小面モデルーーPBRレンダリングパイプラインの材質

PBRレンダリングパイプラインがさまざまな材質(マテリアル)をリアルに表現できるのは、より複雑な材質モデルを使用しているからです。PBRレンダリングパイプラインが登場する前は、通常使用していた材質モデルは、環境光(Ambient)、拡散反射(Diffuse)、鏡面反射(Specular)の3つの部分で構成されていました。Lambertモデルは拡散反射をシミュレートし、Phongモデルは鏡面反射をシミュレートします。ただし、これらのモデルは、粗さが違う表面の異なる反射効果をシミュレートすることは困難です。従って、シミュレートされた材質は、ツルツルとしたプラスチック表面のように見えます。

 

PBRレンダリングパイプラインは、微小面(Microfacet)と呼ばれる材質モデルを利用しています。これは物理的な観察に基づいて、物体(オブジェクト)の表面には多くの小さな凹凸(微小鏡面)があると考え、サイズと向きが異なる微小面は、入射光を反射するときにさまざまな反射効果を生成します。従って、肉眼で様々な材質特性を確認できるようになります。したがって、微小面モデルは、次の図に示すように、さまざまな異なる材質をより写実的にシミュレートできます。

 

PBRレンダリングパイプラインは近年ゲームレンダリングの分野に用いたが、微小面モデルは早くも1980年代にコンピュータグラフィックスの分野で提案されています。本日紹介する技術論文は、1981年にACMComputerGraphicsに掲載されたものです。この論文では、現実の世界の材質をシミュレーションする数学モデルを提案し、Cook-Torranceモデルとして知られます。Cook-Torranceモデルは、コンピュータグラフィックス材質モデルの発展に重要な影響を及ぼします。今日でも、多くのゲームエンジンのPBRレンダリングパイプラインで、Cook-Torrance材質モデルの簡略版と変種を見ることができます。

 

Cook-Torranceモデルが登場する前は、コンピュータグラフィックスで物体材質モデルをシミュレートするための設計アイデアのほとんどは、次のような幾何光学に基づいていました。理想的な拡散反射をシミュレートするLambertモデル、余弦関数指数関数でハイライトをシミュレートするPhongモデル、grazing angleのハイライトを考慮するBlinnモデルなどがあります。これらのモデルは、現実の世界の材質をシミュレートできますが、シミュレートできない材質もあります。それに対し、Cook-Torranceモデルはそれらと違って、物体の表面が多くの小さな平面で構成されているという物理現象に基づいています。これらの平面の方向は異なり、滑らかな物体の場合、微小面の方向分布はより均一で、粗い物体の場合、微小面の方向分布はより分散しています。これにより、Cook-Torranceモデルの用途が広がり、表面の粗い材質をシミュレートできるようになります。前任者によって提案されたモデルは、鏡面反射とハイライトの効果をシミュレートする場合、プラスチックに似ています。Cook-Torranceは、プラスチックをシミュレートできるだけでなく、金属などの粗い表面のハイライト現象もシミュレートできます。

 

次に、反射照明モデル、つまりCook-Torranceモデルの通式を紹介します。次に、ハイライト項の表現式を紹介します。微小面ベースの物理モデルと従来の分析モデルの最大の違いは、鏡面反射ハイライトの処理の違いであるためです。微小表面モデルのハイライト項に基づいて、フレネル現象、微小面の方向分布関数、シャドウオクルージョン項など、より多くの要素を考慮に入れて、一般的な材質モデルとなります。


 

一、反射モデル

 

光源、物体の表面、および観察者が与えられた場合、反射モデルは、光線が光源の方向から物体の表面に当たり、観察者の方向から反射される状況を表します。その中には、光の強度と色の情報が含まれています。反射光の強度と色は、光源から放出される光の強度と色、および物体の表面の反射率に依存します。通常、BRDF(Bidirectional Reflectance Distribution Function)関数で物体の表面の光に対する反射能力を表します。次に、論文の著者がこの関数をどのように定義するかを紹介します。

 

物体の表面の反射能力関数、つまりBRDF関数は、次のように定義できます。L方向から入る光のどれだけがV方向から放出されるか。入射光が無限遠の指向性光であり、光強度がIiで表されるとすると、L方向から点Pに入射する光エネルギーは次のように表すことができます。

 

ここで、ωは入射光の方向角です。 RがBRDF関数で、Irが反射光の強度である場合、Irは次のように表すことができます。

 

ここで、s + d = 1は、それぞれハイライトと拡散反射係数を示します。環境光の影響を加えると、上記の式を次のように変更できます。

 

上記の式は、照明計算式です。


 

二、鏡面反射項Specular Termの式

 

著者は、光源の方向と視線の方向の間のベクトルHを定義しています。上の図に示すように、物体の表面上の点P、光源の方向L、視線の方向Vが与えられます。その場合、その中間ベクトルは次の式で表すことができます。

ここで、θはLとVの間の角度の半分です。したがって、

著者は、環境光が一定の値で、拡散反射が理想的な拡散反射であると想定しているため、RaとRdは視線に依存しません。しかし、鏡面反射項Rsは視線方向に関連しています。微小面モデルの定義によれば、物体の表面は、無限の方向が違う微小面で構成され、各微小面は、入射光に鏡面反射を生成する鏡面と見なすことができます。したがって、法線方向がHと同じ微小面のみが、鏡面反射項に寄与します。鏡面反射項を定義する式は次のとおりです。

このうち、Fはフレネル項、Gはシャドウオクルージョン項、Dは方向分布項です。次に、これら3つの項の式を1つずつ紹介します。

 

まず、シャドウオクルージョンを紹介します。前任者のモデルによれば、G関数は次の式で表すことができます。

方向分布関数Dは、H方向の面の比率を表します。前任者のモデルの中で、BlinnとBeckmannによって提案されたものは特に有名です。Blinnモデルの式は次のとおりです。

 

ここで、Cは定数です。Beckmannモデルの式は次のとおりです。

どちらのモデルでも、αはHとNの間の角度を表し、mは鏡面分布の範囲を決定します。mの値が小さい場合、微小面の方向は比較的均一であるため、鏡面反射の範囲は比較的狭くなります。それどころか、次の図に示すように、鏡面反射の反射範囲は比較的広いです。

(a)と(c)はBeckmannモデルの反射分布です。(a)はm=0.2、(c)はm=0.6の場合の反射分布を表します。(b)と(d)ガウスモデルの反射分布です。(b)はm=0.2、(d)m=0.6の場合の反射分布です。上の図からわかるように、m値は表面の粗さを表しています。物体の表面にさまざまな粗さが存在する場合、分布関数Dは、さまざまなm値の加重平均になります。

前任者によって提案されたフレネルの式によれば、フレネルの項Fは次のように表すことができます。

ここで、c=cosθ=V・H、g2 = n2+c2-1。 θ=0の場合、c=1およびg=n。それによって、

したがって、次のことが求められます。

これまで、Cook-Torranceモデルのスペキュラーアイテムに関するすべてを紹介してきました。次に、論文でレンダリング結果を示します。


 

三、その他の結果

著者は、さまざまなパラメータを使ってさまざまな材質の物体をレンダリングしました。下の図に示すように、モデルが異なれば、s、d、mの値も異なります。

 

レンダリングされた結果を次の図に示します。

 

次の画像は、複数の材質を含む物体をレンダリングした結果です。

 

上の画像に示されているように、左側に黄色のプラスチック材質のボトル、右側に黄色の銅のボトルで、いずれもCook-Torranceモデルでレンダリングされました。上の図からわかるように、Cook-Torranceモデルは、物体の表面のさまざまな粗さの照明条件を適切にシミュレートできるため、プラスチック材質の表面に明確なハイライト(鏡面反射)をレンダリングできるだけでなく、金属表面のぼやけたハイライトをレンダリングすることもできます。このような特性は、従来のモデルでは実現できない効果です。


四、まとめ

 

今回紹介した論文は微小表面モデルに基づく新しい材質モデルを提案した。前のモデルと比較して、このモデルは、フレネル現象、シャドウオクルージョン、微小面の方向分布などの要素が鏡面反射項に対する影響を考慮しています。したがって、モデルは粗い表面での鏡面反射現象をうまくシミュレートできます。さまざまな粗さのパラメータ値の場合、このモデルはより広範囲の材質をシミュレートできます。


五、論文情報

 

論文の著者について:

Robert L. Cookは、コーネル大学を卒業した有名なコンピュータグラフィックス学者です。現在、Pixarアニメーションフィルムカンパニーの有名なレンダリングエンジンRenderManの創設者の一人であり、現在は退職しています。

 

Kenneth E. Torrance、有名なコンピュータグラフィックス学者です。コーネル大学の機械航空宇宙工学部で働いていましたが、現在は退職しています。

 

ダウンロードアドレス:

http://inst.cs.berkeley.edu/~cs294-13/fa09/lectures/cookpaper.pdf


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com

物理ベースレンダリングーーディズニーのレンダリングモデル

今日は、物理ベースレンダリングに関する論文を紹介します。この論文は、2012年のSiggraphグラフィックスカンファレンスでディズニーが共有したPBRテクノロジーに関するレポートです。PBRは、最近のゲームレンダリングの分野における比較的高度なレンダリングパイプラインです。 PBRは、LambertおよびPhongモデルに基づく従来のレンダリングパイプラインと比較して、より現実的な材質(マテリアル、以下も材質)モデルを採用しています。これにより、オブジェクトの表面のさまざまな粗さによってもたらされるさまざまな反射効果をより適切に表現して、さまざまな材質をよりリアルに1シミュレートできます。 PBRを使用する材質は、金属、非金属、およびさまざまな粗さの材質の光に対する反射効果をより適切にシミュレートできます。PBRは、過去数年間はリアルタイムのゲームレンダリングにのみ使用されてきましたが、オフラインの映画のレンダリングには数年間使用されています。本論文は、前任者によって提案された材質モデルに基づいており、実際に測定された材質データを分析および比較することにより、新しい材質モデルを提案します。最終的に、ディズニーはこのアプローチを映画のレンダリングに適用しました。

 

PBRレンダリングパイプラインの原理に関心のある開発者がこのペーパーを通じてPBRの理解を深め、プロジェクト開発でPBRパイプラインをより有効に活用し、満足のいくレンダリング結果を達成できることを期待して、このペーパーをお勧めします。

 

上図は、ディズニーのアニメーション映画Wreck-It Ralphのスクリーンショットです。キャラクターの頭頂部にある金属製の王冠と非金属製の襟が、リアルに近いレンダリング効果を実現できることがわかります。

 

前任者によって提案された物理ベースの材質モデルとは異なり、この論文の材質モデルは、設計当初の物理的正確性の原則に基づいているのではなく、アーティストが理解できて使用しやすくするという原則に基づいています。論文の著者は、物理的に正しいかどうかは重要ではないと考えています。重要なのは、アーティストのニーズを満たすことができ、使いやすく、理解しやすいことです。したがって、彼らは5つの主要な設計原則を提案します。

 

1、使いやすさと理解のしやすさは、物理的なリアルよりも重要です。

2、調整可能なパラメータが少ないほど、優れています。

3、パラメータの値は、効果の許容範囲内で(0〜1)に正規化する必要があります;

4、パラメータには、実際の許容範囲(0〜1)外の値を割り当てることができます。

5、すべてのパラメーターの組み合わせの効果は、許容可能で安定している必要があります。

これらの5つの原則に基づいて、この論文の著者は11個のパラメーターで表される材質モデルを提案します。次の図に示すように、さまざまなパラメーターに従って、さまざまな材質をレンダリングできます。

上図からわかるように、パラメータを簡略化した後、この論文で提案する材質モデルは11個のパラメータを使用して、金属、非金属、およびさまざまな粗さの材質の照明結果を非常にリアルにシミュレートします。

 

上記の5つの原理と実際の測定データの観察に基づいて、従来の微小面材質モデルのさまざまな関数が変更されました。では、まず従来の微小面モデルの定石を紹介し、次にその中の各関数を説明し、論文で使用されている各関数の定石を紹介します。

 

この論文のモデルは、Cook-Torranceモデルで最初に登場したマイクロサーフェスモデルの定式を採用しています。

 

ここで、ベクトルlとvはそれぞれ入射光と視線の方向を表し、ベクトルhはlとvの間の中間ベクトルを表し、それらと法線方向の間の角度は対応する下付き文字θで表されます。θdは、lとvの間の角度の半分を表します。diffuseは拡散反射関数、Dは微小面分布関数、Fはフレネル係数、Gは影係数です。この論文のモデルのdiffuse関数は次のとおりです。

その中で、roughnessは粗さを表します。微小面分布関数Dの場合、現在最も優れている分布関数は、よく知られているGGX関数です。ただし、論文の著者は、GGXよりも一般的な形式のGTR(Generalized-Trowbridge-Reitz)を使用しています。

それとGGXの違いは、GGXは上記の式でγ=2の場合の結果であるということです。著者は、それぞれγ=1とγ=2を使用して、2つの異なるGTR関数を使用して鏡面反射項を適合させました。αの値はroughnessの2乗であり、cは全体的なスケーリングを調整するために使用される定数です。フレネル項Fの場合、この論文ではSchlickの式を使用しています。

ここで、F0は定数で、その値は材質の透過率に依存します。影の係数Gについては、著者はWalterが論文でGGXから導出したG式を採用し、式のroughnessを[0、1]から[0.5、1]の範囲にスケーリングします。このスケーリングの理由は、実際の測定データとの比較およびアーティストからのフィードバックに基づいて、roughnessの値が小さい場合にハイライトが明るすぎるように見えるためです。このスケーリングプロセスにより、モデルは物理的に正確ではなくなりますが、アーティストのニーズを満たすという設計原則を反映しています。

 

以下では、論文の実験的な部分、つまり実際に収集されたデータを観察し、材質モデルを設計する方法を紹介します。興味があれば読み続けることができます。または、結論と今後の作業のセクションに直接スキップすることもできます。


 

一、実際に収集されたBRDFデータを視覚化する

 

著者は、Matusikの2003年の論文のデータ集合を利用しています。これは、Mitsubishi LabsのWebサイト(www.merl.com/brdf)から無料でダウンロードできて、木材、金属、石、プラスチック、ゴム、繊維などの実際の材質に関するデータが含まれています。以下に示すように、各材質はさまざまな入射角と出口角に従ってサンプリングされます。

著者は、実際の測定された材質データを表示し、BRDFモデルでレンダリングされた結果を比較するためのシステムを開発しました。これは、次の図に示すように、GitHub(github.com/wdas/brdf)から無料でダウンロードできます。

その中で、実際の測定データ(ImageSlice)またはレンダリングされたデータ(Lit Object / Lit Sphere)を表示して比較することを選択できます。


 

二、実際のデータから観察された結果

 

拡散面への観察によると、Lambertモデルの仮定の下では、純粋な拡散反射には方向性がなく、反射光は各反射方向で同じ値になりますが、Lambertモデルの仮定前提を表すことができるオブジェクトは少ないです。特に視線と法線が垂直に近い領域(grazingangle area)では、以下に示すように、急激な減衰を示すものがあり、明るさの増加を示すものもあり、それは物体の表面の粗さに密接に関係しています。

左から右に、粗い表面、滑らかな表面、およびLambert モデルによってレンダリングされた拡散反射の結果です。ボールのエッジでは、粗さの程度が異なると効果が異なり、Lambert モデルはこれをよく示していることはできないことがわかります。Oren NayerやHanrahan-Kruegerなどの以前のモデルは、この現象をある程度シミュレートしていますが、この現象を表すには十分ではありません。したがって、この論文の著者は、材質モデルの拡散部分を設計するときにこの現象を考慮に入れました。

 

著者の鏡面反射現象(微小面分布関数に対応)の観察によると、実際に収集されたデータの鏡面反射追跡は、Beckmann、Blinn Phong、Gaussianなどの従来の材質モデルよりも長くなります。次の図に示すように、実際の測定結果と比較すると、GGXのレンダリング効果が最も近くなっています。

 

左側は実際の測定結果、中央はGGXモデルでレンダリングされた結果、右側はBeckmannモデルでレンダリングされた結果です。したがって、提案された材質モデルでは、論文の著者は、鏡面反射項DとしてGGX(GTRγ= 2の場合)とGTRγ=1の関数混合を採用しています。

 

論文の著者によるフレネル現象の観察によると、入射光と視線の間の角度が180度に近づくと、実際に測定されたすべての材質が強調表示されます。例:上図では、視点から離れるほど反射角度が大きくなり、反射光が明るくなります(写真の1、2、3は遠方から近方、1が最も明るい)。この現象は、Torrance-Sparrow微小面モデルで観察および提案されています。モデルの被除数項は、grazing angle領域で無限大に近づいていますが、G項の減衰がキャンセルされているため問題ありません。著者は、最終的に、SchlickとWalterによって得られた結果を、材質モデルのF関数とG関数として使用します。


 

三、より多くの結果

 

以下は、論文のアルゴリズムを使用してレンダリングされたWreck-ItRalphアニメーション映画のレンダリング効果です。


 

四、結論と今後の展望

 

本日紹介した論文は、実際の測定材質データの分析と比較を通じて、既存の微小面モデルのさまざまな項目を適宜変更し、モデルパラメータを簡略化して、新しい材質モデルを提案します。ただし、このモデルの背後にある原則は、物理的な現実に基づいているのではなく、アーティストにとってやさしく、使いやすいものです。この論文の材質モデルは、より広い範囲の材質ライトの反射を表すことができますが、準表面の拡散反射による照明をシミュレートすることができません。したがって、著者は将来でこの問題に対処することを望んでいます。


五、論文に関する情報

 

論文の著者について

Brent Burleyは 、1996年にウォルト・ディズニー・カンパニーに入社し、現在はディズニーアニメーションスタジオの主任ソフトウェアエンジニア、製品でのレンダリング・ソフトウェア開発を担当しています。主な成果は次のとおりです。サブディビジョンサーフェス用のオープンソーステクスチャマッピングシステムPtexを開発し、製品のレンダリングに物理ベースの材質モデルを利用しました。

 

ダウンロード
http://blog.selfshadow.com/publications/s2012-shading-course/#course_content


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com

Font Textureのメモリ値が異常に高い

1)Font Textureのメモリ値が異常に高い

2)UWAレポートにおけるOverdrawの統計およびデータの解釈についての疑問

3)URP Androidプラットフォームでは、ハイライトにモザイクがある

4)Different Material Instanceが原因でUGUIのパッチが中断されている

5)UnityのTerrainDataでSplatAlphaの圧縮についての疑問


 

Font

 

Q:テストレポートでメモリの使用が高いFont Textureを発見しました。それに、最初にゲームに入ってからそこにあります。しかし、私が理解できないのは、256 * 256しかないなのに、61MBほど占るのはなぜでしょうか。

 

バージョン:Unity 2019.4.3f1

 

A:2018にはこのような問題は発生していません。これはUnity2019のバグだと思います。そしてUnity2019.4.21で修正された。

参照URL:https://unity3d.com/unity/whats-new/2019.4.21

 


Rendering

 

Q:UWAテストレポートでは、ゲームの全体的なOverdrawが比較的高いです。イントラネットでOverdrawデータを再テストしたいのですが、いくつか質問があります。

 

1.UnityOverdrawMonitorを使用して、Editorでシーン全体のOverdrawをテストしました。テスト結果はUWAの結果よりも小さく、複数の同じ画面をテストしましたが、相変わらずUWAの結果値がよりいですつまり、このツールの統計値はUWAレポートFill総数より小さいですゲームのある瞬間にOverdrawをどのようにテストするのか聞きたいですが

 

2.Fill総数、平均Fill Times、ピクセルあたりのFill最大などUWAレポートのこれらのデータ間にどのような関係があるでしょう

 

3.他のツールについては、ParticleEffectProfilerをイントラネットに取り込みました。これは、単一の特殊効果に対する単一のピクセルのFill最大数をカウントできます。いくつかの個別の特殊効果をテストした結果、一般的にOverdraw2ですが、高いのは4、5、6までに達しました。Overdraw高すぎる特殊効果アーティストに最適化させました

 

PS:会社のプロジェクトはイントラネット上で開発されているため、Editorでプロジェクトのデータをキャプチャすることはできません。UWAレポートのスクリーンショットをいくつか投稿しま

 

A:

1. UnityOverdrawMonitorは次のオープンソースツールにある場合:https://github.com/Nordeus/Unite2017/

ここでの統計は不正確です。これは、Shader ReplacementでShaderを半透明のShaderに置き換えて、Overdrawを計算するからです。そういう基本的な原理のため、深度のオクルージョンやカリングなどの問題を考慮していません。そうしたら、計算された値が違って、時には不必要な誤解を招くことさえあります。

2.これらの値の具体的な説明は、https://blog.uwa4d.com/archives/PA_GPU.html

(中国語注意)を参照してください。

Fill総数の最大値

プロジェクトの実行中、1つのフレームのFillピクセルのピーク値。

Fill総数の平均値

プロジェクトの実行中、フレームあたりのFillピクセル数。

Fill Timesの最大値

プロジェクトの実行中、1つのフレームで、画面全体が充填されるFill Timesのピーク値。Timesが大きいほど、GPUへのストレスが大きくなります。

Fill Timesの平均値

プロジェクトの実行中、各フレームの平均Fill Timesです。Timesが大きいほど、GPUへのストレスが大きくなります。

スクリーンショットから、特殊効果のOverdrawのストレスはまだ小さくありません。特別な注意を払うことをお勧めします。


 

Rendering

 

Q:Unityのデフォルトの球体を含む最も単純なシーンでは、URPLitShaderを使用しています。

 

Editorで正常に表示されます。

 

 

プロジェクトがAndroidにエクスポートされた後、ハイライトのモザイクは非常に深刻です。

 

 

マテリアルにはカラーのみが設定されていますます。

 

 

どうすれば良いですか?

Unityバージョン:2021.1.9f1

URPバージョン:11.0.0

 

A:URPソースコードを変更する必要があります。

packages / com.unity.render-pipelines.core @ 11.0.0 / ShaderLibrary / Common.hlslファイルの1225行目:

// Normalize that account for vectors with zero length

real3 SafeNormalize(float3 inVec)
{
    real dp3 = max(FLT_MIN, dot(inVec, inVec));
    return inVec * rsqrt(dp3);
}

realをfloatに変更する必要があります

// Normalize that account for vectors with zero length

float3 SafeNormalize(float3 inVec)
{
    float dp3 = max(FLT_MIN, dot(inVec, inVec));
    return inVec * rsqrt(dp3);
}

したがって、やはりモバイルプラットフォームの精度設定に問題があると思います。


UGUI

 

Q:下図に示すように、同じマテリアルボールなのに、Different Material Instanceのバッチが中断されています。その理由は何ですか?

 

A1:マテリアル名が同じからだと思いますが、Debugモードを開いて、Instance IDが同じかどうかを確認したらどうでしょう。

A2:解決されました。テンプレートテストが原因です。

 


Rendering

 

Q:Unity TerrainDataのSplatAlphaは非圧縮形式であり、メモリ使用量が非常に高いですが、より良い圧縮方法はありますか?

 

A:この画像がUnityのネイティブTerrainで圧縮できるかどうかはわかりませんが、原則として可能であるようです(画像が実行時にメモリで生成されない限り)。

ただし、この画像には色情報が保存されていないため、ブレンドのエッジのモザイクなど、圧縮後の効果が低くなる可能性があります。T2Mを使用してMeshに変換した後、この混合テクスチャが圧縮されましたが、効果は非常に劣っていました。最終的に、メモリの半分を減らすために、いくつかの許容可能なプロットで16ビットを使用して、問題のあるプロットは依然として32ビットの元の画像を使用しています。


UWA公式サイト:https://jp.uwa4d.com

UWA公式ブログ:https://blog.jp.uwa4d.com

UWA公式Q&Aコミュニティ(中国語注意):https://answer.uwa4d.com