>   >  痴山紘史の日本CG見聞録:第23回:パイプラインのルールについて考える
第23回:パイプラインのルールについて考える

第23回:パイプラインのルールについて考える

みなさんこんにちは。最近、我が家ではステイホームのかけ声を言い訳に、漫画セットの購入がはかどっています。そんな中でちょっと前からSNSでも話題になっていた『ブルーピリオド』(作者・山口つばさ/出版社・講談社)も購入して読んだんですが、噂にたがわず面白かったです。おかげで、今はすごく油絵を描きたいです。いやー、やっぱりアナログいいですよねっ!!

前回は当社で開発しているパイプラインツールのインストールと、ランチャーを使用したツールの立ち上げの確認をしました。今回は、前半では当社で別のアプローチから開発している類似ツールと、パイプラインツールのちがいを比べてみます。後半では本筋に戻り、ツールを使用してプロジェクト用のフォルダを作成しながら、フォルダ構成やルールのつくり方について考えていきます。

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

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

目的によるツールのちがい

当社では最近、個人・小規模チーム向けツールランチャーcrumenaをリリースしました。既にパイプラインツールとしてランチャーがあるのに、なぜ別のランチャーをつくったのかを説明することで、第21回で解説した「ツール開発とパイプライン整備のちがい 」を具体的に実感していただけると思います。

前回ご紹介したランチャーが、複数人でプロジェクトを回すためにある程度カッチリした環境をつくる用途で使うものであるのに対し、crumenaはもっと手軽に、個人レベルでパパっとお手軽に使うことを目指しています。例えば、作業で使う便利スクリプトをスクリプトエディタにチョチョッと書いたものを残しておいて、毎回そこから実行するという使い方をしている方は多いです。そしてプリファレンスが死んで全て消えるという(苦笑。そういう、ちょっと書きツールをcrumenaに登録して簡単に管理することができます。

crumenaは、作業をするユーザーの利便性を向上させることが目的なので、カスタマイズもユーザー単位で、GUIを使って手軽に行えるようになっています。アイテムの登録はとても簡単で、実行したいスクリプトファイルやコードをcrumenaにドラッグアンドドロップするだけです。


好きなアイコンをセットするのも簡単です。登録したスクリプトファイルと同名のPNG画像があれば、自動的にアイコンとして使用します。また、クリップボードに保存した画像をアイコンとして使用することもできます。


パイプラインツールで同様のことをするためには、設定ファイルを編集する必要があります。例えば、Mayaのメニューに項目を追加する場合、C:\JCGS\JCGS_1.0.2209\JCGSProject\baseProject\conf\menuMaya.xml.default を、C:\JCGS\JCGS_1.0.2209\JCGSProject\(プロジェクト名)\conf\menuMaya.xml にコピーして編集します。慣れれば大したことない作業ですが、誰もが手軽に管理できるというほど簡単でもないです。このようになっているのは、そもそもXMLファイルを手で書ける程度にスキルのある人がメンテナンスを行う前提で提供しているからです。そういう人にとっては、下手にGUIがあるよりも、直接XMLファイルを編集できた方が楽だからです。

前回立ち上げたランチャーは、厳密に決められたルールの上で多くのスタッフがひとつの作品をつくるための映像制作パイプラインの入り口であり、パイプラインという大きなシステムに組み込まれたパーツです。そのため、ランチャーだけ切り離して使用しても十分な効果は得られないですし、ランチャーのないパイプラインというのも存在し得ないです。逆に、パイプラインの入り口としてランチャーを用意することで、パイプラインを構築するための強固な基盤をつくることができます。

これに対しcrumenaは、単独で動作し、使用するためのルールも極力シンプルにし、使い方もユーザーに任せることによって、手の延長線上にあるように使ってもらえることを目指して開発しています。また、スタンドアロンとして動作する以外にも、Mayaや3ds Max上で動作し、そのときに使いたいツールに最小限のクリック数でアクセスできるようにしています。

このように、ひとくちにランチャーと言っても両者には大きなちがいがあります。crumenaを使って大規模なパイプラインの構築をしようとしても、そもそもツール本来の目的から外れてしまっているので、いろいろと無理が生じてくるでしょう。

フォルダ管理について考える

ここからの後半では、パイプラインツールを使用したプロジェクト用フォルダ管理について考えていきます。

プロジェクトで使用するフォルダ階層を奇麗に保つことは、作業効率を上げるための最も大事な要件のひとつです。シンプルで一貫性のあるルールに沿ってきちんと管理されたフォルダ階層があれば、データ管理の多くをツールに任せることができますし、アーティストが気にしなければいけないことも減らせます。

フォルダ構成については、エクスプローラなどを使ったファイルへのアクセスが大変という理由により、プロジェクトのトップ以下にアーティスト作業用フォルダを用意するケースをよく見かけます。また、作業用フォルダ内で階層をたどるのが大変という理由から、指定した階層以下の全ファイルを列挙できるようなツールがほしいという要望が出ることもよくあります。ツールを使わないで、目の前のクリック数を減らすことが目的であればごく自然な発想です。

この場合、作業フォルダ内にプロジェクトの全データが集まってしまうため、プロジェクトの規模が大きくなるにつれて中身がどんどんカオスになってしまいます。また、カオスになったフォルダから必要なものを取捨選択できないため、ファイルサーバが一杯になってもデータの整理ができず、プロジェクト終了後にバックアップを行おうにもどのデータが必要か判断できないので、全データをとりあえず残しておくか、「エイヤッ!!」とデータを削除して後は運に任せるということになりがちです。

数人で作業して短い期間で終わるプロジェクトであれば何とかなるかもしれませんが、ちょっと規模が大きくなると、この方法での運用はとても辛いことになります。

当社のパイプラインツールでは、フォルダ階層をassetsとshotsの2つに分類し、それぞれを3階層で管理しています。これに例外はなく、あるショットだけは細かく管理したいから4階層にするといったことは絶対にしません。

作業用フォルダも各階層の中に入れ、あるショットに関連するファイルは全てその階層の中に含まれるようにしています。これにより、誰でも簡単にファイルを探せるようになったり、納品の終わったショットのデータを丸ごと削除できたりするようになるため、データ管理コストを大幅に削減できます。

深い階層を作成して管理する場合、作業用ファイルにアクセスするためにはプロジェクトのトップ階層から4階層以上たどっていく必要があるため、エクスプローラを使用するのはかなり大変です。この問題に対しては、プロジェクトのルールに沿ってファイルにアクセスするためのFileRequesterを用意して対応しています。

このように、人が手動で管理する前提のフォルダ階層と、コンピュータの力を使って効率的に管理する前提のフォルダ階層は、まったく異なる形になるのです。

次ページ:
フォルダをつくってみる

その他の連載