Houdini 19.0 レンダリング

IFDワークフロー

Mantraでレンダリングをする時にIFDファイルのサイズを小さくする方法に関する簡単な概要。プロシージャル、Alembicアーカイブ、パックプリミティブを使用してIFDを小さくする方法と HQueueによるIFDの挙動について。

On this page

始める前に

IFDをディスクに書き出すには、Houdini、Houdini FX、Education、Indieのどれかのライセンスが必要です。

Apprenticeユーザは直接IFDを生成することはできません。しかし、これらのワークフローを使用することで、いくつかの状況においてレンダリング時間を改善させることができます。 例えば、シーンの背後でのIFD生成をより速くすれば、Mantraレンダラーの起動がより速くなることでしょう。

IFDが重要である理由

Mantraでレンダリングをする際、Houdiniはシーンファイルの内容をMantraで読めるシーン記述ファイルに書き出します。 そのシーン記述ファイルこそが IFD ファイルであり、Instantaneous Frame Descriptionの頭文字です。

通常では、Mantraを使用してレンダリングをする際には、単にレンダーを実行すれば、HoudiniがIFDを生成し、それをMantraに送信してディスク上の画像へレンダリングします。 (特に複雑で長いショットに対しては)この処理が長くなりIFDファイルが大きくなる可能性があり、さらにHoudiniまたはHoudini Engine(Houdini Batch)ライセンスを消費します。

ライセンス数の観点では、Houdiniのフルコマーシャルライセンスには 無制限 のMantraトークンが付いてくるので、このことを知っておくことが重要になります。 つまり、レンダリングに多くのマシンを使用することができると同時に、作業用とシミュレーションの実行用にHoudiniとEngineのライセンスを開放することができます。 そのため、レンダリングをするのにできるだけIFDを高速に生成できることが非常に重要になってきます。

パイプラインの観点においても、IFDを軽量化することが重要です。 たとえアニメーション部門がアニメーションを更新したり、モデリング部門がプロップを修正したり、TDがシミュレーションを調整したとしても、 マテリアルまたはライトが変わった時にだけIFDを更新する必要があります。 マテリアルまたはライトが変わらないなら、単にMantraは次にIFDをレンダリングする時にはディスク上のジオメトリの変更をピックアップするだけです。

(Educationライセンスは教育機関向けのライセンスであり、非商用フォーマットで保存される点を除いては機能的には商用のHoudiniFXライセンスと同等です。詳細は、以下の 教育機関向けHoudini のドキュメントを参照してください。)

関連項目:

Blosc圧縮

バージョン14.0以降では、HoudiniはBlosc圧縮のIFDに対応しています。 これはサイズを非常に簡単に小さく且つ高速なIFDを生成できるので便利です。また、Blosc圧縮はbgeo,vdb,ratにも対応しています。

HQueueとIFDのレンダリングセクションの最後には、.ifd vs .ifd.scの比較を載せていますので、そのサイズの差に関して何かアイデアを得ることができます。

(Blosc圧縮のIFDを使用して何かバグ(またはHoudiniでの他のバグでも)を発見されましたら、サポートオンラインを使ってバグのログを送ってください: バグと機能要望の提出。誰でもバグを報告することができます。お得意様や商用ユーザでなくても構いません!)

コンパクトなIFDの生成

Mantraレンダリングにおける“プロシージャル”とは、特殊なマテリアルによってレンダリング時に生成されるジオメトリのことを言います。 つまり、そのようなジオメトリはIFDファイルには保存されておりません。 プロシージャルの例を挙げると、ファーのレンダリングに使用するマテリアルがそうです。 このマテリアルは、シーンファイル内に現在あるガイドヘアーの情報を元に、何千ものヘアーを補間する方法と場所をMantraに知らせます。 他の種類のプロシージャルでは、レンダリング時にディスク上の外部ジオメトリファイルを参照します。

IFDのサイズを小さく維持させる最も良い方法は、ジオメトリをIFDにベイクさせるのではなく、 外部ジオメトリ または プロシージャルに生成される ジオメトリを参照することです。

Tip

このサンプルでは、ポリゴン、パックプリミティブ、Alembicキャッシュを使用していますが、それと同じ原理をボリュームジオメトリに適用することができます。

サンプルファイル

以下のセクションでは、サンプルファイルを参照しています。そのサンプルファイルを使用したいのであれば、以下のファイルを読み込んでください:

$HFS/houdini/help/files/ifd_workflows/ifd_workflows.hip

HoudiniがIFDファイルを書き出せるように、そのifd_workflowsディレクトリを$HFS外のユーザディレクトリ下のどこかにコピーしてください。

Alembicとパックプリミティブ

Houdiniは、業界で使用されているAlembicキャッシュに対応しており、さらに高速で柔軟性のあるBulletソルバがパックプリミティブに対応しています。 この対応のおかげで、アーティストは、自分のワークフローにより多くのジオメトリを作成できるようになっています。 モーショングラフィックスや背景モデルでも、その最新のジオメトリフォーマットの恩恵が受けられます。 これらのフォーマットは、高速なIFDワークフローに上手く適応します。

パックプリミティブには色々なタイプがあります:

Packed Geometry

Houdiniセッション内の“そのままの”ジオメトリから構築されます。

Packed Disk Primitive

ディスク上のファイルから読み込まれるパックプリミティブ。

Packed Fragments

これもHoudiniセッション内の“そのままの”ジオメトリから構築されます。

(詳細は、パックプリミティブを参照してください。)

このセクションでは、例としてPacked Disk Primitivesを使用していますが、Alembicプリミティブを使用しても構いません。私たちは、以下のセクションのモーションブラーでAlembicを使用しています。

Houdiniで作業する時は、Packed PrimitivesとAlembicプリミティブを頻繁に相互にやり取りすることができます。常にそうすること必要はないですが、通常ではそういうことをします。 これは、Packed PrimitiveがAlembicプリミティブを一般化したものであるとはいえ、そのAlembicプリミティブを 含む すべてのタイプのジオメトリで構成することができるからです。 詳細は、Packed Primitivesのページを参照してください。

Packed Disk Primitivesは本質的にはAlembicプリミティブと同様にファイルからストリームされるジオメトリなので、特別なプロシージャルを使用してIFDを小さくさせる必要はありません。

サンプルファイルのpacked_pigジオメトリオブジェクトの中を見てください。 そのオブジェクトには、いくつかのノードで構成されたジオメトリネットワークが作成されており、すべてのノードがCopy SOPに接続されています。 File SOPを見ると、そのSOPがpig.bgeo.scを指しています。ディスク上のジオメトリを複製しないように、File SOPにはジオメトリをPacked Disk Primitiveとして読み込むためのオプションが用意されています。 Load パラメータを“Packed Disk Primitive”に設定すると、Houdiniは、そのジオメトリをFull Geometryで読み込まずに、ディスクから豚のモデルをストリームで読み込むようになります。

(このファイルはパックジオメトリなので、File SOPには、Houdiniで表示しなければいけない量を管理するための素晴らしいオプションが用意されています。私たちはbgeoをPacked Disk Primitiveとして読み込んでいるので、これはIFDには関係ありませんが、操作性をより快適にします。)

mantra_pig_packed ROPを実行して、そのIFDファイルを見てみると、そのファイルサイズはたったの15Kbです! パックした豚をいくつかのポイントにコピーして、それぞれの豚のカラーを変えたとしても、 そのIFDのサイズはまだ小さいです。Packed Disk Primitivesを使用することで、ディスク容量とネットワークIOを抑えることができます。

ディスク上のジオメトリにはMaterial Stylesheetsが非常に便利です。 Material Stylesheetsを使用すれば、ジオメトリを読み込んでそこにシェーダを紐付けることをすることなく、シェーダを割り当てたり変化させることができます。 Material Stylesheetsを参照してください。

IFDの生成

ネットワークエディタで/outに進み、その中のROPを見てください。私たちは、 Force Objects パラメータを使用して、各ROPがシーンの特定の部分のみをIFDに出力するようにしています。

IFDがマテリアルを取得できるようにするために、各ROPの( Rendering ▸ Render タブ) Declare Materials パラメータを“Save All SHOPs”に設定しています。 ジオメトリはマテリアルを参照しているだけで、そのジオメトリにはマテリアルが含まれていないので、そのマテリアルをIFDに含める必要があります。 すべてのSHOPをDeclare(宣言)することで、すべてのマテリアルが強制的にIFDに含まれるので、それらのマテリアルがどのプロシージャルからでも利用することができます。

pigまたはprocedural_pigのどちらかでオブジェクトレベルまたはSOPレベルでマテリアルが割り当てられていることに気づくことでしょう。 どちらともshop_materialpathというアトリビュートがあります。現在のHIPファイルにそのアトリビュートと合致したマテリアルがあり、且つ、ROPでそれらのマテリアルをDeclare(宣言)している限りは、すべてがレンダリングされます。

mantra_pig_packed ROPの Driver タブに進みます。 Disk File チェックボックスがオンになっています。 Render to Disk をクリックすると、何も起こっていないように見えますが、ROPはIFDファイルを生成します(一時的にIFDファイルを生成してそれを自動的にレンダリングしているわけではありません)。 mantra_pigmantra_pig_packedの両方に対してIFDを生成してください。プロシージャルを使ったROPの実行速度に注目してください。

開いたプロジェクトのifdフォルダの中に入ると、IFDのサイズが劇的に違うことがわかります:

ファイル

サイズ

mantra_pig.ifd.sc

4.3 MB

mantra_pig_packed.ifd.sc

10 KB

このメリットは明白です: パックジオメトリを含まずにそれを参照したIFDファイルのサイズは、それを含んだIFDファイルの0.2%になっています。そして、ジオメトリファイルが変わったとしてもIFDを再生成する必要はありません。

車、窓、他のプロップを含んだ 数百ギガバイト のショットを600フレーム長でレンダリングすることを想像してみてください。そして、同時に多くのコンピュータからそのショットにアクセスすることを想像してみましょう。 スタジオがこの方法で作業をすることを好む理由がわかるでしょう。たった一人のアーティストでも、あまり規模の大きくない学校でも、ディスク容量が節約され、そしてHoudiniライセンスの代わりにMantraトークンを使用することは 非常に大きな恩恵があります。

Delayed Load Procedural

レンダリング時に外部ジオメトリを取り込む他のメソッドには、Delayed Load Proceduralがあります。 Delayed Load Proceduralとは、レンダリング時にディスクからオブジェクトのレンダリング可能なジオメトリを取得し、そのオブジェクト内にあったどんなジオメトリも置換するシェーダのことです(つまり、そのオブジェクトは空っぽのままでもよく、または単純なプロキシジオメトリを含めても構いません)。

Note

このワークフローは、Alembicファイルとパックプリミティブによって、もはや時代遅れになりました。将来のバージョンでは、Geometry Proceduralプロセスが大きく変わるか、または存在していないかどちらかになるでしょう。

サンプルファイルでは、pigというGeometryオブジェクトとprocedural_pigというGeometryオブジェクトがあります。各ノード上でを押したままにすると、pigには1個の子SOP($HIP/geo/pig.bgeo.scを指したFile SOP)、procedural_pigには子ノードが ない ことがわかります。

procedural_pigノードを選択します。パラメータエディタで、 Render ▸ Geometry タブをクリックします。 Procedural Shader というパラメータがDelayed Load Proceduralを指しています。 そのノードにジャンプすると、 File パラメータがディスク上のpig.bgeo.scファイルを指していることがわかります。

Render Viewタブをクリックし、そのROPにmantra_pig_proceduralを設定すると、私たちの豚の像がレンダリングされます。mantra_pigをレンダリングして、視覚的に比較してみてください。

(Auto-Updateがオンの時、場合によっては、まだ古いジオメトリをレンダリングすることがあります。そんな時は、再度'Render'ボタンをクリックするか、'Refresh'アイコンをクリックすることで、古いIFDを更新して、新しいIFDを生成します。)

上記のパックプリミティブを使ったワークフローと同様に、生成されるIFDは、その豚のジオメトリを含んでいるのではなく参照しているのでサイズが 非常に 小さいです:

ファイル

サイズ

mantra_pig.ifd.sc

4.3 MB

mantra_pig_packed.ifd.sc

8 KB

アニメーションするジオメトリ

モーションブラーを付けるためには、Mantraが一定の時間においてモデルを取り込む必要があるので、現在のフレームでのジオメトリ、さらに 最低でも1つ の他の時間でのジオメトリを必要とします。 IFDファイルにジオメトリを含める場合、これはIFDのサイズがもっと膨れ上がります。なんてこった!

このサンプルでは、外部のAlembicアニメーションキャッシュを参照することで、IFDを小さく維持すると同時にモーションブラーを使用する方法を説明しています。

サンプルの.hipファイルを開き、alembic_bearというオブジェクトを選択します。このオブジェクト自体は、プラスチックマテリアルだけを持った非常に単純なオブジェクトです。 その中のAlembic SOPは外部Alembicファイルを指しています。これは、私たちが前のセクションでパックプリミティブを扱った時と非常に似ています。

/outネットワークに進み、mantra_bear_alembicというROPを選択します。 Rendering タブの Geo Time Samples2に設定されています。 私たちは外部Alembicキャッシュを使用しているので、このパラメータは、Mantraに2つの異なる時間で同じキャッシュをサンプルするように伝えますが、ジオメトリをIFDにコピーする必要はありません。

このノードをレンダリングすると、熊に適切なモーションブラーがかかります。 外部ファイルを参照しない他のモーションブラーROPとこのノードを比較してみてください: mantra_bear_geo_samplesmantra_bear_velmantra_bear_geo_samplesノードは単にbgeoジオメトリをレンダリングしているだけなので、Geo Time Sample毎にジオメトリのコピーがIFDに含まれます。 mantra_bear_velノードもbgeoを使用していますが、Velocityを v アトリビュートとしてポイントにベイクしています。

すべての3つのノードはモーションブラーがかかった熊をレンダリングしますが、生成されるIFDのサイズがまったく異なります:

ファイル

サイズ

mantra_bear_alembic.ifd.sc

11 KB

mantra_bear__geosamples_2.ifd.sc

67 KB

mantra_bear__geosamples_3.ifd.sc

101 KB

mantra_bear_samples_vel.ifd.sc

49 KB

熊のポイント数が626個しかないので、この違いは豚のIFDと比べて劇的に変わっていません。 それでもAlembicキャッシュを使用することで多大な恩恵が得られていることがわかるでしょう。 ジオメトリがより複雑になるほど、もはやメリットしかないです。

(フレーム毎にパックプリミティブの.bgeoファイルを生成することで軽量のIFDを得ることも可能ですが、レンダーファームのネットワークIOの能力が単一のAlembicキャッシュよりも劣ってしまうことが考えられます。これは必ずそうとも限らないです。すべてのネットワークが異なるのですから。しかし、レンダーが単一タイプのジオメトリを使った場合に処理が遅いようでしたら、他の方法を試してみてください。)

関連項目:

HQueueとIFDのレンダリング

複数のマシンにアクセスできるなら、HQueueによってシミュレーションとレンダリングを複数のコンピュータに対して行なうことができます。 HQueueでは、専用マシン(またはマシンのグループ)を使用してIFDを生成し、その他のマシンが直接IFDをレンダリングするための機能が組み込まれています。 IFDジェネレータはHoudini/Engineライセンスのみを必要とします。他のマシンはMantraレンダートークンを使用します。 現在、あなたはIFDを最適化するために外部ジオメトリを使用しているので、そのIFDの生成部分が非常に速くなっており、たくさんのマシンを必要としません。

Note

以下のHQueueサンプルをレンダリングするには、まず最初にHQueueファームをセットアップし、 HQueue Server パラメータをあなたのネットワーク上のサーバーに変更する必要があります。 また、 Target HFS をクライアントで使用される$HFS値に設定する必要があります。HQueueがセットアップできないなら、このセクションの最後のHQueueドキュメントのリンクをチェックしてください。

mantra_bear_alembic_hq ROPはmantra_bear_alembicと同じですが、 Frame Range をレンダリングするように設定されており、 Driver タブの Disk File チェックボックスがオフになっています。 mantra_bear_alembic_hqHQueue Renderノードに接続されています。

そのHqueueノードの Mantra Options タブでは、 Generate IFDs パラメータがオンになっており、その出力パスは$HIPを基準にしています。 また、 Assign IFD Job To をレンダリングするクライアント上でIFDを生成する設定から“Clients from Listed Groups”に変更しました。 この例では、IFDを生成するマシンのグループ名はifd-makerです。 Advanced タブでは、レンダージョブを“Clients from Listed Groups”に割り当てていますが、そこではifd-renderグループを指定しています。 そのため、ifd-makerグループ内のクライアントでIFDが生成されると、ifd-renderグループ内のクライアントがそのIFDをレンダリングします。

このノードをレンダリングして、HQueue Dashboardを開くと、そこには Generate IFDs という1個のジョブがあり、その残りのクライアントがレンダリングをしています。 興味あればライセンスマネージャーを見てください。それらのマシンのすべてがHoudiniまたはHoudini Engineライセンスを使用していないことがわかります。それらのマシンのすべてがRenderトークンを使用しています。

他の熊のHQueueノード(bgeoとvel)をレンダリングして比較してみましょう。各ノードで24フレームのアニメーションをレンダリングし、すべてが完了したら、各ノードの24個のIFDの合計サイズを比較してみてください:

ジョブ

サイズ

サイズ (.sc圧縮)

mantra_bear_alembic_hq

484Kb

328Kb

mantra_bear_geo_samples_hq

3.1Mb

1.8Mb

mantra_bear_vel_hq

1.9Mb

1.3Mb

関連項目:

謝辞

  • 熊のアニメーションサークルを提供してくれたGuillaume Arantes。

  • mimetypeアイコンを提供してくれたAlen Warren。

レンダリング

Mantraユーザガイド

基本

ライティング

次のステップ

導師レベル

他のレンダラー