Bulletが衝突と拘束を解決するために使用する拘束ソルバを指定します。 どちらのソルバも作業負荷を並列化しますが、それらのソルバがそれを行なうのに使用する手法が異なります。 Parallel Gauss-Seidel (Islands) は、小さな“島”のオブジェクトをたくさん作用させる場合(例えば、平積みされたたくさんの本)に高速なのに対して、 Parallel Gauss-Seidel (Graph Coloring) は、“島”が少なくて大きい場合(例えば、崩壊する巨大なビル)にパフォーマンスが良いです。

これらのソルバを使って得られる結果は通常では同一になりませんが、品質的な違いは少ないです。

ソルバで使用される拘束の反復数を指定します。 使用する反復数が多いほど、拘束と衝突のハンドリングがより正確になります。

十分に近い解が得られた場合に Constraint Iterations の最大数に達する前に拘束ソルバを終了させることができます。 値が大きいほど、精度が悪くなる代わりにパフォーマンスが良くなります。

Constraint Iterations の各繰り返しの前に、拘束をランダムに並べ替えるように指定します。 これにより、安定性が改善されることがありますが、若干パフォーマンスが悪くなります。

ソルバが、相互作用させるオブジェクト(追加、削除、位置変更させるオブジェクトを含む)の島の変化によって、それらの変化がオブジェクト間に影響しない限り、他の島が異なるシミュレーション結果を生成してしまわないようにさせます。 このオプションを無効にすると、ソルバは、まったく同じ入力を使った場合でしか再シミュレーションで同じ結果を生成できません。 このオプションを有効にすれば、若干パフォーマンスが悪くなるものの、再シミュレーションしてもその結果はあまり変わらないようにすることができます。

CFM(Constraint Force Mixing)パラメータを上げると、Contact拘束が柔らかくなり、シミュレーションの安定性が良くなることがあります。 Contact拘束は、このパラメータと拘束の強化に必要なフォースの乗算に比例した量で問題になることがあります。

次のシミュレーションステップ間で修復されるContact拘束に対する拘束エラーの比率を指定します。 ERP(Error Reduction Parameter)を0に設定すると、拘束されたオブジェクトは、シミュレーションが進むほど離れていきます。 ERPを1に設定すると、ソルバは、次のシミュレーションステップ間ですべての拘束エラーの修復を試みます(しかし、これは、場合によっては不安定になります)。 0.1から0.8の値が、たいていのシミュレーションで推奨します。

相互に貫通したオブジェクトを(オブジェクトが爆発的に吹っ飛ぶのを回避するために)Velocityを加えずに分割しようとします。

位置拘束とVelocity拘束を計算した際の誤差によって、システムに余分なエネルギーを引き起こす可能性があります。 このオプションはその余分なエネルギーのほとんどを除去しますが、特に安定したスタッキング(累積)に関しては若干品質の低下を招きます。

Split Impulse は、オブジェクトがこの距離よりも大きく貫通している時だけ適用されます。この数値は、マイナス(オブジェクト間の距離が0未満であることを意味します)にしてください。

貫通距離が Penetration Threshold の範囲内で Split Impulse が有効なContact拘束に対して Error Reduction Parameter を上書きします。

Sticky Collisionsによって生成された拘束が放出される拘束ネットワークを指定します。 指定しなかった場合、ソルバが最初に見つけた拘束ネットワークが使用されます。 拘束ネットワークが存在しなかった場合、Sticky Collisionsは無効になります。

この拘束ネットワークはリレーションシップである(つまり、 Attach Internal Constraints to Object が無効になっている)必要があり、 Use Internal Constraint Networks によって内部拘束ネットワークに追加されていない拘束を受信します。

有効にすると、ソルバは、同じDOPオブジェクトからの2個のオブジェクト間のSticky Collisions用の拘束を内部拘束ネットワーク(ConstraintGeometryジオメトリサブデータ)に追加するようになります。 DOPオブジェクトにConstraintGeometryサブデータがなかった場合、その拘束は External Constraint Network に追加されます。 Constraint Network DOPを使用して Attach Internal Constraints to Object を有効にすることで、内部拘束ネットワーク(ConstraintGeometryサブデータ)をオブジェクトに追加することができます。

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

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

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

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

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

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

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が安定な方法で操作するには小さすぎるジオメトリの作成を回避することができます。

クラスタ化された破片を一緒に結合する時に使用する許容値。

新しく作成される内側プリミティブ上に、作成時刻を記録するためのcreationtimeアトリビュートを作成します。 これは、プリミティブの初期の破壊の後に短時間にDebris(瓦礫)用のパーティクルの放出などの効果を出すのに役に立ちます。

通常では、破壊は、フレーム内のこのオブジェクトの前に計算するオブジェクトのみによって駆動されます。 異なるソルバ間での相互接続をフィードバックを使って実行する場合、このオプションは、それらのフィードバック効果も破壊をトリガーすることができます。

お互いに静止するだけのオブジェクトによって生成されるImpactは、破壊に考慮されません。

この値は、シミュレーション中の破壊ポイントの生成に使用する擬似乱数シーケンスの初期化に使われます。 これは、同じネットワークから異なるシミュレーションを生成するのに役に立ちます。

破壊は、ポリゴンジオメトリのみに作用します。このオプションは、指定したLODでジオメトリをポリゴンに自動変換します。 この変換は、破壊が発生した時にのみ起こります。

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

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を使用してパラメータをスタンプする場合にも、この設定が必須です。