チェックポイント&リカバリー

チェックポイント&リカバリー

images/chkPool10m.png

10分でのチェックポイント

images/chkPool20m.png

20分でのチェックポイント

images/chkPool30m.png

30分でのチェックポイント

PRManには、中断したレンダーを再開する機能があります。 この挙動は、使用しているモードによって異なります。 TIFFやOpenEXRの画像を出力するNon-Incrementalレンダーは、常にリカバリーすることができます。 OpenEXR画像を出力するIncrementalレンダーもリカバリーすることができますが、チェックポイント機能が使用されている場合に限られます。


チェックポイント

チェックポイントは、バッチレンダリングを実行する時のIncrementalレンダリングモード固有の機能です。 Incrementalモードでは、レンダラーは画像に対してパスを繰り返して作成し、各パスを使って少しずつ画像を精密化します。 初期のパスでは画像にかなりのノイズが発生しますが、最終画像がどのように見えるのか感じをつかむのには十分です。

チェックポイントとは、レンダラーが処理する時の画像の状態を保存するスナップショットです。 普通の画像として閲覧することが可能ですが、通常よりは若干大きいです。 これは、そのレンダーをリカバリーするためにレンダラーが必要とする特別な情報が埋め込まれているからです。 レンダーが何らかの理由で中断されたり、失敗した場合、レンダラーは最後のチェックポイント画像からレンダーを再開することができます。 レンダーが終了した場合は、その特別な情報は、最終バージョンの画像を書き出す時に削除されます。 チェックポイントの作成には、主に2つの方法があります:

1つ目は、定期チェックポイントです。 これは、インクリメント(つまり画像に対するパス)の数または経過した実測時間のどれかで測定されるインターバルによって指定することができます。 例えば、レンダラーに対して、100iのインターバル、つまり100の増分毎にチェックポイントを書き出すように要求すると、 100番目、200番目、300番目などといったインクリメントの時にレンダーの状態をディスク上の画像に付けて更新します。

他には、インターバルを300sに設定すると、レンダラーは、フレームで作業を始めてから約5分毎に画像を更新します。 この時間には、レンダラーの起動時間、例えばRIBの解読やプロシージャルの解決、レイトレースの高速化構造の構築などを含みます。 結果として、最初のチェックポイントまでのインクリメント数が、それ以降のチェックポイントよりも少ないことがあります。 便宜上、時間ベースのインターバルは、秒、分、時間、日数をそれぞれ意味するs,m,h,dの接尾辞を付けて指定することもできます。 例えば、360s6m0.1hのインターバルはすべて同じ時間を意味します。 接尾辞の代わりに、プラスの数字だけを指定すれば、それが秒であると想定され、マイナスの数字はインクリメント数として解釈されます。

チェックポイントの頻度には、バランスがあります。チェックポイントの頻度が上がれば、レンダーが失敗した時の作業の損失が少なくなります。 とはいえ、チェックポイントをあまりにも頻繁に書き出すと、レンダラーの効率が下がることにもなります。 インクリメント毎または秒毎にチェックポイントを書き出す試みは、一般的には良い考えとは言えません。 特に、適応ノイズサブプレッサーは、各チェックポイント間で少なくとも2,3のインクリメントを必要とします。

チェックポイントを生成する2つ目の方法は、合計レンダー時間(定期チェックポイントと同じ表記で指定)に制限を設けることです。 レンダーは、タイムリミットに到達するまで、いつものように進行し、そのリミットポイントで現在のインクリメントを終了して、チェックポイント画像を書き出し、フレームのレンダリングを停止します。 レンダリングするフレームが複数ある場合、このポイントから次のフレームへ単純に進みます。つまり各フレームには独自のタイムリミットを設定することができます。

チェックポイントを生成するこれら2つの方法は、一緒に使用することができます。 例えば、15分経過するまで、100インクリメント毎にチェックポイントを書き出すようにリクエストすることが可能です。 そのポイントで書き出された定期チェックポイントは、終了時に最終のチェックポイントに置換されるだけです。

尚、チェックポイントはディスク上の画像へバッチレンダリングすることを想定して設計されています。 "it"のようなライブのフレームバッファへのレンダーは、レンダリングの進行にともない、瞬時に更新されます。 内蔵のディスプレイドライバの中では、現在のところTIFFOpenEXRのドライバのみがチェックポイントに対応しています。

チェックポイントは、オプションまたはオプションの-checkpoint引数をprmanへ渡すことで指定することができます。


リカバリー

中断したリカバリーは、レンダーを開始する時にprman-recover 1オプションを渡すことで有効になります。 PRManは、その後、いつものようにシーンをロードしますが、0から開始して既存の画像を上書きするのではなく、画像を検査して中断した箇所を判断します。 これがうまくいくと、中断したポイントに近いところからレンダーを続けます。 反対に、画像が終了していたり、画像が見つからなかったり、何かしらの理由で現行シーンと一致しなかったりすれば、そのまま最初から開始します。

レンダーを開始したマシンと同じレンダーマシンでレンダーをリカバリーする必要はありません。 PRManのプロセスがまだシーンファイルで指定した画像を見つけることができ、その画像の整合性が合っていてリカバリー可能な状態であれば、レンダーを再開することができます。

リカバリーは、上記のチェックポイントのオプションと組み合わせることもできます。 タイムリミットの場合、リカバリーは基本的に元のタイムリミットの拡張として機能します。 Incremental(増分)レンダーは、このような方法で任意の数のタイムスライスに分割することができます。 尚、各リカバリーにはリロードするシーンとそのアセットすべてを必要とするため、この作業には注意が必要です。 さらに、この機能は、OpenEXRにのみ対応しています。


ワークフロー

チェックポイントとリカバリーの最も基本的な使い方は、レンダーが失敗した場合にレンダーを再開できることですが、Incremental(増分)レンダーとチェックポイントを組み合わせると、何か強力な新しいワークフローを構築することができます。

例えば、シーケンスフレームにtimelimitオプションを使用すると、ドラフトアニメーションを作成することができます。 ラフなバージョンをすぐにレンダリングして、それをplayblastで確認してから、承認後に最終レンダリングへ続けることができます。 ラフなバージョンで既に費やしたレンダー時間が無駄にならないため、最終バージョンの開始が有利になります。 タイムリミットとそのレンダリングの作業負荷と利用可能なレンダーサイクルとのバランスに注意して配慮することで、決められた締切(例えば、午前中での確認のために一晩でレンダリング)内でplayblastを使用できるようにします。

もう1つの可能性は、レンダーファームのスタジオ規模のタイムリミットの柔軟性です。 例えば、24時間のタイムリミットを超えるレンダーをただ打ち切るのではなく、チェックポイントで終了するデフォルトタイムとしてタイムリミットを設定すると、規定時間を超えたレンダーをレビューして、現行の状態を受け入れるか、レンダーを再開することができます。