Houdini クラウドレンダリング設定

当ファームのHoudiniは、最新のUSDファーストパイプラインを中心に構築されたマルチレンダラー環境です。Karma XPUはHoudini 20.5の新規プロジェクトにSideFXが推奨するパスで、ランディングページのプライマリCTAです。Karma CPUとMantraはレガシーワーク向けに引き続き利用可能です。サードパーティレンダラー（Redshift、Arnold、V-Ray for Houdini、Octane）は、これらのエンジンで確立されたパイプラインを持つスタジオ向けにサポートされています。このページでは、プロジェクトのパッケージ化（Houdiniではテクスチャだけでなく、HDAsとシミュレーションキャッシュも含む）、Solaris/USDアセットワークフロー、レンダラー別ノート、送信フロー、サポートチケットで最もよく見られるHoudini固有のトラブルシューティングについて説明します。

はじめに、ライセンスについて注記します。当ファームでは、オフラインレンダリングのためにレンダーワーカーでHoudiniを実行することを許可するレンダーオンリー利用のもとでHoudiniインストールを運営しています。Super Renders FarmはSideFXパートナーではありません。レンダーオンリー利用は、スタジオのライセンスプールからSideFXシートを占有せずにHoudiniシーンのファームレンダリングを可能にする法的フレームワークです。ファームにHoudiniライセンスを移転する必要はなく、アーティスト側のプロジェクトティアメタデータ（Indie、Core、FX）はワーカーのライセンス取り決めを決定しません。ワーカーはファーム側のライセンスから利用します。

概要（対応Houdiniバージョン、ハードウェアの適合性、料金例）については、の専用ランディングページが正規の参照先です。このページはワークフロードキュメントです：送信ボタンをクリックする前にHoudiniで何をすべきかを説明します。

対応バージョン

Houdini 19.5、20.0、20.5はファームのすべてのワーカーにプリインストールされています。SideFXのリリーススケジュールを追跡し、公開から4週間以内に新しいメジャービルドをプロビジョニングします。ポイントリリース（例：Houdini 20.5.410 vs. 20.5.487）は継続的に追跡されています。ノードの互換性の問題でプロジェクトが特定のビルド番号にロックされている場合は、送信時のジョブメモにビルドを記載すれば、ワーカーをそれに合わせます。

Houdini FX（プロダクションティア）とHoudini Indieのシーンファイル（.hip と .hipnc）はどちらもワーカーでロードされ、ファームのレンダーオンリー利用取り決めのもとでレンダリングされます。アーティスト側のティア（Indie vs. Core/FX）はワーカーのライセンスシートに伝播しません。Houdini Apprenticeファイルはレンダリングされますが、SideFXの非商用ライセンス条件に従い透かし入りの出力が生成されます。有料プロダクションワークでは、送信前に非Apprenticeライセンスからシーンを保存してください。

SideFXは12〜18ヶ月ごとにメジャーバージョンをリリースし、ポイントアップデートはより頻繁に提供されます。特にKarma XPUは19.5、20.0、20.5間で大幅に改善されています（19.5でCPUフォールバックだった機能（重いボリューム、一部のシェーダーネットワーク）は20.5でXPUネイティブになっています）。

Houdiniプロジェクトのパッケージ化

Houdiniプロジェクトは .hip（または .hipnc）シーンファイル以上のものです。通常、HDAs（Houdini Digital Assets — .hda または古い .otl 形式）、シミュレーションキャッシュファイル（.bgeo、.bgeo.sc、.vdb、.abc）、USDアセットレイヤーとリファレンス（.usd、.usda、.usdc）、テクスチャマップ、FileまたはAlembic SOPからインポートされた外部ジオメトリも含まれます。クラウドレンダリングが成功するのは、シーンが参照するすべての依存関係がワーカーに存在する場合です。ローカルの場合はワークステーション固有のパスで解決しても、ファームでは解決できない場合は失敗します。

Houdiniのパス規則は環境変数に基づいて構築されています。最も一般的なのは $HIP（.hip ファイルを含むディレクトリに解決）、$HIPNAME（シーンファイルのベース名）、$JOB（環境変数で設定されたプロジェクトルート）です。クラウドレンダリングでの信頼性の高い規則は、どこでも $HIP 相対パスを使用することです。以下のパッケージ化手順でこの規則をエンドツーエンドで適用します：

プロジェクトフォルダーを設定します。 新しいプロジェクトを保存する際、Houdiniは $HIP を .hip ファイルを含むディレクトリに設定します。Pythonシェルで hou.text.expandString('$HIP') を使用して確認してください。パスはシーンファイルがある場所と一致する必要があります。
標準サブフォルダー構造を使用します。 シミュレーション用の $HIP/cache/、AlembicおよびExternal Geometryの $HIP/geo/、テクスチャの $HIP/tex/、デジタルアセットの $HIP/hda/、USDレイヤーとリファレンスの $HIP/usd/、出力の $HIP/render/。シーンのFile SOP、File COP、ROP出力、テクスチャリファレンスのすべてのパスは、絶対ドライブ文字パスではなく $HIP/... を使用する必要があります。
パスが解決することを確認します。 File → Refresh All。Houdiniは未解決のファイルリファレンスをコンソールに報告します。Pythonシェルから hou.fileReferences() は外部リファレンスの完全なリストを返します。D:\、Y:\、\\server\ のようなUNC共有、またはワーカーが到達できないパスで始まるものを確認してください。
シミュレーションをディスクにベイクします。 ファームはレンダージョブの一部としてシミュレーションを実行しません。すべてのDOPネットワーク（FLIPフルイド、Pyro、Vellumクロス、RBD Bullet、グレイン）、パーティクルソルバー、その他のシミュレーション出力を送信前に $HIP/cache/ の .bgeo.sc または .vdb ファイルにベイクしてください。
HDAsを埋め込むか含めます。 シーンがスタジオライブラリのカスタムHDAを使用する場合、それらを .hip に埋め込む（Asset menu → Save Operator Type → "Embedded"）か、ワーカーがプロジェクトフォルダーからロードできるように $HIP/hda/ に .hda/.otl ファイルを含めます。
USDレイヤーをフラット化またはバンドルします。 シーンがSolaris/LOPsを使用する場合、USD ROPを使用してUSDステージを単一の構成済みUSDファイルにベイクするか、$HIP/usd/ ディレクトリツリー全体を含めてすべてのレイヤーがワーカーで解決するようにします。
$HIP フォルダー全体をアーカイブします。 .tar、.tar.gz、または .7z を使用します。Houdiniプロジェクトの .zip アップロードは受け付けていません。

Houdiniに固有のよくある落とし穴：ROPノードの「Pre-Render Script」と「Post-Render Script」フィールドがワークステーション固有のPythonスクリプトを参照することがあります（スタジオのパイプラインツール、ローカルのHoudiniコンフィグパス、hou.ui.displayMessage 呼び出しなど）。送信前にプリレンダーのPythonやHScriptコールバックを監査してください。ローカル専用パス、UI呼び出し、またはワークステーションバイナリへの hou.system() シェルアウトに触れるコードを無効にするか、パスポータブルにします。インタラクティブなコールバックよりも print() ログを使用してください。

Solaris、USDレイヤー、アセット解決

シーンがSolaris（/stage LOPsネットワーク）で作成されている場合、USDアセット解決レイヤーがOBJ/SOPのみのシーンにはないクラウド送信の追加次元を加えます。HoudiniのUSDリゾルバーは標準のUSDアセット解決ルールに従います。

クラウド送信では、2つのパターンが確実に機能します：

ステージをフラット化します。 USD ROPノードを「Save to Disk」と「Flatten Stage」オプションを有効にして使用します。結果はすべてのリファレンスが解決された単一の構成済み .usd（またはバイナリの .usdc）ファイルです。これはシンプルなパターンですが、コラボレーションにUSDを価値あるものにするレイヤー構造を失います。
フルアセットツリーをバンドルします。 すべてのUSDレイヤーを $HIP/usd/ に配置し、サブレイヤー、リファレンス、ペイロードに $HIP 相対リファレンスを使用します。ワーカーは $HIP をアップロードルートに解決するため、同じ相対位置のレイヤーファイルが正しくロードされます。

重要な注意点：Solaris の「Asset Reference」LOPと/objコンテキストのReference SOPは、書き込んだリファレンスパスをそのままシリアライズします。Reference LOPに D:\studio_assets\char_robot.usd を書き込んだ場合、ワーカーには D:\ がなく、リファレンスが失敗します。リファレンスを $HIP/usd/char_robot.usd として再作成してください。

HDA管理

Houdini Digital Assets（HDA、古い .otl 拡張子で見られることもあります）は再利用可能なノードネットワークをスタンドアロンのアセットファイルとしてパッケージ化したものです。特に個別ショットとは別に作成されシーン間で共有される手続き型アセット（建物、植生、群衆システム、カスタムソルバー）のプロダクションパイプラインで一般的です。

ファームでのHDA処理の3つのパターン：

HDAを .hip ファイルに埋め込みます。 Asset menu → Operator Type Manager → HDをを右クリック → "Save to Embedded"。HDAは .hip に格納されシーンと一緒に転送されます。これは単発のジョブや単一ショット専用のHDAに最も安全なパターンです。
HDAsを $HIP/hda/ にバンドルします。 すべての .hda/.otl ファイルをプロジェクトのサブフォルダーに配置し、$HIP/hda/ がOTL検索パスの一部であることを確認します。
スタジオ共有ライブラリからHDAを参照します。 スタジオがネットワークドライブ（例：\\studio-fs\houdini\hda\）の共有HDAライブラリを使用する場合、そのライブラリはワーカーからアクセスできません。送信前に関連するHDAを $HIP/hda/ にコピーするか、.hip に埋め込んでください。

送信前に、PythonシェルからシーンでロードされたすべてのHDAをリストします。出力のすべてのパスは $HIP 以下で解決されるか、Houdini自体に同梱されているストックSideFX HDAである必要があります。

キャッシュファイル管理

キャッシュファイルはHoudiniプロジェクトのアップロードで最大の単一カテゴリです。FLIPシミュレーション、Pyroキャッシュ、Vellumクロスベイク、Alembicエクスポート、VDBボリュームはそれぞれ数十または数百GBになることがあります。

ベイク時にキャッシュを圧縮します。 .bgeo.sc（圧縮bgeo、blosc圧縮）は同じジオメトリの .bgeo よりも大幅に小さく、File Cache SOPの現代のデフォルトです。
$HIP/cache/ を一貫して使用します。 HoudiniのFile Cache SOPのデフォルトは $HIP/cache/{node_name}/$F4.bgeo.sc で、ファームポータブルなシーンに適したパターンです。D:\sim_cache\ のような絶対キャッシュパスは避けてください。

非常に大きなシミュレーション（ブラウザのアップロードを超えるマルチテラバイトのFLIPまたはPyroキャッシュ）にはウェブアップロードフォームではなくSFTPを使用します。ドキュメントにSFTPワークフローが記載されています。

送信前に確認すること

あらゆるHoudini送信の短いプリフライトチェックリスト：

アクティブなROPノードが正しく設定されていること。 Output context → Render。送信時に選択したROPがワーカーが呼び出すレンダラーを決定します。
フレームレンジがROP設定と一致していること。 ROPに格納されたフレームレンジ（f1、f2、f3 パラメーター）がワーカーが使用するもので、タイムラインの再生レンジやビューポートの現在のフレームではありません。
出力パスが $HIP 相対トークンを使用していること。 $HIP/render/$F4.exr は4桁パディングのマルチレイヤーEXRの安全なデフォルトです。
すべてのFile SOPとテクスチャリファレンスが解決すること。 File → Refresh All。送信前にコンソールの「Unable to read」エラーを修正してください。
HDAsが埋め込まれているか $HIP/hda/ にあること。 シーンを完全に閉じて別のHoudiniセッションから再度開くことで確認します。
キャッシュがベイクされていること。 送信前に各File Cache SOPで手動キャッシュベイクを実行します。
USDレイヤー（Solarisを使用する場合）がバンドルまたはフラット化されていること。
インタラクティブなプリレンダーまたはポストレンダースクリプトがないこと。 ROP PythonコールバックとPre-Frame Scriptを監査します。

レンダラー別ノート

Karma XPU（推奨）

Karma XPUはSideFXのハイブリッドCPU+GPUレンダラーで、Houdini 20.5でプロダクションレディステータスに昇格し、新しいHoudiniプロジェクトのデフォルトの将来志向パスです。

設定ノート：

ワーカーティア： RTX 5090 GPUワーカーティア（カードあたり32 GB VRAM）で動作し、XPUコードパスがまだサポートしていない機能にはCPUフォールバックがあります。
VRAM制約： ワーカーあたり32 GB VRAM。Karma XPUは純粋なGPUレンダラーよりもVRAM効率が高く、VRAMが制限されている場合はレンダリングの一部（特にボリューム）をCPUメモリにオフロードできます。
USDパイプライン統合。 KarmaはSolaris USDベースのパイプライン用に設計されたレンダラーです。
AOV。 USDステージのRender Settings primでレンダリングプロダクトごとに設定します。マルチチャンネルEXRがデフォルト出力形式です。
サンプリング。 KarmaのパストレーシングサンプルはRender Settings primごとに設定されます。シーケンスを送信する前に単一フレームでローカルにキャリブレーションします。

Karma CPU

Karma CPUはKarmaの純粋CPUバリアントです。Houdini 19以降で機能完全かつ安定しており、GPU VRAMを超えるシーンやXPUコードパスにまだ実装されていない機能に依存するシーンの自然なフォールバックです。

ワーカーティア： CPUワーカーティア（Dual Intel Xeon E5-2699 V4ノード、ノードあたり96〜256 GB RAM）。
Karma XPUより優先する場合： 非常に重いジオメトリ（5000万ポリゴン超）、32 GB VRAMを超える密なボリュームレンダリング、XPUに対応するものがないOSLカスタムシェーダー。

Mantra（レガシー）

MantraはHoudiniのKarma以前のレンダラーです。SideFXはMantraが将来のパスではないことを示しており、KarmaはMantora以降のパスです。Karma以前に作成されたプロジェクトとの後方互換性のためにHoudiniビルドに残っています。

ワーカーティア： CPUワーカーティア。
使用すべき時： プロジェクトがMantraにロックされている場合、またはMantra固有の機能が必要な場合のみ。2026年の新しい作業では、Karmaをデフォルトとしてください。

Houdini用Redshift

Houdini用RedshiftはRTX 5090 GPUワーカーティアで動作します。確立されたRedshiftパイプラインを持つスタジオ（FX向けにHoudiniに進出しているMayaまたはCinema 4Dショップで、DCC間でシェーダーライブラリを共有したい場合）に適しています。

ライセンス： 当ファームのRedshiftはMaxonパートナーライセンスで動作します。
アウトオブコアメモリ： デフォルトで有効。ワーカーあたり32 GB VRAMの上限を超えて実効的なシーンメモリを拡張します。
バージョンピニング： RedshiftはHoudiniのリリースサイクルとは独立した3.xサイクルでリリースされます。

Houdini用Arnold

Houdini用Arnold（HtoAと呼ばれることもあり、現在Arnold 7.xリリースサイクル）はCPUワーカーティアで動作します。Maya/HoudiniのArnoldパイプラインを共有しているスタジオに適しています。

ライセンス： Autodeskレンダーノードライセンスで動作します。

Houdini用V-Ray

Houdini用V-RayはCPUワーカーティアで動作します。V-Ray中心のパイプラインを持つスタジオのためにサポートされています。

ライセンス： Chaosパートナーライセンスで動作します。

Houdini用Octane

Houdini用OctaneはRTX 5090 GPUワーカーティアで動作します。HoudiniとCinema 4Dをつなぐスタイライズドな出力のモーションデザインスタジオが主に使用します。

VRAM制約： ワーカーあたり32 GB VRAMで、Redshiftよりもアグレッシブなメモリプロファイル（アウトオブコアパスなし）。

送信フロー

ファームのHoudiniプロジェクトには3つの送信チャンネルが利用できます：

ウェブアップロード + ダッシュボードからの送信。 $HIP フォルダーを .tar.gz または .7z としてアーカイブし、ウェブサイトを通じてアップロードし、ジョブ（レンダラー、ROPノード、フレームレンジ、出力形式）を設定して送信します。
大型プロジェクトにはSFTP。 マルチテラバイトのシミュレーションキャッシュを持つHoudiniプロジェクトは再開可能な転送のためにSFTPを使用します。をご参照ください。
クライアントアプリ。 Super Renders Farmクライアントアプリはアップロード、送信、自動ダウンロードをデスクトップアプリケーションにラップします。

ウォーカーは hbatch（OBJ/SOPコンテキストROPへのHIPファイル送信用）と husk（Karma用のUSDステージ送信用）を使用します。

Houdini固有の失敗のトラブルシューティング

一般的なクロスDCCのトラブルシューティングについては、をご参照ください。サポートチケットで最もよく見られるHoudini固有の失敗パターン：

「Unable to find HDA」またはHDAが古いノードプレースホルダーでロードに失敗する。 シーンが参照するHDAファイルをワーカーが見つけられません。HDAsが .hip に埋め込まれているか（Asset menu → Operator Type Manager → "Save to Embedded"）、検索パスが設定された $HIP/hda/ に存在することを確認してください。
レンダリング時にキャッシュファイルが見つからない / シミュレーションジオメトリが空。 送信前にキャッシュファイルが実際にディスクにベイクされていたか確認してください。パスが絶対ドライブ文字を使用している場合（D:\sim_cache\flip.0001.bgeo.sc）、$HIP/cache/{node_name}/$F4.bgeo.sc に変更して再ベイクします。
レンダリング出力が完全に空 / 黒フレーム。 ROPの「Render Settings」prim（SolarisステージのKarma用）またはカメラリファレンス（/objコンテキストROPのMantra、Redshift、Arnold、V-Ray、Octane用）を確認してください。
Karma XPUが「OptiX not available」または「GPU not detected」で即座に失敗する。 ワーカーが更新中またはドライバーがロールバック中の場合にまれに発生します。5〜10分後に再送信してください。
プリレンダーPythonスクリプトがワーカーで失敗する。 スクリプトを無効にするか、パスポータブルにします。
Solaris / USDアセットリファレンスが壊れる。 USDアセットリゾルバーパスは $HIP 相対である必要があります。
プラグインバージョンの不一致 / シーンのロードが失敗する。 HtoA 6→7またはRedshift 3.0→3.5のジャンプのようなプラグインバージョンの不一致。メジャーバージョンジャンプは互換性が保証されていません。

クロスリファレンス

— アップロード、送信、ダウンロードのワークフロー（クロスDCC）
— Houdiniジョブのコスト計算方法（GPU vs CPUティア）
— SFTPガイド、アーカイブ形式、大型プロジェクト転送
— クロスDCCトラブルシューティング
— デスクトップ送信ラッパー
— ランディングページ

FAQ

Q: ファームはどのHoudiniバージョンをサポートしていますか？ A: Houdini 19.5、20.0、20.5はすべてのワーカーにプリインストールされています。SideFXのリリーススケジュールを追跡し、公開から4週間以内に新しいメジャービルドをプロビジョニングします。Houdini FX（.hip）とHoudini Indie（.hipnc）シーンファイルはどちらもサポートされています。Houdini Apprenticeファイルはレンダリングされますが、SideFXの非商用ライセンス条件に従い透かし入りの出力が生成されます。

Q: ファームでレンダリングするためにHoudiniライセンスを移転する必要がありますか？ A: いいえ。当ファームでは、スタジオのライセンスプールからSideFXシートを占有せずにオフラインレンダリングのためにレンダーワーカーでHoudiniを実行することを許可するレンダーオンリー利用のもとでHoudiniを運営しています。ローカルのHoudiniライセンスはお手元に残ります。

Q: 新しいプロジェクトにKarma XPU、Karma CPU、Mantraのどれを使うべきですか？ A: 2026年の新しいプロジェクトにはKarma XPUを使用してください。SideFXが推奨する将来志向パスで、RTX 5090 GPUティアで動作し、ほとんどのシーンでKarma CPUやMantraよりも大幅に速くなります。32 GB VRAMを超えるシーン、GPUをオーバーフローする重いボリューム、またはXPUでまだサポートされていないOSLカスタムシェーダーにはKarma CPUを使用します。プロジェクトがMantraにロックされている場合のみMantraを使用します。

Q: ファームはHoudiniシミュレーション（Pyro、FLIP、Vellum、RBD）を実行できますか？ A: いいえ — シミュレーションはワークステーションの作業です。送信前にすべてのシミュレーションキャッシュを .bgeo.sc または .vdb ファイルにローカルでベイクしてください。ファームは事前ベイクされたキャッシュに対してレンダリングします。

Q: プロジェクトでHoudiniのSolaris/USDパイプラインを使用しています。正しくレンダリングされますか？ A: はい（レンダラーとしてKarma（CPUまたはXPU）を使用する場合）。Solarisのパスとして設計されているのはKarmaで、両方のレンダラーがUSDステージをネイティブに消費します。クラウド送信では、USD ROPを使用してUSDステージを単一の構成済み .usd ファイルにフラット化するか、$HIP/usd/ ディレクトリツリー全体をバンドルしてすべてのレイヤーがワーカーで解決するようにします。

Q: シーンではスタジオの共有ライブラリのカスタムHDAを使用しています。ファームで見つかりますか？ A: ファームはスタジオの共有ネットワークドライブ（\\studio-fs\hda\... など）のHDAを見つけられません。Asset menu → Operator Type Manager → "Save to Embedded" でHDAを .hip に埋め込むか、アーカイブ前に .hda/.otl ファイルを $HIP/hda/ にコピーします。

Q: シミュレーションキャッシュを使用するHoudiniプロジェクトをどのようにパッケージ化しますか？ A: 送信前にすべてのシミュレーションを $HIP/cache/{solver_name}/$F4.bgeo.sc（またはボリュームの .vdb）にローカルでベイクします。File → Refresh Allでキャッシュファイルが期待されるパスに存在することを確認します。$HIP フォルダー全体（cache/ サブフォルダーを含む）を .tar.gz または .7z としてアーカイブします。

Q: Houdiniプロジェクトのアップロードはどのくらいの大きさにできますか？ A: ハードなアップロードサイズ制限はありませんが、単一のブラウザアップロードは〜50 GB未満に抑えることをお勧めします。それ以上の場合は、再開可能な転送のためにSFTPに切り替えてください。

Q: ファームでMantraのレンダリングがローカルよりはるかに遅くなっています。これは想定通りですか？ A: 当ファームのCPUワーカー（Dual Xeon E5-2699 V4）でのMantraのフレームあたりの速度は、ハイエンドワークステーションと同等です。ローカルと比べてフレームあたりの時間が大幅に遅い場合、最も可能性の高い原因は：ワーカーでのサンプリング設定の違い（MantraはROPからサンプル数を読み取ります — ROPレベルの設定が一致していることを確認）、またはワーカーのCPUのみのティアではアクティブでないローカルのOpenCLアクセラレーション。根本的な解決策は移行です：当ファームのGPUティアのKarma XPUはほとんどのシーンでMantraより大幅に速く、SideFXも今後のパスとしてKarmaを推奨しています。

Q: ファームはHoudiniのPDG/TOPsによる分散タスク管理をサポートしていますか？ A: PDGはワークステーション側のオーケストレーションです；ファームは独自のキューとワーカー割り当てシステムを使用します。ローカルでPDGを使用してアセットを作成しベイクしてから、WebダッシュボードまたはClient Appを通じて最終的なROPジョブをファームに送信することができます。外部ファームへのPDG直接送信はロードマップにありますが、まだファーストクラスのワークフローではありません。

Q: Houdiniのクラウドレンダリングのコストはどのように計算されますか？ A: ファームでのHoudiniのコストはレンダラーのワーカーティアに依存します — Karma XPU、Redshift、OctaneにはGPUレート；Karma CPU、Mantra、Arnold、V-Ray for HoudiniにはCPUレート。フレームあたりの複雑さ（サンプル数、AOV数、出力解像度）がフレームあたりのコストを左右し、レンダラーの選択がノード時間あたりのレートを左右します。シミュレーションはファームで実行する場合のみ追加コストが発生します（ローカルでキャッシュしてアップロードすることをお勧めします）。料金の詳細はをご覧いただくか、で見積もってください。

---

クラウドレンダリング向けHoudiniのセットアップ