Packジオメトリノードを使用してジオメトリをパックプリミティブに変換することで、 メモリ内 のパックプリミティブが得られます。 これは、メモリ内に、あなたの現在のバージョンのジオメトリの埋め込み参照を持ったPacked Geometry Primitiveを作成します。 “埋め込まれた”ジオメトリは、1個のトランスフォームを持った1個の編集不可な“プリミティブ”になります。

“埋め込まれたジオメトリ”は、単にメモリ内の内容の参照です。パックプリミティブをコピーすると、ジオメトリ自身がコピーされるのではなく、 参照 がコピーされます。そのため、参照されたジオメトリがパックプリミティブのすべてのコピー間で共有されます。これは、パックされていないHoudiniジオメトリをコピーするよりも非常にメモリ効率が良いです。パックされていないHoudiniジオメトリでは、すべてのポイント、プリミティブ、アトリビュートなど独立して複製されます。

パックプリミティブのコピーはメモリをあまり使用せず、トランスフォームが簡単で、より効率的にビューポートでの描画やMantraによるレンダリングをすることができます。

参照されたジオメトリは通常のネットワーク内で存在するので、簡単にシーンに順応したプロシージャルなジオメトリを生成することができ、スタンプを使うことでバリエーションのあるパックジオメトリを生成することができ、結果をリアルタイムで確認しながらインタラクティブにジオメトリを編集をすることができます。基本的には、メモリ内のパックプリミティブを扱うほどインタラクティブ性が高くなり、従来のインスタンスワークフローよりもユーザが使いやすくなります。

ジオメトリネットワークのメモリ内のパックプリミティブそれぞれのコピーを“アンパック”することで、参照されているジオメトリの実際のコピーを作成することができます。これにより、従来のHoudiniジオメトリとパックプリミティブのハイブリッドなプロシージャルワークフローを生成することができます。

ここでいう パック とは“圧縮”や“軽量化”を意味していません。RAM内で元のジオメトリを保持し、さらに各参照に対して少ないメモリを使用しています。単一のパックプリミティブは、元のジオメトリを使用するよりも必ずしも効率的であるとは限りません。このメリットは、参照されているジオメトリを共有して膨大な数のコピーを効率的に表現できることです。 これは、パックプリミティブをコピースタンプ時に重要です。パックジオメトリのインスタンスがすべて固有であれば、メモリやパフォーマンスのメリットはありません。実際に、これは“実際の”ジオメトリよりもメモリを消費します。その理由は、各パックプリミティブにオーバーヘッドがあるからです。 (ただし、スタンプのバリエーションの数に限りがある時は、スタンプジオメトリをパック化する負荷を多少は相殺することができます。Copy SOPの Cache Stamping Geometry パラメータを参照してください。)

Packed Disk プリミティブは、ディスク上のファイルに参照を埋め込みます。 表示またはレンダリング時に、Mantra/Houdiniは、メモリ内にデータを保持するのではなく、ディスクからデータを読み込みます。 .bgeoやAlembicなどのファイル形式は、高速なランダムアクセスでデータの内容にアクセスすることによって、そのデータを非常に効率的にします。 Packed Diskプリミティブは、単にファイルから既に生成されたデータを読み込むだけなので、メモリ内のパックプリミティブほど動的ではありません。Packed Diskプリミティブを編集する唯一の方法は、それを“アンパック”して、そのファイルデータをメモリにコピーすることです。

File SOPの Load パラメータを Packed Disk Primitive に設定することで、ディスクからジオメトリをパックプリミティブとして読み込むことができます。

Packed Diskプリミティブは、メモリ内のパックプリミティブと同様に、“埋め込まれた”ジオメトリは、単一のトランスフォームを持った単一の編集不可なプリミティブとして表示されます。 メモリ内のパックプリミティブとほぼ同様に、Packed Diskプリミティブは、ビューポートやMantraでジオメトリのコピーを効率的に作成するのに非常に良い選択肢です。Packed Diskプリミティブのコピーは、単に 参照 をディスクファイルにコピーするだけです。 ビューポートはインスタンス毎にジオメトリをコピーせず、単に異なったトランスフォームで複数回同じデータを描画しているだけです。 ビューポートは参照されたジオメトリを、ポイントクラウドや境界ボックスのようにより単純化した表現で描画することもできます。

Houdiniと同様に、Mantraはデータをメモリにコピーせずに、必要な時にディスクファイルからデータを“ストリーム”することができます。 これによって、Mantraのメモリ使用量を減らすことができます。 Houdiniは、メモリ内のジオメトリに関しては、全体のジオメトリをIFDファイル(Mantraに送信されるシーン記述ファイル)に書き出さなければならないのに対し、Packed Diskプリミティブに関しては、単に 参照 をディスク上のファイルに書き出すだけです。 Packed Diskプリミティブは、IFDの生成を高速にし、非常に大きくて複雑なシーンに対してそのIFDのディスクサイズを小さくすることができます。

Packed Diskプリミティブは、シーンの組み立て、特に静的な背景オブジェクトに適しています。 レンダリング時の少ないメモリ使用量は、シミュレーション出力などの大きなディスク容量を持つオブジェクトにも非常に役に立ちます。

Packed Disk Sequence(PDS)プリミティブは、Packed Diskプリミティブ(上記参照)と同様ですが、ジオメトリファイル名のシーケンスとそのファイルシーケンスのインデックスを参照します。 Mantraは、Packed Disk Sequenceプリミティブをシーンの一部として読み込んだ時に(現行フレームのジオメトリだけでなく)そのフルシーケンスを知ることになるので、モーションブラーでフレーム間を補間することができます。 つまり、Packed Disk Sequenceプリミティブは、モーションブラーを使ったレンダリングにおいて効率的にアニメーションジオメトリを(フレーム毎のジオメトリファイルの形式で)インスタンス化することができます。

アニメーションシーケンスをPacked Disk Sequence(PDS)としてインポートするには、File SOPを使用します。 その Load パラメータを Packed Disk Sequence に設定します。 Geometry File パラメータの隣にあるファイル選択アイコンをクリックして、読み込むジオメトリシーケンスを選択します。

File SOPの Sequence Index パラメータは、使用するアニメーションシーケンスの(浮動小数点)フレームを設定します。 デフォルトは$FF - 1です。Packed Disk Edit SOPを使用することで、既存のPacked Disk Sequenceプリミティブのインデックスを編集することができます。

Packed Diskプリミティブは、レンダリングするフレームがアニメーションのフレーム範囲外の時に自動的に循環します。 File SOPの Wrap Mode を Clamp 、 Cycle 、 Mirror 、 Strict のどれかに設定することで、これを変更することができます:

• Cycle:サンプルインデックスを有効な範囲に自動的にラップします(デフォルトの挙動)。

• Clamp:範囲外のインデックスサンプルを有効な範囲にクランプします(そのため、例えば、有効なフレーム範囲が1-5であれば、5より大きいフレーム番号はフレーム5に固定されます)。

• Mirror:ジグザグまたはピンポン形式で逆にしてラップします。

• Strict:空っぽのジオメトリを有効なフレーム範囲外にします。

nameアトリビュートを含んだジオメトリをパックする時、それと同じname値を共有する各ジオメトリが パックフラグメント プリミティブになります。 このプリミティブは元のジオメトリの参照を含みます。 そのため、各フラグメントは同じジオメトリを共有していますが、そのジオメトリのサブセットを参照します。 フラグメントをアンパックすると、元のモデルのその部分のみがメモリにコピーされます。

パックフラグメントプリミティブは、完全モデルを構成するたくさんの破片を表現するのに適しています。 特に、各フラグメントが例えばリジッドボディシミュレーションでそれぞれ固有のトランスフォームを受け取る時がそうです。

各フラグメントは単に元のジオメトリの参照にすぎないので、膨大な数のフラグメントがある時に非常に効率的です。 とはいえ、ほとんどのフラグメントが削除されていると、実際のジオメトリを使用するよりも効率が悪くなることがあります。 少しの破片しか残っていなくても、Houdiniはまだメモリ内に全体の元のモデルを保持し続けます。 それに対し、実際のジオメトリを使用した場合、最初はメモリ使用量が多いですが、パーツを削除するとメモリ使用量が減ります。 少しの破片しか残っていない箇所で残りのフラグメントを“アンパック”することで、両方の良いメリットを得ることができます。

標準のジオメトリの場合は、2つのレベルでマテリアルを割り当てることができます:

• オブジェクトレベルでは、Geometryノードのパラメータで割り当てます。

• ジオメトリ(SOP)レベルでは、Materialノードを使用して、特定のプリミティブ上にmaterialアトリビュートを設定します。これは、そのアトリビュートを持ったプリミティブに対してオブジェクトマテリアルを上書きします。

Houdiniはレンダリング用のシーン記述ファイル(IFD)を生成する時、マテリアルを割り当てるためにオブジェクトとジオメトリのアトリビュートをチェックするので、どちらのシェーダをIFDに含めるべきか知っています。

パックプリミティブを使用する時は、Houdiniは3つ目レベルまでのマテリアルの割り当てができます:

• パックプリミティブ内に埋め込まれたジオメトリ上のマテリアルアトリビュート。このアトリビュートは、“もっと高い”レベル(Primitiveアトリビュートとオブジェクトマテリアル)を上書きします。

しかし、Houdiniは、IFDを生成する時に、その埋め込まれたジオメトリ(走査するのに遅い非常に巨大なファイルであることがあります)の中を見ません。 その結果として、その埋め込まれたジオメトリが何のマテリアルアトリビュートを持っているのか知ることができないので、IFD内にそのシェーダが含まれているかどうか知りません。Mantraがレンダリング時にそのプリミティブをアンパックする時にだけ、そのプリミティブにMantraで必要なシェーダが含まれていないことに気づきます。

この問題を回避するには、IFDにシーン内のシェーダが すべて 含まれていることを、それらのシェーダがオブジェクトやジオメトリのレベルで割り当てられているかに関わらず、Houdiniに伝えることができます。 Mantraレンダーノードの Save All SHOPs を有効にしてください。(これは、少しだけIFDのディスクファイルが大きくなります)。 パックプリミティブで必要なシェーダをシーンに読み込んでいる限りは、それらのシェーダはレンダリング時に利用可能です。

Houdiniは、標準ジオメトリと同じようにパックジオメトリに対してディスプレイスメントシェーディングとサブディビジョンサーフェスのレンダリングを行ないます。 しかし、主にインスタンスに対してパックジオメトリを使用している場合、 Dicing(細分化) について考える必要があります。

ディスプレイスメントやサブディビジョンサーフェスをレンダリングする前に、Mantraはジオメトリを、(シェーディング品質が1に設定した時)1ピクセル1プリミティブになるまで小さなプリミティブに“Dicing(細分化)”します。つまり、カメラに近いオブジェクトほど遠くにある(ピクセルの大きさ未満の)オブジェクトよりも細分化されます。

パックジオメトリを使ってインスタンス化する時、これは問題を起こす可能性があります。インスタンス化のメリットは、ジオメトリをすべてのインスタンスで共有できることです。しかし、ディスプレイスメントやサブディビジョンのレンダリングを追加すると、Mantraは各オブジェクトをそれぞれ読み込んでDicingしなければなりません。つまり、ジオメトリはもはや共有されなくなります。

この問題を回避するには、インスタンスを含んだオブジェクトにvm_sharedisplaceレンダープロパティを追加することができます。このパラメータを有効にして、Mantraに以下のことを伝えます:

• あるインスタンスに対してシーンに必要な最高レベルのDicingを使用し、そして

• そのDicingされたジオメトリをすべてのインスタンスで共有する

これは、遠くにあるオブジェクトも“非常に細かい”ディテールを持つことを意味し、処理が遅くなる可能性があります。 しかし、インスタンスを維持できるメリットは、他のデメリットよりもおそらく勝ります。

最悪の場合では、“正しくない”Dicingレベルが問題を起こせば、カメラからの距離に基づいて、2つのオブジェクト間のインスタンスを分割することができます。 この場合、最高のDicingレベルは、近いオブジェクトと遠いオブジェクトに対して別々に計算されます。

他の方法では、カメラに近いインスタンスをアンパックして、“必要な最高のDicingレベル”計算からそれらのインスタンスを除去することができます。

ディスク上またはメモリ内の パックプリミティブインスタンスは、単に同じファイルやメモリのポインタなので、各インスタンスには、個々のアトリビュート値を持たせることができません(ただし、materialとvel(velocity)のアトリビュートは、特別に動作します。以下参照)。

パックフラグメント インスタンスには、個々のアトリビュート値を持たせることが できます 。なぜなら、それらのインスタンスは 融合された ものだからです。とはいえ、ディスク上の、またはメモリ内のパックプリミティブよりも効率が悪いことを意味します。

Alembicプリミティブ インスタンスには、個々のアトリビュート値を持たせることができません。とはいえ、Mantraでは、Alembicプリミティブを“unshare(共有しない)”するオプションがあります。これは、メモリをたくさん消費しますが、レンダリング時にAlembicプリミティブインスタンスに個々のアトリビュート値を持たせることができます。

Mantraは、パックプリミティブに対して仮想のMantraオブジェクトのツリーを作成し、ツリーのトップから各仮想オブジェクトまで(それらの仮想オブジェクト自体にmaterialアトリビュートがない場合)materialアトリビュートをコピーしていくので、Geometryオブジェクト上のマテリアルは、パックプリミティブ内部に適切に適用されます。

同様に、vel(velocity)アトリビュートは、仮想オブジェクトツリーを通じて 追加 されるので、モーションブラーは適切に動作します。

パックプリミティブ上のPrimitiveアトリビュートは、仮想Mantraオブジェクトのオブジェクトプロパティにコピーされます。Render State VOPやrenderstate VEX関数を使用すれば、シェーダコード内でそれらのアトリビュートにアクセスすることができます。

パックプリミティブの 内部に materialPrimitiveアトリビュートがあれば、Houdiniは、そのプリミティブの内部を見ないので、Mantraへ送信するファイル内にそのマテリアルを含む必要があることを知りません。 Declare all SHOPs オプションをオンにすることで、(レンダリングファイルが大きくなりますが)これを修復することができます。これによって、Houdiniはレンダリングファイル内に単にすべてのマテリアルを含んでいることを知ります。

Mantraは、パックプリミティブ フラグメント をレンダリングする時、パックプリミティブからアトリビュートをジオメトリにコピーするので、フラグメントに対してVelocityブラーが動作します。他のパックプリミティブタイプは、インスタンスとしてレンダリングされるので、このようには動作しません。