Houdiniクラウドレンダリング：Pyro・FLIP・Vellum・破壊・クラウドシミュレーションの実践解説
概要
Houdiniのシーンは、フレームが生成される前に大量の出力を生み出すことがよくあります。ローカルでのキャッシュに9時間かかるFLIPシミュレーション、240フレームにわたってベイクされたPyroの炎煙、4 TBのスクラッチディスクを使い切るVellumの布シミュレーション——そしてKarmaのサンプルが1つもビューティーパスに届く前の話です。私たちが連携するFX TDやルックデブアーティストにとって、ボトルネックはレンダリング自体であることはほとんどありません。シミュレーション、キャッシュ、そしてバージョン管理が週全体を消費し、その後「レンダリング」は金曜日の午後に収まらなければならないものになります。
このギャップ——シムが完了してからフレームが出荷されるまでの間——こそ、クラウドレンダリングに関する意思決定が行われる場所です。私たちは2017年からSuper Renders Farmを運営しており、チームは2010年からFX負荷の高いプロダクション作業のための分散レンダリングを担当しています。Houdini FX TDから聞く質問は、「クラウドレンダリングを使うべきか？」ではありません。「Pyroのキャッシュは移送できるか？」「VellumのベイクをFarmに移したら、サブステップは安定するか？」というものです。その答えはシムの動作によって異なります。だからこそ、この記事はワークフローステージ別ではなく、シミュレーションタイプ別に構成しています。
以下はシムタイプ別の最適化マニュアルです。エンドツーエンドのワークフロー設定——シーン準備、$HIPと$JOBパス、USDアセット解決、プラグインバージョン固定——については、Houdiniクラウドレンダーファームセットアップガイドをご覧ください。価格、ハードウェア、レンダラーサポートにわたるマネージドHoudiniファームのベンダー比較については、Houdiniレンダーファームの比較をご参照ください。この深掘り解説では、シーンがアップロード準備済みであることを前提として、シミュレーション自体がワーカーフリートへの移送を乗り越え、期待通りの結果が返ってくるかどうかを決定する、シムタイプ別の調整ポイントに焦点を当てています。
Houdiniシムがクラウドレンダーファームに特有の負荷をかける理由
多くのレンダーファームのコンテンツは、ワークロードを「フレーム毎時間」として表現しています——固定シーンをN台のワーカー上でN回レンダリングするというモデルです。このモデルはKarmaやRedshiftでの静的ルックデブパスには適合します。しかし、Houdiniのシムには適合しません。なぜなら、Houdiniでは「シーン」はシムキャッシュが完成するまで確定しないからです。Pyroの炎煙、FLIPボリューム、Vellumの布のプレロール——これらは中間状態であり、シーン状態ではありません。ファームは、その中間状態を事前ベイク済みで受け取るか、ワーカーが受け取ったばかりの.hipファイルから再構築するかのどちらかで処理しなければならず、この2つのパスはコストプロファイルが大きく異なります。
ほとんどのHoudiniソルバーにおけるシングルマシン制約が、ここでの実質的な制約です。DOPnetのサブステップ一貫性——フレームNが同じソルバーコンテキスト内のフレームN-1に依存するという要件——は、Pyro・FLIP・Vellum・RBDのソルブが、シム中にワーカーノード間で並列化できないことを意味します。PDGはウェッジとフレーム非依存のSOP作業を分散できますが、基本的なソルブループは一般にファンアウトしません。実際的な意味として、シムが1台のワーカーに収まるか否かは、ワークステーションに収まるか否かと同義です。ファームがシム側での並列処理ではなく、レンダリング側での並列処理で優位に立ちます。
私たちのファームでは、CPU側にDual Intel Xeon E5-2699 V4ノード（RAM 96〜256 GB、総計20,000コア以上）を使用しており、これはキャッシュ再構築やCPUシム/レンダーパスに関連するティアです。GPU側はRTX 5090（VRAM 32 GB）を使用しており、これはKarma XPUとRedshiftがレンダリングフェーズで消費するティアです。シムフェーズとレンダリングフェーズは異なるフリートにかかるため、Houdiniのワークに対する料金はほぼ常に2行の項目になります——キャッシュ再構築（必要な場合）のCPU GHz-Hr、レンダリングのGPUノード時間です。
標準的なコマンドラインエントリーポイントはhbatch（クラシックなHoudiniシーン実行）とhusk（huskコマンドラインリファレンス — Solaris/USDステージレンダリング）です。ほとんどのファーム側自動化はこのいずれかを通じて実行され、.hipを1度アップロードしてフレームレンジごとに再実行（hbatch）するか、事前ベイク済みUSDステージに対してレンダリング（husk）するかが選択されます。シムタイプごとに問われるのは、ベイク済みキャッシュを送ってhuskを実行するか、それとも.hipを送ってhbatchに再構築させるか、です。
Pyro：クラウドスケールでの煙・炎・爆発キャッシュ
Pyroは、Pyro Solver DOPnet上に構築されたスパースグリッド燃焼モデルです。煙・炎・爆発ソルバーとして、フレームごとに.vdbボリュームを書き出します。燃焼はtemperature・density・fuel・velocity・divergenceフィールドを生成し、ボクセルグリッドがキャッシュサイズの主な制御要因となります。ボクセルサイズを半分にすると、メモリとディスクコストは約8倍になります（三乗スケーリング）。詳細な技術情報については、SideFX Pyroドキュメントをご参照ください。
キャッシュ戦略。 Pyroフィールドはスパースな特性を持つため、.bgeo.scではなく.vdb（OpenVDBスパース形式）にベイクするのがほぼ常に最適です。OpenVDBのナローバンドストレージは空のボクセルをディスクから省きます。ここでサブステップ数が重要になります。Pyroは低速な煙の場合1〜2サブステップで安定しますが、高速燃焼や衝撃波には4〜8サブステップが必要です。ファーム上でサブステップ数が高いほどワーカーがフレームごとに多くのCPUを消費し、低いほど消費は少なくなりますが、高速モーションでシムの一貫性が失われる可能性があります。DOPnetでサブステップ数を固定し、ファームのデフォルト動作に依存しないようにしてください。
ボクセルサイズ、アドベクションスキーム（Semi-LagrangianvsTrilinearvsMacCormack）、燃焼モデルパラメーターが合わさって、フレームごとの.vdbサイズが決まります。ボクセルサイズ0.05の中程度の複雑さのPyro炎煙を240フレームでは、通常20〜60 GBの合計サイズになります。アップロード前にフレームごとのキャッシュサイズを確認してください——アップロードの帯域幅がボトルネックになることが多く、レンダリング自体よりも問題になる場合があります。
クラウドファームでの考慮事項。 Pyroは、.vdbをネイティブに利用するKarma XPUまたはRedshiftのボリュームレンダリングを通じてGPUでレンダリングされます。シム自体はCPUバウンドでOpenCL加速可能ですが、OpenCL加速はワークステーションでのベイク速度に主に貢献し、ファーム側での並列フレームシム（各フレームが前のフレームに依存するため）には寄与しません。実践的なパターン：ローカルでベイクし、.vdbシーケンスをアップロードし、GPUフリートでレンダリングします。
# USDステージに対してhuskを使用してキャッシュ済みPyro炎煙をレンダリング。
# GPUノードでKarma XPUを使用し、ボリュームサンプルを増加させる。
husk --renderer karma \
--frame 1 --frame-count 240 --frame-inc 1 \
--verbose 3a \
--output "$HIP/render/pyro_plume.\$F4.exr" \
--settings xpu \
--override "/Render/rendersettings:karma:volumesamples=8" \
"$HIP/stage/pyro_plume_volumes.usd"
キャッシュ済み.vdbシーケンスを参照するUSDステージに対するhusk呼び出しにより、GPUワーカーはソルブを再実行することなくボリュームを描画できます。Karmaデフォルトの4から8にvolumesamplesを増加させると、密な炎煙のノイズが減少しますが、レンダリング時間は約1.5〜2倍になります。ヒーローショットには16を使用し、プリビズには4のままにしてください。
FLIP：液体・サーフェス再構築・ナローバンド
FLIP（Fluid Implicit Particleソルバー）は、水・粘性液体・自由表面流体をシミュレートするために、粒子とグリッドの表現を組み合わせます。出力は2種類です。粒子キャッシュ（.bgeo.scパックシーケンス）と、オプションで再構築されたサーフェスメッシュ（同じく.bgeo.sc）です。両方がファームに送られるため、FLIPは同等の複雑さのPyroと比較して、ほぼ常にディスクフットプリントが2倍になります。
キャッシュ戦略。 粒子キャッシュとサーフェスメッシュを2つのキャッシュディレクトリに分けてください——粒子を先にベイクし、メッシュは下流のSOPネットワークで粒子から再構築します。この分割により、シムを再実行することなくメッシュを再生成できます。サーフェステンションや粒子分離の2回目の調整が必要な場合に有効です。粒子間隔0.02の200フレームの中程度のFLIPシムでは、粒子側が80〜200 GB、メッシュ側が20〜40 GBになることが多いです。ナローバンドFLIP——表面付近の粒子のみをフル密度で保存する方式——は、カメラが水中を透過しないショットでは粒子キャッシュを60〜80%削減できます。カメラが深いボリュームを見ない場合は有効にしてください。
粘性スティフネスとCFL制約がサブステップ数を決定します。粘性0の水のシムでは通常1〜2サブステップで動作しますが、高粘性の蜂蜜や溶融金属では安定性を保つために5〜10サブステップが必要になることが多いです。CFL違反は粒子の爆発を引き起こし、ファーム上ではワークステーション上よりもはるかにコストが高くなります。レンダリングが完了するまで問題が見えないためです。
クラウドファームでの考慮事項。 アップロード時間がクラウドファームにおけるFLIPの主なコストです。100 Mbpsのクライアントアップリンクで100 GBの粒子キャッシュをアップロードするには、最初のレンダリングフレームが開始できるようになるまで約2.5時間かかります。1 Gbpsアップリンクなら同じキャッシュが約15分でアップロードできます——この差が、クラウドFLIPがショットに対して実用的かどうかを決めることが多いです。アップロード前にキャッシュサイズを確認してください。
# Hythonプローブ——マルチTBのFLIPシムでアップロード帯域幅を消費する前に
# フレームごとのキャッシュサイズを計算するためにワークステーションまたは
# ワーカーから実行します。プリフライトゲートとして使用します。
import os, hou
cache_dir = hou.expandString("$HIP/cache/flip/v003")
total = 0
frames = 0
for f in sorted(os.listdir(cache_dir)):
if f.endswith(".bgeo.sc"):
size = os.path.getsize(os.path.join(cache_dir, f))
total += size
frames += 1
print(f"{frames} frames, {total/1e9:.2f} GB total, "
f"{(total/frames)/1e6:.1f} MB/frame avg")
フレームごとの平均が500 MBを超え、合計が100 GBを超える場合は、アップロード時間を受け入れるか、転送前に粒子間隔、ナローバンド、サーフェスメッシュの閾値を見直してください。
Vellum：布・ソフトボディ・コンストレイントのシリアライゼーション
VellumはHoudiniのポジションベースダイナミクスフレームワークです——布・ソフトボディ・ヘア・グレイン・流体をコンストレイントポジション定式化で扱います。出力はフレームごとの.bgeo.scキャッシュですが、PyroeやFLIPと異なり、Vellumのキャッシュはポイント位置に加えてコンストレイント状態を保持します。コンストレイントグラフ（ピン・ストレッチ・ベンド・スタティックアタッチ）が正しくシリアライズされなければ、ファームのワーカーは壊れたコンストレイントで再ソルブします。コンストレイントタイプの一覧については、Vellum Solverドキュメントをご参照ください。
キャッシュ戦略。 Vellum Solver DOPnetの後、下流のSOPクリーンアップの前にキャッシュしてください。ジェネリックなFile Cacheではなく、Vellum I/O SOPを使用してください。これはコンストレイント属性（__constraintnetwork・restlength・stiffness）を保持するためです。ジェネリックキャッシュはこれらを削除します。プレロールも重要です。布は、カメラフレームレンジが始まる前に20〜40フレームの安定化が必要であり、プレロールはキャッシュに含まれている必要があります。そうしないとワーカーはフレーム1を未安定の布でレンダリングします。多くのVellumプロダクションリグは、キャッシュのフレーム-20から0にプレロールをベイクします。
サブステップ数はファーム側でのVellum失敗の最も一般的な原因です。Vellum Solverのデフォルトサブステップ（5）は緩やかなドレープや基本的なキャラクター布には機能しますが、高速モーション・高いストレッチ比・タイトなピンネットワークでは安定性を保つために10〜20サブステップが必要になることが多いです。DOPnetでサブステップ数を明示的に固定してください——ファームのワーカーにデフォルトを使用させることが、クロスフレームの安定性が崩れる原因です。ワークステーションでベイクしたサブステップ10のキャッシュは、サブステップ5で再構築したワーカーのキャッシュとは一致しません。
クラウドファームでの考慮事項。 VellumはCPUバウンドで、ソルバーごとにシングルスレッドです（コンストレイント解決に限定的なマルチスレッドあり）。キャッシュサイズは控えめで——通常ショットごとに5〜20 GB——アップロードのボトルネックはFLIPほど深刻ではありません。ファームにおける主なコストは、キャッシュの代わりに.hipを送った場合の再構築時間です。4 GBのVellumキャッシュ（中程度の複雑さのコスチューム）は、単一のE5-2699ワーカーで30〜90分でベイクします。ローカルでベイクしてキャッシュをアップロードすれば、ファームはレンダリングコストのみを負担します。
# Vellumの布ソルブを明示的なサブステップオーバーライドで
# .bgeo.scにバッチベイクします。デフォルトのサブステップ数は
# プロダクショングレードの布でファーム側の安定性が崩れやすい箇所です。
hbatch -c "render -f 1 240 -i 1 \
-v vellum_substeps=10 \
-v cache_format=bgeo.sc \
/obj/cloth_sim/dop_cache_OUT" \
-d "/obj/cloth_sim/dopnet1" \
"$HIP/scenes/cloth_main_v007.hip"
-v vellum_substeps=10オーバーライドにより、.hipのDOPnetパラメーターの設定値に関わらず、サブステップ数が固定されます。これはファーム側でのVellumの安定性ドリフトに対する最も安全な対策です。
破壊：RBD・Bullet・コンストレイントネットワーク
Houdiniにおける破壊とは、リジッドボディダイナミクス——RBD Solver・Bullet・粉砕ジオメトリを接着・固定・スナップするコンストレイントネットワークを意味します。キャッシュ形式は.bgeo.scパックドプリミティブで、各パックドプリムが粉砕されたチャンクを表し、コンストレイントネットワークはフレームごとに別の.bgeo.scとして保存されます。シムの上流でフラクチャを行い——DOPではなくSOPで——ポストフラクチャジオメトリとコンストレイントネットワークのみがソルバーに渡されます。
キャッシュ戦略。 2つのキャッシュが重要です。粉砕ジオメトリ（静的、1フレーム）とフレームごとのダイナミックトランスフォーム状態です。シム中はトランスフォームのみをキャッシュし、Packed Disk Primitiveワークフロー経由でレンダリング時に適用します。これにより、重いジオメトリ（粉砕されたピースで5〜50 GB）と安価なダイナミック状態（通常フレームごとに10〜50 MB）を分離します。ジオメトリは1度アップロードし、ダイナミックキャッシュはショットごとにアップロードします。
コンストレイントネットワークのシリアライゼーションが落とし穴です。RBDコンストレイント（グルー・ハード・ソフト・コーンツイスト）はVellum I/O同等品——RBD I/O SOP——が正しく処理する__constraintnetwork属性を持ちます。ジェネリックなFile Cacheは対応しません。コンストレイント側にはRBD I/Oを使用し、トランスフォームにはスタンダードなパックドプリムキャッシュを使用してください。
クラウドファームでの考慮事項。 RBDシムはランダムシードが固定されていれば決定論的です。デフォルトの動作——$F駆動シード・時刻シード・未設定シード——は異なるワーカーで異なるフラクチャパターンを生成します。1台のワーカーがキャッシュを再構築し、別のワーカーが期待されるパターン（ワークステーションキャッシュで構築されたコンプセットアップなど）に対してレンダリングするファームでは、シードのドリフトはレンダリングが完了した後にしか見えない視覚的な不一致を引き起こします。ベイク前にすべてのランダムシードを固定してください。
# 決定論的なRBDベイク——RBD_SEEDを固定することで、
# 同じフレームレンジをレンダリングする2台のワーカーが
# 同一のフラクチャキャッシュを生成します。
# これがなければ、ワークステーションとファームの間でフラクチャソルブが
# デシンクし、コンプ時の不一致として表面化します。
hbatch -c "set -g \$RBD_SEED 42; \
render -f 1 200 \
-v packed_prims=1 \
/obj/destruction/dop_constraint_OUT" \
"$HIP/scenes/destruction_v012.hipnc"
BulletとRBD Solverの比較：Bulletは大量のピース数（1000個以上のチャンク）に対して高速で、中程度の品質の破壊には適しています。RBD Solverはヒーローショットのダイナミクス・スタック崩壊・コンストレイント駆動のセットアップに対してより正確ですが、フレームごとのソルブコストは約3〜5倍です。ファームでは、ショットがヒーローでない限りBulletが実用的なデフォルトです。
Crowds：エージェント・LOD・ラグドール引き渡し
HoudiniのCrowdsはエージェントシミュレーションフレームワークです——モーションクリップライブラリ・ビヘイビアステート・LODバリアントを持つエージェントの集団を扱います。キャッシュは他のシムタイプよりも複雑です。エージェントキャッシュ（.bclip.scモーションクリップ）・Crowdトランスフォームキャッシュ（フレームごとの.bgeo.sc）・レンダリング時にSolarisバリアントセット経由で解決されるエージェントプリムのパックドプリム参照が含まれます。各エージェントには独自のLOD階層があり、レンダリング時にスワップされます。
キャッシュ戦略。 Crowdシムを.bgeo.scトランスフォームキャッシュ（フレームごとに1ファイル、エージェントごとのトランスフォームとモーションクリップインデックスを保持）にベイクしてください。エージェントジオメトリ——実際のメッシュデータ——は参照される別の.bclip.scライブラリに格納され、フレームごとにベイクされません。この分割こそが、Crowdレンダリングを実用可能にする理由です。1000体のエージェントのショットでは、フレームごとのトランスフォームキャッシュが200 MBある一方、エージェントジオメトリの合計は2 GBだけで、ディスクから参照されます。
モーションクリップキャッシュが重要なのは、クラウドがフレームごとのキーフレームではなくクリップのブレンドでアニメートするためです。クリップライブラリはレンダリング開始前にワーカー上に存在している必要があります。クリップライブラリを1度ベイクしてワーカーの永続ストレージにアップロードし、ショットごとのアップロードはトランスフォームキャッシュのみにします。
ラグドール引き渡し——エージェントがクリップ駆動アニメーションからRBD駆動物理に移行する場面——はファームで特別な扱いが必要です。ラグドール状態キャッシュはCrowdトランスフォームキャッシュとは別であり、引き渡しフレームが決定論的である必要があります。つまり、シードとラグドール開始フレームを明示的に固定することが不可欠です。そうしないと異なるワーカーが異なるラグドール軌跡を生成します。
クラウドファームでの考慮事項。 CrowdsはSolarisステージ経由でKarma（CPUおよびXPU）でレンダリングされ、エージェントのLODバリアントはレンダリング時に解決されます。レンダリング時のLODスワップにより、再シムなしでショットごとにLODを変更できます——ヒーローショットには高LODエージェント、ワイドショットには低LODエージェントをキャッシュに触れることなく使用できます。
# husk呼び出し時にエージェントLODを選択したSolarisクラウドステージをレンダリング。
# KarmaはCrowdシムのLODスワップなしでエージェントプリムバリアントに対応します。
husk --renderer karma --settings xpu \
--frame 1 --frame-count 240 \
--output "$HIP/render/crowd.\$F4.exr" \
--override "/World/crowd:variantSet:lodVariant:value=mid" \
"$HIP/stage/crowd_main.usd"
lodVariant:value=midオーバーライドにより、レンダリング時に中LODエージェントバリアントセットが選択されます。Crowdシムを再実行することなく、遠景バックグラウンドパスにはlow、ヒーロー前景にはhighにスワップできます。これはCrowdのクラウドレンダリングにおける最大の単一ショットコスト削減要素です——レンダリング時のLODにより、1つのキャッシュでシーケンス内のすべてのショットに対応できます。
正直な限界：ファームが適切なツールでない場合
クラウドレンダーファームがすべてのHoudiniシムの問題への答えではありません。これを明確にすることで、誰も上流の質問をしないままショットがファームに送られることを防ぎます。
分散シミュレーションはほぼ実現不可能です。 Pyro・FLIP・Vellum・RBDソルバーは、DOPnetのサブステップ一貫性によりほぼシングルマシン制約があります。PDGはウェッジとフレーム非依存のSOP作業を分散できますが、内側のソルブループは一般的にシム中にワーカーノード間でファンアウトできません。シムが1台のマシンに収まらない場合——ファームのワーカーは通常Dual Xeon E5-2699 V4（RAM 96〜256 GB）で、ハイエンドワークステーションと大きくは変わりません——ファームに移しても問題は解決しません。
キャッシュアップロードの帯域幅計算。 100 Mbpsのクライアントアップリンクで100 GBのFLIPキャッシュをアップロードするには、最初のレンダリングフレームが開始できるようになるまで約2.5時間かかります。キャッシュのアップロードはレンダリングが始まる前に支払うウォールクロック時間です。ギガビットアップリンクは有効で、クライアント側ワークステーションの帯域幅はしばしばそうではありません。
GPUとCPUのシムトレードオフは決まっていますが、ユーザーの期待とは異なります。 PyroとFLIPにはワークステーション上でサブステップソルブを加速するOpenCLパスがあります。ファーム側の優位性は、キャッシュ済みシムの並列フレームレンダリングであり、並列フレームシムではありません。言い換えると、ファーム上のGPUはKarma XPUまたはRedshiftによるレンダリング加速を意味し、ファーム上のCPUは.hipをキャッシュの代わりに送った場合のキャッシュ再構築を意味します。
クラウド側シム調整のイテレーション遅延。 Pyroの密度パラメーターを調整して再シムが必要な場合、変更した.hipを再アップロードし、ワーカー上で再キャッシュしてからレンダリングします。ファームでのサイクルは、シム負荷の高い作業に対してローカルサイクルの4〜8倍になることが多いです。ワークステーションが解像度を保持できるならワークステーションでキャッシュし、ファームはレンダリング側で優位に立ちます。イテレーション側ではありません。
Houdini EngineのライセンストークンAvailability。 マネージドファームでのレンダーオンリー利用はHoudiniレンダーワーカーをカバーしますが、Houdini Engine ライセンス（HDAを多用するプロシージャルパイプライン、ゲームアセットワークフローの場合）は別のシートタイプです。EngineトークンがプールされているかどうかとコンカレンシーのHandlingについて、Engine依存のシーンを提出する前にファームに確認してください。ファームが適切なツールだがどのファームかという問いになった場合、Houdiniレンダーファームの比較では、Houdini固有の基準で5つのマネージドプロバイダーを網羅しています。
ワークフロー推奨事項のまとめ
シムタイプごとに、ローカルキャッシュとファームベイクのどちらを選択するかはほぼ次のようになります。Pyro：ローカルでベイクし、.vdbをアップロードしてGPUでレンダリング。FLIP：アップリンクがキャッシュサイズに対応できる場合はローカルでベイク、そうでない場合はワーカー上でhbatch再構築を検討。Vellum：ほぼ常にローカルでベイク——キャッシュは小さく、再構築時間は無視できません。破壊：シードを固定してローカルでベイクし、トランスフォームキャッシュ（フレームごとの完全ジオメトリではなく変換データのみ）をアップロード。Crowds：トランスフォームキャッシュをローカルでベイクし、エージェントライブラリと共に1度アップロードし、ショットごとにLODバリアントでレンダリング。
新規HoudiniクライアントにSuper Renders Farmのランディングページで案内する意思決定ツリーは、バイヤーレベルでレンダラーマトリクスをカバーしています。この記事はその下にあるFX TDレベルの最適化ポイントをカバーしました。私たちの公開レートでのCPU料金は$0.004/GHz-Hrです——マルチデイのキャッシュ再構築とワークステーション代替のサイジングに関連します。私たちのファームのレンダラーマトリクスはKarma XPUとKarma CPU、Mantra、Redshift、Arnold、V-Ray for Houdini、Octaneをサポートしています。
FAQ
Q: クラウドアップロード帯域幅に対して最適な.bgeo.sc圧縮設定は何ですか？
A: FLIPの粒子キャッシュでは、デフォルトの.bgeo.sc（パックドスパース圧縮）がアップロードに対してすでにほぼ最適です——このフォーマットはそのために設計されています。最大の帯域幅節約は上流にあります。カメラが深いボリュームを透過しない場合にナローバンドFLIPを有効にすることで、圧縮が実行される前に粒子キャッシュサイズを60〜80%削減できます。VellumとRBDのキャッシュでは、.bgeo.scも同様にすでに最適です。フォーマットを変更するのではなく、変化するもの（フレームごとの完全ジオメトリではなくトランスフォーム）のみをキャッシュすることで効率化されます。
Q: 複数のクラウドワーカー間でPyroやFLIPのシミュレーションを分散実行できますか？ A: いいえ、内側のソルブループでは不可能です。Pyro・FLIP・Vellum・RBDはすべてDOPnetのサブステップ一貫性に依存しています——フレームNは同じソルバーコンテキスト内のフレームN-1に依存します——そのため、ソルブはシム中にワーカーノード間でファンアウトできません。PDGはウェッジ（パラメータースイープ）とフレーム非依存のSOP作業を分散できますが、実際のソルバーは1台のマシンで実行されます。ファームのシム作業での優位性は、ベイク済みキャッシュの並列フレームレンダリングであり、並列フレームシミュレーションではありません。
Q: Vellumはワークステーションでキャッシュすべきですか、それともファームでキャッシュすべきですか？ A: ほぼ常にワークステーションです。Vellumのキャッシュは控えめで（通常ショットごとに5〜20 GB）、ワークステーションでのベイク時間は管理可能（単一CPUで中程度の複雑さのコスチュームで30〜90分）で、キャッシュは安価にアップロードできます。ファームワーカーに.hipからVellumキャッシュを再構築させることは、ローカルで無料に費やすはずだったワーカー側のCPU GHz-Hrを支払うことを意味します。例外：.hipを調整してサブステップの変更がキャッシュを無効にするショット修正シナリオ。その場合はファームの再構築が合理的です。
Q: Karma XPUはクラウドワーカー上でキャッシュ済みPyroの.vdbファイルのボリュームレンダリングをサポートしていますか？
A: はい。Karma XPUはSolarisステージ経由でOpenVDBボリュームをネイティブに利用し、キャッシュ済み.vdbシーケンスを参照するUSDステージに対するhusk呼び出しは、再ソルブなしでボリュームをレンダリングします。GPUワーカーはボリュームを直接描画し、ソルバーはワーカー上に存在する必要がありません。プロダクション品質のボリュームにはデフォルトの4から8にkarma:volumesamplesを増加させ、ヒーローショットには16を使用してください——コストはダブリングごとにレンダリング時間が約1.5〜2倍になります。
Q: クラウドワーカー間でRBD破壊シムを決定論的に保つにはどうすればよいですか？
A: ベイク前にDOPnet内のすべてのランダムシードを固定してください——RBD_SEED・フラクチャシード・$F駆動または時刻駆動シードすべてです。シードの固定なしでは、同じRBDシーンを2つの異なるワーカーでベイクすると異なるフラクチャパターンが生成されます。ワークステーションでレンダリングされたリファレンスとファームでレンダリングされたファイナルが一致しない場合、コンプ時に不一致として表面化します。hbatch呼び出しでグローバル変数としてシードを設定し（set -g $RBD_SEED 42）、DOPnetがそれを読み取ることを確認してください。
Q: クラウドレンダーファームでCrowdシムをレンダリングするためにHoudini Engineライセンスが必要ですか？
A: Crowdパイプラインの構成によります。.bgeo.scトランスフォームキャッシュにベイクしてキャッシュに対してKarmaでレンダリングするCrowdシムはEngineを必要としません——レンダーオンリーライセンスティアで対応できます。レンダリング時にHDAを実行するCrowdシム（プロシージャルエージェント生成・インスタンス化プロシージャルアセット）はEngineシートが必要な場合があります。Engineトークンがプールされているかどうかとコンカレンシーの処理についてファームに確認してください。私たちのファームでは、レンダーオンリーライセンスモデルにより、GPUフリートでKarma XPUを、CPUフリートでCPUレンダラーをEngine シート制約なしでレンダリングできます。HDAを多用するCrowdパイプラインはショット設定中に相談してください。
関連記事
外部リソース
About Thierry Marc
3D Rendering Expert with over 10 years of experience in the industry. Specialized in Maya, Arnold, and high-end technical workflows for film and advertising.
