可変バケット分割がV-Rayのレンダリングをどのように高速化するか

最新のV-Ray 5 for 3ds Max アップデートでは、バケットレンダリングがこれまでになく高速になりました。 Chaos社の巧妙なアルゴリズムがこの古くからのレンダリング手法の問題をどのように解決したかを解説します

最新のV-Ray 5 HotFixでは、Chaos社のR&Dチームが、バケットレンダリング誕生と同時に発生した問題「最終バケットシンドローム」を解決しました。新しいバケットレンダリング方法は、V-Ray 5 for 3ds Max Update 2、Hotfix 3 （Build 5.20.03）以降で利用可能であり、近い将来他のV-Ray製品でもサポートされます。

バケットレンダリングには、プログレッシブにない無いいくつかの長所があります。バケット方式ではワークロードの分散がより容易になり、Dynamicオブジェクト/MipMapによりメモリの使用量が少なくできます。しかしながら、バケット方式にはよく知られている1つの大きな問題であるいわゆる「最終バケットシンドローム」が存在します。

タスクのサイズと複雑さが不明な仕事をマルチスレッド分散する事は、マルチタスク・コンピューティングに理論上の問題が存在します。

各バケットは単一のCPUスレッドによって計算されます。その為、利用可能なスレッド数よりも残りバケットが少なくなると、残りのスレッドがアイドリング状態のままになるため、CPU使用率は最適ではなくなります。

「最終バケットシンドローム」の名前の由来は、常にレンダリングの最後は１つのバケットの処理になってしまう事です。場合によっては最後の小さな正方形の領域だけでも、イメージの他の場所よりも時間がかかる場合があります。この最終バケットの計算が終わるまで他のスレッドは空いた状態になります。

残念ながら、これは一般的によく起こるシナリオです。3Dのレンダリングは画像全体で複雑さが不均一であるためです。たとえば「空」の部分は「地面」の複雑な状態よりも速くレンダリングされます。また小さく非常に明るいハイライトがある部分では、目的のノイズしきい値に適切に収束させる為に多くのサンプルが必要になります。

バケットレンダリング誕生から時間の経過と共に、「最終バケットシンドローム」を緩和するアプローチが開発されてきました。これは一般に、計算するエネルギーを広く拡散する方法であり、クリーンな結果に収束しやすくなります。例えば、レンダリングの終盤にバケットサイズ自体を小さくするアプローチです。しかし、これらのいずれも、特にレンダリングの終わりが近づくにつれて、バケットレンダリングの効率が最適でなかったという事実から逃れることはできず、単一のバケットでスタックする問題を修正することはできませんでした。

提案

ユーザーとプログラマーの両方が、長年にわたってこの難問に取り組んできました。
Chaosフォーラムでユーザーが提案したいくつかの回避策を次に示します。

バケットを小さくする：

バケットを小さくすると、最新の多コアCPUで役立ちます。ただし、バケット間のアーティファクトを無くす為バケットエッジを2回計算する必要があり、バケットが小さいほどエッジが多くなるため負荷コストも高くなります。そして、結局、最後のバケットがスタックしていると、まったく役に立ちません。

マウスを追跡：

最終バケット問題はマウスカーソルをフォローするレンダリングのバケット順序変更でわずかに軽減できますが、ユーザーがレンダリング画像のどの部分の計算に時間がかかるかを事前に知っている場合に限ります。
この提案は、アニメーションやまったく新しいシーンのレンダリングには適用できません。

しきい値の分割：

ワークロードを最適化するもう1つの方法は、イメージの終盤で残っているバケットを小さなバケットに分割することでした。

これはコアの占有率を高く維持するのに役立ちますが、明度の激しい画像には不向きで、分割された小さなバケツの一つ一つが完成しても、最後の大きなバケットでスタックしたままになってしまう事があります。

Light Cache を使用する:

レンダリング負荷の難しい問題は、未知（計算しないと分からない）の問題の解決策を見つける事にあります。そのため、例えばLightCacheを使用して、その問題を事前に調べておく試みが行われました。

残念ながら、プリパス（LightCache）を使用して画像のどの部分に最も時間がかかるかを把握することは理想的ではありません。LightCacheはサンプリングが十分に高くなく、ノイズしきい値に達していないため、最終レンダリングの負荷を調査する品質を持っていません。

スタックしたバケットの停止・再分割レンダリング：

「最終バケットシンドローム」問題は非常に深刻な場合があり、ハングしたバケットを停止して再起動するという提案が考慮されました。

これは理想的ではありません。すでに計算されたサンプルは途中で破棄される為、特に終了に近いバケットを停止して再起動する場合、レンダリングがさらに長くなる可能性があります。このアプローチのさまざまなバリエーションが検討され、それらはすべて1つ以上の側面で最適ではありませんでした。

前のフレームの使用：

特にアニメーションでは、前のフレームを使用して、次のフレームで計算するのに最も時間がかかる領域を見つける方法が提案されました。

残念ながら、フレーム間の連続性は保証されておらず、レンダリングに時間がかかる新しいパーツが次のフレームに表示される可能性があり、それを検知できるアニメーションフレームがまったくない可能性があります。

新可変バケット分割の利点

データが破棄されることはないため、バケットを分割することは常に安全です。

バケットの分割はアイドル状態のスレッドがある場合にのみ発生するため、常に理想的なタイミングで処理されます。

レンダリングされる画像の負荷が分からなくても分割が行われるため、シーンの内容やレンダリング時間に関係なく、作業負荷を最適に分担することができます。

一般的な結果として、レンダリング時間が短縮されます。これはシーンとCPUのコア数によって異なります。

現在の所、新しいアルゴリズムが古い分割アルゴリズムよりも遅いケースはまだ測定されていません。

制限

この手法でも、個々のバケット（最終的にはピクセル）がシングルスレッドで処理されます。これは運が悪いと最も時間がかかる部分が最後の1ピクセルである場合、1つのスレッドのみがその部分で作業できる事を意味します。スタックしたバケットのサイズは1ピクセルになりますが、それでも「最終バケットシンドローム」が存在し理論的には計算に長い時間がかかる可能性があります。

この新バケット分割アプローチは現在、ローカルレンダリングでのみ実行可能であり、ディストリビュートレンダリングには適用されません。これは、ネットワークトラフィックを低く抑えるために、DRでは異なるアプローチが必要になるためです。

これらの制限を緩和するための研究が進行中です。

ワークフローの変更

この手法はユーザーに対して完全に透過的であり、シーンの設定をまったく変更する必要はありません。また、マウスのフォローや領域のレンダリング機能と併用した場合でもうまく機能します。領域レンダリングの場合、バケットサイズを変更して小さなリージョンに合わせる必要はもはやありませんが、マウスフォローは、ユーザーの操作に関係なく残りのバケットを自動的に分割します。

この改良により、大きなバケットサイズを使用しても問題がなくなりました。ただし、最初のバケットサイズが大きすぎると、他の欠点が生じる可能性があるので、大きすぎないようにしましょう。要するに、画像をより効率的にマルチスレッド処理させる為に小さなバケットサイズを選択する必要はもはやありません。新しいアルゴリズムは、デフォルト（またはそれ以上）のバケットサイズで最適なパフォーマンスを発揮します。バケット分割は、被写界深度やモーションブラーのバケットサンプリングに関する問題も解決します（小さなバケットではサンプルの欠落の可能性が高くなるため）