USD とは (2022 年改定版)
リニューアルに際して
USD AdventCalendar2022 1 日目は、USD についての改訂版です。
USD の記事を最初に公開したのが 2019 年の秋ごろでした。 この年の SIGGRAPH で USD を知り、学習を始めた当時に書いたものなので 今から見ると、だいぶ情報が足りてなかったり 正確でない箇所もちょいちょいあるようになってきましたので
学習から 3 年が経過した今の知識で、改めて USD とは何か？という記事を リニューアルすることにしました。
USD とは
USD とは、Universal Scene Description の略で、
シーングラフを扱うことのできる Pixar 社が GitHub 上で公開している
オープンソースプロジェクトのライブラリになります。
シーングラフ とは
「シーングラフ」という言葉になじみがない方も多いかもしれませ んが これは、コンピュータグラフィックスで一般的に使用されている ツリー構造のノードやディペンデンシーグラフといった 描画に必要な要素を管理するためのデータ構造 のことです。
DCC ツールと呼ばれる 3DCG を扱うソフトウェアは、 そのソフトウェアが扱うのに最適なデータ構造を内部的に持っています。 たとえば、Maya ならば DG・DAG ノード、そしてアトリビュートとそのコネクションのように それぞれ固有の構造を持っていて ツールは、これらのデータ構造を編集します。
上にも書いた通り、このシーングラフは 個々の DCC ツールが扱いやすいように設計されており、 ツールによってその構造は異なります。
そのため、たとえば Maya と Blender でデータを移動しようとすると Maya から保存した mb や ma といったデータは Maya 固有のデータ構造なので Blender で読もうとしても、当然ですが Blender はデータを解釈できず開くことができません。
もし、別の DCC ツールのデータを読めるようにしようとすると、 開きたい DCC ツール側は、保存した DCC ツールの API を使用して 1 つずつ自分自身の構造と照らし合わせて データの変換をしつつ、インポートしなければいけません。 世の中にある DCC ツールが 2 つだけならばこれでも問題ないですが、 DCC ツールにしても、ゲームエンジンにしても、無数に存在しているわけです。 ので、それぞれが都度別のシーングラフを解釈する機能を追加しようとしたら、容易に破綻してしまいます。
これを解決するには、お互いのツールが読んだり書いたりすることができる 汎用的なシーングラフ（データ構造）と、それを扱う API が必要になります。
Universal Scene Description ユニバーサル（すべてに共通の、普遍的な）なシーン記述 とある通り、USD は、ソフトウェア固有のシーングラフではなく ある程度お互いの DCC ツールが共有可能な形のシーングラフの構造を提供し 相互互換を可能にする仕組みです。
USD を導入していない場合
とはいえ、ソフトウェアを行き来するという状況は、USD が同情する以前からありました。
その場合は、お互いのシーングラフを行き来するには「FBX」や「Alembic」と呼ばれる フォーマットを使用することが多いかと思います。
現状の FBX を使用した場合を図で表すと、このようになります。 お互いの DCC ツールがFBX という、ある程度同じルールで解釈することができる状態 に 変換・解釈することで、データの行き来を可能にしています。
つまり、 相互にデータを行き来するだけ であれば、FBX でも似たようなことは実現されています。
ここまで聞くと、
すでに そういうフォーマットがあるなら、 わざわざ新しいものを使う必要なんてないじゃないか。
と思う人もいるかもしれません。 私も 3 年ぐらい前はそう思っていました。 ですが、FBX ではなく USD が一般化するのには大きな理由がありました。
なぜ USD が必要なのか
Pixar 社を含む、ハリウッドなどの大規模な映像制作では 大規模かつ巨大なデータを、多人数で、かつ同時に編集する必要がありました。
そのためには、巨大なデータであっても高速にロードが可能で さまざまなソフトウェアで、 同時に編集可能な柔軟性のあるフォーマットが必要です。
FBX でも対応する DCC ツールでシーンにインポートしたりエクスポートすることは可能ですが API はオープンソースではないため、データの拡張は限定的です。 また、あくまでも一塊のシーンを「インポート」や「エクスポート」するだけで アセット単位で細かく分けたり、Maya の Reference のように外部ファイルを参照するなどは できません。 そして、巨大で複雑なデータを、高速かつ柔軟に扱うには不十分でした。 これらの問題を解決して、共通のパイプラインを構築するための仕組みとして開発されたのが USD です。
https://twitter.com/gishicho/status/1296419840123691010
この辺りは、以前技師長師匠が USD の生い立ちについての記事の日本語訳を Twitter にて投稿しています。 USD のバックグラウンドがとてもわかりやすくまとめられているので ぜひとも一連のツイートを読んでいただきたいです。
USD の特徴
USD は、これらの問題を解決するための機能を備えているのが特徴です。 その特徴というのが、
- インターチェンジ
- スケーラビリティ
- 同時編集
この 3 つであり、USD を扱う大きなメリットになるポイントです。 それぞれの要素を詳しく見ていきます。
インターチェンジ
インターチェンジとは、ジオメトリやシェーディング、ライティング、物理などのデータを 「Schema」と呼ばれる共通の機能や特性をしていするものを定義し ツール間で強固な相互運用を実現する ための機能です。
たとえば、Cube という Schema を定義を用意してあるとして USD を使用できる各種ツールがこの Schema を解釈してツール上で保存された情報を 表現することで、さまざまなツールで USD を介して相互にやり取りを可能にします。
2022 年現在では、Maya や Houdini、3dsMax、Blender といった一般的な DCC ツールや 多くのツールで対応され、一般的なフォーマットになりつつあります。
スケーラビリティ
スケーラビリティとは、長編映画の 数万ファイルから構成される 1 兆ポリゴンを持つ巨大なシーンを取り合いできる機能です。 巨大なライティング・レンダリングを行うシーンを扱うには 速度はとても重要です。 USD は、ほかのファイルフォーマットに比べても非常に高速で 導入をする上での大きなメリットになります。
同時編集
USD の同時編集は、コンポジションの機能を使用して複数のファイルに分割・合成することで 同時編集を可能にする機能です。
大規模な開発では、多くの人がさまざまな工程を経て作業が進みます。 そ うなってくると、大人数で同時に、さらに非破壊での編集が必要になります。
モデリング担当の人が作成したモデルを、アニメーションしたりレイアウトし その結果ライティングをして、レンダリングをしますが それぞれ別のファイルを編集します。 これらのファイルは、「」と呼ばれる決められた合成のルールをもとに、 プロシージャルに、1 つのシーングラフに構築します。 「プロシージャル」に合成されるので いずれかのファイル、たとえばモデルが更新されればそれをレイアウトしているシーンは自動で更新されるし、 ライティングのシーンも更新されます。
これまでは、たとえばモデルが更新されれば レンダリングシーンは再構築するといったプロセスが必要になったりしましたが USD で構築していた場合は、そのようなプロセスが不要になります。
そして、これらの合成処理は非常にロバストな仕組みになっていて 複雑な構造であっても、壊れることなく安定して扱うことができます。 それは、Pixar 社の開発で何度も実際に活用された実績からも感じ取れるのではないかと思います。
できること・できないこと
これまで上げた 3 つの特徴によって 現在では、業界の標準フォーマットになりつつありま す。 非常に多機能ですが、 導入することでできることと、現状だとまだできないことがあります。
できないこと・デメリット
リグが持てない
よく言われることですが、USD は（現状は）リグを持つことができません。 どういうことかというと、 リグの構造というのは非常に複雑で、DCC ツールごとに構造が異なります。 そのため、USD に対してリギングの動作などを追加すればするほど DCC ツール間でのデータ交換は困難になっていきます。
ですが、SIGGRAPH20222 の Birds of a feather で発表があり 今後 OpenExec と呼ばれる機能が追加されれば、リグが持てないというのは変わってくるかもしれません。
学習・導入が難しい
USD は便利なものですが、機能が多く、どのようなことができて、どのように使えばいいのかを 理解するのは大変です。 また、2022 年現在では、さまざまな DCC ツールが対応し 自前で開発をしないでも USD を使用したパイプラインの構築が可能になってきています。 しかし、USD を最大限 活用とすると、パイプライン全体を設計したり、それに応じて開発が必要で、 その場合は、パイプラインエンジニアやテクニカルアーティストの存在が必須になってきます。
できること
ツールをまたいでのワークフローを実現できる
これは、上であげた特徴の 1 つ「インターチェンジ」と「同時編集」にあるとおり USD を導入することで、複数のソフトウェアを超えた環境を構築できます。
拡張できる
USD はオープンソースで公開されています。 パイプラインを構築するのに必要な API が用意されているので、自分たちの環境に合わせて開発をすることが可能です。 データを定義する Schema も独自に拡張することが可能なので たとえば「ゲームエンジン用むけの情報」のように、独自のデータも扱えるようにできます。 それ以外に、パスを解決する や、Metadata USD をプレビューすることができる usdview など も、プラグインを作成して拡張が可能です。
JSON や XML、YAML、TOML のようなファイルフォーマットとして扱える
USD は、3DCG 用のデータと思われがちですが あくまでも USD 自体はデータを入れるコンテナーなので、3DCG 以外のデータも扱うことができます。 USD アスキーであれば、ある程度慣れれば手書きすることが可能なので 設定ファイル的なものを USD として持たせれば コンポジションの機能と組み合わせて、複雑で巨大なデータでも 細かいファイルに分けて管理することが可能になります。
このあたりは別途アドカレの記事で紹介をしようかとおもいます。
!!! info
CEDEC2022の USD活用事例で具体例を紹介しているので、 気になる方は、スライドを確認してください
過去のデータを再利用できる
USD を導入しようとしても、過去作成したアセットデータなどがあると移行が難しいというのがあるかもしれません。 しかし、USD には FileFormatPlugin と呼ばれる機能があり 異なるデータフォーマットでも、USD のシーングラフとしてロードできるようにする機能があります。 デフォルトで Alembic プラグインなども用意されていますし、 プラグインは自分で実装することもできるので、内製のフォーマットを流用したい場合であっても 対応できます。
まとめ
現在では、使用できるツールも増えて日本国内でも導入事例がちらほら聞こえてくるようになりました。 また、使用はしていないものの検証を進めている会社は多くあるのではとおもいます。
USD のライブラリは非常に多機能で巨大なシステムなので、学習するにはなかなか難しいかもしれません。 しかし、USD は非常によくできた仕組みで、 活用することで今まではでは実現することが難しかったパイプラインを構築することが可能になります。 さらに、小さな箇所から導入して徐々に拡張をしたり 過去の遺産を活用したパイプラインの構築なども可能になります。
これからの CG の映像やゲーム開発のスタンダードになっていくと思いますので この記事を機会に、触ってみてほしいなと思います。