>   >  痴山紘史の日本CG見聞録:第28回:アセットのバージョン管理について考える
第28回:アセットのバージョン管理について考える

第28回:アセットのバージョン管理について考える

みなさんこんにちは。前回の冒頭で、『劇場版「鬼滅の刃」無限列車編』の興行収入が公開後3日間で46億円を突破したと書きました。その後も勢いは衰えることなく31日間で233億円を突破したそうです。『鬼滅の刃』旋風は子供の間にも吹き荒れているようで、娘と同じ保育園に通っているお子さんがTV版OP曲、LiSAさんの『紅蓮華』をフルコーラス熱唱しているのを見て度肝を抜かれました。まさかそこまで浸透しているとは。本当にすごいですね(語彙力.........)。

※現在、当社パイプラインツールはWindowsのみの対応となっています。ご了承ください。

TEXT_痴山紘史 / Hiroshi Chiyama(日本CGサービス
EDIT_尾形美幸 / Miyuki Ogata(CGWORLD)

アセットのバージョン管理について考える

前回までで、アセットやショットを管理するために必要な情報を扱うことができるようになりました。実際に作業を行う現場ではもう少し詳細な情報が必要になってくるものの、プロジェクト全体の管理を行う人たちは、これくらいの情報があれば状況の確認や各種判断ができるのではないでしょうか。

今回は、現場で作業を進めるために必要なアセットのバージョン管理について考えていきます。

そもそも、バージョン管理って何? そんなものいるの? という疑問をもたれる方もいるかと思います。たしかに、アセットのバージョン管理を行わなくても作業を進めることはできますし、必要であればファイルを別名保存して手動で管理することもできます。バージョン管理システムを導入して運用するとなると、覚えなければいけないツールが増えますし、日々の作業の中でバージョンというものを意識する機会も増えるため、最初はわずらわしく思うこともあります。

それでも、たとえ個人作業であっても、バージョン管理をきちんと行うことはとても大事です。また、一度身に付けてしまえば、そのメリットをずっと享受できるとてもお得な習慣です。

バージョン管理を行うメリットのひとつが、作業履歴を追いかけられることです。アセットに問題が起きたとき、その原因を究明したり、過去にどのような修正を行なったかを確認したりすることはよくあります。きちんとバージョン管理が行われていれば履歴を追いかけられるため、必要な情報を得ることができます。また、あるバージョンに問題が起きたとき、即座に過去のバージョンと行き来できる点も大きなメリットです。これがないと、ショット作業中に新たにリリースしたアセットで問題が発覚したときに、アセットを修正しないとショット作業を進められないという事態が起きてしまいます。さらに、既存アセットの変更も気軽に行うことができます。何か変更をして失敗しても、その内容を捨てて直前のバージョンからやり直せる安心感は、精神衛生上とても良いです。

バージョン管理は、一度その良さを体験してしまうと、どうやってそれなしで作業を進めていたのか思い出せなくなってしまうほど強力なテクノロジーです。例えるなら、昭和時代は携帯電話なしで人と待ち合わせをしていたなんて、今では全く想像できないですよね。それと同じくらいのインパクトがあります。

様々なバージョン管理の方法

最も原始的なバージョン管理は、手動でファイル名を別名保存していく方法です。この方法は手軽に始めることができる反面、メリットはかなり限定的です。まず、大本になるシーンファイルのみが管理対象となり、その中で使用されているテクスチャファイルなどは管理されないため、作業が進んで関連ファイルが更新されると、元のファイルを開いても当初の状況が再現されなくなってしまいます。また、あるバージョンのときにどのような作業をしたのかという情報も存在しないため、過去に戻って作業履歴を確認したい場合にも困ってしまいます。全て手動で行なっているため、作業者の好みによって運用されたりされなかったりもします。結局この方法で得られるメリットは、何らかの理由でファイルが壊れてしまった場合に壊れていないファイルを探し出して復旧できるかもしれないというくらいです。

次に行われるのが、ファイル保存ツールを使用して自動的にバージョン更新をしつつ、作業内容をメモとして残しておけるようにする方法です。当社パイプラインツールのFileRequesterでもこのような機能を備えていて、ファイルを保存してもファイルが直接上書きされるわけではなく、古いファイルをarchiveディレクトリに移動した上でバージョン管理をしています。これにより、途中でファイルが壊れて全てのデータがダメになったり、ファイル保存中にアプリケーションがクラッシュしてファイルが壊れてしまったりすることを防いでいます。下図は同じファイルを数回保存したあとのarchiveディレクトリの内容です。


このようにツール化することで、ユーザーはバージョン管理していることをまったく意識することなく作業に集中できます。

さらにシステム化を進めると、パブリッシュ(出荷と呼ばれることもあるようです)を行うようになります。これは、シーン中で参照しているファイルを全て収集し、作業場所とは別の場所に保存した上で、詳細情報をデータベースに登録することです。ここまでできると、パブリッシュ時に作成されたアセットの状態を完璧に保存することができます。また、あるバージョンで、誰が、いつ、どのような作業をしたのかという情報も確認できるようになります。

バージョン管理ツールを使用する際の問題点

バージョン管理については第20回:クラウド環境構築[クラウド環境でのアセット管理]でも少し触れ、既存のツールもいくつか紹介しました。

このときにも触れたように、世の中にはバージョン管理システムが多数存在するものの、映像制作用途では「コレ!」と言えるものが意外と存在しないです。特にネックになるのが、異なるバージョンのアセットに同時アクセスできないことです。また、プログラムとちがって変更内容をエディタで確認できないことも困った点です。

プログラムのバージョン管理を行うのであれば、最終的な成果物はある決まった状態のソースコードから生成されるため、過去のバージョンのファイルがディスク上に同時に存在する必要はありません。また、変更内容を確認する場合はバージョン管理システムの機能を使用してテキストベースで簡単に差分を表示できます。例えば、下図はGitHub上で公開されているPythonのソースコードの変更内容を表示したものです。


それに対し、3Dデータや画像データは過去との変更点を確認することが難しいです。Maya ASCIIファイルであればプログラムと同様差分表示はできますが、よっぽどシンプルなものでなければ、差分を見ただけで何が行われているかを把握するのは難しいです。例えば、空のシーンに対してSphereをひとつ作成しただけの差分を表示しても下図のようになります。


さらに、ヒストリの削除をすると下図のようになります。こうなったらまったく手に負えないですね。


こんな状態でもテキスト形式のファイルであれば、がんばって差分を見ることもできますが、バイナリ形式になるとさらに難しくなってきます。画像データであれば差分表示ができるツールもあります。例えばHelix P4Mergeです。このようなツールを使うことである程度問題は解消できますが、ツールが対応している画像フォーマットに限定されますし、3Dデータやオーディオデータのように差分の可視化が難しいデータも多く残っています。また、ZBrushのシーンファイルのように特定のソフトウェアでしか読めないデータの場合は、ソフトウェアなしに内容を確認すること自体が難しいです。

そうなると、異なるバージョンのファイルが同時にディスク上に存在している状態で、それらを同時に開いてビューポート上で確認することが必要になってきます。しかし、前述のとおり既存のバージョン管理システムでは複数のバージョンに対して同時にアクセスすることが考慮されていないので困ってしまいます。

そうは言っても何とかバージョン管理はしなければいけないです。そこで、アセットに関しては承認されたバージョンをチーム内で使いまわすのが正しいやり方だとして、この問題に目をつぶってバージョン管理システムに乗せたとしましょう。そこを何とか乗り越えたとしても、プロジェクトの後半に進むにつれて雲行きが怪しくなってきます。

シミュレーションやレンダリングの結果を使用するとき、前半はVer.10、後半は改良を加えたVer.11を使いたいということがよくあります。さらに、コンポジット段階で複数のバージョンをミックスして成果物をつくるような場合もあるため、単純なバージョン管理では対応できなくなってしまいます。

パブリッシュツール

当社では前述した問題に対応するため、自前でパブリッシュツールとバージョン管理システムを開発しています。パブリッシュツールは日々使用するツールなので、極力高速に動作するための工夫をしており、例えば合計数GBのシーンデータを数秒でパブリッシュすることも可能になっています。Variation(shots側はshot)階層(※1)直下にpublishディレクトリがあり、その下に(作業フェーズ)/(タスク)(※2)という名前の階層が続き、その中でバージョンごとにrev001, rev002...と階層を作成し、パブリッシュを行います。パブリッシュ階層の例は下図のようになります。

※1 階層構造については第24回:アセットの階層について考えるを参照。
※2 タスクについては第25回:タスクの構成について考えるを参照。


revXXX 以下に必要な全てのファイルが揃っているため、外部の会社へのデータ提供も簡単にできます。一見すると深くて複雑に見える階層ですが、これまでの記事で考え方を全て説明済みなので理解には苦労しないはずです。

全てを自作しなくても、最近はオープンソースのパイプラインツールも増えており、そちらを使用するケースも増えています。例えばPyblishは日本でも採用事例が多いパブリッシュツールです。本誌『CGWORLD』vol.268(2020年12月号)掲載記事「Stellaと共に進化するアニマのHoudiniエフェクト」で紹介されているパブリッシュ用ツールも、Pyblishをベースに改良したもののように見えます。

まとめ

今回はアセットのバージョン管理について考えていきました。映像制作とバージョン管理の組み合わせは最初は取っ付きにくいところもありますが、ここがきちんとできているか否かはプロダクションのレベルを上げる際の最初の壁になってきます。もちろん越えなくても仕事を回していくことはできますが、Shotgunや、そのほかのモダンな管理ツールを使おうとしたときに十分な効果を発揮できるか否かにも直結してくるので、がんばる価値は大いにあります。



第29回の公開は、2020年12月を予定しております。

プロフィール

  • 痴山紘史
    日本CGサービス(JCGS) 代表

    大学卒業後、株式会社IMAGICA入社。放送局向けリアルタイムCGシステムの構築・運用に携わる。その後、株式会社リンクス・デジワークスにて映画・ゲームなどの映像制作に携わる。2010年独立、現職。映像制作プロダクション向けのパイプラインの開発と提供を行なっている。新人パパ。娘かわいい。
    @chiyama

その他の連載