9月23日（土）に開催された「あにつく2023」より、「長編3Dアニメーション制作におけるテクニカルチームの重要性2 ～GAMERA -Rebirth-制作上の課題と解決事例〜」のイベント内容をご紹介します。

---

ウェビナー概要

長編3Dアニメーション制作におけるテクニカルチームの重要性2 ～GAMERA -Rebirth-制作上の課題と解決事例〜

9月7日にNetflix様で配信開始を予定しております『GAMERA -Rebirth-』で実際に起こった事例を主として、プロジェクト内でどのような課題や問題がおこり、テクニカルチームの視点からどうやって他チームと協力し、どのようなアプローチで、どのような解決に至ったかについてお話したいと思います。あまり普段は表に出てこないアニメーション制作上の実際に起こる問題を具体例を挙げながらお話できればと思います。
また、弊社”ENGI”がどういったチーム構成で制作しているのかご紹介できればと思っています。

【主催】株式会社Too
【特別協賛】オートデスク株式会社
【協賛】キャノン株式会社、
　　　　株式会社ピー･ソフトハウス、
　　　　株式会社フォースメディア、
　　　　株式会社ワコム、
　　　　Wasabi Technologies Japan合同会社
【後援】CG-ARTS
【講師】株式会社ENGI　帆苅 哲 氏

---

概要紹介

前置き

本セッションは、昨年度も同じ題名で講演しました。主に業界の方、特に業界就職を考えている方に向けて、3Dアニメのテクニカルな部分を紹介するのが目的です。そのため、既に業界にいる方にとっては冗長な説明が多いと思います。

今回は昨年よりも詳しい話をするため、少し細かい話が多くなっています。用語なども1つずつ説明するため、今後の仕事に役立つ内容だと思ってお聞きいただければ幸いです。

昨年度は、「長編3Dアニメーション制作におけるテクニカルチームの重要性」という同じタイトルで講演しました。そこでは、まだタイトルが発表できていなかった『GAMERA -Rebirth-』のパイプラインやワークフローについて説明しました。今回はタイトルが発表されたこともあるため、より詳しく実際の制作事例を踏まえて説明していきます。

会社紹介

まずは、簡単に株式会社ENGIの紹介をします。2018年4月4日に設立した、今年で6期目のまだ若い会社です。弊社は、KADOKAWA様とサミー様、ウルトラスーパーピクチャーズ様の出資で設立しました。作品を制作してる部署としては、四つの部署があります。

まずアニメーション制作部。2D作画部と言った方が分かりやすいかもしれません。作画アニメーションを作成している部署です。

その他に、私も所属している3DCG部と遊撃機部、デジタルコンテンツ開発部の合計四つの部署です。デジタルコンテンツ開発部では、縦スクロールマンガやSpineを用いたムービーなどを制作しています。ゲームのムービー制作の他に、テレビアニメ内のSpineムービーなども制作しています。

それぞれの部署が元請として別の仕事を受けていたり、一緒に同じ作品で協力し合いながら強みを活かして制作しています。元請作品としましては、一部抜粋ですが『旗揚！けものみち』や『宇崎ちゃんは遊びたい』、『探偵はもう死んでいる』、『「艦これ」いつかあの海で』などがあります。

そして、3DCG部の初めての元請が、今回の題材になっているGAMERA -Rebirth-になります。

自己紹介

簡単に私の自己紹介をします。株式会社ENGIの3DCG部で、テクニカルスーパーバイザーをしている帆苅哲と申します。大学卒業後はさまざまなことをしていましたが、一念発起してバンタンゲームアカデミーのCG科に入学しました。卒業後、2020年に株式会社ENGIに入社しました。

業界歴はそこまで長くないですが、人と作品と会社に恵まれて、今回のGAMERA -Rebirth-ではテクニカルスーパーバイザーという役職をいただきました。作品の内外のデータの取り扱い、ツールの作成などを統括する役職です。

GAMERA -Rebirth-（プロジェクトコード：GMR）

ここからは、GAMERA -Rebirth-について説明します。瀬下寛之監督率いるチームが企画や脚本をして、ENGIの3DCG部が元請として制作しました。2023年9月7日よりNETFLIXで配信されています。

3DCG制作では、作品ごとにプロジェクトコードを付けます。タイトルが長い場合に、短く呼ぶためのコードです。本作品では、頭文字を取って「GMR」にしました。以降はGMRと呼んでいきます。

GMRのワークフロー・パイプライン

画像は、昨年度も紹介したGMRのワークフロー・パイプラインの図です。業界外の方にはなじみがない言葉だと思うため、少し説明します。簡単に言うと”ワークフロー・パイプライン”とは”やり方や仕組み”のことで、パイプラインは高速道路でいう道路、ワークフローは道路の走り方だと思ってください。

アニメの制作フローは、大まかに「プリプロ」「プロダクション」「ポスプロ」の3つの段階に分けられます。プリプロとはプロダクションの前の、企画、脚本、それに基づいた劇伴作成などの段階です。

プロダクションとは、実際にアニメを作っていく段階です。3Dアニメーションでいうと、モデルやリグ、アニメーション、その他皆さんが一般的に想像される”アニメーション制作”を行う段階をプロダクションといいます。その後のポスプロとは、出来上がった映像を編集する段階です。テレビアニメの決められた放送尺に合わせて編集する、尺に合わせた映像に音を合わせるなどの段階をポスプロと呼びます。

プロダクションの詳しい中身に関しては昨年度と全く同じ内容になるため、興味がある方は昨年のイベントレポートを見てみてください。 https://www.too.com/dc/report/2209_atsuc2022_engi/

今回は、実際に起こった事例をもとに、ワークフローやパイプラインを整える重要性について説明します。

さきほどGMRのプロジェクトコードの話をしましたが、さまざまなものにコード名やファイル名を付けたりと、結構煩雑なルールがあります。また、ファイルやフォルダの命名規則も細かく決めていますが、なぜこれらが必要なのかという説明もしていきます。

実際に起こってしまった事例A ケース紹介

これは実際に起こった事例、「SVNの誤操作による大量のアセットデータの消失」の話です。よく分からない用語も多いかもしれませんが、大量のデータの消失という字面だけでも嫌な予感がすると思います。

まずは起こった原因の説明と共に、細かい用語の説明をしていきます。

前提知識1

CGプロダクションのデータは、「アセット」と「ショット」という2つのデータに分けられます。アセットとは、人や物のことです。キャラクターは”人物”でわかりやすいかと思いますが、スライド内の”プロップ”とはマイクやペットボトルなどの小物のことです。その他乗り物など”人や物”を総称してアセットと呼びます。

もう1つショットとは映像のことです。カットという言葉は聞いたことがあるかもしれませんが、カットはカッティング編集した後のものを指します。そのカットされる前段階の映像の単位を、ショットと呼びます。シンプルにいうと、アセットは物で、ショットは映像ということです。

前提知識2

次に、”SVN”という用語の説明です。SVNとはSubversionの略称で、バージョン管理ツールと呼ばれているものの一つです。バージョン管理ツールでは、各ファイルの中身や編集歴などを管理しています。いつ、誰が、どのように編集したのかなどをリポジトリという本体に登録します。そうすることで、いつでも復元できるというとても便利なツールです。バグのトレーシングなどをする際には、このバージョン管理ツールが必須になります。

SVN以外にも「Git」や「Perforce」などのツールも有名ですが、弊社ではSVNを使っています。

GMRにおいても、SVNでバージョン管理を行うことでトラブルに備えていました。しかし、そのSVNの操作によって上位階層のフォルダが消えてしまうという自体が起こりました。さきほどプロップの紹介をしましたが、プロップデータをまとめていた上位階層の「Prp」というフォルダが全て消えました。なぜかというと、後述しますがWindowsとSVNの間でファイルパスの扱いに違いがあったからです。

SVNでは、バイナリデータがたくさん扱われています。そのバイナリデータの扱いに強いということでSVNを使うことになったのですが、これまであまりSVNを使ったことがありませんでした。結果として、その違いの認識の甘さゆえ、人為的ミスが起こってしまったというかたちです。

経緯1

詳しい経緯説明をしていきます。まず経緯1として、弊社では外部協力会社様にSVNからGoogleドライブを通してファイルを渡していました。理由は2つあり、1つ目は渡しているファイルのバージョンが即座に分かるからです。これはバージョン管理ツールの利点です。2つ目の理由は、前のバージョンに復元することも容易だからです。こういった便利さもあったため、SVNを使うことになりました。

しかし起こった問題として、大量の不要なファイルが外部協力者様に渡っていました。なぜかというと、SVNの削除ステータスの取り扱いの違いがあったからです。また、別件としてGoogleドライブのファイルの取り扱いの違いでも少し問題が起こっていました。

この話を詳しく説明すると膨大になってしまうため、概要だけ説明します。SVNでは、中身で細かいファイルを大量にやり取りして記録しています。Googleドライブは、そういった細かいファイルの大量なやり取りがあまり得意ではありません。そういった使い方を想定していないのにも関わらず、Googleドライブにデータを入れてしまっていたことも判断ミスの1つだったというわけです。

ここからは、SVNについて説明します。SVNには、リポジトリという本体があります。リポジトリに対して作業しているフォルダから変更があるたびに”コミット”という操作をします。つまり、ファイルを追加したらコミットする、ファイルを削除してもコミットするということです。

私たちが慣れているGitでは作業しているフォルダの中のファイルが消えると、自動で削除されたステータスとなって本体(リポジトリ)に記録されます。一方で、SVNでは作業フォルダからファイルを消しても、見つからない状態(Missing)というステータスになります。

このMissingのステータスは、リポジトリにはコミットされないのです。”ファイルが消えた”ということをSVNのリポジトリに記録するためには、消えた(Deleted)というステータスに明示的変更してコミットしないといけません。そのため、リポジトリに作業フォルダ上Missingになったままの不要なファイルが大量に残っていました。

外部協力会社様にMissingファイルがある状態のリポジトリからGoogleドライブを経由してファイルが渡っていたため、当然不要なファイルも渡ってしまっていました。

これは消さないといけないということで、判断1として「Missingファイルを全てリポジトリ上でDeleted（削除）の状態」にしようとしました。

経緯2

経緯2は、「最適化のためにファイル・フォルダの仕様を後で変更した」ということです。

これは本来やるべきではありません。ファイルやフォルダの名前はシステムの根幹に関わる部分だからです。後からの変更は、潜在的なトラブルの原因となりかねないため基本的には避けるべきです。しかし、その時はまだプロジェクト初期の段階であり、今後大きくプロジェクトが動いていく中で、ファイル名・フォルダ名を変えた方がより効率的でより安全に運用できるとプロデューサー陣やリーダー陣、スーパーバイザー陣とも相談して判断し、変更する決断をいたしました。

その結果、ファイル名・フォルダ名の変更により大量のMissingファイルが生まれました。原因を簡単に説明します。ある名前の変わったフォルダの下に大量のファイルがあったとします。実は、この名前が変わったフォルダはシステム上は新しくできたフォルダとして扱われ、元の名前のフォルダは消えたものとして扱われます。そのため大量のMissingファイルが生まれたというわけです。

また、名前の大文字・小文字の表記揺れも起こっていました。例えば、「test.txt」と「Test.txt」、「folder」と「Folder」などです。これはとても重要な要素で、実際にはフォルダが消えた根本原因になります。

なぜ大文字・小文字の違いの表記揺れが重要かというと、OSによってファイルの大文字・小文字の区別が違うためです。Windowsは大文字・小文字を区別しませんが、Linuxは区別します。MACでは、区別する・区別しないを選べます。

SVNは全てのOSに対応するように作られているため、大文字と小文字が区別されます。弊社はWindowsを使っているため大文字・小文字が区別されない一方、SVN上では区別されるということが起こっていました。

まとめ

ここで一度まとめます。ファイル名を変えたことが原因で、SVNリポジトリ上で、大量のMissingファイルができていました。その上、大文字・小文字の表記揺れも発生していました。

事例Aはなぜ起こったのか？

事例Aが起こった原因を追及していきます。経緯1として、外部協力者様に不要なファイルが渡らないようにするため、MissingのファイルをDeletedにしようとしました。そこには数万を超える大量のMissingファイルがあり、1つずつ手で登録するわけにはいかないため、一括でDeletedにしようとしました。Missingのファイルはサーバー上にないため、本来は問題ないはずでした。

ここで問題だったのが、Windows上では区別されない大文字・小文字がSVN上では区別される件です。

事例Aが起こった原因を簡単にまとめます。

プロジェクト初期では、アセット上位階層プロップをまとめていた大文字の「Prp」フォルダが小文字の「prp」フォルダになっていました。これが、SVN上では大文字の「Prp」と小文字の「prp」が両方とも別ステータスかつ別フォルダとして管理されていました。その後、SVN上のMissingを一括でDeletedにしました。

もちろん、小文字の「prp」フォルダもDeletedになります。そして、Windows上では小文字と大文字の区別ができません。これにより、「Prp」のフォルダも一緒に消えてしまったというわけです。こういったことを経て、ワークフローやパイプラインのルールや仕組みをしっかりと作ろうということになりました。

SVNは堅牢な仕組みであり、本来であればそう簡単にこんなことは起きません。本件が起こってしまった原因は結局のところ私の判断ミスです。コンフリクトの解消時の問題やそもそものワーキングコピーの管理などの細かい話など、安易な操作をしたせいでフォルダが消し飛ぶという自体を生んでしまいました。

こういう作業は本来業務終了後にやるのですが、当時はプロジェクトが動いてたため、残業してる方も数名いました。削除した瞬間悲鳴が上がり、私は立ち上がって「すいません。今日は帰ってください。」と言って皆さんに帰ってもらいました。すぐにサーバールームに駆け込んでサーバーの管理人に頼んでデータを復元してもらいつつ、SVN上の管理データも復元し、整合性も調べていました。

もう一度強調しますが、これは人為的ミスです。本来のSVNは堅牢な仕組みなため、こんなことは簡単に起こりません。

なぜ事例Aを取り上げたのか？

事例Aを取り上げた理由は、ワークフローとパイプラインを整える重要性をお伝えしたかったからです。ファイル名やフォルダ名の命名規則だけでなく、適切な技術選定やルール設定をすることがプロジェクト上非常に重要です。

ここからは、技術選定について少し掘り下げます。CGをやる以上PCが必要で、PCを使うならOSが必要です。そして、OSの中で高いシェアがあるWindowsを使う判断は妥当です。

プロジェクトではさまざまなファイルが動きます。そのため、ファイルのバックアップの取得や変更内容などの履歴を追うことは重要です。当然、バージョン管理をしようというのも妥当な判断です。そういった理由でSVNを使うことになりました。GitやPerforceもある中でSVNを選んだ理由ももちろんあるのですが、長くなるので今回は割愛させていただきます。

まとめると、Windows上でSVNを使うという技術選定自体に問題があったわけではありません。問題は、このような事例を起こさないために最初からルールや仕組みをしっかりと作っておくべきだったということです。

よりよい仕組み作りのために

では、より良い仕組み作りのために何ができるのでしょうか。

なぜルールや仕組みが必要なのか？

なぜルールや仕組みが必要なのかというと、作りたい作品を適切なコストで実現するためです。私たちは、お客様から評価をもらい、視聴料金などをいただくことで作品を作ることができます。そのため、適切なコストでより良い作品を作らなければなりません。そして、コストも人的コストや時間コスト、サーバーコストなどさまざまです。そのコストを測るフォーマットとしてのルールや仕組みが重要というわけです。

「工数」という、エンジニアの業界でよく使われる言葉があります。これは、何人が何時間働いたのかを測る単位のことです。こういった工数計算の仕組みを作っていくことも重要な要素の1つです。

もう1つの側面として、コスト削減のためのルールや仕組み作りも必要です。自動化するだけでも、莫大なコストが削減できます。しかし、プログラムはそこまで柔軟ではないため、自動化するためには細かいルール設定が必要です。

そもそもルールとは、煩雑さの総和を下げるために必要です。要は、一見面倒くさいルールを設定することで後々で全体が面倒くさくならないようにルールを作るべきということです。後の工程への情報伝達を簡単にするためや、後から入ってきた人達の混乱を防ぐためのルール設定をしなければなりません。

難しいですが、MayaやBlender、3dsMaxでも使えるなど、全てを統一的に扱えるのが理想です。そして、それができるようなルール作りをすることが重要です。ルールというのはコミュニケーションのベースです。何をどう作りたいかというコミュニケーションをするために、ルール作りが重要ということです。

よりよい仕組み作りのために私たちがするべきこと

では、よりよい仕組み作りのために私たちがするべきことは何でしょうか。それは、全体の流れと各工程で起こることを把握するということです。

さきほどのWindowsとSVNの話でも、流れや仕様が分かっていないとルールの決めようがありません。社内では事例Aを踏まえてSVNとWindowsで差異がでないようにファイル名は基本的に小文字に統一しようとしています。「小文字のみでは読みづらい。」という声が上がっているので上記の事例を説明して「こういった理由で小文字に統一させてください。」と各リーダー陣に説明しています。そういった説得力がある説明が重要です。

そのため、全体の流れを踏まえた上で、各々が小さいことを把握することも重要です。しかし、作品によって求められるものも変わるため、小さい各部分まで把握することは簡単なことではありません。やはり、作品を通してみて初めて理解することも多い側面もあります。そこでまず重要なのが、セオリーに学ぶことです。

セオリーに学ぶ

今回例に上がったファイルの命名規則でいうと、日本語文字列や特殊記号を使わないなどのセオリーがあります。なぜかというと、今回の事例のWindowsとSVNの間での大文字・小文字の区別が違うように、ツールでいうとMayaとBlender、MayaとAfterEffectsなど各ツール間で解釈が変わることがあるためです。また、OS間でもWindowsとMAC、WindowsとLinuxで解釈が変わることもあります。

弊社では、Mayaで出力したものをGoogleスプレッドシートに自動で上げるということもしていました。自動でGoogleスプレッドシートに上げるために、JavaScriptベースの『Google Apps Script』というものを使います。Mayaでは、Mayaの独自言語のMEL（Maya Embedded Language）かPythonを使います。

そのため、言語間の差によって文字化けが発生することもあります。文字化けが起こってしまうと、データのやりとりができなくなります。人のコミュニケーションと同様、勘違いしやすい言葉は使わないことが重要ということです。

プログラム言語同士の齟齬が生まれないように、ファイルの命名規則として日本語文字列や特殊記号を使わないことがセオリーということです。

また、さきほどのこの図にある工程分け自体が、CGプロダクションでよく使われるセオリーでもあります。モデルを作った後にリグを作って、その間はルックの構成やアニメーション付け、エフェクト作成があるというこの工程分けは一般的な構成です。

作品を通して初めて理解する

ルールや仕組みを作るために、「作品を通して初めて理解する」という話について考えてみます。作品を通して見ると、多くの普遍的な知識を得られます。つまり、色んなプロジェクトに応用可能な多くの知識を得られるということです。

GMRで得た知見には、

● Thinkbox Deadline
● Mayaの2Dパンズームの他ツールへの移植
● mgear
● ShotGridの運用・自動化
● ネットワークインフラ
● Google Workspaceの活用
● Adobeツール類の開発
● シェーダー周り
● Slack

などがありました。一部分を抜粋して説明します。

1つ目はThinkbox Deadlineの運用です。これはディスパッチャーというもので、レンダリングを多数のPCを繋いで一括で送るツールです。これを使い、自動でレンダリングしたチェックデータをShotGridというプロジェクト管理ツールに自動で上げていました。

2つ目は、昨年も取り上げたMayaの「2Dパンズーム」という機能です。これは、3DツールのMayaでも2D的な動き方ができる機能です。Maya独自の機能のため他のツールに移動ができず困ったことがありましたが、最終的には他ツールにも移植できるようになりました。アニメを作る上ではとても強力な表現方法のため、今後も別の作品で使う予定で動いています。

3つ目は「mgear」というリギングモジュールです。リグを作るための便利な自動化ツールだと思ってください。GMRで積極的に使ったことで知見も深まったため、他のプロジェクトでも積極的に使っています。

4つ目は、「ShotGrid」です。ShotGridの運用や自動化も大規模なGMRのプロジェクトを経て、とても効率的に使えるようになりました。

少し割愛して、最後は「Slack」です。弊社はコミュニケーションツールとしてSlackを使っています。ShotGridでのステータスや外部協力会社様からのエラー報告、レンダリング依頼などのやり取りをSlack上で行えるようにしました。

「作品を通して初めて理解する」ということについて、別の観点から考えてみます。実際に、初期段階のレンダリングから最後のコンポジットまでやることは可能なのでしょうか。

さきほど紹介したとおり、GMRの終盤では自動でレンダリングしてShotGridにアップロードし、そこでチェックを行っていました。この工程がプロジェクト初期から行なえていたのであれば、プロジェクトの初期から最後まで通すということが可能です。

当然簡単な道ではありません。しかし、弊社ではそう遠くない未来で実現したいと考えて、日々開発に励んでいます。

採用関係の話

ENGIでは一緒に働く仲間を募集しています。

ENGIには、東京本社と札幌と倉敷に3つのスタジオがあります。冒頭で紹介した通り、4つの部署があり、本社には4部署全てがあります。札幌には、アニメーション制作と3DCG部、デジタルコンテンツ開発部があります。そして、倉敷スタジオではアニメーション制作部が制作部として存在しています。

私たちは、「世界に通用するアニメーション制作を」という理念で活動しています。地方にもスタジオがある理由は、地方からでも世界に羽ばたけるアニメーション制作を可能にしたいという理念があるからです。

募集の詳細については、弊社のホームページ上の採用情報から確認してください。中途採用は、各制作部署、セクション、職種で幅広く募集しています。
https://engi-st.jp/recruit-search/?type=recruit-type-mid

Q&A

Q1. ショットを作る際に、USDワークフローなどは使われていますか。

GMRでは全く使わず、アニメーション工程から出力したアレンビックをライティング側で再構成していました。USDなども取り入れていきたいとは思っていますが、業界全体でのフローのあり方などの根本的な部分を改善しないとUSDも活かせない現実があります。

そもそものルールがしっかりと決まっていないと、USDを出力しても再構成できない、動かないということもありえます。取り入れられる部分から少しずつ取り入れていきたいですが、業界全体にUSDが浸透するのはまだ先のことになると思います。

Q2. ShotGrid、特にデータベースのオープンには膨大な時間がかかると思いますが、何か対策をしていますか。

その点に関しては、ShotGridはとても優秀です。データベースのクエリなどの細かいことを考えずとも、ShotGridは高速に動作してくれます。映像で扱うデータは膨大なため、データベースを自分で作ろうと思うとShotGridのように動作させるのは簡単ではありません。個人の私見かもしれませんが、ShotGridにはとても感謝してます。

Q3. Subversionはそもそも分散リポジトリではないため、それをGOOGLEドライブで共有するのは危険ではないかと思ったのですが、そのあたりはいかがでしょうか。

仰る通り、とても危険です。セミナー内でもそもそもの判断ミスだという話をさせてもらいましたが、今ではもう二度とやるまいと思っています。

Q4. 御社のテクニカルチームの編成や規模感と、最初の元請だったGMRにおいてのパイプライン構築までに掛かった時間についてお聞きしたいです。

チームの人数としては、私とWebから来ているエンジニアとシステムエンジニアから来ている者の3名です。パイプライン構築に関しては、まだできているとは言えない状況です。GMRでは、各ショットやアセットに対してハードコーディングで解決した側面が多くありました。そういったこともあり、パイプラインの構築はまだまだこれからだと思っています。