Unity を検索

『The Heretic』のメイキング：デジタルヒューマンの技術パッケージ

著者：

Lasse Jon Fuglsang Pedersen

2020年7月10日カテゴリ：テクノロジー | 26 分で読めます

取り上げているトピック

アニメーションデモ

Is this article helpful for you?

Thank you for your feedback!

リアリティの高い人間のキャラクターを作成することは、複雑な技術的チャレンジです。なぜなら、ビジュアル面での高い再現度を実現するには、膨大な量のデータが必要だからです。『The Heretic』の制作中に、Demo チームはフェイシャルアニメーションにまつわる数多くの問題を克服するためにいくつかのツールを開発しました。たとえば、肌に髪をアタッチしたり、眼球、歯、肌のレンダリングを Unity で実行したりするためのツールです。これらのツールは現在 GitHub で公開されています。このソリューションの背景にある、プロセスの技術的詳細にご興味のある方は、ぜひ本記事の内容をお読みください。

こんにちは。Lasse Jon Fuglsang Pedersen です。Unity の Demo チームのシニアソフトウェアエンジニアとして働いています。『The Heretic』の制作中に私が取り組んだことの 1 つに、劇中に登場するデジタルヒューマン「Gawain」の顔を動かす技術的なソリューション一式の開発があります。

この仕事の成果が最近 GitHub でスタンドアロンパッケージとしてリリースされました。このブログ記事では、このパッケージの機能のいくつかを説明し、それらの機能の背後にある開発プロセスに関する知見をいくらか共有したいと思います。

フェイシャルアニメーション

『The Heretic』のデジタルヒューマン制作における目標の 1 つは、フェイシャルアニメーションにおける「不気味の谷」を避けつつ、キャラクター全体をリアルに表現することでした。俳優のパフォーマンスにできるだけ近づけるために、顔のメッシュのアニメーションに 4D キャプチャデータ（アニメーションのフレームごとに行なった 3D スキャン）を使用してみることにしました。そうすることで、少なくとも俳優の演技における（隠されていない部分の）顔の動きを正確に再現したジオメトリを得られるだろうと見込んだのです。

アニメーション監督の Krasimir Nechevski が以前のブログ記事で詳しく説明しているように、4D キャプチャデータを使用することで、多くの興味深い、新しい課題が出てきました。キャプチャしたデータをどのように処理し、調整するかを考え出し、実際にそれを行い、動画において満足のいく状態にするために多くの労力が注ぎ込まれました。

処理に関する注意書き

たとえば、まぶたの形状に関する問題がありました。キャプチャ時にまつ毛が部分的にまぶたを隠していたため、キャプチャしたデータにはまつ毛からの影響が含まれており、その部分がノイズとなって現れていました。その結果、まぶたのジオメトリが不正確でギクシャクしたものになってしまい、その部分のジオメトリを再構築する必要がありました。

まぶた付近のギクシャクしたジオメトリ

まぶたの形状の問題は、プロセスのかなり早い段階で明らかになっていたので、データを Unity に取り込むためのインポーターを開発する作業の一環として、差分メッシュ処理技術を使って、ある領域に固有のノイズの低減と（ジオメトリの）再構築の実験も行いました。具体的には、時間の経過とともに変化する曲率の局所的な変化を平滑化することでノイズを低減し、キャプチャしたシーケンスの各フレームでジオメトリが壊れている領域に（クリーンな）ベースメッシュの曲率を移植することで再構築を行いました。

まぶた付近のノイズ除去およびジオメトリ移植

かなり堅牢な結果が得られましたが、オリジナルのデータと比較すると、やや人工的な感じがすると感じました。まぶたの動きは落ち着きましたが、オリジナルのモーションにあった、まさに人間のように感じさせる部分が失なわれていたのです。この2つの中間でほどよいバランスを探ることが必要だということが明らかになりましたが、それには私たちが現実に使える以上の時間が必要かもしれないこともわかりました。この場面で外部のベンダーが再構築作業に取り組むことを提案してくれたことで、私たちにとって救いとなる選択肢が生まれたのです。しかし、GitHubパッケージには、学習用のリソースとして役立つ可能性を考慮して、ノイズ除去と（ジオメトリの）領域ごとの移植のために書かれた内部ツールを含めています。

シワをフィットさせる

もう 1 つの問題は、目標としている顔のメッシュの解像度のために起きる、細かい表面のディテールの問題でした。言い換えると、細かい表面のディテールが不足しているということでした。Gawain の顔のメッシュには約 28,000 個の頂点がありますが、これでは俳優が演技をすると生まれる細かいシワを幾何学的に表現するには十分ではなく、肌の毛穴の伸びを表現するにはまったく不十分でした。生の 4D データにそれらのディテールがあったとしても、デフォルメしてレンダリングしているメッシュの頂点に使える予算に合わせてデータを処理した後では、それらのディテールを残すことができませんでした。フレームごとに法線マップを焼くことも考えましたが、そうするとディスクの容量がかなり必要になるので、なんとか節約する方法はないかと考えていました。

微細な表面のディテールを処理するために、インポートしたシーケンスのジオメトリと、Snappers Systems 社のブレンドシェイプベースのフェイシャルリグの姿勢駆動形の特徴マップを組み合わせてみることにしました。フェイシャルリグの姿勢駆動型の特徴マップには、シワや毛穴の伸びなど、インポートしたシーケンスでは不足していた表面のディテールが含まれていました。そこで、基本的な考え方は次のようなものになりました。4D の各フレームに最も近いブレンドシェイプの組み合わせを見つけ出すことができれば、そのウェイトを使って 4D 再生時に表面のディテールを追加するために、（ブレンドシェイプの変形を除いた）姿勢駆動型の特徴マップだけを適用することができるはず、というものです。

ブレンドシェイプを 4D にフィットさせる良い方法を見つける手順は、2 段階のプロセスとなりました。最初のステップは最小二乗法で、問題を行列形式にしました。すべてのブレンドシェイプ（ベースメッシュに対する差分）を 1 つの大きな行列 A として書き出すと、A の各列が 1 つのブレンドシェイプの差分を保持し、差分を合成した結果は Ax = b で与えられます（x は個々のブレンドシェイプのウェイトを表します）。

A が逆行列を持たないことが多いため、x の解を求めることはできないこともしばしばあります（私たちの場合、A が正方行列にならないため、逆行列を持ちません）。しかし、問題を少し違った形にすることで、近似解 x* にたどり着くことができることがよくあります。いわゆる正規方程式 A^TAx* = A^Tb を用いて、最小二乗解を x* = (A^TA)^-1A^Tb と書くことができます。ここで、A に関する条件は A の各列が線型独立であることだけです。ブレンドシェイプを扱う際には、含まれるシェイプが線形独立になるようにフィルタリングを行う必要がありますが、こうすることで近似解を求めることができます。リグのフィルタリングされたブレンドシェイプについて (A^TA)^-1A^T を事前に計算し、4D の各フレームについて差分 b を挿し込んで、4D の各フレームについて x*（フィットしたウェイト）を計算します。

上で概説した制約のない最小二乗法は、問題の基本的な理解を深めるのには良い方法でしたが、実際にはうまくいきませんでした。また、与えられた 4D フレームに全体的に近づけるために、解に負のウェイトが含まれていることもありました。しかし、フェイシャルリグでは、ブレンドシェイプは減算ではなく加算することを想定していたため、フィットしたウェイトがリグの制約を実質的に超えてしまい、意味のあるシワに変換できないこともありました。

言い換えれば、私たちが表現したいシワを得るためには非負の解が必要でした。非負の解を計算するために、非負の最小二乗問題専用の反復ソルバーを含む Accord.NET というサードパーティ製ライブラリのサブセットを使用しました。問題を分解し、制約のない解をテストした後、フィルタリングされたブレンドシェイプ行列 A と所望の差分 b はすでに得られていたので、それらを反復ソルバーに挿し込んで、4D の各フレームにフィットしたウェイトの非負のセットを簡単に得ることができました。

余談ですが、ベースとなるメッシュ位置の差分ではなく、メッシュのエッジの長さとエッジの曲率に基づいてフィットした重みを計算する実験も行いました。4D データから頭部の動きを除去できなかった場合、頭部の動きに依存しないフィットを実現するために、これらのやり方のうちいずれかを使用する必要があったでしょう。Gawain の場合は、結局、位置差分をフィットさせることになりましたが、他の 2 つのオプションはまだパッケージで利用可能です。

Unity でのワークフロー

4D データを Unity に取り込む前に、最初に外部ツールに頼って、4D キャプチャデータがフレーム間でトポロジが一致する一連のメッシュ（.obj ファイル形式）に変換されることを確認しておくことが重要です。このトポロジはまた、データがインポートされるターゲットのメッシュのそれと一致する必要があります（詳細については、Krasimir Nechevsky のブログ記事を参照してください）。

次に、前処理された 4D データを Unity に取り込み、実行時に使えるクリップに変換するために、パッケージはカスタムタイプのアセットを提供します。私たちはこれを SkinDeformationClip と呼んでいます。作成された SkinDeformationClip は、4D データのセグメントをインポート（および必要に応じて処理）するためのツールを公開します。このツールは、ディスク上の任意の場所にある .obj ファイルへのパス（プロジェクトに中間アセットを含める必要がない）、またはプロジェクト内にすでにある Mesh アセットへのパスとして指定できます。

.obj ファイルからクリップアセットを作成して、4D フレームをインポート

SkinDeformationClip アセットを設定したら、インスペクターの Import ボタンをクリックして、フレームデータのインポートと処理を開始します。アセットでメッシュ処理またはフレームのフィッティングが有効になっている場合は、時間がかかることがありますのでご注意ください。インポートが完了すると、クリップアセットにはインポートしたフレーム間隔やフィットしたウェイトなどが保存されますが、最終的なフレームデータは保存されません。フレームデータはアセットと同じ階層の別のバイナリに保存されるので、再生中にディスクから効率的にデータをストリーミングすることができます。

アセットがインポートされたら「SkinDeformationTimeline」と呼ばれる Unity の Timeline 用のカスタムタイプのトラックにドラッグして再生することができます。このタイプのトラックは、特に SkinDeformationRenderer コンポーネントをターゲットにしており、トラック上のクリップデータの出力として機能します。下のビデオは、インポートした 4D データを Timeline 上でシーケンスして再生するプロセスを説明しています。

Unity の Timeline を使ってクリップアセットを再生しているところ

カスタムトラックと SkinDeformationRenderer を使用することで、複数の 4D クリップをブレンドすることも可能です。例えば、『The Heretic』の第 1 部では、テストフレーズと最初のクローズアップの 3 秒間のパフォーマンスだけを含む、非常に短い 4D データのセグメントしか使用しませんでした。しかし、慎重に再利用（カット、スケーリング、ブレンド）することで、この 1 つのクリップを、動画の第 1 部全体の残りのフェイシャルアニメーションに使用することができました。

肌のアタッチ

フェイシャルアニメーションに 4D データを直接使用することにしたため、まつげ、眉毛、無精ひげなどの重要な二次的な特徴が出る位置を解決するために、ボーンウェイトスキニングやブレンドシェイプに頼ることはできませんでした。基本的には、これらの特徴をアニメーション化された顔のメッシュ自体の機能として解決する方法が必要でした。

技術的には、処理された4Dデータを外部ツールにロードし、そこに二次的な特徴をモデル化してアタッチし、それらすべての追加データをベイクすることができました。しかし、フレームごとに何万もの余分な頂点をストリーミングすることは、ストレージの点で現実的ではありませんでしたし、結果もあまりダイナミックにはならなかったでしょう。私たちは、制作全体を通じて4Dデータを反復的に修正する必要があることを知っていたので、私たちのソリューションは、面倒なベイク工程なしで、これらの反復的な作業に対応しなければなりませんでした。

この問題を解決するために、デジタルヒューマンパッケージには「スキンアタッチメントシステム」と呼ばれる機能があります。このシステムでは、基本的にはエディターでの編集時に任意のメッシュやトランスフォームを特定のターゲットのメッシュにアタッチし、ターゲットのメッシュがどのようにアニメーション化されるかとは無関係に、実行時にアタッチしたメッシュやトランスフォームが、ターゲットメッシュに適合するように解決することができます。

『The Heretic』のデジタルヒューマンでは、主にスキンアタッチメントシステムを使用して、眉毛、まつげ、無精ひげ、論理マーカーを肌に関連付けた形で動かしました。また、チームのシニア 3D アーティストである Plamen Tamnev が詳しく説明しているように、毛皮のメッシュをジャケットに取り付けるためにもこのシステムを使用しました。

使い方を説明するために、例えばゲームオブジェクトのトランスフォームを Gawain の顔にアタッチする手順をご紹介します。

SkinAttachment コンポーネントを追加する。
インスペクターで、アタッチメントのタイプを Transform に設定する。
インスペクターで、Target フィールドを顔の SkinAttachmentTarget に指定する。
トランスフォームを所望の相対位置に移動させる。
インスペクターの Attach ボタンをクリックする。

トランスフォームの配置とアタッチ

仕組み

Attach ボタンをクリックしてトランスフォームをアタッチすると、システムはトランスフォームの位置を使用して、顔のメッシュ上で最も近い頂点を k-d ツリーで検索します。次に、見つけられた最も近い頂点は、その頂点に接続しているすべての三角形を識別するために使用され、接続している三角形のそれぞれについて、システムは、トランスフォームの現在の位置を前提としたローカルポーズを生成し、結果として、トランスフォームのローカルポーズのセットを生成します。

各ローカルポーズは、与えられた三角形の平面上にアタッチされた点の射影であり、三角形の頂点インデックス、アタッチされた点から三角形までの法線距離、および射影された点の重心座標を含んでいます。

1 つの三角形だけではなく、各アタッチされた点に対して複数のローカルポーズを生成するのは、メッシュ内の特定の三角形に属さない点をサポートするためです。これは、例えば、メッシュの上にわずかに浮いているヘアカードのいくつかに当てはまります。複数のローカルポーズに基づいてアタッチされた点を解決するには、まず、各三角形のローカルポーズを個別に逆射影し、三角形の面積ごとに重み付けした結果の平均を取ります。

一度生成されたローカルポーズは、顔への他のすべてのアタッチメントのための他のすべてのローカルポーズとともに、大きな連続した配列に格納されます。各アタッチメントは、基礎となるデータが他の方法で変更された場合の安全対策として、チェックサムとともにこのデータへの参照を保持します。

メッシュをアタッチするプロセスはトランスフォームで行なったプロセスと非常に似ています。メッシュをアタッチするとき、システムは単一のトランスフォームの位置ではなく、メッシュ内の各頂点のローカルポーズのセットを生成します。

通常のメッシュモードでアタッチされた眉毛

メッシュには、MeshRoots と呼ばれる二次的なアタッチメントモードもあります。このモードでは、システムは最初にメッシュの接続性に基づいてメッシュをアイランドにグループ化し、顔のメッシュとの関係で各アイランドの「ルート」を見つけます。最後に、各アイランドの中で最も近いルートと関連付ける形で、アイランド内のすべての頂点をアタッチします。MeshRoots モードは、個々のアイランドの剛性を保つために、いくつかのユースケースで必要になります。例えば、まつげはここで紹介した方法でアタッチされていますが、眉毛はそうではありません。これは、眉毛用のヘアカードはほとんどが肌と同じ平面であり、変形することが予想されるのに対し、まつ毛用のヘアカードは形状を維持することが予想されるためです。

実行時には、システムはアタッチメント（メッシュとして変換）の位置と頂点が顔のメッシュに適合するように継続的に更新されるように管理を行います。フレームごとに顔のメッシュの最終的な出力状態が計算され、既知のローカルポーズと組み合わせて使用され、肌に関連したすべての位置と頂点が解決されます。下の画像は、Gawain に使用したアタッチメントの密度を示しています。

実行時の解決は、C# Job System と Burst コンパイラーによって高速化されており、比較的大量のデータを扱うことができるようになっています。例として、Gawain の顔の場合、顔の二次的な特徴を解決するために、解決のジョブはフレームごとに何十万ものローカルポーズを評価することをまとめて担当していました。

シェーダーとレンダリング

デジタルヒューマンパッケージをスタンドアロンリリースとして出すための開発を開始したとき、主な目標の 1 つは、レンダリング関連のすべてを HD レンダーパイプライン（HDRP）の厳密に変更されていないバージョンに移行し、HDRP の新機能によるアップグレード性を確保して拡張性を高めることでした。

文脈を明らかにするための補足として、『The Heretic』のビジュアルのプロトタイピングを始めた時、HDRP にはまだ拡張性のために必要な一般的な機能がいくつか欠けていました。カスタムアップグレード可能なシェーダーを書くための筋の良い方法はまだ確立していませんでしたし、カスタムレンダリングパスなどのフレーム中にカスタムコマンドを注入する方法もまだありませんでした。

その結果、デジタルヒューマン用のカスタムシェーダー（と、動画の中の他のいくつかのエフェクト）は、最初は HDRP の既存のマテリアルを直接フォークしてそのプロトタイピングが行われました。これは、HDRP が当時まだプレビュー版で、大きな構造的変化がまだ起きているところだったためです。また、カスタムシェーダーの多くは、HDRP のコア部分の修正を必要とし、アップグレードを困難にする要因となっていました。そのため、私たちはカスタマイズの数を減らすことができるように、HDRP にもっと拡張性のある機能を求めていました。

そのため、デジタルヒューマンパッケージを作成するには、当時必要とされていたカスタマイズを、現在の HDRP で提供されている最新の拡張機能を使用するように移行する必要がありました。これは、デジタルヒューマンのカスタムシェーダーをシェーダーグラフに移植し、HDRP 固有のマスターノードを使用し、CustomPass API を使用して必要なカスタムレンダリングパスを実行することを意味します。また、Unity のリードグラフィックプログラマーである Sebastien Lagarde と Unity Hackweek 2019 で組んだチームのおかげで、HDRP に Eye Master ノードが入りましたが、これは以前作った『The Heretic』のためのカスタム実装と機能的に互換性があり、そのため、眼球のポーティングにおいて大きな助けとなりました。

この後のセクションでは、パッケージにも収録されている肌、眼球、歯のシェーダーグラフについて説明します。パッケージには髪のシェーダーグラフもありますが、ほとんど Hair マスターノードの設定をデフォルトのまま使っています。

肌

全体として、肌のシェーダーは、HDRP に組み込まれたサブサーフェススキャッタリング機能に大きく依存しています。これはアーティストがさまざまな拡散プロファイルをオーサリングして割り当て、異なるタイプの肌などさまざまなマテリアルをエミュレートするために役立つものです。肌のグラフ自体は、アーティストに 2 つのスペキュラーローブ（肌の表現に一般的に使用される設定。Lit マスターノードではサポートされていません）を提供するために StackLit マスターノードを使用しています。

2 つのスペキュラーローブについては、通常の Lit シェーダと同様に、主のスムースネスの値は Lit シェーダーと同様にマスクマップを介して提供され、二次的なスムースネスの値はマテリアルのインスペクターで調整可能な定数として公開されています。これもまた通常の Lit シェーダと同様に、マスクマップでは、アンビエントオクルージョンの係数や、2 つのディテールマップの影響をアーティストがコントロールすることができます。一方はディテール法線マップ、もう一方はディテールスムースネスマップです。ディテールスムースネスマップは、主のスムースネス、二次的なスムースネスの両方に影響を与えます。

通常のマスクマップに加えて、肌のシェーダーはキャビティマップ（シングルチャンネルのテクスチャで、キャビティの値が低いもの）も受け付けます。これは、スペキュラオクルージョンの係数をコントロールしたり、肌の毛穴のような小さなキャビティの滑らかさを減らすために使用できます。また、キャビティマップの影響は、オプションで、小さなキャビティが見通し角で見えなくなる効果をエミュレートするために、見通し角でならして消すことができます。

肌のシェーダーには、Gawain のために使用した Snappers のフェイシャルリグの姿勢駆動型の特徴（シワなど）のサポートもあります。肌のグラフでは、この機能はカスタムファンクションノードにカプセル化されています。これらの隠れた入力はパッケージの SnappersHeadRenderer コンポーネントによって駆動されますが、シェーダーを使用する SkinnedMeshRenderer と同じゲームオブジェクトに配置する必要があります。

肌のグラフのもう 1 つの興味深いノードは、ティアラインの設定に関連していますが、これは眼球のセクションの後で説明します。基本的には、ティアラインの設定が肌の法線を変更できるようにするためには、深度のプレパスの間に法線を計算して保存し（中間処理を破棄する再計算の代わりに）フォワードパスで法線を個別にサンプリングしなければなりません。

眼球

『The Heretic』のカスタムの眼球シェーダーは、シニアソフトウェアエンジニアの Nicholas Brancaccio とのコラボレーションによるものです。彼は、2 層のスプリットライティングモデルや、まぶた付近のオクルージョンの評価機能の実装など、初期の作業の一部を担当しました。デジタルヒューマンパッケージでは、これまでのカスタム機能の一部が HDRP の Eye Master ノードに移動し、これを眼球のグラフが出力として使用します。

眼球のシェーダーは効果的に眼球を 2 層のマテリアルとしてモデル化し、第 1 層は角膜と表面の流体を表現するために使用され、第 2 層は第 1 層から見える強膜と虹彩を表現するために使用されます。ライティングは 2 つの層の間で分割されています。すなわち、スペキュラー照明は上側の層（より光沢のある、角膜と表面の流体を表現する層）のみで評価され、拡散照明は下側の層（虹彩と強膜）のみで評価されます。

眼球のみを取り出したところとポイントライト

角膜の屈折は内部的に処理され、その効果は入力ジオメトリとユーザーが指定したいくつかのパラメーターの両方に依存します。眼球の入力ジオメトリは、角膜の膨らみを含む目の表面のみを記述する単一のメッシュである必要があります。

次に、角膜の表面がどこから始まるかを（大まかに）表すユーザー指定の断面が与えられれば、レンダリング中に、あるフラグメントが角膜の一部であるかどうかを判断することができます。フラグメントが角膜の一部である場合、視線のレイを屈折させ、屈折したレイと虹彩を表す仮想平面を交差させます。虹彩の平面は、角膜の断面からのオフセットを介して調整可能で、アーティストが眼球の視差の量を調整できるようにします。

眼球を回転させて角膜の屈折を観察する

虹彩の拡散照明を評価するために、眼球のシェーダーは、現在ラスタライズされている表面（角膜）のフラグメントに基づいて、光の入射方向を虹彩に向けて屈折させるオプションも用意されています。これでは適切なコースティクスは得られませんが（屈折を起こす表面の単一のフラグメントからの寄与分が蓄積されるだけです）、アーティストは少なくとも、例えば横から目を照らしたときに虹彩が不自然に影になることがないことを信頼できます。屈折の入ったライティング機能は、現在、Eye Master ノードの一部となっており、Eye Cinematic モードで有効にすることができます。

私たちは異方性球面ガウス分布を用いてまぶた付近の遮蔽をモデル化しました。この分布は、スキンアタッチメントシステムを用いてまぶたを追跡する 4 つのマーカー（トランスフォーム）によって駆動されます。具体的には、2 つのマーカーを用いて両方の眼角を追尾して目を閉じたときの眼軸を形成し、さらに 2 つのマーカーを用いて上下のまぶたを追尾して眼の閉じている度合いを角度を推論します。そして、この軸と角を用いて、眼球表面の異方性球面ガウシアンを評価するために必要な基底ベクトルを生成します。この評価結果は、Eye Master ノード上の環境およびスペキュラーオクルージョン因子への入力として直接使用し、（オプションで）アルベドを調整して隠蔽された領域を人為的に暗くします。

4 つのマーカーがオクルージョンのための異方性球面ガウシアンを駆動する

眼球のグラフでは、角膜の屈折やまぶたの近くのオクルージョンなど、説明した機能のほとんどは、グラフ内の EyeSetup というラベルの付いた 1 つのカスタム関数ノードによって促進され、グラフ自体に多くの読み取り可能な出力を提供しています。肌のグラフのフェイシャルリグのカスタム関数ノードと同様に、眼球のグラフのカスタム関数ノードでは、パラメーターの複雑さとフレームごとの性質上、マテリアルのインスペクターではなくスクリプトコードで制御されている隠しパラメーターを使用しています。特に眼球のグラフでは、隠しパラメーターはパッケージの EyeRenderer コンポーネントによって制御され、シェーダーが意味のある結果を生成するためには、シェーダーを使用するレンダラーが配置されているものと同じゲームオブジェクトに配置する必要があります。

EyeRenderer コンポーネントは、計算してシェーダーに値を渡すだけでなく、眼球の設定を支援するための便利なギズモやハンドルも提供しています。例えば、角膜の領域を定義する断面のオフセットを視覚化して微調整したり、与えられた眼球のジオメトリが正確に z 軸の方を向いていない場合に、平面テクスチャ投影の前方向の軸を検査して微調整したりするためのギズモがあります。

眼球をシーンビューのハンドルを使って調整する

最後に、肌のグラフと同様に、眼球のグラフにもティアラインの設定との統合を処理するノードがあります。法線とスムースネスは深度のプリパスの間に書き込まれ、フォワードパスの間に再びサンプリングされます。

ティアライン

ティアライン（目と皮膚の間にある湿った部分）を再構築するために、私たちは HDRP CustomPass API に頼っています。これはアプリケーションがカスタムレンダリングの結果をあるフレームの特定のステージに注入できるようにする仕組みです。

HDRP の法線バッファ（法線とスムースネスのデータの両方を保持している）の内容を操作するカスタムパスを使用して、顔の特定のスクリーンスペース領域（例えば、目と皮膚が出会う場所）の法線とスムースネスの値をぼかします。皮膚と目はフォワードのみのマテリアルなので、フォワードパスの間に結果を特別にサンプルするように、これらのグラフに特定のノードを挿入しなければなりませんでした。

法線バッファで滑らかな遷移を作ることで、2 つの表面を視覚的につなぐことができます。この領域に高いスムースネスの値を設定すると、2 つのマテリアルの間にスペキュラーハイライトが現れることが多く、ティアラインの領域が効果的に濡れて見えるようになります。

ぼかしが発生する領域をマークするために、特定のユーザーレイヤーに配置され、画面に色をレンダリングしないマスキングデカールのシンプルなセットアップを使用しています（デバッグ目的を除く）。デカールを特定のユーザーレイヤーに配置することで、より簡単にフィルターをかけたり、カスタムパスで排他的にレンダリングしたりすることができます。これはほとんどの場合、HDRP のユーザーステンシルビットのうち 1 つを設定するだけです。すべてのマスキングデカールがステンシルに描画されると、ぼかしを実行する領域を示すスクリーンスペースマスクを効率的に得ることができます。また、ブラーカーネルの幅をマスクのエッジまで動的に縮小して、ぼかしたい領域のエッジを越えてぼかすことを避けるために、このマスクを使用しています。

Gawain のティアラインについては、各側の眼球用にマスキングデカールを作成し、ニュートラルな顔のポーズでまぶたと眼球の両方が視覚的に重なるようにし、アタッチメントシステムを使って肌に貼り付けました。（4D データの一部で明らかになった）眼球とまぶたの間のわずかな隙間をサポートするために、ジオメトリを少し誇張して、眼球と内向きに重なるようにしました。

歯

歯のシェーダーは、サブサーフェススキャッタリングやクリアコート用のマスクなど、Lit マスターノードの多くの機能に依存しています。このシェーダーには、Lit の既存の機能を使用するだけでなく、口がいまどのくらい開いているかに基づいて、口の中を滑らかに暗くするために使用するカスタムタイプの減衰も追加されています。

現在の口の開き具合を近似するために、口の開口部の近くに 6 つのマーカーを配置し、唇の内部の輪郭をほぼ近似したポリゴンを形成します。Gawain の場合は、スキンアタッチメントシステムを使用してこれらのマーカーを駆動し、顔のメッシュがどのようにアニメーション化されていてもマーカーが唇に沿うようにしました。

レンダリング中に、まずこのポリゴンをシェーダーに渡し、シェーダーで現在のフラグメントの周囲の単位半球にポリゴンを投影して球形ポリゴンを作成します。直感的には、この球形ポリゴンは、現在のフラグメントの視点から見て、口の開口部から外側がどの程度見えるかを教えてくれるというものになります。

口の中の球体に貼り付いた球形ポリゴンの視覚化

口の内部を暗くするために、単位半球の面積に対する球形ポリゴンの面積を非物理的な減衰項として使用します（余弦を無視します）。具体的には、既存の環境オクルージョン係数とスペキュラーオクルージョン係数、コートマスク、アルベドを減衰させてから、これらをグラフの Lit マスターノードに渡します。

肌や眼球のグラフと同様に、歯のグラフにもカスタム関数ノードが含まれており、その入力はグラフでは見えません。歯のグラフの場合、隠し入力はパッケージ内の TeethRenderer コンポーネントによって提供され、シェーダーを使用するレンダラーが付いているものと同じゲームオブジェクトに追加する必要があります。