ALabを見てみよう - AssetStructure
今回は、AnimalLogic 社が公開している USD のサンプル「ALab」を見ていきたいと思います。
Alab とは
まず、今回見ていく ALab とは
上記のサイトで公開されている、主に教育やデモンストレーション用途の USD のデータと、そのドキュメントの総称です。
公開しているのは、有名な映像プロダクションである AnimalLogic 社で、以前から様々な講演をしていたりなど
積極的に技術を公開しています。
また、Maya 用の USDPlugin もだいぶ初期のころから公開していて
現在の maya-usd プラグインにも大きく影響をしています。
USD のサンプルとしては、Kitchen_set が有名です。
Kitchen_set は、非常にシンプルながら USD の使用を深く理解するために有用なサンプルではありますが
テクスチャやキャラクタ、アニメーションがなかったり
実戦向けのデータとしては物足りない部分があります。
対して、 この ALab は
アニメーション付きのキャラクターや、高品質なテクスチャを含んだサンプルになっています。
さらに、このサンプルの パイプラインの設計について詳しく説明したドキュメントがついています。
USD を扱う場合、USD 自体に気を取られがちですが
それよりももっと重要なのは「パイプラインをどのように設計するか」にあると、私は思っています。
ですが、プロダクションのワークフローにかかわる部分というのは
あまり表には情報がありません。
多くの人がどのようにパイプラインを設計し、それを USD で表現するのか
わからずに困っている人も多いのではないかと思います。
この ALab は、そういった人におすすめのサンプルになっているので
自分の勉強を兼ねてアセットを解読していきたいと思います。
なお、上記に書いてある通り非常に 実戦的なサンプルになっているので、あまり初心者向けではありません。
（多分、USD の前知識なしで見てもよくわからないはず）
なので、ALab を見る前に Kitchen_set 等で USD の概要を見ておいたほうが
個人的には良いのではないか？と思います。
https://zenn.dev/remiria/articles/7514e41f89a887b33730
Kitchen_set の見方は、以前このページに書いてあるので、ぜひ参考にしてみてください。
ダウンロードする
サンプルデータは公式ページの Download からダウンロードすることができます。
データは、 AssetStructure、Techvar Assets、Texture Pack、Cameras、Baked Proceduals など
いくつかのファイルに分かれています。
今回は、アセットの構造を確認したいので Asset Structure をダウンロードします。
このデータには、Mesh や Light などの実データなどは含まれておらず
アセットの基本構造とプレビュー用の Cards モデルのみが含まれています。
モデルのデータ構造を見たい場合は Techvar Assets をダウンロードすれば見ることができます。
今回見ていく AssetStructureは、USDのコンポジションがどのように組まれていて それぞれのファイルがどのように関係しているのかを確認することができます。
https://digitalproductionexamplelibrary.github.io/ALab/main/ https://digitalproductionexamplelibrary.github.io/ALab/documentation/
以降は、このテクニカルドキュメントをもとに、ALabのAssetaStructureを確認していきます。
開く
まずは、ダウンロードしたファイルをUSDViewで開いてみます。
開くファイルは、ALab直下にある entry.usda です。
開くとこのようなデータが表示されます。
このAssetStructureの場合は、テクスチャやジオメトリなどはなく、あくまでも
リファレンスやサブレイヤーで構成された「データ構造を見るだけ」のデータです。
ジオメトリな度が必要な場合は、別途TechVarをダウンロードする必要があります。
なので、このAssetStructureで見るべきなので
「どのようなコンポジションで構成されているか」になります。
fragment と entity と techvar
まず、このALabのAssetStructureを理解する上で必要な要素が「entity」と「fragment」と「techvar」です。
これはUSDの用語ではなく、AnimalLogicのパイプライン用語です。
まずわかりやすいところから、Techvar。 これはDCCツールなどで作成される、ジオメトリやライト、テクスチャ、リグなどのことを指します。
これは、TechVar Assetsをダウンロードした中身ですが
Fragmentフォルダ以下にこのようなMeshデータが入っています。
重要なのが、このTechVarはあくまでもシンプルな実データなことです。
TechVarは、あくまでもデータ本体なのが重要です。
fragment/geo/assetName下には、このように
アセットごとのモデルのパターンがあり、その下にそれぞれのパターンに沿ったモデルが含まれています。
この、個別データとして保存されているTechVarを実際に使用しているのがFragmentです。
Fragmentは、いわゆるデータバンドルと呼ばれるものです。
「バンドル」とあるとおり、複数のデータを「束ねる」のがFragmentです。
サンプル的には、Fragmentの各アセットフォルダ直下にあるUSDがそれに当たります。
このFragmentが束ねているものが実データ、上記に書いたTechVarAssetです。
TechVarは、ローメッシュ、ハイメッシュなど、同じアセットの別形状を持っています。
レイアウト時には、上記のメッシュを直接リファレンスなどしても問題なさそうに見えますが
用途を切り替えたりしたい場合（レイアウトの時はローメッシュだけど、レンダリング時にはハイメッシュにしたい）などを考えると
直接リファレンスするのではなく、間に共通のリファレンスを作り
その中でバリアントセットを作り、TechVarAssetをペイロードで遅延ロードを可能にしておいた方がアセットとしては都合が良いです。
つまりは、このFragment部分がその取りまとめを行い、実際のアセットとして扱いやすくする構造を提供しています。
個人的には、ALabを見ていて「このFragmentがアセットなのでは？」と
当初思っていましたが、実際にはやや異なります。
このFragmentの段階では、「データ」と「そのバリエーション」でしかありません。
たとえば、キャラクターを例にとるとわかりやすいです。
キャラクターには、ざっくり分けても
- モデル
- マテリアル
- スケルトン（RIG）
という３つの要素があります。
ですが、モデルとスケルトンは同じであってもマテリアルが違うケースもあるし
同じモデル、マテリアル、スケルトンを共有しつつも 追加のアセット（帽子とかマフラーといった装飾品など）を持つケースもあります。
このような場合、共通する箇所を考慮してデータを組み立てようとすると
Fragment階層のみだと成立しません。
そのために定義されているのが Entity です。
このEntityとは、「キャラクター」や「背景』、「ショット」などの構成要素を指します。
おそらく、一般的にイメージする「アセット」がこのEntityにあたります。
このALabの面白い構造が、Fragmentと呼ばれるデータ側と
実際に使用するアセット側のEntityを別の階層として厚あっているというところです。
あ くまでも自分の解釈になりますが、どうしてこうなっているのか考察してみます。
まず、Entityという構造がどうしてこうなっているかというと、
アセット単体とみても、１人で全てつくっているわけではなく
複数の担当者（デパートメント）に分かれています。
複数に分かれている場合、１つのディレクトリ以下でアセットを作るというのは難しいので、
できるだけ構造を分離しておく方が都合が良いはずです。
ALabでは、Entityには「DomainLayer」と呼ばれるレイヤー構造を持っています。
これは、パイプラインのステップを意味していて、そのステップのデータがんあいか？というのをFragmentの中のデータから指定しています。
こうすることで、あるアセット（Entity）の担当部署のデータがなにか？というのを
EntityのレイヤーのUSDファイルで表現が可能になります。
それ以外に、どういうケースでこの構造に意味が出るかというと
例えば「同じキャラクターの色違い」を作りたくなった場合です。
Entityにあたるところはキャラクターです。
キャラクターにはデフォルトの人Humanと、その色違いのHumanBがあるとします。
データ的にはGeometryとSkel（RIG）は共通だけれどもマテリアルだけ違う
みたいなアセットを扱いたい場合、実データが各アセット以下にあると階層的に成立しません。
このよ うに、データを共有したいケースは容易に起こり得ます。
これをFragmentという形で実データ部分を分けておくと、データの共有化が容易になります。
もう１つ、USDにはAssetResolverという機能が用意されています。
今回は、entry.usdaを起点とした相対パスで扱われていますが、多くの場合ファイルを起点とした相対パスで扱うというより
パス解決部分はAssetResolverで、どのバージョンのデータを使うのか？
をコントロールしたくなります。
EntityからFragmentを読み込む（サンプルで見えるとサブレイヤー）のならば、
パス解決をAssetResolverで行うことができるので
何をどう使うかをプログラム的にコントロール可能になります。
他にも色々面白い構造があるのですが、出先でちゃんとサンプルを見れないため
続きは年明けあたりに追記しますので、しばしお待ちください。