クラウドレンダリングで、時間とお金、ストレスを最小化し、収益の可能性を最大化できます。
目次
このガイドのパート１では、さまざまなオンラインファームの種類、クラウドレンダリングサービスのワークフロー、一般的なコストと時間の見積もり手順、およびレンダリング前に必要な準備について説明しました。
パート２では、オンラインファームにおいて非常に重要なテスト方法について詳しく説明します。
1、シーンを少し変更するだけで全く異なるシーンになる
レンダーファームからすると、少しでも変更されたシーンは別のシーンになります。小さな変更により、稀に時間とコストに予期しない変更が発生する場合があります。
そのため、まず事前にファームでシーンのテストを実行することが重要です。小さなプロジェクトをたくさんレンダリングする場合はあまり意味がないかもしれませんが、大きなプロジェクトの際は小さな変更でも、再確認することをお勧めします。
注意：
ファームは、シーンをユーザーのローカルPCでレンダリングするのとまったく同じようにレンダリングすることを重視しています。ご自分の環境でレンダリングに問題がある場合は、レンダーファームでも正しくレンダリングされない可能性があります。
2.テストの重要性と問題把握
レンダーファームを問題なく使用するために、全範囲のアニメーション、またはフル解像度の静止画をレンダリングする前に、ファームでテストを実行して下さい。テストがそこまで重要なのにはいくつか理由があります。
テストすることにより事前に費用感を把握でき、潜在的問題も発見できるので、万が一問題が発生した場合でもすぐに解決して正常にレンダリングすることができます。
ただし、レンダーファームのワークフローがどれほどシンプルであっても、それでも問題が発生する可能性はあります。
問題が発生する可能性の原因として以下があげられます：
- ファームとまったく同じビルドの3Dソフトウェアを使用することはできません。
- 一部のソフトウェアの機能は、グラフィックユーザーインターフェイスからは正常に機能しますが、ファームで使用されるコマンドラインレンダリングまたはネットワークレンダリングオプションからは同じように機能しない場合があります。
- すべての3Dソフトウェアには多少のバグがあり、レンダーファームで修正できる場合とできない場合があります。（レンダーファームのサポートチームが対応できても時間がかかる場合があります）
補足
レンダーファームのサポートチームが問題に気付けることがありますが、プロジェクトを最もよく知っているのはあなたであり、フレームがPCでのテストとまったく同じかどうかを確認できるのはあなただけです。
もし上記のような問題の可能性があったとしても、テストを事前に行うことにより、時間とお金を浪費する心配なく問題を回避できます。
メモ
以下のテスト方法は、一般的にレンダーファームの見積りシステムで使用されている方法です。サーバーをレンタルしたり、自宅のコンピューターでレンダリングするときにも使用できます。
3.ステップごとにテストする
本番レンダリングの前に、1つまたは複数のアニメーションのフレームをテストすることで、正確なコストの見積もりを得ることができ、本番レンダリングの前にシーケンス全体の品質を確認することができます。
ステップでテストを行うことにより、フレーム範囲全体を均等に確認でき、すべてのアニメーションのパーツとそのレンダリング時間を計算できます。
例： 1〜400のフレーム範囲をレンダリングする場合は、20フレームごとにステップとしてレンダリングするため、20個のテストフレームがシーケンスに沿って均等に分散されます。
この範囲から1フレームの平均コストを取得し、それをシーケンス内のフレーム数で掛け算すると、アニメーション全体のレンダリングコストの見積もりが得られます。
この範囲から1フレームの平均レンダリング時間を取得し、それにフレームの総数を掛けると、すべてのレンダリングの合計時間が得られます。多くのノードがレンダリングしているため、プロジェクトのレンダリングのリアルタイムは比例して短くなります。
例： ステップ20で100フレームのテストをレンダリングしたとして、コストが$ 0.90、$ 1、$ 1、$ 1、$ 1.10の5つのテストフレームを取得した場合、フレームあたりの平均コストは1ドルなので、範囲全体のレンダリングには約100ドルかかります。
補足
いくつフレームをテストすればいいですか？
基本的に、全範囲から少なくとも20フレーム毎にテストすることをお勧めします。範囲が長い場合は、ステップの間も長くなるため、より多くのフレームが必要になります。100フレームよりも大きくなる場合は、見積もりが不正確になる可能性があります。テストでは20フレームごとにレンダリングすることをお勧めします。
補足
優先度のを選択するテストに時間をかけたくない場合は、テストの優先度を”高”にし、範囲全体を本番レンダリングする際に優先度を”低”にしてレンダリングしてください。テストのコストは本番レンダリングのコストのほんの一部です。テストに問題がなければ、本番レンダリングでテストフレームをスキップできます。
4.フリッカー/ノイズテスト
すべてのレンダリングエンジンは、特に品質設定が低すぎる場合に、ノイズなどのアーティファクトを生成する可能性があります。グローバルイルミネーションのキャッシュを作成するGIソリューションは染みになる可能性があり、ブルートフォース/ QMC /パストレーシングエンジンは、ノイズを伴う可能性があります。
これらの影響はフレームごとに分布が変化するため、静止画像よりもアニメーションで顕著になります。これは、すべてのフレームが異なるコンピューターでレンダリングされる分散レンダリングにおいて、それぞれGI計算の方法が少し異なるためです。
本番レンダリングの前に5〜20の連続するフレームの「フリッカーテスト」を実行し、適切にアニメーション化されるか確認することをお勧めします。
場合によっては、問題を取り除くためにGIのベイク/プリキャッシュが必要になります。大抵のファームは、一般的なイラディアンスキャッシュのGIソルバーの自動キャッシュをサポートしていますが、コンピューターで生成されたキャッシュを使用することもできます。
レンダリング能力が十分でない場合は、ファームのサーバーの1つにリモートアクセスし、GIベイク処理（または他の種類のキャッシュ）を準備できます。
補足
キャッシングシミュレーション
最も安全にすべての種類のシミュレーションをレンダリングするには、「ロード」モードのプロジェクトにリンクされているプリキャッシュのファイルを使用します。 一部のシミュレーションアプリケーションには別のオプションはありませんが、シミュレーションを「オンザフライ（事前準備なし）」でレンダリングする場合でも、事前にキャッシュされたファイルのレンダリングはネットワークレンダリングにおいてより安定しています。 キャッシュフォルダが大きすぎてアップロードに非常に時間がかかる場合は、ファームのノードをレンタルして、ファーム側でキャッシュを生成できます。
5.静止画のテスト
静止画像がレンダーファームでどのようにレンダリングされるか、またそのコストとレンダリング時間の見積もりを取得するには、最初に低解像度でテストをすることをお勧めします。
このテストに基づき、フル解像度の見積りを算出できます。
たとえば、最終的なレンダリングが2000x2000pxになる場合、500x500pxでテストを実行します。最終的な費用の見積もりは、テストの費用の約16倍になるので、テストの解像度が1 / 4〜1 / 5を下回らないようにすることをお勧めします。
さまざまな解像度でレンダリングされた静止画像のレンダリング時間は、常に直線的にスケーリングされるとは限りません。 そのため、静止画像のテストは、ステップを使用したアニメーションのテストほど正確ではない場合があります。
レンダーファームのすべてのレンダリングプロセスは、解像度に依存しない部分と以下の2つの部分に分かれます。
たとえば、ライトキャッシュ+イラディアンスマップを使用したV-Rayレンダリングの場合、解像度に依存しない部分は次のとおりです。
- プロジェクトをノードにロードする
- 3Dアプリケーションで開く
- 前処理時間（ジオメトリの準備、事前レンダリング）
- ライトキャッシュの計算（変位に十分なRAMがある場合）
解像度に比例してレンダリング時間が増加する部分は次のとおりです。
- 放射照度マップの計算
- 最終レンダリング
- 出力の保存
- 多くのRAM、特にディスプレイスメントを必要とするシーンの機能
低解像度でのテストの場合、見積りにどのように影響するか見てみましょう。
低解像度テストでは、解像度とともにレンダリング時間が急速に増加するため、最終的な見積り結果が、実際の静止画像の本番レンダリングの時間とコストよりも低く算出される場合があります。
いくつかの例をご紹介します。
- V-Rayの解像度に基づくディスプレイスメントを使用したライトキャッシュレンダリング
- 高品質のぼやけた反射があるシーンや、お互いに反射し合っているもの（車の反射によるスポイラーシーンなど）
- ぼやけた反射またはSSSの複数のレイヤーがあるシーン。
- 解像度に応じた品質設定を使用するシーン
オンラインレンダーファームを使用する際に、毎回このように細かく計算を掘り下げる必要はありませんが、静止画のテストは解像度に正比例する関係にあり、スケーリングできませんので、テストの解像度を低く設定しすぎないようにしてください。
補足
コストと時間の見積もりが誇張される可能性があるので、解像度は1/5を下回らないようにしてください。 できるだけ大きな解像度でテストを実行するのが理想的ですが、１/2の解像度でのテストはレンダリングとコストがかかってしまう可能性があります。 一般的には、最終解像度の1/4でのテストが最適です。
補足
長いレンダリングの反射のために小さなバケットを設定するバケットレンダリングでは、複雑なシェーダーや高品質の光沢のある反射など、時間のかかる部分において最後のバケットが非常に長く留まる場合があります。 特にレンダーファームで、初めて静止画の最終解像度をレンダリングするときに発生する可能性があります。 そのような複雑な部分がプロジェクトにあることが事前にわかっている場合は、非常に小さいバケットサイズでレンダリングすることをお勧めします。 最適化が必要な場合（反射や屈折の数を減らすなど）がありますので、 詳細についてはバケットレンダリングのガイドをご覧ください。
6.低解像度でのアニメーションテスト
通常、低解像度でテストを行うより、ステップを使用してアニメーションをテストすることをお勧めしています。理由は前述した静止画像のテストと同様で、低解像度でのテストはアニメーションのプレビューの確認や、クライアントに提示する素材としてのみ使用できます。
フレームが小さい場合、本番レンダリングの準備が全てできているかどうかを判断するのに十分な情報が得られない場合があります。ステップでのテストよりも費用がかかり、加えて、本番レンダリングの際にこのフレームを使用することはできません。
補足
プログレッシブレンダリングの制限を使用する
プログレッシブレンダリングを使用して画像をレンダリングする場合、レンダリングを停止するタイミングをエンジンが認識できるように制限を設定する必要があります。最良のオプションは、ノイズまたはパス制限を使用することです。レンダーファームは、ほとんどの場合、コンピューターとは異なるパワーのノードでシーンをレンダリングします。コンピュータと同じ制限時間でレンダリングする場合、マシンよりも高速なノードは同じ時間をレンダリングするため、画像の品質は向上しますが、必要以上にコストがかかる可能性があります。遅いノードは、指定された時間内にコンピューターでレンダリングされたフレームの品質レベルに達しない場合があります。
左側：ハードドライブのネットワーク、右側：ファイルサーバー、ライセンスサーバーなどの管理サーバーを備えたラック。
7.時間の見積もりと優先順位
フレームを取得する時間は、プロジェクトのボリュームや使用されているノードの数などだけに依存しないため、より注意が必要です。また、その時点でのファームの負荷にも依存するため、動的に変化します。
大抵のレンダーファームでは、価格のバランスを取り、ニーズに合わせてスピーディーにレンダリングするために優先順位の選択を提供しています。優先度によって、プロジェクトに割り当てられるノードの数と、ジョブが待機キューのどこに配置されるかが決まります。
補足
特定の優先度で見積もりのテストをした場合、それらは同じ価格の倍数であるため、別のコストを計算するのは非常に簡単です。
8.まとめ
レンダーファームは究極の時間節約であり、高価なコンピューターネットワークに投資したくない人にとっては最適のソリューションです。社内に独自のファームを所有するスタジオでさえ、さらに多くの計算能力を必要とすることがあります。
他のサービスと同様に、本番レンダリングをする前にレンダーファームをテストすることをお勧めします。シーンはご自身のコンピュータと違う環境でレンダリングされるため、レンダリング中にいくつかの問題が発生する可能性があります。レンダーファームのコスト計算ツールで大まかな見積もりを取得できますが、技術的な観点からもプロジェクトのテストを実行することをお勧めします。
・アニメーションのテストにはステップを使用し、静止画像のテストは低解像度で実行することで、本番レンダリングの正確な見積もりを得ることができ、シーンがファームのネットワークで適切にレンダリングのされるか事前に確認できます。
・いくつかの連続したフレームをテストすることにより、プリキャッシュGIを使用しないアニメーションでの、ちらつきを回避することができます。レンダリング時間はその都度変わりますが、ジョブ管理ツールを使用すれば必要に応じて優先度を簡単に変更できます。
ご不明な点がございましたら、経験豊富なサポートチームが喜んでお手伝いしますので、いつでもご連絡ください。
このガイドのワークフローとヒント、制作や他の作業の効率アップに繋がれば嬉しいです。
ハッピーレンダリング！
参考文献：
- Elisa Bertino, James B.D. Joshi ( Eds.) ‘Collaborative Computing: Networking, applications and Worksharing’
- https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose
- 自身の経験とテスト
- ウィキペディア
参考リンク
- https://rentrender.com –オンラインレンダーファームオプションの長期的に更新されているリスト。
- https://www.maxon.net/en/products/cinebench/ –CPUベンチマークツール
- https://render.otoy.com/octanebench/ –GPUベンチマークツール
- https://garagefarm.net/blog/speed-up-your-renders-in-3ds-max/ –シーン最適化ガイド–ジオメトリ
- https://garagefarm.net/blog/guide-rendering-optimizing-scenes-3ds-max –シーン最適化ガイド–テクスチャ
- https://garagefarm.net/blog/quickstart-guide-how-to-render-at-garagefarm-net-render-farm –クラウドレンダーファームーGarageFarm.NETのクイックスタートガイド
- https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/ –クラウドレンダリングサービスの種類について
クレジット
このガイドはMichałMoś（ミハウ・モシ）によって書かれ、GarageFarm.NETのチームの助けを借りて編集されました。
（元記事：
）
ここでご紹介している知識は、10年以上レンダーファームを運営してきた、彼の豊富な経験に基づいています。
MichałMoś（別名Andrew）はGarageFarm.NETのメンバーで、アニメーションやトラブルシューティングからテクニカルライティングまで、3Dレンダリングのトピックを専門としています。彼は、CGアーティスト、デザイナー、インストラクターとして、数多くのデザインおよび建築会社に従事していた経験も持ち、主に 3ds Max、C4D、V-Ray、Octaneを使用しています。絵を描くこと、執筆、そしてテーブルRPGが趣味です。
参考文献：
https://michalmos.carbonmade.com
https://blog.garagefarm.net/