高度なユーティリティ：Render Node Template、Troubleshoot Machine、Simulate Local Path、APIアクセス

Super Renders Farmは、デフォルトのWebアップロード・提出・ダウンロードフロー以上が必要なスタジオ向けに4つの高度なユーティリティを提供しています：Render Node Template（ジョブをレンダリングするワーカーの再現可能なソフトウェアスタックを定義）、Troubleshoot Machine（レンダーノード環境に合致するRDPアクセス可能なデバッグVMを起動）、Simulate Local Path（ハードコードされたパスでアセットを解決するプロジェクトの絶対パスを保持）、そしてAPIアクセスサーフェス（現在は制限されています — 現在のプログラマティック提出については§APIアクセスを参照）。このページはすべての4つのリファレンスマニュアルです — それぞれをいつ使用するか、弊社ファームでの基本的な仕組み、各ユーティリティを設定または呼び出す正確な手順、そしてサポートで最もよく見られる失敗モードについて説明します。

ファームを初めて使用していてデフォルトのアップロードフローを探している場合、が適切な出発点です。失敗したジョブのデバッグをしている場合、ページは最も頻繁なエラーパターンをカバーしています。ここで文書化されているユーティリティは、デフォルトフローが合わない場合向けです — 通常は確立されたパイプラインを持つ大規模スタジオ、異常なアセットパス要件のあるプロジェクト、またはレンダリングワーカーが見ているものを正確に確認する必要のあるスポットデバッグセッション向けです。

どのユーティリティを使うかの判断

各ユーティリティセクションの前の短いオリエンテーション：

| 必要な場合... | 使用するユーティリティ | |---|---| | ジョブに割り当てられたワーカー上で実行するDCCバージョン、プラグインバージョン、プラグインライセンスをロックする | Render Node Template | | Microsoft Remote Desktopを通じて実際のレンダリングワーカーに接続し、その場でシーンを修正してから実際のジョブとして提出する | Troubleshoot Machine | | 絶対パス（C:\projects\…またはD:\textures\…）を使用し、相対パスに変更できないプロジェクトをレンダリングする | Simulate Local Path | | スクリプトまたはパイプラインツールからプログラマティックにジョブを提出する | APIアクセス（プレースホルダーを参照 — 現在のパスはClient AppまたはDCCプラグイン） |

これらを組み合わせることができます。Render Node TemplateはSimulate Local Pathと同じジョブで組み合わせられます。Troubleshoot MachineはアクティブなRender Node TemplateとSimulate Local Pathの設定を両方尊重するため、デバッグ環境が本番レンダリング環境と一致します。4つのユーティリティはコンポーズできるよう設計されています。

Render Node Template

Render Node Templateは4つのユーティリティの中で最も強力で最も長い歴史を持つものです。ジョブをピックアップする前にレンダリングワーカーが持つべき正確なソフトウェア環境を指定できます：どのバージョンの3ds Max、どのV-Rayビルド、どのプラグインがインストールされライセンスされているか、そしてレンダリング開始前にワーカー上の既知の場所に配置する必要があるカスタム設定ファイル。一度定義すると、テンプレートはジョブ間で再利用できます — そのテンプレートでタグ付けされたすべての提出が同一のワーカースタックで実行されます。

どのような問題を解決するか

デフォルトで、Super Renders Farmはすべてのレンダリングワーカーにキュレーションされたソフトウェアスタックをプレインストールします — 最新のDCCバージョンと最も一般的なレンダラーおよびプラグインで、弊社が最もよく見るワークロード向けに調整されています。80%のジョブにとってこれが適切なデフォルトです；ワーカーにはシーンが必要とするソフトウェアがすでにあります。しかし、デフォルトが不十分な2つの状況があります：

• バージョンピニング。 スタジオは3ds Max 2024 + V-Ray 6.10.05 + 特定のForest Packビルドで標準化しており、同じアニメーション内のフレーム間でサンプリングやノイズの違いを引き起こす可能性がある新しいポイントリリースをワーカーがピックアップするリスクを取れない。
• ニッチなプラグイン。 デフォルトのファームスタックにないプラグイン（またはプラグインバージョン）を使用している — 例えば、あまり一般的でないPhoenix FDリリース、Pulze ZBrushブリッジ、または珍しいCoronaフィーチャービルド。

Render Node Templateを使用すると、スタックを明示的に宣言できます。ファームはジョブを宣言されたテンプレートにすでに一致するワーカーにルーティングするか、割り当て前に一致するように新しいワーカーをプロビジョニングします。どちらの方法でも、バージョンピニングの保証はエンドツーエンドです。

弊社ファームでの仕組み

Render Node Templateはアカウントに紐付けられた名前付きの設定レコードです。以下が含まれます：

• DCCとバージョン — 例：3ds Max 2024.2.2
• レンダラーとバージョン — 例：V-Ray 6.10.05
• バージョン付きプラグインリスト — 例：Forest Pack Pro 8.4.2、RailClone Pro 6.3、Phoenix FD 5.10
• ライセンスチャンネル — どのライセンス（Chaos、Maxon、Otoy、AXYZ Design）が弊社のアンブレラライセンスインフラ経由でワーカーに利用可能であるべきか。ほとんどのプラグインはデフォルトでカバーされています；テンプレートが弊社がまだホストしていないプラグインを参照している場合、サポートがフラグを立て、自分のライセンスファイルを持参します。
• オプションのファイルペイロード — レンダリング開始前にワーカーの既知の場所に配置する設定ファイル、プリセット、またはシェーダーライブラリ。

ジョブを提出してテンプレートでタグ付けすると、ファームスケジューラーはテンプレートを現在のワーカープールと照合します。一致するワーカーがアイドルであれば、ジョブは即座にディスパッチされます。一致するワーカーが利用できない場合、スケジューラーはテンプレートに対してフレッシュなワーカーをプロビジョニングします — これは通常デフォルトスタックのジョブより数分長くかかります。これが主なトレードオフです。

Render Node Templateの作成

テンプレートエディターはダッシュボードの「Render Node Templates」（または同様の項目 — 正確なUIラベルはダッシュボードリリース間で変わる可能性があります；エントリが見えない場合はサポートに連絡すればアカウントに表示します）からアクセスできます。

手順：

1. superrendersfarm.comにサインインしてダッシュボードのRender Node Templatesセクションを開きます。
2. 新しいテンプレートを作成し、わかりやすい名前を付けます — 通常はプロジェクトコードまたはstudio-archviz-2024-vray6のようなスタジオ標準ラベル。名前は自由です；ファームはマッチングにのみ使用します。
3. DCCとバージョンを選択する。 ドロップダウンは現在弊社がホストしているすべてのDCCバージョンを一覧表示します。必要なバージョンがリストにない場合、サポートとの話し合いなしにそれに対してテンプレートを作成できません — 一部のレガシーバージョンは廃止されています。
4. レンダラーとバージョンを選択する。 同じ制約 — ドロップダウンは現在のファームスタックを反映しています。
5. プラグインを1つずつ追加する。 各プラグインについて：カタログからプラグイン名を選択し、バージョンを選択し、ライセンスチャンネルを確認します。弊社のカタログ外のプラグインはサポートとの話し合いが必要です — プラグインがライセンスをホストするには十分に主流であれば通常一回限りの作業です。
6. ファイルペイロードを添付する。 ワーカーに必要な設定またはプリセットファイルをアップロードします。ファームはこれらをテンプレートと共に保存し、レンダリング開始前にワーカーの作業ディレクトリにコピーします。
7. 保存と検証。 ダッシュボードは現在のワーカープールに対して検証パスを実行し、「matching workers available」（最初のジョブで即座にディスパッチ）または「no current matches — workers will be provisioned on first use」（最初のジョブで若干の起動遅延）のどちらかを報告します。

テンプレートはその後の任意のジョブ提出で選択可能になります。

提出時にテンプレートを使用する

レンダリングジョブを提出する際 — Webアップロード、Client App、またはDCC提出プラグイン経由 — 提出フォームには「Render Node Template」ドロップダウンが含まれます。作成したテンプレートを選択します。ジョブはスタック宣言全体を継承します；提出フォームでDCC、レンダラー、プラグインバージョンを再指定する必要はありません。

2つの操作上の注意：

• テンプレート + Expressプライオリティの組み合わせ。 テンプレート付きジョブをExpressプライオリティで提出できます。スケジューラーは両方の制約を満たすアイドルのワーカーを見つけようとします；利用できない場合はプロビジョニングします。Expressテンプレートジョブは通常デフォルトスタックのExpressジョブよりディスパッチウィンドウが若干長くなりますが、価格差は同じです。
• テンプレート + Simulate Local Pathの組み合わせ。 プロジェクトに絶対パスも必要な場合は、通常通り提出時にSimulate Local Pathを設定してください（§Simulate Local Pathを参照）。テンプレートはソフトウェア環境を制御し、Simulate Local Pathはファイルシステムレイアウトを制御します。これらは直交する関心事です。

テンプレートの編集とバージョン管理

テンプレートはミュータブルです — バージョンピニングを編集し、プラグインを追加または削除し、ファイルペイロードを置き換えることができます。しかしテンプレートを編集すると、それを使用するすべての将来のジョブに影響します；すでにディスパッチされた進行中のジョブは提出時にキャプチャしたテンプレートのバージョンで継続します。

テンプレートリビジョン間の厳密なバージョン管理が必要なスタジオの一般的なパターンは、クローンしてから編集です：プラグインバージョンを更新する必要があるとき、既存のテンプレートをstudio-archviz-2024-vray6-r2にクローンし、そこで変更を加え、プロジェクトの提出スクリプトを新しいテンプレートを指すように更新します。古いテンプレートは、その正確なスタックに依存する進行中のプロジェクトのために変更されないまま残ります。

一般的な失敗モード

• 「No matching workers — provisioning takes 5-10 minutes.」 これはエラーではなく通知です。スタック変更後の最初のテンプレートジョブはフレッシュなワーカーをプロビジョニングします。同じテンプレートに対する後続のジョブはワーカーがすでにウォームなので即座にディスパッチされます。
• 「Plugin licence unavailable for template.」 指定したプラグインは弊社のホスト型ライセンスカタログにありません。サポートに連絡してください — 主流のプラグインについては通常数営業日以内にホスト型ライセンスを追加します；ニッチなプラグインについてはライセンスを追加するか、提出にライセンスファイルを持参してください。
• 「Renderer version no longer supported.」 古いDCCまたはレンダラーバージョンは定期的にアクティブスタックから廃止されます。テンプレートエディターは保存時にこれを表示します；修正はテンプレートをサポートされているバージョンに更新するか、現在のビルドにクローンして編集することです。
• 「Job dispatched but worker stack does not match template.」 まれですが知っておく価値があります。これが発生した場合、ジョブは事前レンダリングのサニティチェックに失敗し、ファームは確認済みの一致するワーカー上に自動的に再キューします。失敗したディスパッチの試みに対してお金は請求されません。

Troubleshoot Machine

Troubleshoot Machineは本番レンダリングパスに対する診断カウンターパートです。実際のジョブを提出してエラーメッセージで失敗するのを待つ代わりに、Troubleshoot Machine — レンダーノードのソフトウェアスタックと一致するWindows VM — を起動し、Microsoft Remote Desktopを通じて接続します。レンダリングワーカーが見るものを正確に確認し、シーンファイルを開き、失敗しているものを特定し、その場で修正し、修正されたシーンをストレージに保存し直して、確信を持って実際の本番ジョブを提出できます。

どのような問題を解決するか

ほとんどのレンダリング失敗は2つのバケットに分類されます：シーンレベルの問題（欠落しているプラグイン、壊れたアセット参照、ワーカー上のバージョンと互換性のないレンダラー設定）と環境レベルの問題（利用できないライセンス、ロードされないプラグイン、パスの不一致）。どちらもリモートで診断するのは難しいです — 失敗した本番ジョブから受け取る唯一のシグナルはレンダーログで、それはしばしば簡潔です。

Troubleshoot Machineは診断ループを圧縮します。提出 → 失敗 → ログ読む → 推測 → 再提出 → 失敗 → 推測 → 再提出の代わりに、Troubleshoot Machineを起動し、DCCのGUIで実際のエラーを確認し、1回修正して、動作する実際のジョブを提出します。

弊社ファームでの仕組み

Troubleshoot Machineをリクエストすると、ファームは指定したDCC（およびアクティブなRender Node Templateがあればそれ）のための現在のレンダーノードスタックと一致するフレッシュなWindows VMをプロビジョニングします。VMはSRF SpacesストレージをS:ドライブとしてマウントします — すでにアップロードしたプロジェクトファイルは本番レンダリングワーカーと同じように表示されます。ローカルワークステーションからRDP経由で接続します。

VMには時間予算があります — 通常は分単位で計測され、文書化されたレートでレンダリングクレジットに対して請求されます（現在のレートはダッシュボードを確認してください；これは時々変わります）。終わったら切断し、同じプロジェクトから本番ジョブを提出するか、VMを解放します。

Troubleshoot Machineセッションの開始

手順：

1. ダッシュボードから「Troubleshoot Machine」に移動します（またはダッシュボードの同等の項目 — 命名はリリース間で変わる可能性があります）。
2. DCCを選択します — プロジェクトと一致するもの。VMはそのDCCがプレインストールされ、宣言されたRender Node Templateがあればそれと一致してプロビジョニングされます。
3. 時間予算を確認します。 ダッシュボードは1分あたりのクレジットコストを表示します；最大セッション長をコミットし、必要に応じてセッション中に延長できます。
4. プロビジョニングを待ちます。 通常数分かかります — ソフトウェアスタックでフレッシュなVMが準備されています。
5. RDP接続の詳細を受け取ります。 ダッシュボードはホスト名、ユーザー名、パスワード（またはダウンロード可能なRDPファイル）を提供します。Windowsではダブルクリックして接続；macOSではApp StoreのMicrosoft Remote Desktopを使用します。
6. 接続します。 ワーカー上にいます。S:ドライブにはSRF Spacesプロジェクトファイルが含まれています。

セッションの使用

接続後、ワークフローはレンダリングワーカーのところに座っているかのように同じです：

• S:からシーンファイルを開きます。 DCCはテンプレートで指定されたバージョンで起動します、またはそのDCCのファームデフォルトで。
• 失敗を再現します。 本番で失敗していたもの — レンダープレビュー、スクリプトエラー、アセット参照 — はここで再現するはずです。DCCの診断ツールを使って調査してください。
• シーンを修正します。 欠落しているアセットを再リンクし、レンダー設定を変更し、プラグイン参照を修正し、または診断が必要とするものを行います。
• S:に保存し直します。 修正されたシーンをS:\SuperRendersOutput\または SRF Spacesの別のフォルダに保存します。保存は永続的です — Troubleshoot Machineセッションを終了しても、修正されたシーンはストレージに残ります。
• （オプション）VM内から実際のジョブを提出します。 DCCのSuperRendersの提出プラグインはTroubleshoot Machine内にインストールされています；VM内から本番レンダリングジョブを提出し、切断してファームが通常通りレンダリングするのを待てます。

終わったら、RDPから切断しダッシュボードからセッションを終了します。VMは破棄されます；S:に保存したファイルはSRF Spacesに残ります。

一般的な失敗モード

• 「Cannot connect to RDP — connection timed out.」 ローカルネットワークまたはVPNがアウトバウンドRDP（ポート3389）を許可していることを確認してください。一部の企業ネットワークはRDPエグレスをブロックします。この場合は、IT部門にTroubleshoot Machineのホスト名をホワイトリストに追加するよう依頼してください。
• 「RDP credentials rejected.」 ダッシュボードからRDPファイルを再ダウンロードしてください — 認証情報はセッション固有であり、セッションが長時間一時停止されると期限が切れることがあります。
• 「S: drive is empty or missing files.」 ドライブはSRF Spacesにマップされています — ファイルが表示されない場合は、VMがプロビジョニングされたときにSRF Spacesへのアップロードがまだ完了していなかったか、間違ったフォルダを見ている可能性があります。デフォルトマウントは通常S:\<account-id>\です。
• 「Troubleshoot Machineでは修正が機能したが、本番ジョブが依然として失敗する。」 最も多くの場合、本番ジョブがTroubleshoot Machineセッションとは異なるRender Node Template（またはデフォルトスタック）に対して提出されたためです。本番提出のテンプレート選択がTroubleshoot Machineの設定と一致していることを確認してください。

Simulate Local Path

Simulate Local Pathは4つのユーティリティの中で最も小さい範囲ですが、「クラウドでレンダリングできない」プロジェクトの最大の単一カテゴリを解決します。一部のDCCシーンは相対パスではなくハードコードされた絶対パス — 例：C:\projects\studio\my-scene\textures\wood_01.tx — でアセットを解決します。そのシーンがレンダーファームにアップロードされると、絶対パスがワーカー上に存在しないためレンダラーがテクスチャを見つけられません。Simulate Local Pathはその絶対パスを存在させます。

どのような問題を解決するか

このカテゴリの問題に対する直接的な解決策は提出前にシーンを再パスすること — すべてのアセット参照を絶対から相対に切り替える — ですが、一部のワークフローではこれは実用的ではありません：

• Animaシーン（AXYZ Designのアニメーションされた人物プラグイン）はシーン保存時にキャラクターキャッシュファイルへの絶対パスを書き込みます；手動での再パスはキャッシュバインドを壊します。
• Corona Image Editor 4Kキャッシュレンダリングはレンダリング時に同じパスで再び見つけることを期待するレンダラーが絶対パスを書き込みます。
• Substance / Substance Painterエクスポートワークフローはテクスチャソースへの絶対パスを埋め込む場合があります。
• アルンビックアセット参照はDCCのエクスポート設定によっては絶対パスを書き込む場合があります。
• 古いアーカイブプロジェクトですべてのアセット参照を再パスするのが実用的でなく、スタジオはプロジェクトをそのままレンダリングしたい。

これらのケースでは、Simulate Local Pathはファームに指示します：このジョブが実行されるとき、シーンがアセットを期待している場所でレンダラーが見つけられるよう、ワーカー上に絶対パスを再作成してください。

弊社ファームでの仕組み

Simulate Local Pathが有効な状態でプロジェクトをアップロードすると、SuperRenders Client App（または適切な設定を持つWebアップロード）はアップロード時に元の絶対パス構造を保持します。レンダリングワーカー上で、ファームはレンダリング開始前に同じ絶対パスに対応するディレクトリツリーを作成します — シーンファイルがD:\studio-2024\project-x\textures\wood.txを参照している場合、ワーカーはレンダリング時に実際のD:\studio-2024\project-x\textures\wood.txを持ち、シーンは正しく解決されます。

この機能はSuperRenders Client Appの「Auto keep local path」オプションと組み合わせると最も信頼性が高くなります。このオプションはアップロード時に絶対パスを自動的に保持します。Webアップロードの場合は、ファイルをアップロードする前にSRF Spacesフォルダ構造でパス構造を手動で設定します。

Simulate Local Pathの設定

この機能には2つの入り口があります：

SuperRenders Client App経由（推奨）：

1. Client Appで、ファイルをアップロードに追加する前にアップロード設定を開きます。
2. 「Auto keep local path」を有効にします（正確なラベルはClient Appのバージョン間でわずかに変わる可能性があります — パス保持チェックボックスを探してください）。
3. プロジェクトファイルを追加します。 Client Appは追加時に各ファイルの絶対パスを読み取り、アップロードツリーに保持します。
4. アップロードプレビューでパスツリーを確認します。 SRF Spacesの下に完全な絶対パス構造がミラーされているはずです。
5. 通常通りアップロードします。 パス構造はファイルとともに転送されます。
6. 提出時に「Simulate Local Path」を有効にします — ダッシュボードまたはClient Appの提出フォームにはこれのチェックボックスまたはドロップダウンがあります。ファームはワーカー上に絶対パスを再作成します。

Webアップロード経由（手動）：

1. SRF Spaces（アカウントダッシュボード内のWebファイルブラウザ）で、「Create Folder」ボタンを使用して絶対パス構造を手動で再作成します。例えば、プロジェクトがD:\studio-2024\project-x\を参照する場合、D:（文字通り、フォルダ名として）というフォルダを作成し、次にstudio-2024サブフォルダ、次にproject-xなどを作成します。
2. 再作成されたパスツリーにファイルをアップロードします。 各ファイルはSRF Spaces内の一致する絶対パスに置かれます。
3. 提出時に「Simulate Local Path」を有効にします。 ファームはSRF Spacesからパス構造を読み取り、ワーカー上に複製します。

Webアップロードパスはより手動ですが、正しく設定されれば機能します。Client Appはこれを定期的に行うスタジオにとってより速くエラーが少ない方法です。

操作上の注意事項

• ドライブレター。 レンダリングワーカー上で、シミュレートされたドライブ（例：プロジェクトがD:\…を使用する場合はD:）は物理ドライブではなく論理マウントです。マウントはジョブ開始時に作成され、ジョブ終了時に取り除かれます；永続的ではありません。
• パス長の制限。 Windowsには歴史的なパス長制限があります（レガシーアプリケーションでは約260文字）。絶対パスが非常に長い場合、Simulate Local Pathが設定されていてもファイルのロードに失敗するDCCがあります。修正はプロジェクトレベルでパスを短くするか、ほとんどの現在のバージョンがサポートするDCCの長パスサポートを有効にすることです。
• DCC横断のコンポジション。 Simulate Local PathはRender Node TemplateおよびTroubleshoot Machineと組み合わせられます — シミュレートされたパスツリーはすべての3つのコンテキストで同一に表示されます。

一般的な失敗モード

• 「Simulate Local Pathを有効にした後もアセットが見つからない。」 最も一般的な原因はアップロードが実際にはパスを保持しなかったことです。Webダッシュボードでの SRF Spacesを開き、絶対パス構造がそこに存在することを確認してください。存在しない場合は、Client Appで「Auto keep local path」を有効にして再アップロードしてください。
• 「レンダリングが開始するが誤ったテクスチャがロードされる。」 時にシーンが異なるパスに同じファイル名を持つ複数のアセットを持つ場合があります；パスシミュレーションが不完全な場合、レンダラーは同じ名前の別のファイルにフォールバックする場合があります。SRF Spacesで完全なパス構造が保持されていることを確認してください。
• 「シミュレートされたパスでレンダラーがアクセス拒否を報告する。」 これは通常パスがWindowsの予約済みディレクトリ名（con、aux、prnなど）を含んでいて、通常のフォルダとして作成できないことを意味します。予約済み名を避けるためにプロジェクトを再パスしてください。

APIアクセス

Super Renders Farmへのプログラマティックなアクセスはロードマップ上にあります。ジョブ提出、ステータスポーリング、出力取得のためのパブリックREST APIが設計中です；現時点では、ダイレクトインテグレーション用のパブリックAPIエンドポイントは利用できません。

現在のプログラマティック提出ニーズには、サポートされているパスは以下です：

• SuperRenders Client App — デスクトップClient App（）はWindowsとmacOS上のスクリプトから、そのコマンドラインサーフェス（利用可能な場合）またはアップロードディレクトリへのファイルドロップ自動化によって操作できます。確立されたパイプライン自動化ツールを持つスタジオにとって、Client Appは現在のベストプラクティスのインテグレーションポイントです。
• DCC提出プラグイン — DCCごとのプラグイン（3ds Max、Maya、Cinema 4D）はDCC固有のスクリプト環境（MAXScript、Pythonなど）と統合し、すでにDCC内で実行されているパイプラインスクリプトから操作できます。

パブリックAPIがリリースされると、このセクションは完全なAPIリファレンス（認証、エンドポイント、レート制限、SDKの例）に置き換えられます。パイプラインインテグレーションのためにパブリックAPIが必要なスタジオは、サポートに連絡してユースケースを共有してください — ロードマップは実際のパイプライン要件に基づいて情報を得ています。

クロスリファレンス

• — これらのユーティリティなしのデフォルトのアップロード・提出・ダウンロードフロー
• — デスクトップアプリケーションのインストールと使用
• — ブラウザベースの提出フロー
• — 大規模プロジェクトの転送パターン
• — Troubleshoot Machineセッションの料金を含むレンダリングクレジットの課金方法
• — DCC横断トラブルシューティングリファレンス
• — アップロード方法の比較
• 、、 — これらのユーティリティと組み合わせるDCCごとの提出セットアップ

FAQ

Q: すべてのジョブにRender Node Templateが必要ですか？ A: いいえ。ほとんどのジョブはファームのデフォルトソフトウェアスタック — 最も一般的なプラグインを持つ最も一般的なDCCとレンダラーバージョン — でクリーンに実行されます。Render Node Templateは、長期プロジェクト全体でバージョンピニングが必要な場合、またはデフォルトカタログにないプラグインを使用している場合向けです。必要かどうかわからない場合、デフォルトスタックがほぼ常に適切な出発点です。

Q: Troubleshoot Machineセッションのコストはどのくらいですか？ A: Troubleshoot Machineセッションは、セッション開始時にダッシュボードに表示される1分あたりのレートでレンダリングクレジットに対して請求されます。基盤となるVMインフラを更新するにつれてレートは時々変わります；ダッシュボードが常に信頼できる情報源です。典型的な30分の診断セッションでは、単一のフルレンダリングジョブのコストのごく一部を期待してください。

Q: プロジェクトがmacOSまたはLinuxにある場合にSimulate Local Pathを使用できますか？ A: ワーカーのレンダリング環境はWindowsなので、絶対パスはWindowsパス（D:\…形式）としてシミュレートされます。プロジェクトが/Users/…または/home/…形式の絶対パスを持つmacOSまたはLinuxで作成された場合、パスシミュレーションは機能します — ファームはシーンが期待するパス文字列に一致する論理Windowsマウントを作成します — しかし実際にはmac/Linuxで作成されたプロジェクトは通常相対パスを使用するため、このユーティリティは必要ありません。

Q: Render Node Templateはレンダリング時間を追加しますか？ A: 新しいテンプレートに対して提出された最初のジョブは、ファームが一致するワーカーをプロビジョニングする間、数分長くディスパッチに時間がかかる場合があります。同じテンプレートに対する後続のジョブは、一致するワーカーがすでにウォームなのでデフォルトスタック速度でディスパッチされます。テンプレートがアクティブになった後のジョブごとの正味時間はデフォルトスタックと同じです。

Q: ジョブが進行中にRender Node Templateを編集できますか？ A: はい、ただし進行中のジョブは提出時にキャプチャしたテンプレートバージョンで継続します。編集は将来の提出にのみ影響します。より厳密なバージョン管理が必要なプロジェクトには、テンプレートを新しい名前にクローンし、提出スクリプトを既存のテンプレートを編集するのではなく新しいクローンを指すように更新してください。

Q: Render Node TemplateドロップダウンにDCCバージョンがありません。どうすればよいですか？ A: 必要なバージョンをサポートに伝えてください。主流のDCCについては、通常は現在のバージョンといくつかのバックバージョンをホストしています；非常に古いバージョンはアクティブスタックから廃止された場合があります。数日のリードタイムでバックバージョンを追加できることが多く、またはシーンの互換性に最も近いサポートされているバージョンを案内できます。

Q: パイプラインからジョブを提出するために使用できるパブリックAPIはありますか？ A: まだありません。パブリックREST APIはロードマップ上にあります。現在の推奨されるプログラマティック提出パスはSuperRenders Client App（スクリプトから操作）またはDCCごとの提出プラグイン（DCCのネイティブスクリプト環境から操作）です。パイプライン自動化のユースケースが特にパブリックAPIで blocked している場合はサポートに連絡してください — ロードマップは実際のパイプライン要件に基づいて情報を得ており、あなたの入力が優先順位付けに役立ちます。

Q: Render Node Templateに対してTroubleshoot Machineを実行できますか？ A: はい — これはテンプレートが設定されたジョブをデバッグする際の推奨パターンです。Troubleshoot Machineセッションはプロビジョニング時にアクティブなRender Node Templateを読み取り、対応するソフトウェアスタックでVMをプロビジョニングします。本番ワーカーが見るものをテンプレートのプラグインバージョンを含めて正確に確認できます。