Solarisで作業する際のパフォーマンス向上に役立つ全般的なヒントと提案をいくつか説明します。

• プリミティブの数が多い場合、特に兄弟プリミティブが多数ある場合には、USDとHydraが低速になります。できる限り、Meshプリミティブを結合し、GeomSubsetsを使用してその異なるパーツのメッシュにマテリアルをバインドすることを試してください。

• 参照が機能するよう、プリミティブは1つのPrim下にグループ化することをお勧めします。これは、アセットを構築する場合に非常に重要です。シーンを構築する場合でも、ライト、アセット、カメラすべてが含まれた1つのPrimを作成することをお勧めします。よく使用されるPrimは/Sceneや/worldなどです。

• HoudiniのPrimパターンマッチングは非常に強力であるものの、シーン内の非常に膨大な数のPrimを走査しがちです。Primパターンを工夫する時間を割くのはとても価値があります。

• Selection Rulesを使用すると、Houdiniでの作業中、プリミティブ選択を保存および再利用することができます。USD Collectionsは、プリミティブのグループ化に適していますが、USDを通じてプリミティブコレクションをパイプラインまたはワークフローの他の部分に送る場合を想定して設計されています。

• Scopeは、意図せずにトランスフォームが作成されてしまう可能性のある場所を持つことなく、Primを整理するのに役立ちます。また、ScopeはPrimのトランスフォームに関与しないため、Hydraがシーンを処理しやすくなります。

• ジオメトリをSOPからLOPに変換する場合、インポートするアトリビュートが多すぎると、エクスポート時にUSDファイルが大きくなってしまいます。

• Purposeを使用すれば、ビューポートが常にすべてを描画しようとして停滞してしまうのを回避することができます。

• 多数のPrimにPurposeを個々に設定すると、Hydraビューアに大きなオーバーヘッドが加わってしまいます。そのため、個々のPrimでPurposeを管理しなくても済むよう、親PrimにPurposeを設定することを検討してください。

• 距離によるジオメトリのカリング(間引き)効果を最大限に活かすには、Scene Polygon Limitをグラフィックスカードが処理できる値に設定します。カメラから遠いプリミティブの境界ボックスは有用な場合もありますが、オーバーヘッドが加わる場合は非表示に設定することをお勧めします。

• SOP Create、SOP Modify、InstancerのLOP内部で作業する時は、Solarisパネルを非表示にして、ビューポートを Hide Other Objects に設定すると、そのSOPネットワーク内のインタラクティブ性が向上します。これらのインターフェース要素を表示しておきたい場合は、Output SOPをNullに接続すると、微調整の度にSolaris UIがSOPの動作を再変換するのを避けることができます。

• ノードの再クックにより、一見単純な操作が非常に低速になる可能性があります。例えば、立方体のトランスフォーム操作はインタラクティブに行ないたいことでしょう。しかし、ネットワークの上部で立方体をトランスフォーム操作して下部でノードを表示している場合、このような単純なトランスフォーム操作で大量の再クックが発生します。

• Houdiniの時間依存に注意してください。この時間依存が原因で、LOPノードが不必要に再クックを行なってしまって、USDの処理が増える可能性があります。アニメーションまたはアニメーションするエクスプレッションを持つノードグループの直後にCache LOPを使用することで、そのタイムサンプルをUSDに書き出すことができます。USD Render LOPは、huskを使用してレンダリングされる一時的なUSDファイルを書き出すので、低速なUSDエクスポートはレンダリングにも影響を与えます。

• ネットワークエディタの LOP Layer Colors 機能は、低速なシーンのクックの問題解決を行なう際に役立つ指標となります。各LOPノードがレイヤに対して機能し、その色は同じレイヤを編集しているノードに呼応しています。ノードグラフ内でその色が変わる度に、ステージに新しいレイヤが追加されたということが示唆されます。また、完全に新しいステージが生成されたことを意味する場合もあります。色が変わったその箇所では、コンポジションに関連したオーバーヘッドが存在する可能性を示唆しています。

• LOPレイヤにオピニオンや値がもっと追加されると、ビューポートが低下してしまいます。ビューポートで単純なトランスフォームの速度が非常に遅い場合は、Configure Layerを使用して現在作業中の場所より上で新しいレイヤを開始して、インタラクティブ性が向上するかどうかを確認してください。

• Merge LOPがシーンの改善に役立つこともありますが、一部のケースでは、処理が増えることもあります。マージへの各入力に複雑なUSDコンポジションセットアップがある場合、Merge LOPの再クックが大きなボトルネックになる可能性があります。

• デフォルトでは、Scene Graph TreeとScene Graph Detailsは、現在選択されているノードに追従します。これが便利な場合もありますが、Scene Graph TreeおよびScene Graph Detailsを更新するためには、ノードグラフ内のその時点でステージを合成する必要があるので、オーバーヘッドが発生します。これは気付かない程度のこともありますが、選択ノードのステージに多数のコンポジションの調整、レイヤの平坦化、ステージの構造へのその他の変更が含まれる場合、Houdiniが低速になる可能性があります。

• 非常に重いシーンでは、ビューポートとネットワークの両方でペイロードをアンロードすることをお勧めします。SublayerノードおよびConfigure Stageノードでペイロードを制御することができます。ペイロードのデフォルトを変更する設定は、Lightingプリファレンスにあります。これを使ってシーンの関心のある部分を決定すれば、そのロードの負荷のみを負うだけで済みます。

• アクティブ化による作業シーンの能率化はお勧めしません。アクティブ化/非アクティブ化によってUSDの再コンポジションが多数発生すると、Houdiniがそれを待機しなくてはならないためです。一般的には、PayloadまたはVisibilityを使用することをお勧めします。

• Population(収集)マスクはシーンを能率化する強力な方法ですが、これらのマスクは絶対的なものであり、USD/Houdiniによるマスクの外にあるPrimの表示または編集は完全に禁止されています。

• Render Geometry SettingsはPrimvarとして作成されます。 これによって、Render Geometry Settingsをシーングラフ内の上位レベルのPrimsに適用することができ、プロパティは子Primsに継承されます。 すべてのGrpimを過剰に走査しないことで、Solarisの動作パフォーマンスを大幅に改善することができます。

• Solarisには、USD向けにSDFファイルフォーマットプラグインが用意されています。これは、.bgeoファイルを直接サブレイヤ化、リファレンス、またはペイロードできることを意味します。このプラグインを使用すると、.usdファイルを書き出す時間やディスク容量を節約することができます。.bgeoファイルをステージにロードする方法を制御するには、USD Configure SOPを使用してDetailアトリビュートを設定し、ステージに追加するSOPアトリビュートを指定します。

• H21.0以降、SolarisにはいくつかのAdobe USDファイルフォーマットプラグインが含まれています。 これらのプラグインは、LOP内でFBX、glTF、SBSARのファイルをサブレイヤ化して参照することができます。また、USD ROPからFBXおよびglTfをエクスポートすることもできます。

Samba4.17.xまでのバージョンのネットワークでは、USDワークフローを遅くさせてしまう可能性があります。 そのため、 Samba4.18.x以上に更新することを推奨しています! これは主にLinuxファイルサーバーを使用するWindowsユーザに関係します。公式のSambaドキュメントに以下の記述があります。

この記述のソースに興味があるのであれば、このリンクを辿ってください。

• Python LOPで作業する場合、Sdf.Changeblock()内でSDFレベルのAPIを使用すると、パフォーマンスを大幅に向上させることができます。その代わり、シーンを操作するための便利な関数が少なくなります。SDFコードを使用するには、UsdStageのPrimとSdfLayerのPrimSpecの違いを理解しておく必要があります。

• Pythonでhou.LopSelectionRuleを使用して、HoudiniのPrimパターンマッチングにアクセスすることができます。このノードの入力ステージを使用して、Primパスを解決します。これは、単にネイティブのUSD APIを使用して走査するよりも簡単な場合があり、Solarisのアーティストにとってはより快適で馴染みのある方法です。

• For Eachブロックは非常に便利ですが、Python LOPでのイテレーションほど高速ではありません。