Stack Solverは、すべてのオブジェクトを辿って、弾道衝突を検索します。 1つの衝突を計算すると別の所でまた衝突が起こる可能性があるので、局所的な計算方法では1回のパスでこれを計算することができません。

そのため、Stack Solverは、衝突が見つからなくなるまで、またはこのパスの数に到達するまで衝突計算を繰り返します。

たとえ、それらのパスで衝突が完全に計算されなくても、その衝突は Contact Pass でクリーンアップされます。 大きな違いは、その衝突の弾性がなくなることです。

Stack Solverは、すべてのオブジェクトを辿って、接触を安定化するのに加速度を調整する必要がある箇所を検索します。

複数にスタックされたオブジェクトが一般的なので、これは複雑な相互関係になることがよくあるので、複数のパスをまとめる必要があります。

静止オブジェクトには、跳ね返るオブジェクトよりも安定性が必要になります。 そのため、そのオブジェクトを急に停止させず、システムを安定させるために何回も繰り返してオブジェクトを遅くしていきます。

これは、すべてのContactパスに対してそれを行なうステップ数です。

これらのパスは、 Contact Passes と非常に似ています。

大きな違いは、もし本がテーブル上に静止している場合に、このパスでは、そのテーブルには無限の質量が割り当てられます。 これにより、テーブルが地面とずれることがなくなり、システムをより速く収束させることができます。

経験上では、この値にはスタックオブジェクトの期待する最大数に設定してください。 安定した構成で相互に10台のテーブルを積み重ねようとするならば、10の値がスタックの完全な計算に役に立ちます。

オブジェクトが適切に静止しても、ゆっくりとお互いに沈め合い始めているようであれば、 Shock Propagation の値を上げると解決することがあります。

これらのパスは、相互貫通を回避するための最終の試みです。 Shock Propagation と同様に、下から上へオブジェクトを処理しようとします。

もし本がテーブル上に静止していて、そのテーブルと貫通していれば、その本をテーブルの外側に乗るように動かされます。 これは、本がテーブル上に乗っていても実行されます。

その貫通の修復は、貫通がなくなるまで、または、このパラメータで設定した最大数に到達するまで繰り返されます。

SubContact Passes は、オブジェクトをゆっくりと引き離すために使われます。 本をテーブルの外側へ即座に動かすのではなく、 SubContact Passes に指定した数に基づいて動かされます。 これは、複雑なオーバーラップが発生した時に処理を安定化させようとするために実行されます。

ポイント位置の変化を衝突計算で使用するかどうか決めます。

このフラグは、Velocityアトリビュートを、初期Velocityのセットアップではなく、衝突にのみ使用するかどうかを制御します。

これを設定すると、ポイント毎のVelocityアトリビュートに対してオブジェクトが検査されます。 そのVelocityアトリビュートが存在すれば、そのVelocityアトリビュートをローカル変形ベクトルと見なし、衝突反応の改善に使用されます。

そのVelocityアトリビュートが存在しなかった場合は、そのジオメトリを2フレーム間で比較して、手動でポイント毎のVelocityを計算します。

ボリューム表現の変化を衝突計算で使用するかどうか決めます。

これを設定すると、ボリューム表現がこのフレームと前のフレーム間で比較されます。 その差分を使用して、サーフェス変形のVelocityを計算します。 これにより、変形オブジェクトがもっともらしく相互作用するようになります。

オブジェクトがお互いに接して静止している時、それらのオブジェクトは、まだ重力の影響を受けています。 このオプションは、その影響がGlue Impulseに追加されないようにし、オブジェクトがオブジェクト自体の重力によってばらばらにならないようにすることが簡単になります。

RBD計算処理中に、多くのImpactがRBDオブジェクト間で計算されます。それらのImpactは通常では時間を節約するために記録されません。

これを設定すると、Impacts/RBDImpactsデータを衝突するオブジェクトに取り付けることで、それらのImpactすべてが記録されます。

膨大な数のオブジェクトのシミュレーションでは、色々な空間分割の仕組みを使用して衝突検出の負荷を減らすことが役に立ちます。 このオプションでは、それらの仕組みのどれかを選択します。

None は、空間的再分割を行なわないことを意味します。

Sphere は、オブジェクトを球として扱い、小さな交差検知がそれらの球で処理されることを意味します。 これは高速ですが、細長いオブジェクトは誤検知を起こす可能性があります。

OBB とはOriented Bounding Boxes(方向を定義した境界ボックス)の略です。 これは細長いオブジェクトに対してもきっちりと境界を用意しますが、空間分割ツリーの構築が遅く、メリットがあまりないことが多いです。

Houdiniがポイント衝突を計算する時、類似ポイントをまとめてグループ化するかどうか、そして、その方法を制御します。

このパラメータを None 以外の値に設定すると、Houdiniは、類似ポイント(つまり、以下の Contact Grouping Tolerance で指定した距離の範囲内にあるポイント)を 衝突計算用の単一ポイントとして扱います。

これは、立方体などのオブジェクトのジオメトリのポイント(その立方体のコーナー)が遠く離れている時に役に立ちます。

Contact Grouping Method が None の時、1つのコーナーが最初に地面と衝突して、その立方体が跳ね返って回転し、また別のコーナーが衝突して、その立方体が跳ね返って回転することになるので、 ジッター(微震)が生じます。

Contact Grouping Method を Average に設定すると、Houdiniは、コーナー間の平均ポイントに基づいた当たりを計算し、ジッター(微震)の少ない安定した結果を生成します。

これは、RBD Objectノードの Surface タブの Edge Representation がオンの時の効果と似ています。 立方体などのエッジがシャープなSparse(疎)ジオメトリがあれば、それらのオプションの両方をオンにすると良いです。

Contact Groupingの効果を確認するには、立方体を地面に落とすシミュレーションを作成します。 その結果のImpactを確認するには、RBD Visualization DOPを接続します。

Contact Grouping Method が None 以外の時にポイントをまとめてグループ化する距離。

RBD Solverは、フルタイムステップを最低でもこのサブステップ数に分割します。

この値を上げることで、サブステップを細かくすることができます。 これは、何かしらの理由で自動計算が粗くなってしまった場合に使用することができます。

RBD Solverは、シミュレーションをこの値よりも多いサブステップに分割しません。

シミュレーションの複雑さに関係なく、必ずフレーム内で終了する最大サブステップを常に設定することは非常に良い考え方です。 この最大数を下げると、精度が悪くなりますが最大計算時間を抑えることができます。

CFL Condition は、シーンで必要なサブステップのサイズを自動的に決めるために使用される係数です。 この考えは、サブステップがどのオブジェクトも1ボクセルのセルより大きく相互貫通しないようにするためのものです。

この条件は、このパラメータが1の時に満たされます。10の値は、サブステップが10ボクセルのセル分相互貫通することを許可します。 これは、オブジェクトが適切に跳ね返るというよりも、お互いにオブジェクトをくぐり抜けます。

各データオプションパラメータには、それに関連するそのパラメータの動作方法を指定するメニューがあります。

Use Default に設定した Operation メニューのパラメータに対して、このパラメータが、使用するオペレーションを制御します。

このパラメータは、 Parameter Operations メニューと同じメニューオプションと意味を持ちますが、 Use Default の選択がありません。

このノードの1番目の入力に接続されたすべてのオブジェクトが、相互アフェクターになります。

これは、それらのオブジェクトをこのノードに接続する前にAffector DOPを使用して、*と*の間にアフェクターリレーションシップを作成する事と同じです。 このオプションは、すべてのオブジェクトをソルバに送って、お互いに影響し合うようにするのに便利です。

オブジェクトコネクタをこのノードの1番目の入力に接続した時、このパラメータを使って、 このノードから影響を受けるそれらのオブジェクトのサブセットを選択することができます。

オブジェクトまたは他のデータにデータを追加するために使用する名前を意味します。 Data Name に“/”(または複数)を含めれば、それはサブデータ内側に移動することを意味します。

例えば、Fan Force DOPのデフォルトの Data Name は“Forces/Fan”です。 これは、“Forces”という既存のデータに“Fan”という名前のデータを追加します。 “Forces”というデータが存在しなければ、単なるコンテナデータが作成されて、そこに“Fan”サブデータが追加されます。

異なるデータは、それらを使用する名前に対して異なる要件を持ちます。 非常に稀な場合を除いて、デフォルト値を使用してください。 いくつかの例外は、特定のデータまたは特定のタイプのデータを利用するソルバで説明します。

このパラメータを有効にすると、このノードで作成されるデータが既存データを上書きしないように 固有な名前で Data Name パラメータの値を修正します。

このパラメータをオフにすると、同じ名前の2つのデータを追加すると、2番目のデータが1番目のデータを置換します。 各タイプの挙動が必要な場合があります。

オブジェクトにいくつかのFan Forcesを吹き付けたい時に、各ファンが前のファンを上書きしないように、 個々のファンの Data Name を変更して名前の衝突を回避するよりも、 Unique Data Name の機能を使用する方が簡単です。

一方で、オブジェクトに既にRBD Stateデータが追加されていることを知っていれば、このオプションをオフにすることで、 新しいRBD Stateデータが既存データを上書きすることができます。

ソルバのデフォルトの挙動は、まったく同じソルバをグループで指定したすべてのオブジェクトに取り付けます。 これにより、パラメータが各オブジェクトに対して同一になるので、それらのオブジェクトをソルバによって1個のパスで処理することができます。

とはいえ、いくつかのオブジェクトは、同時に単一オブジェクトに対してより論理的に作用します。 それらの場合では、$OBJIDエクスプレッションを使用して、オブジェクト毎にソルバのパラメータを変化させたいことがあります。 このトグルを設定すれば、オブジェクト毎に別々のソルバが作成されて、$OBJIDが期待通りに変化します。

Copy Data DOPを使用してパラメータをスタンプする場合にも、この設定が必須です。