2021年11月に開催いたしましたHoudini19 ゲーム開発者向けセミナーにおいて紹介された機能をまとめました。
セミナー動画は下記より視聴いただくことが可能です。
ここではPyroに関して簡単にまとめたいと思います。
詳細はぜひ上記セミナー動画をご視聴ください。
上に出ているのは SimpleFX シェルフで、これ自体は新しいものではありませんが、従来の PyroFX とは別に SOP ベースのシミュレーションツールをまとめたシェルフが SimpleFX として存在します。
ここにあるツールは Houdini Core でも使えます。PyroFX シェルフは、HoudiniFX が必要となります。
この中には GPU で実行されるMinimal Solver を構成するツールもあるので非常に便利です。Minimal Solver は OpenCL で実行されます。
以前はソースのベイクが必要でしたが、 今回ソースのインスタンス化が可能になり、ソースの移動や向きの操作が可能になりました。 この動画では、このトーチが動いて、向きが変わっています。
上記のようにトーチの先端にパイロソースをインスタンスすることで、 動き回ることで向きが変わっても、 セミリアルタイムソルバで更新されています。
また、これはビューポート描画の向上度合を示す良い参考例になっています。最終出力の評価が可能です。
この設定もsimpleFXシェルフのGPU Torchから作成することが可能です。
次の例は、最終的には Texture Sheet で書かれたカードを UE5 上で実行しています。
このエフェクトを作る上で、データを最適化した上で、いかにリアルに見えるエフェクトを作れるかということが重要でした。
※動画をご確認ください。
正しい色を出力するのに重要なのが正しいカラースペースで作業することです。
右の画像は ACES のカラースペースを使っています。 ACES は Academy Color Encoding System の略で、 ハリウッド系映画業界では近年標準となっています。
この設定は従来は 自分で ディレクトリ一式をダウンロードして環境変数 OCIO でパスを設定する必要があったのですが、最近リリースの SideFX Labs ツールでクリックで設定できるようになっています。
次に、新しいフリップブック生成方法をご紹介します。
画面の左下にある、フリップブックのレンダリング設定のサイズタブで、フリップブックのレンダリングを直接行うことができます。
sheet sizeという新しいオプションを使用し、希望するフリップブックの行番号と列番号を指定することができます。
「Render」ボタンを押すと、すべてのフレームがレンダリングされ、下図のようなグリッドに自動的に合成されていきます。これにより、すべての中間ファイルを保存し、合成のためにそれらを読み込む必要がなくなります。
すべてのフレームがレンダリングされると、それがデスティネーションバッファにコピーされるので、既製のフリップブックである「Mplay」で1フレームを処理するよりも効率的で高速です。
手作業ではなく、もっと自動化したいという方には、「Flipbook Textures」というツールをご用意していますので、ぜひご利用ください。この機能はSideFX Labs 19.0.448で追加されました。
このツールは、単にテクスチャを合成してレンダリングするだけでなく、さまざまな種類のテクスチャをレンダリングしたり、途中で設定を変更したりすることができるので、プロセスが非常に効率的になりました。
実際の下記のようなエフェクトを作る上で、重要な部分はレンダーパスになります。
ここでは、左が Base Color で 右が Smoke Color です。
この2つの違いは、Smoke Colorは基本的にBase Color でからEmissiveコンポーネントを除いたものです。
このワークフローは、Emissiveコンポーネントだけを格納するEmissiveマップを使用する以前のワークフローとは異なります。
ここではEmissiveコンポーネントは、単純にBase ColorからSmoke Colorを引き算しただけです。これは従来のワークフローとは異なり、 Emissive Map を生成が不要になりました。
これによる利点が二つあります。
ひとつは、減算法であるため、ボリュームの上にある黒いマスキング部分を変更することなく、Emissive成分をうまく分離することができます。
このように、Emissiveをオンにせず、Base Colorにテクスチャを差し込むだけで、ダークバージョンになります。そして、炎のEmissive成分の強さやカーブを独立してコントロールすることができます。
※実際の調整はセミナー動画をご確認ください。
2つ目の利点は、Smoke Colorを単独で無指向性散乱のソースとして使用できることです。無指向性散乱は、煙が空や一般的な環境から拾ってくる色のことで、どちらかというと全指向性に近いため、煙の色にはアンビエントオクルージョンが焼き付けられています。
つまり、単純にすべての値が同じ量だけ明るくなるのではなく、グラデーションによって明るくなるので、このようにとても見栄えが良くなるのです。
Houdini 19 ではビューポートにも様々改善があり、そのうちの一つが モーションベクトルをビューポートに直接表示できるようになったことです。
従来は Mantra でレンダリングしないと確認できず時間がかかりました。しかし、ノード追加するだけでビューポートに表示され、カメラやオブジェクトを動かせばインタラクティブに更新されます。 モーションベクターは常に見る角度とビューポートの大きさに応じて計算されます。
設定方法は、
ビューポートでモーションベクターやNormalを確認する方法はこちら。
モーションベクトルを使うことでより少ない画像数でもスムーズな再生を可能にします。つまりモーションベクトルがテクスチャシートの各画像のをベクトルで変形して表示しよりスムーズに見せるからです。
左側はモーションベクトルが組み合わされた時の様子で。右は、それをデータ量を削減すべく様々にエンコードしたものです。
エンコーディングが実際に何をしているのかを比較した結果です。
中央にあるのは、ベンチマークとして使用している16ビット/チャンネルのモーションベクターの高価なバージョンです。すべてがスムーズで、バンディングもあまりないことがわかります。左側に見えるのは、標準的なR8G8のモーションベクターです。バンディングが見られ、非常にピクセル化されているように見えます。エンコーディングの方法を基本的に変更し、右側には新しいバージョンが表示されています。つまり、ここに表示されているのは、Unreal Engineのビューポート内でデコードされたフォーマットです。
つまり、その前のテクスチャとは異なり、8ビットバージョンに比べて16ビットバージョンにはるかに近く、バンディングがはるかに少ないことがわかります。これが意味するところは、深刻なバンディングがあると、異なる速度で動くはずのピクセルが同じ速度で動くことになり、よりリアルで滑らかでないものになるということです。これが、メモリサイズを抑えながら解決しようとしている問題です。
Motion Vector 無しで再生すると非常にかくついてみえますが、途中で MV をオンにすると、その後スムーズに再生されるのがわかります。
※セミナー動画にてご確認ください。
モーションベクターに加えて、新たにビューポートでノーマルマップが表示できるようになりました。左側は、ビューポートからレンダリングされたノーマルマップで、これもインタラクティブに操作できるものです。
ボリュームを回転させたり、カメラの位置を変えたりすることができますが、ノーマルマップは常にビューポートに関連して計算されます。右側はグレースケールで、コンポーネントの1つを示しています。必ずしもRGB 3チャネルすべて持つ必要はなく、2つのコンポーネンチャネルから3つ目のコンポーネントをシェーダーで動的に導き出すことができます。これにより、テクスチャのスペースが節約でき、モーションベクターを配置した同じテクスチャにノーマルマップをパックすることができます。
もうひとつの変更点は、このノーマルマップによって、ボクセル単位のノーマルをより詳細かつ正確に表現できるようになったことです。そのため、先ほどの火砕流のような状況では、細かいディテールをフラットにすることができます。
ノーマルマップの以前の作成方法は、6方向から照射されるRGBのライティングリグを使用し、その光の結果をノーマルに再解釈することで、全体としてより滑らかな法線を作り出しました。その方法では、よりボクセル単位の詳細なレベルとブレンドする必要がありますし、各ピクセルでは、どの色をエンコードするかという選択肢が1つしかないことになります。そのため、ブレンドでは常にどちらかが犠牲になります。
このようにして、高度に詳細なバージョンを維持しつつ、高レベルのノーマル処理を全く異なる方法で行うことで、より正確なライティング結果を得ることができます。
ノーマルオフ
ノーマルオン
新しいライティング手法は、MDC（マルチ・ディレクショナル・コントリビューション・マップ）と呼んでいます。名前の通り方向からの構成によりブレンドを行います。
以前の方法と違って軸に固定ではなく、必要とされるシーンのライトの方向に合せることが容易になり、よりシーンにあったライト情報をシェーダに渡すこと可能で、かつダイナミックにライティング情報が計算されます。
左の画像はそのうちの単一チャネルだけを表示したものです。これは後ろからライトが当たった状態です。右側は複数の異なるチャンネルを合成したもので、それぞれのチャンネルが独自の色を持っています。このリグでは正八面体を使用しており、照明の方向は基本的に正八面体のFaceノーマルから来ています。これにより、様々なアングルをカバーできるようになりました。アングル間の光の方向を解釈することは、通常、問題が多いからです。したがって、リグ内のさまざまなライト間の角度が減少するように補間されると、全体的な結果が大幅に向上します。ライトの位置は常に重要なので、実際にスモークが発生する場所に近い形でライトを配置しています。これらのテクニックを組み合わせることで、実際に使用する際には、より正確な結果が得られるテクスチャマップを得ることができます。
下記がシェーダーの結果です。
ここでは、MDCマップの結果をオンにしています。
設定したパラメータは、強い方向性を持つDirectional Scatterです。
この例では、光が左後ろから来ているので、リムライトの効果を与えます。
全てオフ
Directional Scatter Intensity オン
Directional Scatter Curveオン
Directional Scater Offsetオン
ライトを動かした状態。
ライトを雲の周りで回転させるとスムーズなトランジションが確認できますが、これが MDC から来ている結果です。
従来のノーマルマップよりも良い結果を生み出していてます。
次に「 Normalized Depth Map.」について説明します。
これは、カメラに基づいて、カメラに近いボクセルから始まり、カメラから最も離れたボクセルで終わる深度マップを計算しています。ゼロから1の範囲に正規化されますので、Houdiniでは実際の煙の大きさは関係ありません。理由はシェーダー上でそれを動的に解釈する必要があるからです。そのため、それぞれの出力は0から1になり、Exportもしやすくなります。テクスチャメモリをあまり使わずに、エンジン内で1チャンネルの圧縮を行うことができます。
ノーマル、モーションベクター、エミッシブ、MDCマップによるリムライト効果、全方位ライトでの空の色の反映すべてを有効した結果はセミナー動画にてご確認ください！