Path Traced に設定すると、バウンスあたり最大1本の間接光線が生成されます。 Automatic に設定すると、間接光線の数は、初期ノイズ推定量、ターゲットノイズ閾値、最大カメラ光線数に基づいて計算されます。 さらに Automatic モードでは、直接照明のサンプル数もノイズ推定量に基づいて調整されることに注意してください。

Karmaにライトの均一サンプリングを実行させるのか、または、レンダリングでライトツリーを使用するのかどちらかを指定します。 ライトツリーは、膨大な数のライトを持ったシーンに対して非常に高速にレンダリングすることができます。

一部のライトはライトツリーに追加することができず、すべてKarmaでサンプリングされます:

• Dome Lights

• Distant Lights

• Point Lights

• ライトフィルターを持ったライト

• シェイプコントロールを持ったライト(例えば、スポットライト)

これは、すべてのライトのサンプリング品質を改善するためのグローバルコントロールです。 これは、個々のライト品質コントロールの乗数として作用します。 サンプリング品質を上げると、直接照明サンプリングだけでなく、シャドウ/オクルージョンの品質も良くなります。

光線が部分的に不透明なオブジェクトを通過する時にシェーディングされる透明サンプルの数。 この数を増やすと、部分的に不透明なオブジェクト内のノイズが少なくなり、通常では Pixel Samples , Volume Step Rate , Min Ray Samples , Max Ray Samples を増やすよりも負荷が少ないです。 ただし、このパラメータは、 Indirect Sources からのノイズには何の効果もありません。

光線がボリュームを通過した時にそのボリュームをサンプリングする細かさを設定します。 ボリュームオブジェクトはボクセルと呼ばれる3D構造で構成されており、このパタメータの値は、次のサンプリングを実行する際に光線が通過するボクセル数を意味します。

デフォルト値は0.25で、4個のボクセル毎に1回のサンプリングが実行されることを意味します。 1の値はすべてのボクセルがサンプリングされ、2の値はすべてのボクセルが2回サンプリングされることを意味します。 つまり、この Volume Step Rate 値は、ピクセルサンプルと同様の挙動をし、ボリュームオブジェクトに対するサンプル総数の乗数として作用します。

Volume Step Rate を上げるとレンダリング時間が劇的に長くなるので、必要な場合にのみ調整するように注意してください。 また、デフォルト値の0.25よりも大きな値にするとボリュームノイズを軽減することができますが、1を超えた値ではそんなに結果が変わらなくなります。

ディフューズ光線がシーンを伝搬できる回数。

Reflect Limits や Refract Limits と違って、このパラメータは、シーン内の全体のライトの量を増やし、グローバルイルミネーションの大部分に寄与します。 このパラメータを0より大きく設定すると、Diffuseサーフェスは、直接光源に加えて、他のオブジェクトからのライトも蓄積します。

この例では、 Diffuse Limit を上げて、最終画像の見た目に劇的な効果が出ています。 現実的な照明環境を模倣するには、 Diffuse Limit を上げる必要があることが多いです。 とはいえ、ライトの寄与度は通常ではDiffuseバウンス毎に小さくなるので、 Diffuse Limit を4よりも大きく上げても、シーンでの視覚的な忠実性の改善はほとんどありません。 さらに、 Diffuse Limit を上げると、ノイズレベルとレンダリング時間が劇的に増える可能性があります。

光線がシーン内で反射できる回数。

この例では、2つの鏡の間に配置した被写体を使った典型的な“鏡のホール”のシナリオを載せています。

これは、無限に続く反射を効果的に作成しています。

このカメラ角度では、その反射制限が非常にわかりやすく、最終画像の精度に大きく影響していることがわかります。 しかし、ほとんどの場合では、その反射制限を巧妙に調整することで、シーン内の反射の数を減らすことができ、レンダリング時間を最適化することができます。

光源がオブジェクトで一度反射すると、それを直接反射と見なされることを覚えておいてください。 そのため、 Reflect Limit を0に設定しても、まだ光源のスペキュラー反射が見られます。

このパラメータは、光線がシーン内で屈折する回数を制御します。

この例では、10個のグリッドすべてが1列に並んだ単純なシーンを載せています。

屈折のあるシェーダを適用することで、それらのグリッドを通じて、背景の夕焼けの画像を見ることができます。

このカメラ角度では、画像の精度を良くするためには、屈折制限をシーン内のグリッドの数に合わせなければなりません。

しかし、ほとんどのシーンでは、この数の屈折オブジェクトすべてが一列に並ばないので、最終画像に影響を与えずに屈折制限を下げることができます。

この Refract Limit は、オブジェクトの数ではなく、光線が通過しなければならないサーフェスの数を参照していることを覚えておいてください。

光源がサーフェスを一度屈折すると、それを直接屈折と見なされることを覚えておいてください。 そのため、 Refract Limit を0に設定しても、まだ光線の屈折が見られます。 しかし、シーン内のほとんどのオブジェクトは、最低でも2枚のサーフェスを持つので、その光源と直接屈折が最終レンダリングではあまりわからないことが多いです。

ボリューム光線がシーンを伝搬できる回数。これは Diffuse Limit パラメータと同じように動作します。

Volume Limit パラメータを上げると、よりリアルなボリューム効果が得られます。 これは、特にボリュームの一部のみが直接照明を受けている状況で顕著です。 さらに、ボリュームオブジェクトが他のオブジェクトからの間接照明を受けるためには、 Volume Limit パラメータを0よりも大きく設定しなければなりません。

Volume Limit を0より大きい値に設定すると、Fogボリュームは、ボリュームを通過するライトから、あなたが求めている独特の光の散乱を行ないます。 しかし、 Diffuse Limit と同様に、一般的には、ライトの寄与度は、光線が跳ね返る度に小さくなるので、4より大きい値を使用しても、目で見てわかるほどに現実的な画像になるとは限りません。

また、このパラメータの値を上げると、ボリューム画像のレンダリングに費やされる時間が劇的に増える可能性があります。

SSS光線がシーン内を伝搬することができる回数。 これは、 Diffuse Limit パラメータと同様の方法で動作します。

非常に明るい光源のサンプリング不足によって引き起こされる“蛍”の出現を軽減するためにシェーディングサンプルがLPE画像平面に寄与できる最大値。

有効にすると、間接バウンスは Color Limit パラメータの値を使用し、 Indirect Color Limit パラメータを無視します。

間接バウンスのみに適用されるカラー制限。

光線処理数に基づいて確率的に間引かれ始める間接光線の深さ。

被写界深度レンダリングを有効にします。

明示的にオピニオンが設定されていないオブジェクトに対してモーションブラーを有効または無効にします。 これを On by Default に設定すると、以下のパラメータをデフォルトに設定することができます。

シャッターオープン時間に対して トランスフォーム モーションブラーをレンダリングする時に計算するサンプル数。 デフォルトは2サンプル(シャッター時間の開始と終了)で、1つのセグメントにブラーがかかります。

極端に速く移動したりと方向を変更するオブジェクトの場合、サブフレームでの方向の変更を取り込むためにサンプル数を上げる必要があります。

上図の例では、1フレーム内で発生した複雑な動きを正しくレンダリングするために40個のトランスフォームサンプルが必要です(1フレーム内でのこの変化量は、非常に稀で、説明をするために使用しただけです)。

トランスフォームブラーは、各オブジェクトのフレーム間のトランスフォームを補間することでブラーをシミュレーションしているので、計算が軽いですが、表面の変形を取り込みません。 変形ジオメトリのブラーを有効にするには、karma:object:geosamplesを上げます。

シャッターオープン時間に対して 変形 モーションブラーをレンダリングする時に計算するサブフレームのサンプル数。 デフォルトは1サンプル(シャッター時間の開始のみのサンプル)で、デフォルトでは変形ブラーは ありません 。 高速に変形するジオメトリを適切にブラーさせたい場合、この値を2以上に上げなければなりません。

“Deformation”は、ジオメトリ(SOP)レベルでトランスフォームだけを参照したり、キャラクタやフレームに応じて形状が急速に変化するオブジェクトなどの実際の表面の変形を参照することができます。

1フレーム内で複雑に変形するオブジェクトには、Geo Time Samplesの数を上げる必要があります。

変形ブラーは、シャッター時間内の アトリビュート値の変化 もブラーさせることができます。 例えば、オブジェクトが移動した時にポイントカラーが急変化する場合、そのCdアトリビュートにブラーをかけることができます。

Geo Time Samplesの数を上げると、Karmaの使用メモリ量に 影響を与えてしまします 。 サンプル数が増える度に、Karmaはシャッター時間の間にサンプリングしている間はメモリ内にそれだけのジオメトリのコピーを維持しなければなりません。 レンダリングを最適化する時、滑らかなモーションの軌跡を生成するのに必要な最低限のGeo Time Samplesを調べることは良い考え方です。

Velocity Motion Blurが有効なオブジェクトでは、変形ブラーは無視されます。

このパラメータでは、オブジェクトに対して実行する ジオメトリVelocityブラー のタイプを選択することができます。 トランスフォームブラー や 変形ブラー とは別に、時間と共に変化するポイントに保存されたアトリビュートを使って、ポイントの動きに応じたモーションブラーをレンダリングすることができます。 ジオメトリ内のポイント番号が時間と共に変化する場合(例えば、ポイントが誕生したり死亡するパーティクルシミュレーション)、このタイプのブラーを使用してください。

フレーム間でジオメトリのトポロジーが変化する場合、Karmaはジオメトリを補間できなくて正しくモーションブラーを計算できなくなります。 そのような場合、元のジオメトリが変化しても整合性のあるvelocitiesやaccelerationsのアトリビュートをモーションブラーに使用することができます。 流体シミュレーションのサーフェスがまさにそのよい例です。 この場合と他のタイプのシミュレーションデータでは、ソルバが自動的にVelocityアトリビュートを作成します。

これを“Velocity Blur”または“Acceleration Blur”に設定すると、変形ブラーがオブジェクトに適用されなくなります。 これを“Acceleration Blur”に設定すると、karma:object:geosamplesプロパティを使用して、加速度サンプルの数を設定することができます。

インスタンスに対してモーションブラーを定義すると、プロトタイプで発生するモーションブラーだけでなく、各インスタンスのトランスフォームにもブラーをかけることができます。 このオプションは、各インスタンスのトランスフォームのモーションブラーの計算方法を制御します。 例えば、プロトタイプをパーティクルシステム上にインスタンス化した場合、Velocityブラーを使用してモーションブラーを計算したいことでしょう(パーティクル上のVelocityによってプロトタイプのトランスフォームにブラーがかかるようになります)。

ボリュームに対してモーションブラー量を軽減または誇張する際に使用されるVelocity乗数。

ポイントクラウドをレンダリングする時、カメラの方を向いた円盤、球、法線アトリビュートの方を向いた円盤としてレンダリングすることができます。

カーブをレンダリングする時、カメラの方を向いたリボン、両端を丸めたチューブ、ポイントに追加された法線アトリビュートの方を向いたリボンとしてレンダリングすることができます。

USDは、Houdiniで直接対応できていないCurve Basisタイプに対応しています。 時には、HoudiniのCurve Basisをオーバーライドしたいことがあります。 例えば、Houdiniの直線カーブをBezier、B-Spline、Catmull-Romのどれかの基底を使ってレンダリングしたい時です。 このメニューは、KarmaがUSD Primsに関連付けられている基底をオーバーライドするようにします。

有効にすると、カメラに背いているジオメトリはレンダリングされません。

この値を上げると、コースティクスの精度は悪くなるもののノイズを少なくすることができます。

このノードの2番目の入力からRenderVar Primsを検索し、そのRenderVar Primsをこのステージに追加するので、生成するRender Varsのリストにそれらが追加されます。 これによって、他のLOPノード(例えば、Background Plate)は自身のノードに関連したRender Varsを生成するように“提案”することができます。

このノードの2番目の入力からRenderProduct Primsを検索し、そのRenderProduct Primsをこのステージに追加するので、生成するRender Productのリストにそれらが追加されます。 これによって、他のLOPノードが自身のノードに関連したRender Productを生成するように“提案”することができます。

ピクセルに対するサンプルの分布を指定します。 Boxフィルターは、個々のピクセルの内側に対してランダムにサンプルを分布します。 Gaussianフィルターは、ピクセルの中心を基準とした円盤内に(均一な分布の代わりに)Gaussian分布でサンプルを分布します。

これは Pixel Filter のサイズです。 フィルターサイズが1.8のGuassianフィルターは、フィルターサイズが2.0のGaussianフィルターよりも若干ぼかしが弱くなります。

これを有効にすると、レンダラーは、タグが付けられたライト毎に追加でAOVを作成します。 ライトのLPE Tagを管理するには、LPE Tag LOPを使用します。

完了した出力画像に対して実行するデノイザ、または、 No Denoiser を選択します。 現在のところ、このユーティリティは、Intel Open Image Denoise(Houdiniに同梱されています)とNVIDIA OptiX Denoiser(別途インストールする必要があります)に対応しています。 これを動作させるには、対応しているプラットフォームを確認し、選択したデノイズライブラリをインストールしてください。

NVIDIA OptiX DenoiserはNVIDIAカードでのみ動作します。 このデノイザは今ではNVIDIAドライバ(バージョン435以降)に含まれています。

一部のデノイズライブラリは、アルベドを利用して画像をもっと上手く知覚し、ノイズを軽減する方法と場所を補助することができます。

一部のデノイズライブラリは、法線を利用して画像をもっと上手く知覚し、ノイズを軽減する方法と場所を補助することができます。

???

デノイザを適用するAOVをスペースで区切ったリスト。

OCIO画像フィルタを様々なRender Vars/画像平面に追加することができます。

以下で定義したOCIO画像フィルタを有効にします。

OCIO画像フィルタが適用されるRender Varの名前。

画像フィルタが適用するOCIOカラー出力空間を指定します。

たいていの場合、ここはdataのままにします。 AOVのソースが既に定義済みのカラー空間であった場合では色が変になることがあります。 そういった場合、ここでソース空間を指定することができます。

完了した画像に適用するLookをスペースで区切ったリスト。 “Look”は名前が付いたOCIOカラートランスフォームのことで、通常ではアーティスティックな効果を表現するためにあります。 詳細は、OCIOドキュメントを参照してください。

Color Limits は、シェーディングサンプルがLPE画像平面に寄与できる値を制限して、極端に明るい光源のサンプリング不足によって引き起こされる“Fireflies(ホタル)”の見た目を軽減します。 このマルチパラメータでは、Render Var毎に別々に制限を適用することができます。

以下で定義されたカラー制限サンプルフィルタを有効にします。

このカラー制限が適用されるAOV名をスペースで区切ったリスト。

シェーディングサンプルがこれらのAOVに寄与できる最大値。

出力画像のアスペクト比( Resolution の幅を高さで割った値)がカメラの絞りのアスペクト比(カメラのアトリビュートで制御)に一致しなかった場合の挙動。 これによって、カメラを切り替えた時に標準レンダラーが妥当な挙動をするようにすることができます。

出力画像全体のうち、このウィンドウ内だけをレンダリングするようにレンダラーに指示します。 このウィンドウは、正規化された0から1の範囲の値でminX, minY, maxX, maxYで指定します。 0, 0座標は左下、1, 1座標は右上、0.5, 0.5座標は中心を示します。 デフォルトは0, 0, 1, 1(クロップなし)です。

このウィンドウを使用することで、一時的にレンダリングをテスト用に小さい領域に クロップ することができます。

そのデータがウィンドウ内に 完全に収まっている 場合のみピクセルがレンダリングされます。

正規化された座標は、 Aspect Ratio Conform Policy で調整された 後 の画像にマッピングされます。

画像 ピクセル ( 画像自体 ではありません )のアスペクト比(幅/高さ)。 デフォルトの1.0は、正方形ピクセルを意味します。

画像ファイルを作成した人、部署、スタジオの名前。 このノードは、画像フォーマットがメタデータに対応している場合に(例えば、exr)、出力画像にこのフィールドを設定します。

任意のコメント。例えば、出力画像の用途の説明を入れます。 このノードは、画像フォーマットがメタデータに対応している場合に(例えば、exr)、出力画像にこのフィールドを設定します。

この出力ファイルを生成したコンピュータの名前。 このノードは、画像フォーマットがメタデータに対応している場合に(例えば、exr)、出力画像にこのフィールドを設定します。

.exr出力ファイルに適用する圧縮のタイプ。

これを有効にすると、Karmaは、BSDFサンプリング分布に依存しない代わりに、プリパスレンダーを実行してシーン内のすべての箇所で入力ライトのおおまかな評価を構築し、その情報を使用して間接ディフューズ光線をガイドします。 これによって、(コースティクスやほぼ間接照明といった)“難しい”ライティングを改善することができますが、“簡単に”ライティングノイズが発生します。 これを使用する前に、Direct系AOVとIndirect系AOVをレンダリングしてノイズの箇所を確認すると良いでしょう。 そのノイズの多くが直接照明によって発生している場合、パスガイドを有効にしても意味がありません。

Indirect Guiding を有効にした時にプリパスレンダーに使用されるピクセルサンプル数。 推奨する最低ピクセルサンプル数は、 Convergent Mode が Path Traced の場合だと Pixel Samples の10%、 Automatic の場合だと Pixel Samples と同じ数になります。 この数が少なすぎて十分なデータが収集されなかった場合、グリッド状の乱れが最終レンダリングで発生する可能性があります。 この数を64以上に維持するのを推奨します。

レンダリングする時、Pixel OracleはKarmaにどのピクセルを追加でサンプリングする必要があるのか、どのピクセルが集中しているのかを伝えます。 このパラメータは、使用するPixel OracleをKarmaに伝えます。

各ピクセルのカメラ光線(プライマリサンプル)の最小数。

バリアンス(差異)の測定に使用するAOV。

もっと多くの光線を発動させるバリアンス量。

バリアンスサンプリングにはランダムさが必要です。 この数を変更することで、若干異なる結果が得られます。

バリアンスを測定する前にOCIOトランスフォームをピクセルに適用するかどうか。

OCIO Transform が Display View の時、バリアンスを測定する前に変換するディスプレイ。

OCIO Transform が Display View の時、バリアンスを測定する前に変換するビュー。

OCIO Transform が Explicit の時、バリアンスを測定する前に変換するカラー空間。

これを有効にすると、Karmaは画像タイルデータを定期的にチェックポイントファイルへ書き出します。 レンダリングが完了する前にプロセスが強制終了した場合、 Resume From Checkpoint を有効にしてプロセスを再起動することで、レンダリングを再開することができます。

Output Checkpoint Files が有効な時、書き出し先のチェックポイントファイルの名前を設定します。 デフォルト($HIP/render/$HIPNAME.$OS.$F4.checkpoint)では、2つのプロセスが同時に同じチェックポイントファイルを使用しないように、現行シーンファイルのディレクトリのrenderディレクトリ下に、ファイル名に現行シーンファイルのベース名($HIPNAME)とこのノードの名前($OS)とレンダーフレーム($F)を含んだチェックファイルを書き出します。

Output Checkpoint Files が有効な時、Karmaは、チェックポイントファイルを書き出す際にここで指定した秒数だけ待機します。 デフォルトは60です。

これが有効な場合にレンダリングを開始して、レンダラーが有効なチェックポイントファイルの存在に気づくと、そのレンダラーはそのチェックポイントからレンダリングの再開を試みます。 最初からレンダリングをやり直したいのであれば、これを無効にするか、または、単にチェックポイントファイル(s)を削除してください。

Karmaはレンダリングをするために画像を複数のバケットに分割します。 これは、その正方形バケットの1辺の長さ(単位はピクセル)です。 デフォルトの32は、32 x 32ピクセルのバケットが指定されます。 スレッドはバケット単位で動作するので、部分的に負荷の大きいバケットが数個しかない時にバケットサイズを小さくすると役に立つ場合があります。 そうすることで、負荷の高い領域をもっと多くのスレッドに分割することができます。

例えば、画像内のほとんどが空っぽなものの、1個の32×32バケット内に収まる遠方のオブジェクトが存在した場合、そのオブジェクトは1スレッドのみを使用してレンダリングされることになります。 16×16バケットに切り替えれば、そのオブジェクトが4個のバケットに分割され、4つのスレッドでそのオブジェクトを処理させることができます。

バケットサイズを変更しても結果が変わらないのが理想ですが、Karmaは現行バケット内のピクセルからバリアンス(分散)を測定するため、 バケットサイズを例えば4とか低いサイズに下げると、4 x 4 = 16ピクセルしか見なくなるので、Karmaは非常に精度の悪いバリアンス評価を行なう傾向になります。 これによって正しくないバリアンス評価が原因でピクセルレンダリングが途中で終了してピクセルをブラックとして表示してしまう可能性があります。

最初にレンダリングされるバケットを指定します。指定可能な値:

固定サイズのキャッシュ(karma:global:cachesize)を使用するのか、物理メモリの割合(karma:global:cacheratio)を使用するのか指定します。

Karmaが統一キャッシュに使用する物理メモリの割合。

例えば、vm_cacheratioがデフォルトの0.25で、物理メモリが16GBであれば、 Karmaは統一キャッシュに4GBを使用します。

この統一キャッシュには、レンダリングで使用される動的でアンロード可能なデータ(以下のデータを含む)が格納されます:

• 2D .ratテクスチャタイル

• 3D .i3dテクスチャタイル

• 3D .pcポイントクラウドページ(メモリに事前ロードしない時)

統一シェーディングキャッシュの明示的なメモリ上限。 これは廃止され、代わりに Cache Memory Ratio を使用してください。

画像のレンダリング方法を決めます。

バケットモードでレンダリングする場合( Image Mode を参照)、ここには、バケットモードに切り替える前に画像に対して実行するプログレッシブパスの数を指定します。

エクスポート用に計算されるシェーディングコンポーネント名をスペースで区切ったリスト。 マテリアルで新しいコンポーネントラベルを定義していた場合、それらのラベルをこのリストに追加することで、コンポーネント単位のエクスポート平面にそれらのラベルをエクスポートすることができます。 いくつかのコンポーネントを使用しないのであれば、リストからそれらを削除することでレンダリング効率を上げることができます。

PBRライトエクスポートは、このリストがすべてである(つまり、シェーダで生成されるすべてのコンポーネントがリストされている)と想定します。 リストに挙げられていないコンポーネントがあった場合、ライトエクスポートは、それらのコンポーネントからの照明を見逃してしまいます。

ディフューズバウンスのような挙動をするコンポーネントタイプをスペースで区切ったリスト。 これは、光線タイプに基づいて使用される反射スコープに影響し、使用するバウンス上限にも影響します。 カテゴリ化されていないコンポーネントタイプは、反射とみなされます。

屈折バウンスのような挙動をするコンポーネントタイプをスペースで区切ったリスト。 これは、光線タイプに基づいて使用される反射スコープに影響し、使用するバウンス上限にも影響します。 カテゴリ化されていないコンポーネントタイプは、反射とみなされます。

ボリュームバウンスのような挙動をするコンポーネントタイプをスペースで区切ったリスト。 これは、光線タイプに基づいて使用される反射スコープに影響し、使用するバウンス上限にも影響します。 カテゴリ化されていないコンポーネントタイプは、反射とみなされます。

サブサーフェススキャタリングのような挙動をするコンポーネントタイプをスペースで区切ったリスト。 これは、光線タイプに基づいて使用される反射スコープに影響し、使用するバウンス上限にも影響します。 カテゴリ化されていないコンポーネントタイプは、反射とみなされます。