ハリウッドVFX業界就職の手引き

ハリウッドVFX業界就職の手引き
鍋潤太郎氏による、海外のVFX業界で働くための手引き。お薦めです。

2013年1月14日月曜日

ワーク・フローとパイプラインを考えてみる その3

木村でございます。早くも更新のスピードが遅れて参りました。ブログも3回目にして風前の灯という感じでしょうか。実は年が明けてから本業の方が忙しくなり、この週末も働いておりました。「家に帰ったらブログ書くか」といつも会社では思うのですが、帰ると何となくテレビを見たりゲームをしたりしてしまいます。つまり仕事のせいではないということなのですが、あまり無理をしても続かないので、このペースでいきたいと思います。

実は最近ブログを読んで頂いている方から、ブログでの言葉に関して、「フューチャー・アニメーションではなく、フィーチャー・アニメーションではないのか」というご指摘をいただきました。確かにフューチャー・アニメーションですとFuture Animation、未来のアニメーションという風に聞こえてしまうので、Feature Animation、フィーチャー・アニメーションと記述するのが妥当でしょう。「ええそうですよ、私は未来のアニメーションの話をしていたんです」と意固地になってフューチャー・アニメーションと言い続けてもいいんですが、さすがにそれは大人げないので、これからはフィーチャー・アニメーションでいきたいと思います。

3回目ですが、前回の予告通りデータ・ストラクチャのお話をさせて頂きます。


データ・ストラクチャ

前回は各デパートメントがアセットをどう出荷するか、というお話をさせて頂きました。ではこれら出荷されたアセットは、どういったデータ・ストラクチャ上にまとめられるのでしょうか。各プロジェクト(長編映画では、ショウ “Show” 呼ばれることが多いです)毎のディレクトリが作られ、以下のような階層でデータが管理されるのが一般的です。

  1. ショウ
  2. シークエンス
  3. ショット
  4. アセット・グループ

図式化するとこんな感じになります。




すいません、私、表とかグラフとかを書くのが非常に苦手でして、本当であれば線引きツールとかを使ってちゃんとしたチャートを作るべきなのでしょうが、とりあえずこれでご勘弁頂きたいと思います。ちなみに右下のニコニコマークはスペースが余ったので描いただけで、他意はありません。

シークエンスは、同じようなロケーション、時間軸上に存在するいくつかのショットの集まりです。そしてそれらのシークエンスが集まって、一つのショウをなします。アセット・グループは、例えばジオメトリやパーティクルのグループだったり、イメージ・パスのグループだったりします。もちろん、ショウ全体で使われるような、この階層下に入らないアセットも存在しますが、ショットごとに必要になるアセットは基本的にこの階層下に入ります。

こうしたデータ・ストラクチャの構築の一番の肝は、アセットの所在を抽象化できることにあります。例えば、ある映画プロジェクト”movieA”のシークエンスDEFのショット004にカメラが出荷されているとしましょう。大体以下のようなイメージの階層になります。

/show/movieA/DEF/004/layout/camera.data

かなり大雑把なイメージですが、layoutがアセット・グループだと思ってください。これを例えばライティングのシーンにインポートする場合、通常アセットをインポートする専用のカスタム・ノードやデータ・セットがあり、このカメラ・データは単にlayout/camera.dataと認識されます。なぜならどのシークェンスのどのショットかは、既にライティングの作業がどこで行われているかで、わかるからです。ちなみにここでインポートと書きましたが、1つ重要なことがあります。他のデパートメントのアセットは、その実データが参照できるだけで、実際に自分のシーンの中に取り込んでしまう訳ではありません。市販のアプリケーションで言えば、MayaのFile ReferenceやHoudiniのfile SOP(リード・オンリー)の様なものです。それによりアセットがその出荷元のデパートメントによって更新された場合、常に最新のものを読み込めるようになるだけでなく、このDEF/004のライティングのシーン・ファイルがテンプレートとして他のショットで再利用できるようになります。つまり、単純にlayout/camera.dataというパスだけが記述されたアセット・インポート・ノードは、他のショット、例えばシークエンスGHIのショット002に持っていっても、camera.dataがちゃんとそのショットに出荷されてさえいれば、そのまま利用できます。

以前働いていたある会社では、この肝がわからずに、こうしたデータ・ストラクチャを単に整理整頓という程度の目的だけに使っていました。またあるプロダクションでは、アセットの取り込みには上手くこれを活用していたのですが、ライティングで吐き出されるレンダリング用のキャッシュ・データ(ポイント・クラウド、デプスマップ・シャドウなど)のパスが抽象化されておらず、テンプレートの元になったショットのキャッシュを使ってレンダリングし、そのままディレクター・アプルーブ(承認)までいってしまったことがあります。テンプレート元のショットがその後キャッシュを更新して問題が発覚し、結局ライティングがやり直しになりました。

この辺のパイプラインは多くの場合、独自のツールが必要になりますが、一番基本的な部分ですので、プロダクションの規模が大きい場合はやっておいた方がいいでしょう。アプリケーションによっては、こうした抽象化を支援するためにファイル・パスやパラメータなどに変数やエクスプレッションの利用を認めたり、ビルドインのスクリプト言語をサポートしているものがあります。まとめさせて頂きますと、

  • 常に決まった階層の決まった場所に、アセットを格納する
  • 常に、決まったルールでアセットに名前を付ける(ネーミング・コンベンション)

図表に示した階層は、あくまで一番自然でよく使われる階層という意味であり、別にそうしなければない訳ではありません。しかし、一度どういう階層にし、どういう風に名前を付けるかを決めたら、全てをそのルールに従って作っていきます。そうすることでパイプラインのツールがアセットを管理し、単純作業をツールに任せることが出来るようになります。物量が多い場合、非常に重要なポイントです。

次回はプロダクションの指揮系統であるマネージメントについてお話ししたいと思います。

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。