みなさんこんにちは。SIGGRAPH、CEDEC、GDCなど、大型カンファレンスのオンライン開催が続々と決まり、具体的な内容も発表され始めています。特に、本記事執筆時点だと、GDCはConference Passが$399という破格なお値段になっています。私もこれまではGDCはちょっとフィールドがちがうので参加してこなかったのですが、これを機に申し込んでみました。旅費や滞在費を考えると直接行くよりも断然リーズナブルに参加できるので、読者の皆さんも参加をご検討してみてはいかがでしょうか。そんな中、目下の悩みは時差です。われわれは世界のカンファレンスを梯子して徹夜でセッションを見る生活を1ヶ月も続けるんでしょうか...............？
前回は、前半で当社が開発しているcrumenaとパイプラインツールのランチャーを例に、同じようなツールでも目的やターゲットごとにどの様なちがいが出てくるかを確認しました。後半ではパイプラインツールを使用したプロジェクト用フォルダ管理について考えていきました。今回は、アセット管理、特に管理する際の構造について考えていきます。
※現在、当社パイプラインツールはWindowsのみの対応となっています。ご了承ください。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
アセットの階層構造を決めるためのルールづくり
アセットの管理をするためには、最初にどのように整理するかを決める必要があります。本来の話の順番としてはアセットを管理するためのルールがあって、それをストレージ上に落とし込むためのフォルダ構成がある、というのが素直なながれになります。ただ、具体的に目に見える形がないまま「アセット管理とは」というお話をしても実感が湧かないので、まずはフォルダ構成（Excelシートでもいいですが）に落とし込んでみるというのがいいでしょう。フォルダをつくるとどのような感じになるかなというのが確認できたら、よりよく管理するためにはどうしたらいいのか？ という話に進むことができます。
ここでは、フォルダ階層以外の、もう少し広い範囲を視野に入れたお話をします。アセットの階層構造は色々なところに関わってきます。フォルダ階層はもちろん、ExcelシートやShotgun上での階層、クライアントや外注先とやり取りするための管理など、形を変えてプロジェクトの隅々にまで影響をおよぼしてきます。そのため、アセットの階層構造を決めて厳密に運用することはとても大事です。
プロジェクトで管理する階層は大きな分類としてassetsとshotsの2つに分かれ、それぞれを3階層の深さで分類するというのは前回お話しました。階層の深さは人それぞれ好みやこだわりがあり、細かい要望が出てきやすいところです。皆さんの中にも、2階層もしくは4階層で管理したい、assetsとshotsで異なる深さにしたい、アセットやショットごとに階層の深さを変えたい等々、喧々諤々の議論をして結局まとまらなかったという経験をした方は多いのではないでしょうか。
階層の深さに関しては最終的には「エイヤッ！！」と決めるしかないところではありますが、全てのプロジェクト、全てのシチュエーションで統一して管理するためには2階層は少なすぎます。3階層でもちょっと足りないなと感じることはもちろんありますが、運用ルールを工夫することである程度無理なく収めることができるので、あまり多くないケースのために階層を増やすよりはいいという考えから3階層を採用しています。状況によって階層の深さを変えることは様々な理由から避けるべきです。ひとつに、ルールが増えれば増えるだけ関わる人間の負担が増えてしまいます。このプロジェクトは3階層、このプロジェクトは4階層、assetsは3階層だけどshotsは4階層.........など、考えることが増えるだけ脳の容量を圧迫し、本来考えなければいけないことに使える余裕が減ってしまいます。もうひとつの理由としては、システム化をする際の問題です。ルールが複雑になればなるほどシステム化のコストが上がっていきますし、バグも増えていきます。見えづらいコストとして、ルールを増やすことで既存の別のルールとの一貫性を保つのが難しくなってくることもあります。
よくある失敗として、ルールを決める段階では可能な限り全てのケースに対応できるように、あれもこれもと詰め込んでオーバースペックになってしまったり、ルールが複雑になってしまったりすることがあります。確かに隅々まで考え、どのような例外にも耐えられるように準備することも大事ではあるのですが、それと同じくらい物事をシンプルに保つことも大事です。ここは経験とセンス、そして極限までルールを減らすんだという執念が必要なところです。
構造を揃える
アセットの階層構造をつくるときには、以下の2つの視点から考えるとよいです。例として、前回ディレクトリを作成するために使用したExcelファイル（sample_Assets.xlsx）を挙げます。
この例では、列にcategory、elements、variationという名前が付いています。各列にある項目（例えば、char、prop、BG）は同じようなレベルの情報を置きます。例えば、categoryとしてchar、prop、TokyoTowerの3つが並んでいたらどう感じるでしょうか。char、propというのがキャラクターや武器といった比較的大きなグループを表しているのに、TokyoTowerだけは特定の建造物を指しています。これだとちょっとバランスが悪いですね。TokyoTowerであれば BG/building/TokyoTowerや、BG/TokyoTowerのようにする方がスッキリします。
次に、同じ階層の中に含まれるアセットに注目します。BG/buildingA以下には、typeA、typeB、typeCという3つのアセットが含まれています。ここの内容はひとつのフォルダ内に存在したりShotgunでも同じページに表示されるため、あまり多すぎない方がよいです。特に背景や小物は数が増えがちなので、1階層に入るアセットの数が増えそうなら上の階層で分割して、管理を分けるのがよいです。
アセットの分類方法には指針はあるものの、これが正解という答えがないためにケースバイケースになります。Tokyoの中のひとつとしてTokyoTowerがあるなら、BG/Tokyo/TokyoTowerみたいになるでしょうし、Tokyoの広い範囲をカバーするのであれば、BG/MinatoKu/TokyoTowerのようになるかもしれません。TokyoTower内で話が進む作品であれば、BG/TokyoTowerと、1段階上のレベルでの管理になるかもしれません。こうやって考えていくと、BG/Tokyo/MinatoKu/TokyoTowerのように階層を増やしていきたくなります。そこはグッとこらえて、いい感じに3階層に収まるよう工夫しましょう。
このように、アセットの階層構造は人が考える必要があるため、責任者を決めて管理することが望ましいです。責任者がマスターデータとしてアセットリストを作成し、それを元にツールを使ってフォルダやShotgun、そのほかの環境に展開するながれにすることで、一貫性を保つことができます。
variationとLOD
初心者にとって混乱しやすいのが、variationとLODのちがいです。
variationは、アセットのバリエーションを指します。例えば、決まったキャラクターの
-私服姿
-制服姿
-幼少期
-大人
といったちがいです。これはショット作業の際にも別のアセットとして扱われるものなので、管理上も別物として扱います。先ほどの階層の例では、char/sato 以下にあるNormal、Suit、Schoolが該当します。
それに対して、作業を行う上で使い分けるためのLODは同一のアセットを用途ごとに見え方を変えただけのものです。私服姿のキャラクターがいたとして、アニメーション作業のためにローポリゴンのモデルを用意したり、クロスシミュレーションのためのリグを含んだモデルを用意したりすることはよくあります。それでも、私服姿のキャラクターとして扱うことには変わりありません。こういうデータは同一のアセットとして扱うようにします。
LODの詳細については今後解説していきます。ここでは、異なるLODのものでもアセットとしては同一のものとみなす、ということを理解しておいてください。
命名規則
プロジェクト内でアセットを管理するためには、様々なところで命名規則を決めておく必要があります。プロジェクト内で使用する命名としては以下のようなものがあります
-アセットの場所を示すパス（例：assets/char/sato/Normal）
-アセットの名前（例：satoNormal）
-ファイル名（例：satoNormal.ma）
-ネームスペース（例：satoNormal_00）
厄介なことにツールの制限などの理由から命名規則はプロジェクト全体でひとつに統一することができないため、似たような命名規則が様々な場所で使われることになります。このような内容を人手で管理するとミスを起こすので、ツールに任せるのがよいです。逆に、ツールに任せればユーザーは命名規則に対して一切関知する必要がなくなるため、もっと大事なことに意識を向けることができるようになります。
まとめ
今回はアセットを管理する際の構造を中心にお話を進めました。ここで設計を間違えるとプロジェクトの最後まで尾を引くことになるため、慎重に準備を進める必要があります。ただ、あまり考えすぎるとどんどん複雑なルールを追加することになってしまいがちなので、十分気をつけてください。感覚的には、ちょっと物足りないかなというくらいがちょうどいいです。
第25回の公開は、2020年8月を予定しております。
プロフィール
