各フレームをこのサブステップの数で分割します。 高速移動する衝突オブジェクトまたは急なフォースには、サブステップを上げる必要があります。

デフォルトのサブステップだと、非常に挑戦的な設定になっており、もしVellum Solverがあまりにも伸縮が大きいようでしたら、 通常だとサブステップを2とか5に上げると、ちょうど良く始めることができるでしょう。

各サブステップ内で、この回数だけ拘束が実行されます。 硬い拘束を収束させるには、この反復回数を上げる必要があります。 最初に設定する目安はジオメトリの直径です。要するに、一番遠くのポイントまでのエッジの数です。

Constraint Iterationsは、収束が早いガウス・ザイデル法をデフォルトで使用しています。 しかし、剛性が高すぎたり、不可能な設定が原因で完全に収束しなかった場合、ひどい見た目の三角形でエラーを残してしまいます。 Smoothing Iterationsは、収束が遅いけど、もっと感じの良い方法でエラーを残すヤコビ法を使用しています。 デフォルトの10回は、エラーを滑らかにしますが、全体的な Constraint Iterations の回数が非常に多い場合は、この回数も上げる必要があります。

実行する衝突検出パスの数。この衝突検出パスは、拘束反復と交互に行なわれます。 衝突検出は処理が重いので、この数を最小限に抑えるのが良いです。 しかし、交互に頻繁に処理することによって、小さいColliderが非伸縮拘束に対して無駄に負荷をかけてしまうテントポールのような現象を回避するのに役立ちます。 実際に試してみると、ほとんどの状況において10が適切であることが分かり、品質を上げるならサブステップを上げることで解決されることが多いです。

すべての拘束が実行された後に、最後決戦の衝突検出が行なわれます。 衝突が最も目立つ失敗モードになる場合が多くて、次のフレームでは交差していないジオメトリから開始できるのが理想です。 そのため、最終クリーンアップのパスによって、それらの要件を成し遂げることができます。 私どもは、このパスの数は"積み上げる層の数 + 2"が妥当であると分かりました。 これによって、下側にあるColliderが、その上に積み上げられた層を完全に波立てるようにする伝搬させることができます。

ある衝突パスにおいて、ある衝突ペアが完全に解決できないことがあります。 この数だけ追加したColliderペアのパスは、その衝突ペアが解決されるまで実行されます。 これらのパスはアクティブなColliderに対してのみ実行されるので(そして、新しい衝突検索が実行されないので)、非常に計算が軽いです。

layer整数Pointアトリビュートを使って、異なる層の布に属するポイントを示すことができます。 この番号が大きいほど、上層の布を参照します。 Layer Shockは、衝突を評価する際に、低いレイヤー番号ほど何倍も重くするので、高いレイヤー番号が低いレイヤー番号をよけるようになります。 他のダイナミクスは、このレイヤー番号の影響を受けません。 レイヤー番号の差分は、その2つの布間のレイヤーの数に関係なく修正されます。 この差分によって、一方向のシミュレーション、完全双方向のシミュレーションの制御方法が決まります。

完全摩擦が適用される閾値。 接線Velocityと法線インパルスの比率がこの閾値未満の時、接線Velocityが完全に摩擦から除去されます。 これは、重力だけでスライド可能な勾配角度のtan()のようなものです。

Static Thresholdが失敗した場合、これは、動摩擦によって接線Velocityが減少する割合を制御します。

外部ジオメトリとの干渉に適用する摩擦効果の度合いに対するスケール係数。

自己ジオメトリとの干渉に適用する摩擦効果の度合いに対するスケール係数。

Volume Colliderの静摩擦に対するスケール係数。摩擦のない地面の作成に役立ちます。

Volume Colliderの動摩擦に対するスケール係数。摩擦のない地面の作成に役立ちます。

If this checkbox is turned on, all constraints in the specified Constraint Group will be solved in a separate, interleaved pass to the remaining constraints.

There are two main uses for this option. First, there are some expensive constraint types that do not need to be solved as frequently as the rest of the constraints, so enabling this option and choosing a low Solve Frequency can improve performance. For example, cloth bend constraints on high resolution cloth with low bend stiffness such a silk or cotton. You need to ensure that you're solving distance constraints every pass so the cloth doesn’t stretch. However, bend constraints are expensive and don’t need to be as strong, since silk and cotton have very low bend resistance and wrinkle easily. Solving the bend constraints as a secondary pass will give you strong performance gains. However, this method isn’t practical for stiffer material such as leather.

The second use case is constraints that cause frequent changes in the constraint topology, which causes the solver to re-order the constraint solve, possibly causing jittering in the remaining constraints. An example is organic tissue represented by tetrahedra and attached together with sliding Stitch constraints. As the sliding causes changes in the constraint topology the tetrahedra might jitter slightly as the constraint solve order changes. Moving the Stitch constraints to another pass by setting Constraint Group to @type=ptprim and increasing the Solve Frequency to 1 will retain the same stiffness but eliminate tetrahedral jittering due to changes in the solve order.

The constraint group(s) that should be solved in the interleaved secondary pass. This parameter accepts standard group syntax, so can contain explicit group names and ad-hoc groups, often specifying one or more constraint types with something like @type==bend. Any constraint not contained in these groups will be solved in the primary pass as usual.

The frequency at which to solve the secondary pass. A setting of 1 will solve the secondary pass as often as the primary pass, while a setting of 0.25 will solve once every four passes of the primary pass (one quarter of the time).

Multi-Passオプションによって、特定の条件が満たされるまでサブステップを繰り返すことができます。 現在の条件は、無効化されたポイントが原因でジオメトリが引っかかり、無効化されていないポイントがストレッチを生成してしまう問題を修復するように設計されています。 コリジョンは常に拘束を未然に防ぐので、その結果として、布やヘアーがストレッチします。 自動的に無効化されたポイントに隣接したポイントは、過度なストレッチが検出されるとそれらのポイント自体が無効化されます。 この解決ステップは、ジオメトリが解放されるまで繰り返されます。

サブステップを繰り返す最大回数。 無効化する必要のある新しいポイントがなくなれば、そのプロセスが即座に停止します。

ポイントが無効化の対象となる判断をするための解決ステップの終わりにおけるストレッチ量。 これは、失敗したコリジョンがVellumオブジェクトを引き離している時期を検出するためにあります。 無効化するポイントを増やして失敗させることで、通常ではオブジェクトを解放することができるので、ストレッチを続けるよりも良い結果が得られます。

ポイントがポストコリジョンパスの後で干渉を解決できなかった場合、そのポイントにdisabledフラグを立てて、そのポイントとそれが属するプリミティブが干渉なしで移動できるように許可します。

disabledフラグのポイントは、絡みついた状況において何も干渉を検出しなくなっていて、且つ、disabledフラグのないポイントと繋がっている場合、そのポイント自体が再度アクティブになります。 disabledフラグのポイントは、あらかじめジオメトリの正しい側に移動させておくことが望ましいです。

overlap_selfとoverlap_externalのアトリビュートを作成し、ソルバの初期セットアップを評価できるように初期化します。

これらのアトリビュートが既に存在していれば、初期化されないことに注意してください。 モデリング操作が原因で設定が変わってしまった場合、それらのアトリビュートを削除しておいた方が良いでしょう。

overlap_selfとoverlap_externalを更新して、現在の設定を反映します。 これらの値は、この処理によって減少していくだけなので、初期化する時は大きな初期値を設定してください。

これを設定すると、四面体メッシュの非共有フェースから干渉ジオメトリが生成されるようになります。 場合によっては、三角形シェルと四面体メッシュの両方を使って、この処理を冗長化したいことがあります。

色々な加速度制限オプションを使うことで、シミュレーションが非現実的なフォースの追従にあまりこだわらないようにさせることができます。 加速度制限オプションを使わないと、大きなエネルギースパイクが発生してしまうことがあります。

ポイントが Max Acceleration を超過すると、鋭くて不連続な干渉の信号が出ていれば、2次予測が誤って、跳ね返りの形式で間違った動きを追加してしまうことが多いです。 この場合では、影響を受けるポイントに対しては、1次の積分に戻されます。

パーティクルのVelocityがダイナミクスの何かの結果として変更可能な量を制限します。 これは、なにか瞬間的な動きが大きなフォースとして認識されないのを回避することができるので、 パーティクルが遠くに飛んでいってしまわないようにするのに役立ちます。

衝突を解決する時に、その衝突補正が加速度の量よりも大きくパーティクルを動かしてしまう場合に、その効果を制限します。 モデルの一部が布にひっかかって、ありえないような形で布を引っ張ってしまう時は、潔く失敗するのが望ましいです。

接合が切断された時、2つの新しいポイントが隣接した状態から動き始めます。 切断を発動させたものが原因でサーフェスが自然な感じに離れない場合、衝突検出を発動してサーフェスを押し離すため、 切断が発生した時に爆発のような動きを招きます。 このオプションは、ポイントの接合を解除した時にそれらのポイントが自己干渉しないようにdisableselfアトリビュートを設定します。 ただし、これによって、層になった布が自己貫通を引き起こしてしまうことに注意してください。

時間と共に応力計算を正規化するので、 Substeps パラメータを上げるほど計算結果の精度が良くなります。

接合と拘束が切断ポイントに到達したかどうかをテストする回数。 値が大きいほど、計算精度が良くなりますが、切断された拘束のトポロジーの変化量に応じて計算が遅くなってしまいます。

Attach to Geometry または Stitch Points の拘束を滑らせた時に、ターゲットジオメトリ上の次に近い位置を検索する際に使用されるメソッド。 Closest Point は、単に投影した滑り位置からターゲットジオメトリ上の一番近いポイントを選択します。 この手法は高速ですが、ターゲットジオメトリ内の凹部分では不適切に飛んでしまう可能性があります。 Traverse Polygons は、現在のターゲットプリミティブから開始して継続して外側へ走査して周辺のプリミティブ上で一番近いポイントを検索します。 この手法は処理が重いですが、凹状のターゲットジオメトリを上手く制御することができます。 Traverse Triangles (Optimized) は、改良された凹部分の制御において以前のオプションと同様ですが、特別な三角形距離関数を使用しているので何倍も高速化されています。しかし、三角形で構成されたターゲットジオメトリにしか使用することができません。

交差し得るパーティクルは、2つのパーティクルのpscaleアトリビュートの平均値をこれでスケールした距離の範囲内にあると想定されます。 通常では干渉は拘束の反復中に更新されないので、これは過大評価です。 そのため、現在の干渉パーティクルだけでなく、前の反復が原因で干渉を起こし始める可能性のあるパーティクルも記録する必要があります。

これは、凝集したパーティクル内の引力の範囲にも影響を与えます。

サブステップ内で起こり得る干渉を検索する時に考慮されるパーティクルの最大数。 この制限は、ある箇所でパーティクルが非常にたくさん作成されている際に、過度な計算を回避するのに役立ちます。

Repulsion(反発力)ウェイト、Attraction(引力)ウェイト、Friction(摩擦)ウェイトに適用される共通ウェイトスケール。 拘束の平均化を使用していないので、安定性を良くするには、これを下げる必要があります。特に、Attractionの強度が強く使用されている時です。 1 / Max Neighborsの値で安定するはずですが、収束が遅くなってしまいます。

各パーティクルの半径は、pscaleアトリビュートを使って決定します。 すべてのパーティクルが同じ半径であれば、より高速化された構造体を使って近接パーティクルを検索することができます。

複数のパーティクルが同時に衝突した時、これは、すべての拘束を平均化します。 これは、安定性を確保するのに効果的ですが、モーメンタム(運動量)を維持しません。 そのため、膨大なパーティクルが凝集した時に内部フォースと組み合わさって自身のフォースを加速化させてしまいかねないです。

パーティクル干渉フォースのウェイト。 値をゼロにすると、パーティクル干渉が無効になります。

パーティクルを引き離す強度。値が大きいほど弾みの少ない反発力になります。

隣接パーティクルがお互いに近い時に自然な感じに引っ付けさせるウェイト。 値をゼロにすると、パーティクルの凝集が無効になります。

attractionweight Pointアトリビュートを使えば、スケールをかけることができます。

隣接パーティクルがお互いに引っ付く強さ。値が大きいほど、弾みの少ない粘着力になります。

パーティクルの位置と重力を考慮して、人工的に質量にスケールをかけます。 パーティクルの位置が高いほど質量を軽くすることによって、パーティクルの積み重なりがもっと速く収束し、もっと安定するようになります。

適用するスケールの大きさ。 数値が大きいほど、連続パーティクル間の差異が広がります。 値をゼロにすると、パーティクル間の比率はなくなり、値を1にすると、垂直に積み重なる2個のパーティクル間の比率は15%になります。

数値を大きくしすぎてしまうと、パーティクルが極端に軽くなり、システムが不安定になります。

パーティクル質量の変化比率を定義するために使用するUpベクトル。

積み重ねる方向を指定するので、通常では、ここには重力の反対方向を指定します。

Vellum Brush SOPで使用されている制限付きバージョンのソルバを有効化します。 現在のところ、これは制限事項があるのでブラシでのみ使用されている内部機能です。 布や他のソフトボディを非常に高速に静的ジオメトリと相互作用させることができます。 しかし、これはアニメーションするコリジョンまたは何かのアニメーション入力には動作しません。 このオプションはエンドユーザーには推奨していません。

カーネルに対して必要なコンパイルフラグを指定します。

Finish Kernelsが無効な時、次のソルバに進む前にOpenCLカーネルが完了するのを待たなくなります。 これによって、ソルバの結果が実際に必要となるまで、バックグラウンドでOpenCLカーネルを走らせることができます。 デバッグまたはタイミングを単純化したいのであれば、正しい箇所でエラーが検出できるようにカーネルが終了するのを待った方が便利です。

ディスクからカーネルを読み込む時、計算毎にそのカーネルを再生成されないようにそのカーネルをキャッシュ化します。 これを有効にすると、強制的にそのカーネルを再ロードして再コンパイルします。 これは、変更されたコードを#includeファイルが参照していたり、そのカーネルファイルを外部テキストエディタで変更した場合に役立ちます。

これは、プロトタイプが完了した時には必ず無効にしてください。

グラフカラーを実行した時、高速な並列のOpenCLアルゴリズムが使用されます。 残念なことに、これは四面体メッシュに対する他の計算と比べて10倍以上のメモリを必要とします。 そのため、その計算を収めるほどのメモリのないシステムでは、そのカラーパスは成功しません。 これを無効にすることで、すべてのグラフカラーを強制的に遅い逐次手法で処理させて、実際の計算にかかるRAMを抑えることができます。