メインコンテンツへスキップ
見出し画像

SolarisとUSDを用いたワークフロー導入について (Part1)

    この記事を書いた人

    ▼著者

    株式会社テレコム・アニメーションフィルム
    高野怜大 リードCGIスーパーバイザー

    ▼共同著者

    株式会社テレコム・アニメーションフィルム
    佐伯圭介 CGIエンジニア

    日本AMD株式会社
    藤枝 慎 シニアソフトウェアディベロップメントエンジニア

    株式会社クラウドアトラス
    田中一郎 代表取締役 

    株式会社スタジオゼン
    井上博隆 代表取締役 
    田中利樹 CGサポートエンジニア


    0.この記事の背景と目的

    この記事は、USDを実践導入し3年近くの学習・経験を踏まえて、USDとは何かを説明した連載記事になります。

    そもそも先ずUSDとは何かですが
    USD(Universal Scene Description)は、Pixar社がGitHub上で公開しているオープンソースのライブラリです。 
    主な役割としては、異なるDCC(Digital Content Creation)ツールで
    利用されている「シーングラフ」というデータ構造を
    共通統一的に扱うための仕組みを提供する役割になります。
    今回はUSD自身の事を掘り下げていこうと思います

    次にUSDの主要な特徴として

    インターチェンジ(Interchange):
    共通のSchema(例:Cubeなど)を定義することで、ジオメトリ、シェーディング、ライティングなどのデータをツール間で統一的に扱えます。
    結果として、各ツールが自前のフォーマットに依存せずにデータ交換が可能になります。  
    これまでは各スタジオが各ツールのシーングラフと
    中間ファイルのシーングラフを結合していた作業が緩和されるという事になります。

    スケーラビリティ(Scalability):
    数万のファイルや1兆ポリゴンに及ぶ巨大なシーンであっても、非常に高速なロードと処理が実現できるため、大規模なプロダクションでの利用に適しています。 

    同時編集(Simultaneous Editing):
    シーンを複数の参照ファイルに分割し、それぞれ別々に編集した後に、プロシージャルな合成ルールに従って1つのシーングラフに統合できるため、複数人が同時にかつ非破壊的に作業できる環境を構築できます。 

    この主要な特徴だけでも これまでの前工程の作業を待つウォーターフォール型の制作ではなく 各セクションの工程のみの作業を同時に進められることが考えられます。
    つまり、各工程のイテレーション回数をより多く挑戦できることが可能になります。 


    1.USDの導入にあたり可不可に関して

    DCCをまたぐ共通ファイルとして期待が高まりますが
    導入にあたり、気を付けるポイントがあります。

    できること :
    ツール間のワークフロー実現 複数のDCCツールを横断するパイプラインの構築が可能です。
    拡張性 オープンソースであるため、独自のSchema追加やパイプラインに合わせたカスタマイズが可能です。 

    できないこと:
    セットアップの保持ができない
    現状では、各DCCツール固有のセットアップ構造に対応することが難しい。
    学習・導入のハードル 機能が豊富な反面、パイプライン全体の設計や開発が必要で導入時の学習コストが高い点が挙げられます。

    セットアップに使用する複雑なコンストレインを持ちいた、
    所謂コントロールRIGなどは、そのDCC固有の計算なのでシーングラフでは無いという事がUSDを扱うポイントになると思います。


    2.USDが必要になった背景からHydraを理解する


    Houdini18以降、「Solaris」「USD」や「Hydra」「Hydra Render Delegate」 という言葉を耳にする機会が多くなったのではないでしょうか。
    USDは数年前から技術展示があり大きな可能性を示してきましたが、アーティストがそれを最大限に活用するワークフロー構築を開始するには、ソフトウェア開発会社側がUSDをサポートする事が必要でした。

    サポートは、SideFX社がSolarisをHoudiniに追加したことを切っ掛けに、現在は数多くのソフトウェアにUSDサポートが含まれています。
    本文では、SolarisがHoudiniに追加され、USDがどのように必要とされたのかを記載していこうと思います。

    まず初めにこれまでどのような問題や制作への足かせがあったかの
    観点から考えてみます。

    多くのプロダクションパイプラインで既存の問題として、各ツール毎にシーンデータを保存および処理する為にソフトウェアごとに独自のフォーマットが使用されている事があげられます。

    これはアーティストがモデリング、スカルプティング、シミュレーション、ライティング、シェーディング、合成、アニメーション、リギングなどの特定のタスクに適したソフトウェアの利用を好むため生じていました。

    この問題に対してのアプローチとして、
    ソフトウェア間でデータを交換するために、OBJ、FBX、Alembicなどの中間フォーマットを使用し解決してきました。

    ですが、それぞれの形式は元のシーンのほんの一部しか保存しておらず、必要な情報を充分に伝達するように設計された物ではありませんでした。

    対してUSDは、ほぼすべてのタイプの3Dシーンおよびアニメーションデータをサポートし、3D作成ソフトウェア、アセンブリソフトウェア、およびパイプラインユーティリティ間でデータを転送できる様に設計されました。

    というよりも、そう読めるように記述のルールを存在させ、それに沿う様に記述する必要があるというのが正しいです。

    例えばHoudiniのSOPにFBXやAlembic等を用いて望んだショットを作成したとします。
    この段階のSOP階層ではHoudini独自のシーングラフですが、Solarisに持ち込み、シーングラフを改めて作成することで、USDシーングラフとしてくみ上げることができます。

    画像
    SOPでのAlembicファイルの読み込み
    画像
    SOP側(Tree View)左とSolaris側(Scene Graph Tree)右

    実際に私がSolarisにふれ感じたことは、USDシーングラフを正しく作ることで、結果として洗練されたシーングラフを構築される。
    という事を実感いたしました。

    また、ここから書き出されたUSDは、他のソフトウェアでもシーングラフを維持した状態で読むことができます。

    このテクノロジーにより、様々なプラットフォーム間でモデル、シーン、アニメーションデータを共有することがはるかに容易になり、
    参照することで複数部門のアーティストが同時に作業することが可能になりました。

    画像

    USD自体の詳しいLINK  ココ参照 
    ▼Universal Scene Description

    ▼USDの基礎


    3.Hydraの話

    次にレンダリング工程からHydraがどのようなものか説明をしていきたいと思います。

    Solarisのビューポートにはこのように「Houdini VKもしくはHoudini GL/Karma CPU/Karma XPU/Storm/その他レンダラー」と複数のレンダラーがあり、スイッチで切り替えることができるようになっています。

    これは、HoudiniのSolarisドキュメントに書かれている、『USDは、特定の時点でUSDシーンから画像を生成するためのAPI(Hydraと呼びます)を定義します』にあるとおり、HydraのAPIの恩恵で複数のレンダラーを切り替えることができるようになっています。

    画像

    このように、レンダラータイプを切り替えられるのでHydraのことを「レンダラー」と考えてしまうのですが、実際はレンダラーとはまた別のものになります。

    これは Hydraがなかったときの話をすると伝わりやすいとおもいます。

    基本的にはレンダラーがそのソフトのシーングラフを解析して初めてレンダリングを開始できるというのがレンダリングの視点です。

    レンダリングするために、レンダラーが指定したシェーダーを使用するのはそのためです。何か一つでも歯車が合わないと画像として出力することができません。 オブジェクトがあるのに真っ黒な画面が出力されるなどは
    歯車があっていないときに起こります。

    ソフト毎に異なるシーングラフを解析できるか、対応できるのか?
    が、レンダラーを外部プラグインとして追加できるのか?否か?になります。

    画像

    ではこれまでは、複数のソフトウェアを用いた場合どのようにレンダー処理まで持って行っていたのでしょうか?

    仕事を進めていくうえで、その表現に適したソフトウェアでショットを作成したい場面が数多く出てきます。

    先述したようにこれまでは、OBJ、FBX、Alembicなどの中間フォーマットを使用して、レンダリングするソフトウェアにデータを読み込ませ、ソフトウェア独自の一つのシーングラフに結合させてレンダリングをしていました。

    当然使用ソフトウェアが増え各ソフトウェアごとのシーンファイルが作成されたり、ショット数が増えれば増えるほど 手間が増え、データ管理が複雑化し管理用ソフトウェアも必要とされていたわけです。
    また、後になってソフトウェアを変更したり、レンダラーを変更したりすることは、シーングラフの作り直しを意味するので、基本的に避けるべき行為でした。

    そこでHydra は、シーングラフとレンダラーをつなげるブリッジとしての役割として開発されました。

    画像

    つまりHydra 空間に使用したいデータを組み込むことができれば、
    Hydraに対応するレンダラーがレンダリングできるという事になります。

    すこし専門用語を交えて説明すると、「Hydra Scene Delegate」に対応していれば、「Hydra Render Delegate」はその異なるシーングラフをとりまとめ、レンダリング することが可能になります。

    ▼参考資料(Siggraph2019 Hydra)

    http://graphics.pixar.com/usd/files/Siggraph2019_Hydra.pdf

    今回は、USDのシーングラフについて掘り下げてみました。
    次回はHoudini18で追加されたSolarisについて掘り下げていこうと思います。


    あなたへのおすすめ