レンダーファームは最終レンダーだけのためのものではありません。 パイプラインの最後でしかファームを使っていないなら、膨大な生産性向上のチャンスを見逃しています。
レンダーファームは、CGチームが重い計算処理（コンピュート負荷の高いジョブ）をサーバー群に投入し、アーティストの作業ステーションを「実際の創造的な作業」に専念させるための仕組みです。問題は、多くのスタジオがそれを“最後に最終ショットをレンダリングするため”にしか使うことを思いつかない点にあります。
その結果、パイプラインのより早い段階でボトルネックが発生し、苛立つアーティストが自分のマシンの作業待ちを強いられ、納品が遅れることになります。
解決策はシンプルです：もっと早い段階で、より頻繁に作業をファームへ投入しましょう！この記事では、CG制作においてレンダーファームをより有効に活用するためのヒントを紹介します。
1. モデリング＆ルック開発のレンダー
ハイポリメッシュや複雑なテクスチャで素材をテストする作業は、作業ステーションを何時間も占有してしまうことがあります：
- ルック開発の提出用に、ファーム上で軽量な「テストレンダー」ジョブキューを用意する
- DCC（Maya、Blender、Houdini）からシーンを離れることなく直接提出できるようにする
- テストレンダーが制作ショットと競合しないよう、専用の低優先キューを維持する
ルック開発のレンダーはKitsu上でタスクとして記録できます。これにより、スーパーバイザーはSlackでプレビューを追いかけるのではなく、適切なバージョニング付きの素材テストを確認できます。
2. テクスチャベイク
複雑な素材をシンプルなテクスチャにベイクするには、単一のアセットであっても、複数の長いレンダーパスが必要になることがあります：
- テクスチャベイクを、アーティストが自分のマシンで一晩走らせるような作業ではなく、第一級のファームジョブとして扱う
- 関連するアセットをまとめてベイクし、セットアップの手間を減らす
- ベイク済み出力を、名前付き＆バージョン管理された場所に保存し、下流部門が常に最新を見つけられるようにする
Kitsuで「Texture Bake（テクスチャベイク）」という専用タスクタイプを作成してください。アーティストは提出時にIn Progress（進行中）をマークし、ファームが完了したらDone（完了）にします。これにより、アセットチームはリグやシェーディングに向けて何が準備できているかをリアルタイムで把握できます。
3. アニメーションキャッシュ生成
アニメーターは素早く試行錯誤し、多くのバリエーションが必要です。各キャッシュ（フレームごとの頂点座標）の計算には、数分から数時間かかることがあります：
- キャッシュ生成はローカルで計算するのではなく、すべてをファームへ回す
- アニメーションファイルが公開されたときにキャッシュが自動的にトリガーされるよう、ファームのジョブ依存（dependency）システムを活用する
- 古いキャッシュはバージョン管理しておき、アニメーターが再計算せずにロールバックできるようにする
Kitsuのリビジョンシステムを使えば、キャッシュのジョブを特定のアニメーションタスクのリテイクに紐づけられます。スーパーバイザーが変更を要求した場合、新しいキャッシュバージョンがそのリビジョンに対して追跡されるため、「どのキャッシュがどの指摘に対応しているか」の混乱が起きません。
4. FXシミュレーション
FXシミュはほとんど並列化できません。単一のコアで長時間動作するだけです。ファームは1つのシミュを劇的に速くすることは難しいかもしれませんが、アーティストのマシンを占有せずに同時に多数の作業を回せるようになります：
- FXアーティストが選択肢を試したいと思った瞬間に、シミュのバリアントを別ジョブとして投入する
- 探索（exploration）用のシミュには低優先キューを使い、承認済みの方向性には高優先枠を確保する
- 承認されたシミュのバージョンを記録し、下流のコンポジットで参照できるようにする
Kitsuのタスクコメント機能により、FXリードは特定のシミュ提出に対して直接ノートを付けられます。フィードバックが適切なバージョンに紐づいた状態を保てます。
5. プレビュー＆プレイブラスト生成
検証（バリデーション）ステップごとにレビュー可能なプレビューを生成するには、数十分かかることがあります。それがアーティストのマシンをブロックしてしまうなら、アーティストはスキップするか、遅くまで待機することになります。代わりに：
- プレビュー生成をポストパブリッシュの手順として自動化する。アーティストが新しいバージョンを公開するたびに、ファームが自動でプレビューを生成する。
- プレビューが完了した瞬間に、制作追跡ツールへ直接配信する。
- プレビュー形式（解像度、コーデック、フレームハンドル）を標準化し、レビュー担当者が常に比較可能な出力を見るようにする。
Kitsuはまさにこの用途のために作られています。アップロードされたプレビューを受け取り、関連するタスクとバージョンに直接紐づけます。ファームがレンダリングを終えると、API経由でプレビューをKitsuへそのまま送れます。これによりスーパーバイザーは通知を受け、すぐに注釈を付けられます。
6. 最終ショットレンダリング
レンダリングの優先度を管理するのは難しいです。「全部が緊急」だと、効率よく進むものがなくなってしまいます。
- 制作マネージャーと協力し、クランチ（逼迫）に突入する前に、ショット締切をレンダリング優先度へマッピングする
- 緊急のリレンダー用にファーム容量の一部を確保する。探索的な作業で枠を埋め切らせない
- ファームの稼働率を定期的に監視する：クランチ中にアイドル状態のノードがある場合、パイプラインの問題のサインです
Tip: Kitsuのスケジューリング／優先度ビューを使って、レンダーファームの優先度を実際のショット締切に合わせましょう。スーパーバイザーがKitsu上でショットを「高優先度」に引き上げた場合、そのシグナルはパイプライン連携を通じて自動的にファームマネージャーへ伝播させることができます。
7. コンポジット
- コンポジットレンダーを、最終用途だけでなくコンポワークフローの標準手順としてファームへ投入する
- コンポジョブのテンプレートを用意し、アーティストが毎回ファーム提出を手作業で設定しなくて済むようにする
- コンポ出力をレンダリングと同じやり方でバージョン管理する
Kitsu上のコンポタスクは、ライティング部門からコンポジターへの引き渡しポイントを明確にします：ライティングがKitsuでショットをDone（完了）としてマークしたら、通知が届き、承認されたレンダーレイヤーを使ってファーム提出を開始できます。
The Hidden Problem: Managing the Workload
あなたが制作のあらゆる段階でファームを使い始めると、次の新しい課題に直面します：ジョブが多すぎるのに可視性が足りない。 レンダーファームは、かなりのネットワーク帯域とストレージを消費します。人はファームが扱える以上の投入を行いがちになり、優先順位付けは技術的な問題であると同時に、政治的な問題にもなります。
そこで効いてくるのが、制作追跡とパイプラインのツールです。Kitsu を使うと：
- 全部門にまたがるタスク状況の単一の真実の情報源
- プレビュー管理：レビューの会話が正しいバージョンで行われるようにする
- API連携：ファームマネージャーを制作データへ接続する
- オープンソースの柔軟性：パイプラインチームが、使用しているファームソフトに合わせて組み込める
