チュートリアル / カットシーンのデータ管理
第1回：TimeEditorを工夫して管理を効率化してみよう①
- Maya
- UI・ビューポート
- ゲーム
- コラム
- チュートリアル
- 上級者
- 中級者
はじめに
ごあいさつ
みなさん、こんにちは。
クリーク・アンド・リバー社 COYOTE 3DCG STUDIO TECHNICAL ART TEAMの山本です。
私たちCOYOTE TECHNICAL ART TEAMは、元はCOYOTE 3DCG STUDIOのテクニカルサポートをするチームとして始まりました。
しかし、今ではクリーク・アンド・リバー社という、デジタルコンテンツ業界で幅広いネットワークを持つ環境を生かして、「業界のTAチーム」を目指し、社内外とわず様々な開発案件のお手伝いをさせていただいています。
今回のコラムでは、そんな数多の開発案件の中でも、カットシーンのデータ管理について少し変わった取り組みをご紹介いたします。
皆様の業務において、少しでもお役立てできれば大変幸いです。
本コラムで取り上げること
ゲーム制作におけるカットシーンの製作では、Mayaシーンから出力される様々なデータ…
・キャラモデル
・モーション
・カメラアニメーション
・その他プロップ類
…などといった、たくさんのオブジェクトの組み合わせで、管理が煩雑になりがちです。
本コラムでは、この管理をMayaで一元管理し、管理のスマート化と業務効率化を行った事例として…
・TimeEditorをカットシーン管理に使う
・カメラドリブンでカットシーンの管理を行う
…について、ご紹介いたします。
【前提説明①】本コラムで取り扱う「カットシーン」とは？
なお、ゲーム制作において、「カットシーン」とか「イベントシーン」というと、
・主にプリレンダリングによって作られたムービーを再生するケース
・実際にインゲームで使用される3Dデータ（キャラクターや背景など）を使い、ランタイムで再生されるケース（リアルタイムレンダリング）
…の２ケースがあり、いずれかを「カットシーン」「イベントシーン」などと言い分けていることがあります。
しかし、どちらを「カットシーン」「イベントシーン」と呼ぶかについては、スタジオや案件ごとに違って、実際は曖昧な状態です。
本コラムでは、後者の「ランタイム再生」のケースを「カットシーン」として取り上げ、前者の「プリレンダリングによるムービー」のケースには触れません。
【前提説明②】カット・ショット・シーンの言葉の定義について
また、「カット」「ショット」「シーン」という言葉の使い方についても、ゲーム制作現場においては曖昧だったりするケースをしばしば見受けます。
ここでは、これらの言葉の意味を
・カット : 映像の最小単位。続けざまの映像になるもの。（ショットとも言いますが、ここではカットと呼ぶことにします）
・シーン : カットの集合。ある状態を描写している映像。(シーン の集合をシーケンスと呼びます。)」
…とさせていただき、以降文章を展開いたします。
参考：[cgworld.jp CG用語辞典]
・https://cgworld.jp/terms/カット.html
・https://cgworld.jp/terms/ショット.html
・https://cgworld.jp/terms/シーン.html
前提説明のお話は以上にして、以降から本題に入ります。
【事例その１】カットシーンの管理をMayaで一元管理
TimeEditorをカットシーン管理用にカスタマイズして運用
まずはサンプルToolでご説明いたします。
このサンプルは、実際に業務で使用したものではありませんが、当時のものを参考にポイントを絞って復元したものです。
ご覧の様に、TimeEditorを一部拡張したものを作り、カットシーンデータの管理に使いました。
カットシーンのデータ、主に…
・カメラ
・キャラクターモデルとアニメーション
・プロップモデルとアニメーション
…は、上図のようにトラックで分けられ、アニメーションの長さはクリップ長で管理されます。
シーン全体で、
・カットの分割がどのようになっているのか
・そのカットで使われているアセットはどれか
…が、一目瞭然です。
また、TimeEditorの左側にOutLinerを合体させました。
このOutlinerの右クリックメニューを拡張して、「COYOTE CutScene Menu」という項目を足しました。
ここから、選択したノードを「カットシーンのクリップ」として、このカスタムTimeEditorに登録することができます。
ノードを選択して、右クリックから登録できるので、便利です。
さらに、TimeEditor側のメニューにもカスタムメニューを追加してあります。
このメニューからは、
・compositionの追加・削除
・クリップ名のリネーム
リネームを手作業で行う場合、少々手数が多くなって面倒です。そのため、こちらのメニューから簡単に実行できるようにしました。
・選択したクリップから、紐づく対象のアセット（モデル・モーション・カメラ）をFBX出力
・現在のcompositionに含まれる、すべてのクリップを参照し、紐づく対象のアセットをFBX出力
…などが実行できます。
実際の運用では、これとは別に別担当者や実装担当が参照するエクセルファイルを用意する必要があったため、compositionの情報をもとに、管理用のエクセルも出力できるようにしていました。
以上の様に、シーン内に散らばっているカットシーンのデータや関連性について、TimeEditorのGUIを拡張して使用することで、直感的かつ、楽にデータを運用できるようにしました。
また、FBX出力に必要な情報をTimeEditor上で管理することで、スクリプト操作が可能になりバッチ処理しやすくなるため、複数シーンの管理にも効果を発揮します。
エクセルでデータ管理している場合、Mayaでの一元管理が平行管理のコスト削減につながる
こういうデータの情報管理にエクセルを用いるケースは、未だ少なくないと感じています。
しかし、実際の運用では…、
・Mayaとエクセルの同期に注意が必要
・カットの情報を確認するために、Mayaとエクセル両方を確認する必要がある
・シーンからカットごとに出力させるには、エクセルを参照しないといけない
といった状況で、混乱するケースは珍しくありません。
また、Mayaとエクセル、どちらの情報が正しいのかわからなくなって、データが先祖返りを起こす可能性も心配で、気が抜けません。
これを防ぐためには、エクセルの情報精度を常に高く保っておく必要があり、情報の同期や確認を頻繁に行わないといけません。
それには手作業での目視確認の他、CI（ジェンキンズなど）で定期的に同期させる必要が考えられますが、いずれにしても管理コストが肥大化します。
これは、Mayaとエクセルが並列（若干エクセル優位）という構図に問題があります。
Mayaとエクセルの間を取り持つオペレーションが、相当足を引っ張っている、と見て取れるためです。
すなわちこのケースでは、Mayaを情報の最上流にしてMayaで情報を一元管理できれば、概ねの問題は解決できるのです。
なお、TimeEditorを使うアイデアは、以前案件でご一緒したカットシーンのご担当者さまからのご提案でした。
当時、その方の目の付け所に「なるほどな！」と個人的にも大変感服したのをよく覚えています。
この場を借りて御礼申し上げます。まことに、大変勉強になりました。
【設計】TimeEditorをカットシーン管理につかおう
TimeEditorは見た目も動作も非常に直感的で使いやすいToolです。
しかし、カスタマイズやスクリプティングにおいては、その特殊なつくりをある程度理解しておく必要が有ります。
まずはTimeEditorを構成するノード構造などについて理解を深め、設計を進めます。
また、今回のToolでは、TimeEditorのコアな機能（モーションのブレンドや縮尺の編集など、TimeEditorの一般的な機能）は使わず、あくまでGUI部分の「見た目」を「カットシーンのデータ管理」のために使うという、少々特殊なことをします。
そのため、TimeEditorの機能制御部分には触れませんので、予めご了承ください。
トラックノードと対象のデータを紐づけて管理する。
トラックにアトリビュートを登録しすぎると激重
TimeEditorで取り扱うアニメーションのアトリビュートが多い場合、要注意です。
便利だからと言って、リグのすべてのアトリビュートをTimeEditorに登録してしまうと、再生が非常に重たくなってしまい、フレームレートを維持できなくなります。
また、操作に対する動作もかなり鈍重になり、作業になりません。
接続するアトリビュートを極力絞って運用する
とはいえ、昨今のキャラクターデータは、インゲームモデルといえども相当数の骨数を持っています。
ブレンドシェイプのアニメーションなども含めると、登録しないといけないアトリビュートの数はかなりのものになり、たとえアニメートしているアトリビュートをなるべく絞ったとしても、限界があります。
そこで、もういっそ「アニメートさせているアトリビュートを登録しない」とバッサリ割り切ってしまった方が良さそうです。
これによって、本来TimeEditorが得意としている
・アニメーションの尺や再生タイミングの調整
・アニメーションの「ブレンド」や「切り貼り」
・アニメーションの移植
…などといった機能は使えなくなりますが、今回はあくまでTimeEditorのトラックを「カットシーンデータの管理のためのGUI」として使えればよいわけです。
ですので、TimeEditorにアトリビュートを登録するのはやめます。
代わりに、カスタムアトリビュートを紐づけるトラックとノードに追加して接続させて、スクリプト側でたどれるようにしておきます。
これであれば、TimeEditorの機能とは全く無関係に接続を追加することができ、動作に影響が及びません。
【調査】TimeEditorのノード構造について
TimeEditorのノード構造を見てみましょう。
Maya上ではどのような構造になっているのでしょうか。
TimeEditorの構成をoutlinerで見てみる。
TimeEditorを起動したり、TimeEditorでアニメーションが管理されているシーンを確認すると、outliner上にTimeEditorのノードが表示されています。
outlinerの表示を見ると…
…このように、階層構造を確認することができます。
一見すると、シンプルでわかりやすい構造です。
Outliner上の階層構造は「見かけだけ」なので、注意が必要
しかし実のところ、これはoutliner上の見た目だけ。
実態は各種ノードがアトリビュートの接続でつながっている、DGノードの集合です。
NodeEditorでAnimationClipからTimeEditorまでの接続をたどって観察してみます。
すると…
このように、予想よりも大分ノード数が少ない接続だということがわかります。
まず、Track・Compositionsノードなどというノードはなく、
TimeEditor >> Composition >> クリップノード
という接続になっていることがわかりました。
ノードタイプにも注意
上図の「Composition1」を選択し、ノードタイプを確認してみると、
「Compositionノード」ではなく、「timeEditorTracks」というノードだということがわかりました。
これは、そもそもが「timeEditorTracks」というノードタイプ。
名前だけ「Composition1」となっているという点に注意が必要です。
なお、他のノードのノードタイプは…
・TimeEditorは「timeEditor」ノード。
・アニメーションクリップは、「timeEditorClip」ノードです。
「トラック」は「timeEditorTracks」ノードのマルチアトリビュートとして存在
では、肝心のTrack情報は？
Trackの名前などは、いったいどこに格納されているのでしょうか。
これは「timeEditorTracks」ノードのマルチアトリビュートとして存在しています。
トラック名は、このマルチアトリビュート内の「Track Name」アトリビュートで管理されています。
トラック名を試しにアトリビュートエディタで変更してみると。
TimeEditorのGUI上でもトラック名が変わることが確認できました。
AnimationClipを操作した際のアトリビュートの変化
TimeEditor上でAnimationClipを操作した際、TimeEditorClipノードのアトリビュートがどのように変化するのか、観察してみます。
・クリップの再生位置を前後に移動すると…
「Clip Start」の値が前後しました。
・クリップの長さを変えると…
「Clip Duration」の値が変化しました。
・TimeEditor上で右クリックし「Scale Start/End to Current Frame」を実行すると
「Clip Scale」の値が変動しました。
…と、ここまではいいのですが、クリップの名前を変えると…
「Clip Name」の値が変動しますが、timeEditorClipノードの名前は変わりませんでした。
つまりこのことは、「クリップのリネームの際には注意が必要」というだけでなく、 「クリップ名とtimeEditorClipノードの名前は必ずしも一致しているわけではない」ということになります。
今後、クリップノードを取得する際にクリップ名から名前解決で検索するのは危険と言えるでしょう。
まとめ
以上、ここまででカットシーンのデータ管理の方法や、TimeEditorの基礎的な挙動とノード構造について軽く紹介いたしました。
TimeEditorというToolは、一見直感的で使いやすそうな印象ですが、少し深堀してみると大分癖の強いToolであることがわかってきました。
次回は、TimeEditorをスクリプトで操作する方法をご紹介いたします。
TA応援隊の小話
【第1回】
みなさんはじめまして。
COYOTE TAチームの小澤と申します。
「TAチームの」と申しましたが私自身はTAではなく、営業と申しますか、採用担当と申しますか…広報、ブランディング、総務、雑用…そう、雑用から雑用まで担当しております。
ちょっとかっこよく申し上げますと、最近耳にする「DevRel」なんていうものに近いかもしれません。…が、まぁ平たくあらわすと「TA応援隊」です。
そんなことはさておき、この度本連載に際して「小話コーナー」を頂戴いたしましたので、僭越ながらチームのご紹介やTA談義を綴らせていただきます。
初回は山本も所属する「COYOTE TECHNICAL ART TEAM」の概要をご紹介したいと思います。
弊チームは2012年に設立した「COYOTE 3DCG STUDIO」内で発足した、「テクニカルサポート専門」のチームです。はじめは山本含むほんの1～2名からスタートしましたが、直近5～6年ほどで急拡大し、2024年現在で約30名超の個性豊かなTAが在籍しています。
一口に「TA」といっても実のところは千差万別…というのが現状であるとも思いますが、弊チームでは「開発における課題を抽出し、それを解決に導く人」とあえて広めに定義しています。
その解決手法が何であれ、同じ目線・志を持つ人と仕事がしたい、それを通してゲーム業界・コンテンツ開発を豊かにしていきたいと考えているからです。
日夜、様々なクライアント様・プロジェクトと向き合い、協力しながら開発に励んでおります。
次回以降は順次、サービスメニュー、雰囲気、活動内容…など、弊チームのいろんな側面をご紹介したいと思います。
プロジェクトのご相談、一緒にお仕事できる仲間も随時募集しておりますので、ぜひお目通しいただけますと幸いです。
それではまた次回お会いしましょう！