💬

BlenderUSDHydraAddonを使おう(2) USDHydraAddon補足とMaterialX

2021/08/27に公開

前回、Blenderでの使い方をざっくりまとめたのですが
RenderEngineに指定した「USD Hydra」について補足しないといろいろと誤解を生みそうだなーと思ったので
今回は、このHydraについての補足と、前回調べ中だったMaterialXについてをまとめてみようと思います。

Hydraとは

USDが普及するにつれて、Hydra や HydraRenderDelegate という言葉がよく聞かれるように
なったのではないかと思います。

公式ドキュメントの用語集を確認すると

Hydra is a modern rendering architecture optimized for handling very large scenes
and "change processing" (i.e. responding to authored or time-varying changes to the scene inputs).
https://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-Hydra

...とありますが、おそらくこのHelpの文章を読んでも、どういったものなのかイメージがしにくいのではない
かとおもいます。

Blenderでは

EEVEEやCyclesと同列に並んでいることから、USD Hydra をレンダラーの一種と思う人もいるかもしれません。
ですが、Hydraはレンダラーというわけではなく、
「レンダリングアーキテクチャ」と呼ばれるように、レンダリングをするための仕組みの基盤になるものです。

まず、今までのDCCツールとレンダラーの関係をみてみます。

現在販売されている Arnold V-Ray Redshiftといったレンダラーの多くは
1つのDCCツールではなく、複数のDCCツール Maya Max C4D Houdini といった複数のDCCツールに
対応しているかと思います。
この場合、レンダラー側からみると、対応するDCCの数だけそのDCCツールのシーンフラグを解釈し
最適化して、レンダリングできるデータにする処理を作る必要があります。

また、DCCツール側から見た場合を考えると
それぞれのレンダラーに対応してもらう場合を考えても、都度対応してもらうより
1つの共通の規格を持っていたほうが、その規格に対応しているレンダラーを
使用できるようになることから、メリットがあります。

文字だけだとわかりにくいので、図に書き表すと

今までのレンダラーとDCCツールの関係をざっくり書くとこんな感じになります。

レンダラーの計算部分はどのDCCツールでも同じだったとしても、
DCCツールからデータを受け取るところは、各DCCごとに実装が必要になります。
つまり、n個のDCCツールに対応しようとした場合は、そのn個分に実装が必要に
なっていくため、それだけコストが大きくなります。

ですが、Hydraを使用した場合はこのようになります。

今までは、複数のレンダラーに対応する場合それぞれ必要な処理を実装する必要がありました。
しかし、Hydraを使用すると、
レンダラーはHydraからデータを受け取る部分(HydraRenderDelegate)を実装することで
Hydraに対応するDCCツールのシーングラフを受け取り、レンダリングをできるようになります。
つまりは、Hydraは DCCツール(シーングラフ)とレンダラーをつなぐ共通の規格 のような
役割をしてくれます。

ということで、今回のAMDの作成した Blender USD Hydra Addon がなにかというと、

Rendering in Blender via the USD Hydra Framework

READMEにあるとおり、HydraFrameworkに対応することで
HydraRenderDelegateに対応したレンダラーでレンダリングできるようにするプラグイン
ということになります。

改めて、BlenderのRenderSettingをみると
FinalRenderSettings / Viewport RenderSettings とぞれぞれ設定項目がありますが
その中に「Renderer」が指定できるのがわかると思います。
ここで設定するレンダラーが、Hydraを経由して実際にレンダリングする「Hydra RenderDelegateに対応した」
レンダラーになります。

デフォルトだと、ProRenderとGL(Storm?)の2つのレンダラーを使用することができますが

Addonを見ると、hdRprもhdStormもプラグインとして入っているので
対応するレンダラーなら追加できそうです。
時間ができたらCyclesあたりで実験してみようと思います。

MaterialX

続いてMaterialXについて。
USD Hydraを使用すると、Blenderでマテリアルを指定しようとした場合

マテリアルはMaterialXを使用することになります。

https://www.materialx.org/

MaterialXとはなにかというと、
異なったDCCツールやレンダラー間でルックデヴやマテリアルを共有するためのオープンソースです。

https://graphics.pixar.com/usd/docs/api/usd_mtlx_page_front.html

USDにも、マテリアルを表現するためのUsdShaderShade、UsdShaderMaterial等がありますが
それとは別に、このMaterialXもサポートが進んでいて
マテリアルを扱う共通規格としてMaterialXが使われているのではないかと思います。

その流れからか、今回のBlenderAddonでもマテリアル部分はMaterialXが使用されていて

出力されるUSDデータは、

ProRender用のMaterialXシェーダーとして出力されます。

Principled BSDFを使用していた場合

BlenderでPrincipled BSDF を使用してマテリアルの指定がされた場合は、

内部的に自動でMaterialXノードに変換されます。

MaterialXを作成・編集する

次に、実際にMaterialXを使用してマテリアルの設定をしてみます。

設定は、通常のマテリアル作成と同じで、Materialタブを開き、MaterialX 「 + New 」を押します。

編集するには、 MaterialX のビューを開きます。

デフォルトだと、 RPR Uberというシェーダーが作成されています。

Addで対応するノードを確認すると、かなりの量のノードがあるので
これらを使用してMaterialXのマテリアルを作成できそうです。

MaterialXから UsdPreviewSurface を作成することもできますが
作成しても、UsdPreviewSurfaceのPrimとしてつくられるわけでもないのと
かなり不安定なのかBlenderが止まる+落ちる多発で現状だと使えそうにありませんでした。

ので、基本はデフォルトのマテリアルを使いつつ、用途に分けてほかのシェーダーを使い分けると
良いのではないかと思います。

注意点

USDでもMaterialXをロードすることができますが、

こちらを見る通り、MaterialXをFileFormatPluginでロードしているわけではないので
RPRが入っていないusdview等では、見た目を確認することができません。
また、MaterialXのファイル(mtlx)もTempDirに保存されるものなので
MaterialX対応のエディタとして使えないのも残念なところ。

ここがRPR限定でなくなると、もう少しいろんなことができそうです。

まとめ

前回の基本構造の説明と合わせてUSDHydraAddonでできることがなんとなく見えてきたかなと思います。
3.0で追加されたImportとは違い、このAddonを使用するとBlenderのDataとUSDを組み合わせて
レンダリングできたり、MaterialXを使用してマテリアルの設定ができたり
Blenderを使用したライティングやレンダリングがができそうな未来が見えてきました。

まだ若干不安定だったりするので、実践運用は難しそうですが
今回のテストで、Blenderでどう運用するかが見えてきたので
バージョンを重ねて安定してくれば、運用もみえてくるのでは?と思います。

さらに、Addonの中身をみていたら、USD内で使用するNodeはすべてPythonで書かれているのと
InputはStageで受け取れるというのが判明したので
自作USDコンポジションノード等が作れそうだなと思いました。

同様に、MaterialXがTempに出てしまうのとかRPR用の出力になってしまうのとかも
いじれば何とかなりそうです。

次回はそのあたりをやってみようと思います。

GitHubで編集を提案

Discussion