9月23日（土）に秋葉原・UDX GALLERY NEXT／UDX GALLERYで行われたアニメ制作技術の総合イベント「あにつく2023」。4年ぶりにリアル開催となった本イベントから、株式会社ENGIによる「長編3Dアニメーション制作におけるテクニカルチームの重要性2 ～GAMERA -Rebirth-制作上の課題と解決事例～」の内容を一部お送りする。

イベント概要

『GAMERA -Rebirth-』で実感したワークフロー＆パイプラインの重要性

「長編3Dアニメーション制作におけるテクニカルチームの重要性2 ～GAMERA -Rebirth-制作上の課題と解決事例～」に登壇したのは、ENGIの帆苅 哲氏（3DCG部 テクニカルスーパーバイザー・テクニカルチームリーダー）。本セッションは前年の続きということで、パート2と謳われている。ちなみに前年の時点では、作品タイトルが未発表のまま講演が行われた。

帆苅氏は「今回のセッションではワークフローやパイプラインを整えることの重要性について。そして整えるルールなどについて説明します。ガメラという作品の主役である怪獣が出てこない、一見地味なお話で恐縮ですが、なぜそれらが重要なのかを伝えたいです」と話し、解説に移った。

ファイル大量消失の原因とその回避方法

プロダクションのデータは、アセットとショットに分けられている。もしこれらのデータが消失したら……と考えるだけでヒヤリとするが、同プロジェクトでは実際に大量のアセットデータが消失した。

バージョン管理にはGitやPerforceなどのツールがあるが、ENGIではSVN（Subversion）を使用している。『GAMERA -Rebirth-（以下、GAMERA）』でも不意のトラブルに備えてSVNを使っていたが、誤操作によって上位階層の「Prp」というフォルダの全てのデータが消えてしまったという。

WindowsとSVNでファイルパスの扱いが異なることを、帆苅氏は後になってから知ったそうだ。GitはENGIのエンジニアも扱っていたので知っていたが、バイナリデータの扱いでSVNを使うこととなり、取り扱いのちがいに対して認識が甘かったため、人為的なミスが起こった。

ことの発端は、外部の協力会社にSVNからGoogle Driveを通してファイルを渡していたことだ。理由としては、どのバージョンのファイルを渡しているかすぐわかる点、そして前バージョンに復元するのも容易な点が挙げられる。ところがここで、不要なファイルが協力会社に渡ってしまっていた。

原因はSVNの削除（deleted）ステータスの取り扱い。そしてGoogle Driveのファイルの取り扱いの問題だ。SVNの中で大量のファイルのやりとりがされているが、Google Driveは細かいやりとりが得意ではない（そういう使い方が想定されていないため）。

SVNでは、リポジトリ（本体）に作業しているフォルダからコミットという登録処理が行われる。何か変更がある度にコミットが走るため、ファイルを追加したらコミット、削除（deleted）したらコミットという処理が実行される。

ENGIが使い慣れていたGitでは、作業フォルダからファイルが消えると、自動的に削除（deleted）としてコミットされ、本体に記録されていた。

一方、SVNでは単にフォルダから消えても見つからない状態（missing）になる。本来、リポジトリには、SVN上で消えたというステータスでコミットしなければならない。それが、リポジトリにmissingのまま、いらないファイルが残ってしまっていた。

この「いらないファイル」を外部の協力会社に渡らないようにするために、missingファイルをリポジトリ上で全て削除（deleted）になるようにした。

問題はその際に起こった。プロップ全体を管理している"Prp"という大文字"P"始まりのフォルダが、プロジェクト初期に誤って"prp"と小文字の"p"始まりとして記録されていたのだ。

ここで重要なのが、冒頭に述べたWindowsとSVNでのファイルパスの取り扱いのちがいである。Windows上ではファイルパスの大文字／小文字は区別されないが、SVNでは他OSにも対応しているため、大文字／小文字を区別する仕様になっている。

プロジェクト初期に"prp"として小文字始まりになっていたフォルダは、当時運用していた大文字始まりの"Prp"フォルダとは別フォルダとして、SVN上でmissingとして取り扱われていた。そして、"prp"フォルダをdeletedに変更した際にWindows上では"Prp"と"prp"の区別をしないため、運用フォルダの"Prp"が消える、 という事態が起こったのだ。

この事例からわかるように、ワークフローとパイプラインを整えることは非常に重要だ。WindowsでSVNを使う判断自体は妥当だが、ファイルやフォルダの命名規則など、こうしたミスを起こさないよう適切な技術選定、ルール設定が重要になる。

では、改めてなぜルールやしくみ（ワークフローやパイプライン）が必要なのか。それはつくりたい作品を適切なコストで実現するためであり、人的コストや時間的コストやサーバコストなど、コストを測るためのフォーマットとしてのルールやしくみをつくっていかねばならないからだ、と帆苅氏は言う。

例えばプロジェクトが定義されていなければ、プロジェクトのファイルサイズが定義できない。どのくらいのサイズを使うのかを測るため、プロジェクトごとにフォルダを切ったり、レンダリング時間を記録するためにレンダージョブ名を決めたり、どのくらいの人数がどれだけ働いたのか工数を計算することが必要となる。

自動化すればコストを削減できるが、自動化するためのルール設定が必要になる。サーバコストを削減するためには、ファイルサイズの圧縮が必要になる。Mayaであれば.maと.mbのうち、.mbの方が圧倒的にファイルサイズが小さいが、GAMERAでは他を削減し.maを選んでいる。というのも.maは.txtに変更して読むことができるため、プログラムを書く人間が扱う場合に都合がよいからだ。

データが消えてしまった場合は、つくり直すためにバックアップが必要になる。万が一のファイル消失に備えてバージョン管理をする必要がある。結局のところ、「一見ある部分では煩雑見えるルールを設定した方が、全体としての"煩雑さの総和"を少なくできる。そういう環境をつくるべきだ」と帆苅氏は言う。

また、自分たちがわかりやすくても、次に使う人間がわかりにくい場合もあるかもしれない。そのため、後から入ってきた人のために適切に説明できるルールをつくる必要もあると言う。例えば、実際には難しいかもしれないが、Mayaでも3ds MaxでもBlenderでも使えるようなルールづくりがあると良い。

ルールはコミュニケーションのベースであり、結局は「何をつくりたいか、どうやってつくっていくか」というコミュニケーションのために必要となる。

では、よりよいしくみづくりのために、するべきことは何だろう。

まず重要なのは、全体のながれと各工程を把握することだと言う。先ほどのWindowsとSVNの話も、何が起こるかを把握していないとルールの決めようがない。例えば、作業するスタッフから「小文字で統一すると読みづらい」と言われたときに、「こういうミスが起こる可能性があるから、小文字で統一している」という説明が必要になる。このように、全体のながれを踏まえた上で、各々を把握することが重要だ。

ファイルの命名規則でよく挙げられるのは、日本語文字列（2バイト文字）や特殊記号を使わないこと。WindowsとSVNの間で大文字／小文字を区別するか否かが異なっているように、Mayaと3ds Max、Blender、After Effectsのようなツール、PythonとJavaScriptのようなプログラミング言語の間でもデータの解釈が変わってしまうことがある。

ENGIでは、Mayaから出力したチェック情報等をGoogleスプレッドシートへ自動的にアップしていた。スプレッドシートへはJavaSctiptベースのGoogle Apps Scriptでアップする。Mayaからの出力時はMELかPythonを使う。プログラミング言語の間で齟齬が生まれかねないので、2バイト文字や特殊記号は使わない方がよい。勘違いしやすい言葉は使わない方が良いというのは、人のコミュニケーションでも同様である。

作品づくりを通して得ることができる普遍的な知識・技術

「作品を通して初めて理解する」ことも多い。それは普遍的な知識や、様々なプロジェクトに応用可能な知識だ。

『GAMERA』の制作で得られた知見も多い。『GAMERA』ではレンダーディスパッチャーのThinkbox Deadlineを用いてレンダリングを行なっていたが、レンダリング以外でもDeadlineを活用してエラーチェックのジョブ登録などを行なっていた。

Maya独自の機能である2Dパンズームは当初他ツールに移植できずに難儀したが、最終的には成功した。これはアニメ表現をする上で強力な機能であり、他の作品でも応用する予定だと言う。リギングモジュールのmGearも『GAMERA』では積極的に使われた。

Google WorkspaceではGoogle スプレッドシートの利用が多く、主にエラーデータのチェックを行なった。Adobe製品ではAfter EffectsやPhotoshopの自動化も行なった。他にもシェーダの作成を行なったり、SlackとShotGridを連携してレンダリング依頼やエラー報告通知などをSlackで受け取れるようにしていた。

『GAMERA』の終盤では、自動でレンダリングして自動でShotGridに上げてチェックを行なっていたという。

現在、ENGIではさらに良いしくみづくりのために、プロジェクトを統一的に扱えるしくみを計画中だ、と今後の展望が明かされた。