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

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

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

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

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

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

このセクションでは、例として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を参照してください。

ネットワークエディタで/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_pigとmantra_pig_packedの両方に対してIFDを生成してください。プロシージャルを使ったROPの実行速度に注目してください。

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

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

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

レンダリング時に外部ジオメトリを取り込む他のメソッドには、Delayed Load Proceduralがあります。 Delayed Load 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が一定の時間においてモデルを取り込む必要があるので、現在のフレームでのジオメトリ、さらに 最低でも1つ の他の時間でのジオメトリを必要とします。 IFDファイルにジオメトリを含める場合、これはIFDのサイズがもっと膨れ上がります。なんてこった!

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

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

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

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

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

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

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

関連項目:

• Alembicファイル

• Alembic Geometry SHOP

• 膨大なポリゴンのレンダリング