あにつく2022レポート | 長編3Dアニメーション制作におけるテクニカルチームの重要性(ENGI)

9月23日(木)から9月25日(日)で開催された「あにつく2022オンライン」より、Day2「長編3Dアニメーション制作におけるテクニカルチームの重要性」のイベント内容をご紹介します。


ウェビナー概要

長編3Dアニメーション制作におけるテクニカルチームの重要性

ENGI-3DCG部から見た、長編3Dアニメーション制作におけるテクニカルチームの重要性を、主に業界に興味を持たれている方や、業界を目指す学生さん向けて、お話ししていきます。
具体的には、”テクニカルアーティスト(TA)” の仕事について紹介するとともに、プロジェクトにおいてデータを正しく運ぶことがどれほど重要か、そして正しく運ぶためにアーティストに意識してもらいたいことなどを、実例を交えてお話しできればと思います。

 主催 :株式会社Too
 協賛 :オートデスク株式会社
 講師 :株式会社ENGI 飯島 哲(いいじま さとし)氏
     株式会社ENGI 鳥谷部 正輝(とりやべ まさき)氏
     株式会社ENGI 帆苅 哲(ほがり さとし)氏
     株式会社ENGI 加藤 ミルトン 栄二(かとう みるとん えいじ)氏


登壇者紹介

イベントの内容に入る前に、まずは登壇者を紹介します。本イベントは以下の4名でお送りします。

飯島 哲 氏

飯島 哲 氏

株式会社ENGI 3DCG部 部長/プロデューサー

鳥谷部 正輝 氏

鳥谷部 正輝 氏

株式会社ENGI 3DCG部 札幌スタジオ ヘッドチーフ/ジェネラリスト
久遠の旅人

帆苅 哲 氏

帆苅 哲 氏

株式会社ENGI 3DCG部 札幌スタジオ テクニカルアーティスト

加藤 ミルトン 栄二 氏

加藤 ミルトン 栄二 氏

株式会社ENGI 3DCG部 部長/プロデューサー

前置き

本題に入る前に、2つほど前置きをさせていただきます。本イベントの目的は、テクニカルアーティストという仕事の重要性を知ってもらうことで、将来活躍してくれるテクニカルアーティストを増やすことです。そのため、主に業界への就職に興味がある方をメインターゲットとして説明していきます。

また、本イベントを通してテクニカルアーティストに興味を持ってもらい、アニメ業界で活躍してくれる人が一人でも増えれば嬉しい限りです。

本イベントの内容は、2023年8月公開予定の長編アニメーション作品の制作中に起きた出来事などを例に進めます。現段階では作品情報を公開できないため、内容を伏せた上でテクニカルアーティストの視点で説明をしていきます。

テクニカルアーティストとは

前提として、「テクニカルアーティスト」という言葉を聞いたことはあるでしょうか。業界内では浸透し始めていますが、初めて耳にする方も多いと思います。実際には、業界内でもテクニカルアーティストの仕事についてあまり知らないという方も多いです。

テクニカルアーティストの業務を簡単に言うと、「映像制作を技術的側面から組み立てる仕事」です。売上貢献よりも利益貢献をする職種のため、業務の効率化などを図ることも多いです。プログラミングをしている人もいればMayaのノードを触っている人もいて、業務内容は多岐にわたります。

テクニカルアーティストに共通する役割を簡潔に言うと、「プロジェクトデータの守護者・運び屋」です。これは、「パイプラインを構築・運用する技術者」とも言い換えることができます。

ここで、「パイプライン」について少し説明します。

作品制作の段階は大きく「プリプロダクション(プリプロ)」と「プロダクション」、「ポストプロダクション(ポスプロ)」の3つに分けられます。プリプロでは、企画や脚本制作などの作品制作前の作業を行っています。プロダクションとは、多くの人がイメージするようなアニメーション制作工程のことです。そして、ポスプロは制作された映像と音声を合わせる作業のことです。

ここからは、プロダクションについて細かく説明します。プロダクションの1つ目にある「モデル」とは、形状を作る工程のことです。しかし、モデル形状だけでは動かせないため「アニメーション」を付けることができません。そこで、モデルを動かすために骨を入れて、その骨を動かすためのコントローラーを付ける工程が「リグ」という作業です。

そして、「ルック」とは「ライティング」という光を当てる作業で定義したものに対して、見た目を可愛く、もしくはかっこよく見せるための工程のことです。その後、「レンダリング」で画像を書き出します。最後に、書き出した画像や映像を合成する作業が「コンポ」という工程です。また、「VFX」はエフェクトを付ける工程で、「美術」は背景を作る作業を指しています。

そして、パイプラインとはこれらの工程を跨いでデータを正しく渡せるようにフォーマットを決めたり、データを受け渡すためのツールを作る仕組みのことです。

ここからは『テクニカルアーティストの必要必要性』についてのお話です。データの受け渡しはメールやチャットツールで問題なくできると思うかもしれませんが、3Dツールは種類と数が多様なためそう簡単にはいきません。

画像は、弊社内でメインに使っているツールをさきほどのパイプラインの図に付け足したものです。プロダクションで使っているメインツールだけでもこれだけの種類があります。

当然、ツールの数だけ多様なファイル形式があります。3Dデータを別のツールに移す際の「fbx」という形式など、ファイル形式はさまざまです。実際にわたしたちも作業時に使用するファイル形式に迷うことがあります。

また、画像のように専門用語も多様です。「ノーマライズ」や「トポロジー」、「マテリアル」など、多くの用語があります。数学用語には、「右手系」や「左手系」などが含まれています。

ここで「なぜテクニカルアーティストが必要なのか?」という問いに回答させてもらうと、「”小難しい”事柄とアーティストの間の翻訳家」ということになります。さきほど説明したようなツール間でのデータの受け渡しは、制作工程の中で何度も発生します。同じファイル形式で渡す場合でも、参照するツールが違うと不具合が起こることがあります。その翻訳をすることが、テクニカルアーティストの仕事というわけです。

もう1つのテクニカルアーティストの必要性は、ファイルの数が膨大になる大規模プロジェクトの際にあります。

画像左側に書いてある「アセット」は実際の「物」だと捉えてください。車やキャラクターなどのアセットの1つ1つが画像では500と書いてありますが、大規模プロジェクトでは600を超えることもあります。そして、アニメーションは1秒で24フレームであり、「フレーム数」は右側に書いてあるように平均で100フレームほどになります。「要素」は1枚ごとに書き出される画像の数のことです。そうなると、「ショット数」は全部で3600くらいになります。これらは全て掛け算になるため、膨大な量のショット数になっていることが分かります。

テレビアニメの1話は平均300カットのため、ショット数は12話分で合計約3600です。つまり、1クールのテレビシリーズでも大規模プロジェクトと言えるというわけです。そのため、大量のファイルが様々なファイル形式で飛び交っています。

つまり、「なぜテクニカルアーティストが必要なのか」のもう1つの答えは、「人の手ではさばききれない大量の処理をプログラムで一気にさばくため」です。

プロジェクトでの業務例

ここからは、実際のプロジェクトでの業務例をもとに紹介していきます。まずは、ENGIで働いているテクニカルアーティストたちを少し紹介します。

1. リギングアーティストとしての活動を軸にリギング効率化のための開発を行っているブラジル人アーティスト

2. エンジニアとアーティストの経験をバックボーンに、日常的に各工程からの要望を受け、多様な業務改善のための開発を行っているブラジル人アーティスト

3. エンジニアの経験をバックボーンに、ファイルサーバーのバージョン管理ツールや、ファイル収集スクリプトなどを作成しているマレーシア人エンジニア

4. 社内システムエンジニアとアーティストの経験をバックボーンに、各DCCツール間の連携や協力会社との情報フローに関連したスクリプト開発などを行う日本人エンジニア

こちらに書いてある通り、業務内容はさまざまです。今までの経験もそれぞれのテクニカルアーティストで異なることが確認できます。

業務内で発生した依頼の例

札幌スタジオの加藤氏が担当していたタスクをもとに話をしていきます。最初に紹介するのは、「一回やるのはいいけど…系」です。

大量のファイルを処理しなければならない場合に、Mayaも開きながらシーンも開いて作業をするのは、膨大な時間がかかってしまいます。Mayaの起動ですら1分ほどかかるため、10個以上ファイルを開くだけでも膨大な時間が必要です。

こちらは、それぞれの作業者から届いた「作業中の一連の単純作業を簡略化したい系」の依頼です。アニメーションをチェックに出す際に、「キャラクターのアニメーションを見たいから背景を目立たないようにしてほしい」などの依頼があります。

これらの例にあった依頼は基本的に流れ作業のため、人間がやるのは効率的ではありません。一回スクリプトを組んでしまえば自動化できるため、効率化のためにスクリプトを描くのもテクニカルアーティストの仕事です。

案件内プチ依頼の例

次は、「ブレンドシェイプの動作を簡単に確認したい」という実例をもとに説明します。

従来の作業では、まずブレンドシェイプが入っているデータを読み込み、頭と頭、目と目という対応するものを1個ずつ選択してブレンドシェイプを適応させていました。その後、変形させたいものを1個ずつ変形させて、見た目の変化を確認するという面倒な作業でした。表情を2個確認するだけでも3分以上かかっていたため、キャラクターに設定されている20個の表情全部を確認する場合では相当な手間と時間がかかっていました。

その作業を効率化するため、ツールを組んで対応しました。ブレンドシェイプを設定したファイルを読み込むまでは同じですが、その後は選択して指定をするだけで設定完了です。スライダーを動かすだけで、キャラクターの顔と表情の変化が確認できるようになりました。2個の表情の確認が30秒ほどでできるため、5倍以上の時間の効率化が図れています。

この効率化によって、デザイナーはクリエイティブな作業に専念できるようになりました。人間にしかできないクリエイティブな作業に専念できることは、大幅な効率化に繋がります。このツールを使うことで、作業したら合計1〜2時間ほどかかる作業を5〜10分で終わらせることができます。

日常業務の改善についてアーティストが出来る事

ここからは、「日常業務の改善についてアーティストが出来る事」という内容について鳥谷部氏から説明します。さきほど紹介したツールのように、テクニカルアーティストが活躍してくれるプロジェクトでは時間を節約できるため、クリエイティブなことに時間を費やすことができます。

業務を行う上で重要な3つの基盤と使用ルール

ここからは、最適な業務環境を保つための取り組みを説明します。ENGIで現在進行中の大規模プロジェクトで実際に起こった問題と、その解決方法をあわせて紹介します。

まずは、業務を行う上で重要な3つの基盤と使用ルールについて説明します。上の画像にある図のように、「コミュニケーション・情報管理」と「データ管理」、「プロジェクト管理」の3つがあります。

1つ目の「コミュニケーション、情報管理」では、普段の業務で起こるさまざまなことを、SlackやNotionなどのコミュニケーションツールを使って情報を管理しています。

2つ目の「データ管理」では、社内サーバーやGoogleドライブで外部と連携して、制作途中や完成時のデータを管理しています。

3つ目は「プロジェクト管理」です。制作進行やプロジェクトをマネジメントするためのツールである『ShotGrid』や『Google Sheet』、『Notion』を使って、プロジェクトの状態やデータのステータスを管理しています。

これら3つの基盤を踏まえた上で、実際に起こった問題を例に話をしていきます。

実際に起こった大きな問題

実際のプロジェクトで起こった問題は、以下の3つです。

1. コミュニケーションロス
2. 情報ロス
3. データロス

この3つを深掘りしていきます。

1. コミュニケーションロス

1つ目の「コミュニケーションロス」で起こった問題点です。簡単に言うと、「伝えたつもりだが伝わっていなかった」ということです。口頭で伝えたまま満足してしまい、他のチームメンバーには伝わっていなかったというケースです。

倉敷と札幌と東京の3ヶ所にスタジオがあることが原因で、拠点間での情報の差が生まれてしまっていました。また外国人スタッフも多くいるため、日本語が不得意なメンバーに情報が伝わり切れていなかった、もしくは伝わってはいたが理解できていなかったというケースもありました。

コミュニケーションのためのチャットツールで、大事な情報が埋もれて忘れ去られてしまったこともありました。古い情報は1ヶ月前でもすぐに流れてしまうため、それら情報を探すことが困難な状況になってしまったこともありました。

ここからは、実際の解決方法を見ていきます。解決方法として大きく、「チャットツールの整備」と「翻訳ツールの活用」、「情報共有ツールの活用」を行いました。

まずチャットツールのルールを整備するためにマニュアルを作り、スタンプキー機能とスレッド機能、メンション機能の3つの機能を使うように徹底しました。こういったチャットツールのルール整備によって、拠点間やチーム間でコミュニケーションが円滑に取れるようになり、伝わっていないという事象を減らすことができました。

また、翻訳精度が高いことで知られる『DeepL』という翻訳ツールも導入しました。こちらの導入によって、外国人スタッフに対しても伝えたいことを伝えられる状況が整いました。

次は情報共有ツールという点に関して、主に「Notion」という情報管理ツールを使うことで、チャットでは流れてしまう重要な情報を貯める場所を作りました。弊社ではチャットツールを報告や確認などの日々のコミュニケーションのツールとして使い、重要な情報やデータは貯めないという意識を持ってチャットツールを使っています。

2. 情報ロス

次に、情報ロスに関して起こった問題点を紹介します。「作業者が変わったときに作業中のデータがどのような状態なのか引き継がれていなかった」という問題や「頼んだはずの業務がされていなかった」、「必要な最新の資料がどれか分からない状態になっている」ということが発生していました。

実際の解決方法を見ていきます。解決方法として大きく、「プロジェクト管理ツールの導入」と「タスクの割り振りをシステム化」、「情報場所を一ヵ所にまとめる」という対策を行いました。

まずはプロジェクト管理ツールを導入しました。弊社では「ShotGrid」というツールでプロジェクトのアセットの管理やカットの管理、実際のステータス進行管理、更新状態の管理などを行っています。あらゆる情報をShotGridに貯めていくことで、作業者が変わっても引き継がれる状態を作りました。

次に、タスクの割り振りをシステム化しました。大きなプロジェクトや流度の高いものは基本的にShotGridで管理し、小規模のプロジェクトはNotionで管理するようにしました。これにより業務で必要なものや担当者などを管理でき、混乱が起きないように整理しながら進められるようになりました。

また、情報場所を一ヵ所にまとめるようにしました。制作に必要な資料のバージョンが複数存在していたため、リンクやデータをNotionで一ヵ所にまとめました。情報の一元管理をすることで、新しいメンバーも業務のことを理解しやすい状況を作りました。

画像はShotGridでのプロジェクトのキャプチャーです。このように、プロップや小物などを作っているときの作業者やステータスなどを管理しています。

こちらはNotionで情報管理をしている画像です。キャラクターアセットを作るときの進捗などをこのページで全てを管理しています。テクニカルアーティストはプログラマーではないためプログラミングはしませんが、こういったノーコード系のツールでのシステム組みなどをすることはあります。

また、日々の会社での働き方に必要な情報である社員マニュアルや議事録などもNotionで一ヵ所にまとめて、なるべく必要な業務に集中できる様な仕組みづくりを心掛けています。

3. データロス

次は「データロス」の問題について説明します。実際に起こった問題は、「間違ってデータを削除してしまった」でした。また、ファイル名がそれぞれ違っていたことが原因で「最新のデータがどれかわからない」などの問題もありました。

ここからは問題の解決方法を紹介します。実際に行った解決方法として、「ファイルのバージョン管理システムの導入」と「ネーミングルールの設定」を行いました。

ファイルのサブバージョン管理システムを導入することで、間違って消してしまったファイルを復旧しやすいようにしました。消してしまったケース以外の「過去のデータの方が良かった」というケースに対しても、過去の状態に戻すことで対応可能です。

ネーミングルールの設定に関しては、仕様として全てのデータに固有のネームをつけることを徹底しました。それにより、テクニカルアーティストが作った大量のデータを扱いやすくなりました。

日常業務の改善まとめ

実際にプロジェクトが進行していくと、いくつかの問題が起きます。プログラミングが必要な場面もありますが、テクニカルアーティストやエンジニアなどの業種に関わらず、「良い作品を作る」ために目の前で起こっている問題を放置せずにチームで共有し、解決することがとても大切です。

ツール紹介

ここからは実際に使っているツールを紹介します。最初に紹介するのは、『mGear』というツールです。こちらはリギングのモジュールとして使っていて、弊社ではカスタマイズして使っています。

使用する際には、まずリグのベースを読み込みます。その後はワンクリックするだけで、全ての機能を備えた状態のリグが構築されます。リグには骨を動かしてアニメーションする「ボーンベース」と別の形のモデルをモーフィングしてアニメーションする「ブレンドシェイプベース」がありますが、弊社のプロジェクトのリグではボーンベースとブレンドシェイプベースが両立するようになっています。

2つ目の『check movie tool』は、名前の通りチェックムービー用のツールです。日々多くのチェックをする中で、さまざまな情報と紐付けなければいけません。その作業を動画で書き出した後でするのは大変な作業です。

当ツールでは、ワンクリックで自動的に他のツールを開いてキャプションやファイル名を一括で出力できます。チェックの時に重要なカメラの画角の「フォーカルレングス」やフレーム数なども出力できるようになっています。

3つ目は『en Submission Tool』です。3Dアニメーション制作に必須のレンダリングには、膨大なマシンパワーが必要です。自分のPCでレンダリングすると他の作業ができなくなってしまうため、『レンダーディスパッチャー』を使い、多くのレンダー専用のマシンでレンダリングしています。また、弊社内ではレンダーディスパッチャーをただ使うのではなく、「一括で全シーンにこういう作業をしたい」ということもできるようにしています。

4つ目は、「2Dパンズームのツール間連携」についてです。2Dパンズームのツール間連携とは、Maya上にある2Dパンズームの機能に関連することです。2Dパンズームとは、カメラを振ってもパースが変わらずに画像の方を動かす機能のことです。本来3ds MaxやHoudiniなどでは使えないこの機能をMayaから移せるようにしました。

パイプライン構築の苦難の一例 ~2Dパンズームの移植を例に~

「パイプライン構築の苦難の一例 ~2Dパンズームの移植を例に〜」ということで、さきほど説明したツールの必要性を説明していきます。

弊社では、Mayaでアニメーションを作っています。さきほどのプロジェクトでは、背景は作画アニメと同様に2Dになることに決まりました。しかしながら、カメラを3Dで動かしてしまうとパースが変わってしまうため、絵では描きづらいという側面がありました。

そこで、2D美術から「カメラは2Dの方が楽です」という要望がありました。アニメーションでMayaを使うのであれば、そのままMayaの機能を使おうということに決まりました。

今回のプロジェクトでお願いしているアウトソーシングの協力会社様は、主に3ds MaxやHoudiniを使っていました。さきほど説明した通り2DパンズームはMaya特有の機能のため、3ds MaxやHoudiniでは使えません。そのため、エフェクト作業時にアニメーションに合わせて1フレームごと調整が必要という可能性が発生しました。

解決策の1つとして、力技をいくつか考えました。

力技:その1では、カメラの2Dパンズームに合わせてポリゴンの方を動かしてしまえばいいのではないかと考えました。しかし、現実的ではない計算量になってしまうため難しいという判断になりました。

力技:その2は、エフェクトが出る点にロケーターを置き、その点だけを計算するという案でした。しかしながら、結局コンポで全頂点の情報が必要になるということで却下になりました。

力技:その3として、大判で撮ってAfter Effectsで合わせるという案も出ました。しかし、こちらも膨大なピクセルデータになってしまうためコスト的に現実的ではないという結論になりました。

落としどころ案:その1として、エフェクトや3ds Max、HoudiniではなくMayaで作ってしまおうという話になりました。実際に交渉しましたが、3ds MaxやHoudiniをメインで使っている外部会社様だったため、断られてしまいました。これは「英語話せるならフランス語も話せるよね」くらい無茶なお願いのため、当然の結果です。

そこから、そもそもなぜMayaの2Dパンズームが3ds MaxやHoudiniには移らないのか考えました。問題の原因は、Mayaにある「2d Pan Zoom」という値が3ds MaxやHoudiniには存在していないことでした。そこで、等価な値さえあればどうにか移せるのではないかという話になりました。結論としてはその値を見つけることができたため、それぞれのツールに合う数値に変換するための計算に取り組みました。

画像は、3ds MaxやHoudiniではなくAfter Effectsに移してカメラを合わせる時の計算です。After Effectsには「アンカーポイント」や「コンポジション」などのさまざまな座標系があります。それらを2Dパンズームでズームしたりしなければならないということを計算したものが、上の計算図になります。

テクニカルアーティストを目指す人へ

大規模なプロジェクトになればなるほど、最初にパイプラインを設計することは重要です。これは、後で協力会社様に無茶なお願いをしないためにも必要です。そういった点からも、テクニカルアーティストが情報を含めて作業のフローを把握しておく必要があります。つまり、テクニカルアーティストが果たすべき役割はとても大きいということです。

少しだけ、テクニカルアーティストに必要な素養についてお話しします。

プログラミング的素養や数学的素養は、テクニカルアーティストになる上であるに越したことはありません。しかしながら、「わからない」や「難しい」で立ち止まらずに常に調べる姿勢があれば、後から身につけることができます。

仕事でメインで使っているプログラミング言語は『Python』で、数学に関しては「線形代数(ベクトル)」と「三角関数」をよく使います。逆に言うと、この3つがあれば、テクニカルアーティストとして働くことは十分可能です。数学においては、4年制大学の理系で選考されている1年次の線形代数と微分積分の知識だけで十分です。CGはほとんど線形代数でできているため、それだけは最低限必要な知識というわけです。

それよりも、テクニカルアーティストに必要なのは「コミュニケーション能力」です。ここでのコミュニケーション能力とは、面白く話せる能力ではありません。プロジェクト全体の中で人の立場を理解した上で、それを他の人に伝えられる能力のことです。

何より必要なことは、相手を尊重する意識や物事を伝える力ということです。

Q&A

Q1.テクニカルアーティストは、どのアニメ制作会社でも職種としてあるのでしょうか?

3DCGアニメーションの業界では、元請としてテレビアニメや劇場作品を作っている企業であれば確実にある職種だと思います。それ以外の場合では、テクニカルアーティストの中でも特にプログラミングのみの専属という方は少ないのが現実です。元請メインではない企業やゲームやアニメを含めて幅広く仕事をしている企業の場合は、テクニカルアーティストがデザイナーを兼任しているケースもあります。

当然、会社の規模や仕事の内容によって変わります。3DCGで映像を作っている限り必要な職種ではあるため、本来であれば必須の職種だと考えています。

Q2.NotionとShotGridは繋げて管理していますか?

現状は繋げずに、それぞれで管理しています。

Q3.SlackやNotionのセキュリティはどう考えていますか?

セキュリティ面で言うと、これらは使い方を誤らなければ問題がないツールだと捉えています。重要なのは、使い方と運用のルールです。弊社では使い方や運用のルールを全スタッフが守るように徹底することで対応しています。

関連記事

3ds Max 無料体験コースオンラインウェビナー

Maya無料体験コースオンラインウェビナー

kvizのレポートBookダウンロード

最近の記事

  1. ShotGrid 製品名変更のお知らせ

  2. 【動画配信】広告業のジェネラリストが使うOmniverse最新事情

  3. InterBEE2023 Tooブースの歩き方!

TOP
Tooへの各種お問い合わせ >>