| On this page |
前項 モーションブラー
概要 ¶
この章では、KarmaとUSDにおけるマテリアルの概念について、さらには、すぐにでも使えるようになるためのヒントをご紹介します。
Tip
とりあえず マテリアルを使ってKarmaを始めたいのであれば、クイックマテリアルをご覧いただき、後で詳しい内容を知りたくなったら、この章に戻って来てください。
Karmaのマテリアル構築は考え方としては簡単で、これまでHoudiniでMantraまたはその他のレンダラーを使ってきた人なら特にそうです。
マテリアルを作成するには、
Material Library LOP内でVOPネットワークを接続します。
Houdiniは、VOPノードをUSD Material Primに変換し、それらをジオメトリに割り当てます。
レンダリング時に、HydraはそれらのプリミティブとマテリアルをKarmaに送信します。
Material Library LOPの中に入ると、マテリアルビルダー系のノードとツールが利用可能になります。 これによって、VOPネットワークがUSDデータをもっと正確にミラーリングできるようになります。 また、Tabメニューに、ほとんど互換性のない膨大な数のオプションが表示されないようにすることが容易になります。
ビルダーのクィックスタート ¶
-
Material Library LOPを作成します。
-
そのノードの中に入って、 Karma Material Builder を作成します。
-
そのサブネットノードの名前を“quickstart_material”に変更します。
-
親のLOPネットワーク(つまり、
/stage)に戻ります。 -
Assign Materialを先ほど作成したMaterial Libraryノードに接続します。 -
Assign Materialノードで Primitives をいくつか選択し、 Material Path を
/materials/quickstart_materialに設定して、マテリアルを割り当てます。
MaterialXサポート ¶
詳細に入る前に、KarmaのMaterialXサポートとそれがアーティストのマテリアル構築にどのような影響があるのか説明しておく価値があります。 KarmaはMaterialXシェーダをサポートしていますが、MaterialXのコード生成には依存していません。 代わりに、KarmaはUSD内に記述されているMaterialXノードのシェーダネットワークを読み込んで、その場でレンダラー用のマテリアルを構築しています。 このおかげで、Karmaは、Karma用ノードまたはUSD Previewノードを使用して、MaterialXで不足している機能を補うことができています。
たいていの場合、アーティストは、Karma用の新規マテリアルを構築する時は Karma Material Builder から始めるべきです。 独自のKarma用ノードも慣例もない“純粋な”MaterialXネットワークを構築できるように、“USD MaterialX Builder”は、その純粋な仕様の範囲内に対応しているMaterialXノードのみを提供します。
USDマテリアル ¶
USDのマテリアルは異なるレンダラーをターゲットにすることができます。 プリミティブが持つことができるマテリアルバインドは1つだけですが、その1つのマテリアルが様々なレンダーコンテキストに対応することができます。 そのレンダリングコンテキストは、異なるレンダラーのシェーダだったりシェーディング言語に該当します。
Karmaはいくつかのレンダーコンテキストに対応しています。 マテリアルがそれらの対応しているコンテキストを複数持っている場合、Karmaは次の優先順位を使用します:
優先順位 |
レンダーコンテキスト |
ビルダー |
サンプルのノード |
|---|---|---|---|
1 |
|
|
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
VEX Material Builder 
Classic
Karma Material Builder 
USD Preview 
Note
Karma XPUとKarma CPUは、MtlX/Karma/Previewノードの混在に対応していますが、これは通常だと他のレンダーエンジンでは対応していません。
マテリアルバインド ¶
Solarisでマテリアルをプリミティブに割り当てるのは簡単です。
Material LibraryまたはAssign Materialノードを使用して、マテリアルをPrimまたはGeomSubsetにバインドすることができます。
デフォルトでは、 Material Binding Strength は Weaker Than Descendants です。 これは、子Prim自体にマテリアルバインドがない限り、すべての子Primにバインドが適用されることを意味します。 マテリアルを親Primに割り当て、Strengthを Stronger than Descendants に設定すると、シーン全体のマテリアルを上書きすることができます。
Warning
Hydraは、期待した通りにインスタンス上の“弱い”マテリアルを上書きしてくれません。 この挙動は、今後のバージョンのUSDおよびSolarisで改善される予定です。 それまでの間は、継承されたクラスPrimを使用してマテリアルの上書き範囲を広げることで、インスタンスのマテリアルを置換してください。
USDにおけるマテリアルバインドは特定のPurposeのみに適用できます(USD Render Purposeは、プレビュー、マップ生成、最終レンダリングなど、様々なタイプのレンダリングを指します)。 デフォルトでは、マテリアルはどのPurposeにも適用されますが、例えばマテリアルを最終レンダリングだけにバインドするよう設定することも可能です。
USDはCollectionベースのマテリアルバインドに対応していますが、現時点では、その方法を強くお勧めするほどのワークフロー/パフォーマンスのメリットはありません(USD Collectionをパターンとして定義でき、および/またはHydraがCollectionベースの割り当てを介したインスタンスの上書きに対応している場合、これは非常に強力なワークフローとなります)。
シェーダ構築 ¶
-
Karma向けのシェーダ構築は、HoudiniのMantraや他のレンダラーの場合とほとんど同じで、VOPを使用します。
-
Material Libraryは、マテリアルから自動的にUSD Preview Surfaceの生成を試みます。これは、Principled ShaderおよびMtlX Standard Surfaceで最も上手く機能します。場合によっては、USD Previewマテリアルの自動生成を避けた方が望ましいです。Material Libraryノードのトグルを使用することで、そのプレビュー生成を無効にすることができます。
-
テクスチャが原因で、GLビューア、特にStorm(PixarのOpenGL Hydraデリゲート)が低速になる場合があります。スケーラビリティが心配な場合は、中景から後景までのオブジェクトに対してテクスチャを使用するのではなく、USD Previewシェーダの
displayColorsとdisplayOpacityを使用して色を付けると良いでしょう。 -
マテリアルの構築時に
Collect VOPを最終ノードとして使用すると、ディスプレイスメントシェーダが追加しやすくなり、さらには、手動でUSD Preview Surfaceやその他のシェーダもマテリアルに追加しやすくなります。 -
Parameter VOPを使用することで、“パブリックな(外部からアクセス可能な)”マテリアルインターフェースを作成することができます。これにより、下流のLOPでマテリアルを編集しやすくなるうえ、大元のシェーダグラフを編集する必要がなくなります。(テクスチャマップのパスなど)同じパラメータで異なるシェーダを駆動することも可能です。
MaterialX ¶
-
UsdMaterialXに対応しているどのような環境でも動作するように純粋なMaterialXシェーダのみでシェーダネットワークを構築したい場合は、 USD MaterialX Builder から始めてください。
-
Karma Material Builder は、MaterialXをベースとしたKarmaマテリアルの作成を簡略化します。このサブネット内では、⇥ Tabメニューがフィルタリングされて、互換性のあるKarma、USD Preview、MaterialXノードのみが表示されます。これにより、シェーダネットワーク内で誤ってVEX VOPノードを使用してしまうのを防ぐことができます。
-
MaterialXノードを使用して、Karma Hairまたはその他のKarma固有のシェーダのパターンを駆動させることができます。
-
HoudiniのPrincipled Shaderと異なり、MtlX Standard Surfaceノードはパラメータをジオメトリアトリビュートに自動バインドしません。
-
このアイコン
やhmtlx接頭辞で始まるMaterialXシェーダは、純粋なMaterialXノードを使用して実装されていますが、MaterialX標準配布の一部ではなりません。
USD Previewシェーダ ¶
-
USD PrimVar Readerは、KarmaではMaterialXノードと互換性があります。
-
UsdMaterialXに対応したレンダーデリゲートが増えるまでは、USD Previewシェーダがマテリアルを定義するのに最も一般的で汎用的な方法となります。
-
厳格にUSD Preview専用マテリアルを構築する場合は、 USD Preview Material Builder を使用してください。
VEX ¶
-
VEXシェーダは、Karma CPUで のみ 機能します(Karma XPUでは機能しません)。
-
直接
Cdにバインドするのでなく、Surface Colorノードをシェーダで使用してください。Cdがジオメトリで見つからない場合、displayColorPrimvarが代替となります。これにより、VEXシェーダはMantraからKarmaに簡単に切り替えることができます。 -
Point Cloud系シェーダや他のジオメトリルックアップ系シェーダは、Karma CPUでも機能するはずですが、ステージ上のプリミティブにアクセスすることはできません。これらのシェーダはディスク上の
.bgeoジオメトリファイルにのみアクセスすることができます。
Warning
Karma XPUはPrincipled Shaderに 対応していません 。 しかし、Material Library LOPの自動プレビューシェーダ機能が原因で、Karma XPUがPrincipled Shaderに対応しているように思えてしまうことでしょう。 統計情報やログ情報を調べればこれらの状況は明確になり、誤った問題のデバッグに時間を費やしてしまうのを回避することができます。
Primvars ¶
Primvarとして暗号化されたアトリビュートやプロパティを使用することで、マテリアルのシェーダのパラメータを駆動させることができます。 どのPrimvar補間タイプにも対応しており、サポートされている値タイプは、そのノードのシェーダシグネチャがそれです。 汎用のReader系ノードに加えて、KarmaはMaterialXに同梱されている特定のアトリビュートリーダーにも対応しています。
シェーダファミリー |
Primvar Reader系ノード |
|---|---|
MaterialX |
|
USD Preview |
|
VEX |
Bind-
MaterialX系ノードとUSD Preview系ノードは、どちらもKarma CPUとXPUで使用することができます。
-
MaterialXのPrimvar Reader系ノードを使用してボリュームをバインドすることができます。
-
ボリューム系シェーダでPrimvarを読み込む場合、
densityフィールド上の定数補間のPrimvarしか読み込むことができません。他のフィールド上の定数Primvarsは無視されます。
マテリアルプロパティ ¶
Karmaのレンダープロパティの多くは、ジオメトリレベルで上書きすることができます。
簡単にレンダープロパティをマテリアルに関連付けれるようにするために
Karma Material Propertiesノードが用意されており、
これによって、ユーザはマテリアルを介してレンダー設定を適用することができます。
この挙動は、レンダープロパティが入力としてマテリアルのサーフェスシェーダに追加されるというものです。
Karmaは、その入力を読み込んで、まるでGprim自体に設定が適用されているかのようにジオメトリプロパティを適用することができます。
マテリアルを介して適用されたレンダープロパティは、ジオメトリに直接適用されているレンダープロパティよりも弱いです。
透過マテリアル ¶
デフォルトでは、Karmaはグラスや水などの透過マテリアルに対して何かしらの最適化を使用します。
-
デフォルトでは、Fake Caustics(疑似コースティクス)が有効になっています。
-
内部反射も無効になっています。
これは、たいていの場面では綺麗に見え、そして、非常に高速です。 しかし、真のコースティクスと内部反射も有効にすれば、もっと物理的に正しい結果が得られます。
他にも、マテリアルプロパティまたはジオメトリプロパティを使用してNested Dielectrics(入れ子状の絶縁体)をセットアップすることで、入れ子状の透過マテリアルを正しくレンダリングすることができます。
Transmissive Geometry Render Properties
Enable Caustics
透過オブジェクトからのブルートフォース(総当り)によるコースティクス。 間接ディフューズバウンスで見受けられる光沢BSDFの評価を許可します。 その計算には非常に膨大な数のディフューズ光線が必要となることが多いです。 特に Caustics Roughness Clamp パラメータに非常に小さな値を設定した場合、または、 Indirect Guiding の機能が無効な場合でそうなります。
Caustics Roughness Clamp
シェーダで設定された値を超えて、真コースティクスのために最小の粗さを強制します。 この値を上げると、コースティクスの精度は悪くなるもののノイズを少なくすることができます。
Note
Roughness Clamp はGGX BSDFでのみ動作し、Phong BSDF、円錐BSDF、スペキュラBSDFには何の効果もありません。
Evaluate BSDF On Fake Caustics
BSDFが擬似コースティクスに影響を与えるようにします。例えば、赤いボトルは自動的に赤い影を落とすようになります。
BSDFを無効にするとレンダリング時間を短くすることができますが、代わりにfakecausticscolorを使用して一定の影の色を設定する必要があります。
Fake Caustics Opacity
疑似コースティクスの不透明度を制御します。これを使用して、BSDFの結果を明るくすることができます。
Enable Internal Reflection
光沢のある透過BSDFの背面で内部反射を評価することができます。 内部反射を適用したいのであれば、このオプションを有効にします。
Note
Thin Walledを有効にしたMaterialX Standard Surfaceでは、このオプションは何の効果もありません。 このマテリアルは常に内部反射を表示します。
Dielectric Priority
屈折マテリアルの優先度を指定します。これによって、レンダラーは、レンダリング時に多数の重なった屈折マテリアルからどれを優先させるのか選択することができます。 これは、グラスの中の水と氷などの効果で有効です。 デフォルトは0(最高優先度)で、数値が上がると(1、2、3など)、優先度が下がっていきます。
発光マテリアル ¶
非ライトプリミティブを発光させることで、レンダリング時にそれをライトとして機能させることができます。次のシェーダは発光に対応しています:
|
MaterialX |
|
|
USD Preview |
|
|
VEX |
|
発光シェーダの作成はたいてい、最初の一歩にすぎません。 発光ジオメトリのサンプリングは、実際のライトプリミティブのサンプリングほど効率的ではありません。 Karmaには、発光ジオメトリのサンプリングを改善できる特別なレンダープロパティがあります。 これらのプロパティは、マテリアル上、または、ジオメトリオブジェクト上に設定することができます。
Karma Material Propertiesノードは、マテリアル上にレンダープロパティを設定します。
一方、Render Geometry Settingsノードは、特定のジオメトリプリミティブを光源として扱うようにKarmaに指示することができます。
発光ジオメトリのルックと品質を制御する追加パラメータもいくつか利用可能です。
Emissive Geometry Render Properties
Treat As Light Source
発光マテリアルを持つオブジェクトがシーン内にライトを生成するようになります。 オブジェクトが十分に影響力を持っている場合(サイズ、明るさなど)、Karmaはそのオブジェクトを(通常のライトと同様に)明示的な光源であるかのように扱うことができます。 つまり、放出される光が非常に効率よく処理されるようになります。 しかし、これを行なうと、システム内の他のところで余計なオーバーヘッドが発生します(例えば、メモリ使用量が増えたり、更新時間が遅くなったりなど)。
3つのオプションがあります。 “No”は、オブジェクトが光源でないと設定します。 “Yes”は、オブジェクトが光源であると設定します。 “Auto”(デフォルト)は、Karmaが内部の経験則に基づいてオブジェクトを光源として扱うべきかどうかを決定します。
Light Sampling Quality
オブジェクトをジオメトリ光源として使用する時、これは、ライト毎のサンプリング品質を設定します。 この品質を上げると、この光源のサンプル数が増えるので、他の光源よりもこのライトのサンプル品質が良くなります。
Note
これは、オブジェクトが受ける光の品質ではありません。
Light Source Diffuse Multiplier
この発光オブジェクトがマテリアルのディフューズ、SSS、ボリュームの反応に与える効果の乗数。
Light Source Specular Multiplier
この発光オブジェクトがマテリアルの反射、屈折の反応に与える効果の乗数。
AOVs ¶
マテリアル定義のRender Vars(AOVs)は、まだUSDの一部として定義されていません。 それまでの間、Houdini/Karmaには、AOVsをセットアップするためのいくつかのソリューションが用意されています。 このワークフローは、過去のSolarisのリリースと比べて、はるかに合理化されています。
詳細は、
Karma AOV 2.0を参照してください。
カスタムノードグラフ定義 ¶
MaterialX Shade Primの複雑な構成の集まりを、とてもコンパクトなノード定義に変換することができます。 あなたのHDAがたくさんのUsdShade Primを生成していたり、Material LibraryやKarmaによる処理時間が長くなっている場合は、これが役立つとわかることでしょう。
現在のところ、これは技術的な過程を踏むことになりますが、スタジオや上級ユーザにとっては有益なワークフローになり得ます。以下には、順を追って、または、自動化する必要のあるおおまかな手順を載せています:
-
Hythonから
$HHP/vop2mtlx.pyを実行して、サブネットベースのVOP HDAをMaterialX定義に変換します。このスクリプトの入力はHDAですが、HDAアーティストが直接使用するようなHDA ではない ので、標準のotlsフォルダに保存する必要はありません。ユーザ向けのHDAはその後で生成します。 -
変換された
.mtlxソースファイルは、以下の他のツールによって後処理します:-
$HHP/mtlx2karma.py- これは、Karmaがこれらのシェーダを正しくレンダリングするのに必要なkarmaNodeGraph.jsonファイルを出力します。このJSONファイルは、HOUDINI_PATHまたはユーザプリファレンスディレクトリに追加してください。 -
$HHP/mtlx2hda.py- これは、ユーザ向けの出力HDAを生成します。このHDAファイルは、HOUDINI_PATHまたはユーザプリファレンスディレクトリの otls フォルダに追加してください。
-
-
出力されたHDAファイルを
$HOUDINI_USER_PREF_DIR/otlsに、karmaNodeGraph.jsonファイルを$HOUDINI_USER_PREF_DIRに追加します。 -
カスタムシェーダを使用したマテリアルがKarmaでレンダリングできるようになっているはずです。
サンプルファイルは、$HFS/houdini/help/files/karma_user_guide/custom_nodegraphsにあります。
そのフォルダをどこか書き込み可能な場所へコピーし、そのcustom_nodegraphsフォルダ内からHoudiniを起動します。
result.hipを開くと、この画像の左側のように、Karmaによってビューポート内に緑と赤の円柱がレンダリングされるはずです。
custom_nodegraphs.hipでは、カスタムノードを生成するための手順が分かります。
以下にいくつかのTipsを載せています:
-
各スクリプトの
--help出力には、たくさんの有益な情報が含まれています。 -
デフォルトでは、1番目のシグネチャのみがMaterialXにエクスポートされます。もしシェーダが複数のシグネチャを持っている場合は、
vop2mtlx.pyに--all_signaturesを渡す必要があります。 -
あなたが開発したHDAはデフォルトではTabメニューに出現しません。 Type Properties ウィンドウの Node タブにある VopNet Mask に
MaterialXを設定することで、これを修復することができます。ユーザ向けのHDAには、これを行なう必要はありません。 -
sidefx::mtlx::defaultgeompropを使用して入力にタグを付けることで、ジオメトリプロパティを暗黙的に読み込むことができます。利用可能なトークンを以下に載せています:-
texcoord入力に対してUV0トークンを使用すると、USDのデフォルトのprimvars:stにバインドされることに注意してください。
-
kma_*ノードはMaterialXシェーダではないので、それらのノードを使用しても動作しません。 -
グラフが他のカスタムノード定義を使用して構築されている場合、
vop2mtlx.pyには--library-pathフラグを使用してください。
次のステップ ¶
Karma向けのシェーダとマテリアルの構築の詳細については、SolarisでのMaterialXの使い方を参照してください。
次項 テクスチャ