・V-Rayのバケット最適化について

・V-Rayのバケット最適化について

V-Rayでプロジェクトをレンダリングしたことがある人なら、誰でもこの厄介なバケットの停滞に遭遇したと思います。画像の小さな部分のためにレンダリングの完了に長い時間がかかるか、むしろまったくレンダリングが完了しないというような状態で、下の画像のようになります。

バケットが停滞した画像

画像の左上部分(白い建物の上の木のあたり)には、レンダリングされていない2つの「バケット」があります。 実際には、これらの部分はまだレンダリング中かもしれませんが、時間がかかり過ぎています(画像の他の部分は数時間前に終了している可能性があります)。 または、これらの問題の部分によってレンダリングが完全にクラッシュした可能性があります。

なぜこんな問題があるのでしょう。では、あなたは自分の敷地の芝生を刈っているとしましょう。 芝刈り機を持ってきて、芝生を横切って草を刈り始めます。

バケットの停滞を芝生を刈るに例えた図

芝生全体の刈り取りはほぼ完了しましたが、頑固な草が生えているエリアに出くわしました。 その部分に何度芝刈り機を走らせても草を刈り取ることができず、一日中芝刈り機をそのエリアで稼働させましたが刈り取ることができません。 あなたはその最後の部分のためだけに時間を無駄にし、そしてもし芝生を刈るために時給制で誰かを雇っていたなら、お金も無駄にします。

V-Rayの停滞しているバケットは、この頑固な草の群れにようなものです。 レンダリングの時間を浪費する可能性があり(締め切りに間に合わなくなる可能性があります)、さらに悪くすると、クラウドレンダーファームでレンダリングしている場合は予算を浪費する可能性があります。

どうすればこれを回避できるのでしょう。この質問に答える前に、まずバケットとは何か、レンダリングにおけるバケットの役割は何かを知っておきましょう。

バケット入門編

バケットとは、V-Rayのバケット画像のサンプラーを指します。 これは、画像がバケットと呼ばれる長方形の断片に分割されるレンダリングの一種です。

レンダリングの一種であるバケット

これは画像をバケットに分割した後、バケットが特定の順序で画像を1つずつレンダリングすることを意味します(これについては後で詳しく説明します)。 使用しているCPUプロセッサのコアまたはスレッドごとに1つのバケットを取得します。

バケットが特定の順序で画像を1つずつレンダリングする

レンダリングにガレージファームなどのレンダーファームを使用している場合は、より多くのプロセッサにアクセスできるため、同時に画像をレンダリングするバケットが増え、レンダリング時間が短縮されます。 この説明がよくわからないという場合は、レンダリングとCPUコアの関係について詳しく説明した、レンダーファームとは?という記事から詳しく知ることができます。

バケットはレンダリング時間に影響を及ぼす

バケットは基本的にピクセルの集まりです。 また、実行したテストによると、バケットサイズが大きいほど(つまり各バケットのピクセル数が多いほど)、レンダリング時間が速くなります。

なぜそうなるのでしょう?これには一般原則を伴ういくつかの理由があります:

  • バケットは画像の一部をレンダリングする前にデータをロードおよびアンロードし、これには時間がかかります。 バケットサイズが小さい場合はバケットサイズが大きい場合に比べて、各バケットがこれを何度も実行する必要があり、その時間が加算されます。
  • レンダリング時に画像全体を保存するのに十分なRAMがない場合、バケットサイズが小さいほど遅延を悪化させ、レンダリング時間が長くなります。
  • バケットが画像をスキップするレンダリングパターンを選択すると、バケットサイズが小さいために発生する遅延がさらに悪化します。

簡単に言うと、バケットサイズを1または2ピクセルに設定することはお勧めしません。 しかしそうは言うものの、小さいバケットサイズは、問題である停滞するバケットを解決することができます(ただし、バケットあたり1〜2ピクセルほど小さくすることはありません)。

上級者向けのヒント:クラウドレンダーファームで高解像度の静止画像をレンダリングする際、問題を回避するには、バケットサイズ(256または512ピクセル)を大きくする前に、まず画像が単一ノードでレンダリングされるかを確認してください。 よくわからない場合は、デフォルトの小さめの48ピクセルを使用することをお勧めします。

バケットのサイズと形状に関する簡単なまとめ

我々がテストした結果に基づき、バケットサイズを2の累乗(512 = 2x2x2x2x2x2x2x2x2)または2の累乗の3倍(48 = 3x2x2x2x2)の数値に設定することをお勧めします。 数学的でコンピューターサイエンスな感じになりますが、これを行うと、CPUの計算効率が向上し、レンダリング時間が短縮されます。

また、V-Rayはデフォルトでバケットの形状を正方形に設定します。 私たちは非正方形のバケット形状に対してテストし、正方形のバケットは、非正方形よりも高速にレンダリングされました。したがって、非常にまれなケースを除いて、デフォルトのバケットの形状を変更する必要はありません。

さまざまなレンダリングシーケンス

V-Rayでは、ユーザーがバケットがレンダリングを開始する場所と、その開始点からレンダリングする順序を選択できます。 さまざまなシーケンス/パターンとそれらの長所と短所、およびレンダリング時間への影響を次にご紹介します。 これらのレンダリングシーケンスは、後に停滞するバケットを解決する役割を果たすため、理解しておくことが重要です。

左から右へ

バケットは画像の左側からレンダリングを開始し、次に右側に進みます。 長所:画像に変更を加えたい場合はいつでもレンダリングをキャンセルでき、それからPhotoshopで画像の完成した部分から、後でレンダリングされた画像の変更された部分へステッチできます。これらは通常横長で出力されるため、建築ビジュアライゼーションの画像に最適です。

上から下へ

バケットは画像の上部からレンダリングを開始し、次に下部に向かって進みます。 長所は左から右へのシーケンスと同じです。

三角測量

これはV-Rayのデフォルトです。 レンダリングを開始する新しいバケットは、完成したバケットに近くなります。画像からデータのアンロードとロードを繰り返す必要が少なくなるため、レンダリング時間が短縮されます。 長所:速度。 短所:停止して変更を加えたい場合、部分的にレンダリングされた画像は使用できません。

ヒルベルト曲線

三角測量と同様の方法ですが、異なるパスに従います。 速度も効率化されています。 また、レンダリングを停止して変更を加えようとした場合、使用できない部分的な画像が生成されます。

スパイラル

レンダリングは中央から始まり、バケットは外側に向かってらせん状に進みます。 長所:プレビューやレンダリングされた画像を素早く確認するのに適しています。 短所:レンダリングが中央の開始点から進んで遠くなるにつれて、バケットが画像全体でスキップするため、レンダリング時間が遅くなります。

チェッカー

レンダリングは交互のバケットで行われ、チェッカーボードのように画像を細分化します。 長所:レンダリングされた画像のクイックプレビューを確認でき、正確なレンダリング時間の見積もりを提知ることができます。 短所:レンダリングを停止すると部分的な画像は使用できなくなり、レンダリングに時間がかかる場合があります。

マウスフォロー

バケットがマウスが指す画像の部分をレンダリングします。 長所:画像の特定の部分をプレビューできます。 短所:効率が悪く、クラウドレンダーファームでは使用できません。

バケットが停滞する原因

ではここから、厄介なバケットの停滞をどうすべきかについて話していきましょう。 レンダリングが永遠に終わらない、またはまったくレンダリングできなくなるバケットを取得してしまう、一般的なの理由は次のとおりです。

技術的なエラー

これらのエラーは、3D画像のジオメトリの破損(不均一もしくは反転した法線、結合されていない頂点、貧弱なサードパーティモデル/プラグイン効果)、サポートされていないシェーダーまたはレイ、シーンのバウンディングボックスが大きすぎる、シーンが原点から遠すぎる、 またはソフトウェアのバグなどが関係しています。

シーンの複雑性が高い、または品質設定が高すぎる

画像の複雑な部分をレンダリングするのに十分なRAMがないと、バケットが停滞する可能性があります。 シーンのサンプリングセット(高マテリアル設定、モーションブラー、コースティクス、またはDOF設定)が高すぎる場合、または、光沢のある反射のループに変わる表面を持つオブジェクト、もしくは屈折(たとえば、車のヘッドライトと 車の合金ホイール)がある場合もバケットは停滞する可能性があります。 バケットは、シーン外の壊れた/問題のあるオブジェクトを反映しているオブジェクトをレンダリングしようとしても問題が発生する可能性があります。

シャーロックバケット:バケットが停滞する原因を見つける

停滞しているバケットを修正する前に、まず何が原因であるかを特定する必要があります。 停滞するバケットには2つのケースがあります。

  • バケットが全くレンダリングされない。 これは通常、技術的なエラーが原因で発生します。
  • バケットは時間を置いてからレンダリングされる。 これは通常、複雑性の高さ/高度な設定が原因で発生します。

バケットがまだレンダリング中であるか完全にフリーズしているかを判断するには、バケットのCPU使用率を確認する必要があります。

  • 停滞しているバケットのCPUコアの容量が10%未満の場合は、技術的なエラーが原因である可能性があります。
  • CPUコアの容量が10%〜100%の場合、シーンにさらにRAMが必要である可能性があります。
  • CPUコアの容量が100%の場合、複雑性が高いことが原因です。

停滞しているバケットが完全にフリーズしている(技術的なエラー)か、レンダリングに時間がかかる(複雑な設定が原因)かを判断するためにできるもう1つの方法は、最終的な画像の1/10解像度でレンダリングを試すことです。 この小さいバージョンの画像が15分以上レンダリングされる場合は、画像に重大な問題(技術的なエラー)があり、そのエラーに対処しない限りレンダリングが終了しないことを意味します。

停滞しているバケットに対する処置方法

それでは、どう対処していくべきかについて説明しましょう。 技術的なエラーが原因でバケットが停滞するする場合、残念ながら、他のレンダリングプロセスであるプログレッシブイメージサンプラーを試す以外に、V-Ray内でできる対処法はありません。 技術的なエラーが原因で停滞するバケットを修正する方法は、レンダリングの問題の原因となっている壊れたモデルやシェーダーを修正または削除することです。 壊れたジオメトリを最初から修正する方が速い場合があります。

壊れているオブジェクトをどのように見つければいいのでしょうか。問題の原因となっているオブジェクトはシーン内ではなく、シーン内にあるオブジェクトの1つに反映されている可能性があります。

壊れているオブジェクトを見つける方法

問題の原因となっているオブジェクトを特定するには、シーンオブジェクトの半分を削除してから、テストレンダリングを実行して、レンダリング時間に変化があるかどうかを確認します。 このプロセスを繰り返して、削除されたオブジェクトを元に戻し、オブジェクトのサブセットを毎回削除して、問題のあるオブジェクトを最終的に特定することができます。 このビデオの7分18秒のあたりでこの方法について説明しています。

FOV(視野)外側で壊れたオブジェクトを発見したら、それを修正、削除、またはモデルし直すことができます。

高品質の設定によって引き起こされるバケットの停滞を解決する方法に移りましょう。 レンダリングに時間がかかるバケットに対してできる操作を次に紹介します。

  • シェーダーのサンプリング設定を最適化する。
  • 反射または屈折の数を減らす。
  • 視野(FOV)の外側にあるが、FOV内の反射で表示される長いレンダリングオブジェクトを削除する。
  • 小さいバケットサイズを使用する。 これにより、より多くのCPUコアを利用して、ハンギングバケットをレンダリングできるようになります。 ただし前述のように、バケットサイズを小さくするとレンダリング速度が低下しますが、少なくとも画像を修正する必要はありません。 これは公平な条件下の状況での方法である、これに関しては上のビデオの10:00あたりで紹介されています。
  • 適切なレンダリングシーケンスを使用する。 停滞するバケットが画像の左側にあるとしましょう。 バケットが画像の左側から始まる、”左から右へ”のレンダリングシーケンスを使用できますこのように、画像の複雑な部分をレンダリングするバケットは、画像の残りの部分がレンダリングされているときにレンダリングを終了できます。停滞するバケットが画像の中央近くにある場合は、”スパイラル”のシーケンスを使用してみます。詳しくは、上のビデオの11分05秒からをご確認ください。
  • 「バケットの開始点をロックする」というオプションを使用する。 この方法は上記の方法と似ていますが、ここではマウスを使用して、開始点をより具体的に設定することができます。 このオプションに関しては、上のビデオの12秒07秒でマークで確認できます。
  • 長いレンダリングの部分で終了するようにシーケンスを設定しする。 これは上記の方法とは反対の方法で、V-Rayの自動バケット分割システムで機能します。

というわけで、厄介な停滞するバケットの対処方法を見ていきました。 自分で問題に対処する自信がない場合は、ガレージファームには24時間年中無休のサポートスタッフがいますので、クラウドファームでのレンダリング中にバケットが停滞した場合はいつでもチャットで相談できます。ですのでバケットが停滞して時間とお金を無駄にする心配の必要はありません。 私たちがサポート致します。

関連記事

live chat