|
Expression Tactics
【４】 スレートの内容を自動表記する |
|
プロの制作現場ではムービーのレンダリングを行う際、映像の先頭に「カチンコ画像」を付与して、そのムービーの素性を把握し易くする事がよくあります。「どの作品の、何話の、カット何番で、尺は何秒か、云々」と言う情報を書き記す訳です。 さて、ここでよく考えてみましょう。その「カチンコ画像」＝スレートに記される内容は、既にAfter Effects上の「コンポジション設定」で入力してある要素ばかりです。それを再度、テキストレイヤーを使って手作業で書き記す‥‥なんていうのは、ちょっと非効率に感じます。プロジェクトやコンポジションの情報を参照し、テキスト内容を自動生成すれば、手作業の手間から解放されるだけでなく、タイプミス、つまり人災による入力ミスもぐ事ができます。 では、早速やってみましょう。 まずレンダリング直前の最終コンポジションにスレートを設定します。今回は8コマ分のスレートを挿入しますので、カットの尺（ムービーの継続時間）に８フレーム加えた設定にしておきます。今回は「2+0」２秒ジャストのカットを想定してみます。
あれまあ、なんとも質素なスレート。もっとカッコよくしたい人はお好きにカスタムしてくださいネ。 ではここから、エクスプレッションの出番。コンポジションの名前から話数を取り出し、１番目のテキストレイヤーの内容として自動入力するよう、エクスプレッションを記述します。以下のようになります。  エクスプレッションを使用可能にして、
結果は下図の通り。
うーむ、今回もすごく短いエクスプレッションですね。なぜ「 今回の事例におけるコンポジション名は、作品略号、話数、カット番号、撮影種別略号、テイク番号と言った要素を、すべて「_」＝アンダーバーで区切っています。つまり、話数やカット番号にアクセスしたければ、ひとまずアンダーバーで名前をブツ切りにして、そこから欲しい要素を取り出せば簡単です。
＊ちなみにAfter Effectsの「コレクション」は１から数えます。ややこしいですね。
こうしてブツ切りになった要素の集まりを「配列；Array」と言います。配列の要素はゼロからカウントするので、話数すなわち２つ目の要素にアクセスしたければ、[1]と指定します。「コンポジションの名前」を「split」で「_」に用いてブツ切りにして配列化し、その後に2つ目（要素番号１）の要素を取り出す‥‥と言う段取りです。
‥‥と言う事は、カット番号を取り出したい場合は、以下のようにすれば簡単に取りだせるはずです。
あらまあ、何とも簡単に、思った通りの結果。とりあえず満足ではありますが、折角「撮影種別略号」と「テイク番号」があるのですから、それも表記してみましょう。 付け足しの１番目、撮影種別です。撮影種別の略号が何を意味するのかが解らないと、具体的に表記できません。今回の事例では、撮影種別の略号を以下のように定めてみました。
これをもとに、「type」と言う連想配列を作り「略号辞書」として活用し、スレート表記に用います。「連想配列って何じゃい！」と思う人もいるかも知れませんが、要は「見出し付きの配列」です。連想しやすい見出しを配列内の要素に付与し、検索しやすくする訳です。‥‥日常生活ではよくやる整頓方法で、別に難しい事では無いですよね？ 以下のように改造します。名前をアンダーバーでブツ切りにした配列は幾度となく登場するので、「nArry」と言う変数に入れて使い回す事にします。変数に入れて使う事で、何度も名前をブツ切りにする手間を省けます。
コンポジション名から取り出した「hon」と言う文字を使って、「略号辞書」＝「type」から見出しにより検索し、「本撮」と言う日本語を取り出しています。取り出した後に「+」を使って文字と文字とを連結し、最終的に「006(本撮)」と言うテキストを生成しています。 このような芸当が簡単に出来るのは、名前を付ける際に「テキトーに」付けなかったからだとも言えます。名前は一番身近な「データベース」ですから、命名規則を考える時は、先の先まで見越して考えておきたいものですネ。 さて、追加の２番目は「テイク番号」です。テイク番号は最後の要素、つまり「t1」と名前に刻まれている要素です。これを「Take1」と言う文字に作り替えます。テイク番号は、他と違って「t」と言う「テイク=Take=t」を連想させる添え字が付随しています。ですから「１」を取り出す時に「t」が邪魔になります。邪魔ならばスキップして読み出せば良い、と言う事で以下のようになります。
「t1」と言う文字列の「1文字目以降」を読み出し、「Take 」と連結する事で、「Take1」を作り出しました。この「文字をスキップする方法」の他にも、まだやり方はあります。「t はテイクの t なのだから、邪魔にせずに巧く使えば良いのに」‥‥と思う人もいるかも知れません。ではそのようにしてみましょう。
「t」を探し出して「Take」に置換し、結果的に「Take1」と言う文字列を生成しました。この置換機能は「正規表現」の機能のほんの一部ですが、こうした心強い機能を使えるのも、エクスプレッションの強みです。 では、最後の仕上げ、尺の表記をエクスプレッションで自動表記しましょう。「thisComp」と言う「現在のコンポジションを指す、決め言葉」の次に「width」やら「duration」などの単語を付随させると、当該コンポジションの色々な情報を取得できます。今回は尺を表記したいので、「duration」を用いて尺表記の元手にします。 アニメ業界の尺表記は「秒＋コマ（フレーム）」です。単純に「duration」を表記したのではアニメ業界の慣習に合いませんので、整形して表示します。
上図のようなスレートが完成しました。ちゃんとスレート表示時間分の8コマを差し引いた表記になっています。「コンポジションのフレームレートと、フレーム総数（スレート分の時間は除く）を取得し、秒とコマを算出する」と言う段取りです。普段なら頭で計算する事を、エクスプレッションにやってもらっただけの事です。 今回のエクスプレッションの肝は、「コンポジション設定を変えるだけで、自動でスレートの記述内容が更新される」と言う点です。もちろん、工夫次第で、もっと多彩で情報満載のスレートも作れるでしょう。
ちなみに、私が仕事でスレートを作る際は、エクスプレッションとレンダーオートメーションの連携で処理しています。エクスプレッションには特に表記処理を担当させて、コンポジション設定などの「エクスプレッションでは変更できない領域」をレンダーオートメーションに委ねています。私の管理する撮影データベースと連携し、作品名、尺の情報などカット個々の情報を取得し、同時に作業者のローカルから作業者情報を取得、最終的にスレートの表記に反映させています。カットの基礎情報の他に、「誰が何時、どのマシンで作ったか」などの情報も表記するように設計しています。 スレートのエクスプレッションを作っていると、エクスプレッションの不可侵領域ゆえの限界を感じる事もあるかも知れません。そんな時は、After Effectsでのスクリプトにおける「親玉」的存在のレンダーオートメーションに踏み込んでみるのも良いかも知れませんヨ。
■ファイルの「名前」について、メモ■ スレート自動表記のエクスプレッションは、ムービー名、ファイル名に大きく左右される事となります。エクスプレッションにて自動表記し、レンダーキューのレンダリングファイル名を自動更新する為には、タフな命名規則が望まれます。 また、アニメ制作においてファイル名は、「小さな、データベース記録媒体」である事を認識すべきでしょう。「カット番号が判別できればいいや」的なぞんざいな使い方は、「皮だけ食べて、肉を捨てる」ような使い方であり、現場においては、例え１文字でも「記録媒体」として使うぐらいの計画性・合理性を働かせたいものです。 とは言え、ムービーファイルの命名規則は作品や会社ごとに多種多様です。よく練られたものから、かなりテキトーなものまで千差万別です。私が命名規則を作る際に気を配るのは、以下のポイントです。
「１」＝「直感的に認識・把握しやすい構造を持つ」は、命名規則の解説を読まなくても、名前を見ただけで状況を把握できる構造を持つと言う事です。「x&r54n1g2.mov」なんて言う暗号のような名前では、初見では全く内容が理解できませんが、「xr_54_001_gen_t2.mov」と言う名前ならば、「xrの54‥‥54話？‥‥の、001‥‥カット001？‥‥の、gen‥‥げん‥‥原撮？‥‥の、t2‥‥ティー‥‥テイク？の２？‥‥。つまり、xrと言う作品の54話カット001原撮テイク２‥‥と言う事？」と、不確かながらも憶測する事が可能です。 これは、制作現場においてカットの諸元を伝える際の手順が、作品・話数・カット番号だからであり、その手順を命名規則に導入しているからです。アンダーバーなどの区切り文字が接続詞の「の」の役割を果たしている事も重要です。現在では8+3の文字数で縛られる事はありませんから、多少冗長でも直感的な名前を心がけるようにしています。 「２」＝「フィールド分解（配列化）が容易」は、コンピュータの素養のひとつ、データベースを活用する際に重要となります。「直感的に認識・把握しやすい構造を持つ」名前は、その把握し易さゆえ、名前の中にカットの基礎情報を取り出しやすい形で内包しています。名前の中に封じ込んだ情報を取り出す際に、手間があれこれ必要になったり、作品ごとに規則が違うのでは、効率を著しく損ねます。 例えば「c」をカット＝Cutの略号・イニシャルとして用いた場合、作品の略称の中にcがあったり、「シーン c」がある場合は名前がcだらけになり、cがいったい何を意味しているのか、混乱の元となります。 作品「California Conference Center」のＣパートのカット001‥‥‥ccccc001 ちょっとイジワルな例題かもしれませんが、作品略号cccのｃパートのc001をそのまま連結すると、どうしても「ccccc001」になります。フィールド分解する際に「cはカットのイニシャルだから、cを区切り文字にして分割して」とか、「cが表われたら、その次にカット番号が来る」と言った分解規則性が、作品によっては通じない‥‥と言う欠陥が生まれます。よって、「作品ごとに情報取り出しルーチンを作り直す」ハメになる訳です。「いっその事、Cで始まる作品は何か他の文字で代用する」と言う回避策も考えられますが、本来ならばCを使いたいところを「Cの制限」故に断念する事になり、「作品をイニシャルで表す」と言うごく平凡な（かつ直感的な）処置が不可能となります。 またフィールドで分解する方法は、「何文字目から何文字目」と言う「文字の配置」による制限を受けない為、例えば「作品略号は2文字厳守」のような「すぐに限界がきそうな禁則」とは無縁です。「文字規定方式」ではなく、「フィールド文字列方式」であれば、フィールド内の文字列は「可変」ですから、如何様にでも融通が利きます。 「名前を情報の１つ」として考えるのならば、その情報を取り出す際の利便性も考えておく必要があります。 「３」＝「拡張性を持つ」は、名前を扱う際に「名前の中に、xxの情報を新たに追加したい」といった場合に有効です。例えば、撮影チームや撮影会社、日付など、「名前の中に書き込む予定が無かった情報」を新たに追加する状況が発生した際に、全く拡張性が無いと対応できません。私の使用する「atDB」互換の命名規則は、予約フィールド以外は自由に拡張できる仕様です。いわゆる「可変」の名前を持つ訳です。
第４以降〜第マイナス３フィールドまでを可変としている為、「状況が許せば」どんな長い拡張も可能となります。「3Dテスト」とか「デモリール」とかの任意情報を名前に追加しても、破綻する事はありません。ただし、あまり長い名前は「読み辛い」と敬遠されますので、注意が必要ですネ。 私がスタンダードとしているこの「フィールド文字列（可変）方式」は、実は色々な画像フォーマットやQTフォーマットから学んだ方式を応用しているのです。可変ヘッダや可変データを持つファイルフォーマットの構造を、（ほんのエキス程度ですが）命名規則に取り入れた結果なのです。 「４」＝「2000年以降の各プラットフォームに難なく対応する」は、名前の文字列長や禁則文字などに関する配慮です。「\\」や「/」や「:」などを避けるのは勿論の事、「'」なども避けるようにしています。 「５」＝「同名の項目が存在しない、または存在する可能性を抑制する」は「名前が何の為に付けられているか」を考えれば、自ずと理由はわかると思います。映像内容が違うのに同じ名前を付けたりするのは、ファイル管理・バージョン管理が迷走して混乱するだけでなく、上書き誤消去の代表的な原因でもあります。「上書きして更新するから、同じ名前で構わない」と言う主義もあるのですが、それは言うなれば「更新する手間の都合だけしか考えない」やり方です。「明らかに違うバージョン」であるものを、恒常的に同じ名前で扱う制作システム・作業ルーチンは、少なくとも私は採用していません。 「６」＝「歴代作品の共通仕様と成り得る」は、作り終えた作品のアーカイブ（保存・ライブラリ化）と、これから作る作品の作業利便性を考える上で重要です。これは言い換えれば、自分たちの作った作品、及び、これから作る作品について、どのくらい「思いをめぐらせているか」と言う事でもあります。 以上、私は６つの「考えどころ」で命名するようにしています。故に、視認性も良く、データベースとの連携も滑らか、スクリプトとの相性も良い‥‥と言う結果となっています。ただし、条件を満たそうとする故に、名前が冗長になり易いという危険をはらんでいますので、どのくらいの文字列長が良いかなどの相談を作品の制作担当と取り交わすようにしています。また作業者に対しては、何度も同じ名前をタイプさせないように（それによって疲労しないように）、作業周りをスクリプトで武装し、「１度の名前入力が、作業全般に対して活きる」ように環境整備をおこなっています。 「たかが、名前」ではありますが、エクスプレッションを使い、様々なスクリプト言語を使い、１作品を丸ごと扱うようになり、おびただしいカット数の物流を扱うようになると、命名規則が「現場の効率」「疲労蓄積の度合い」を左右する一要因となり、ともすれば「命取り」になる事すらあるのです。
注意１）この解説ページに掲載してある「ちょっとピンぼけ」は実在しないアニメ作品です。 注意２）ここで紹介したスクリプトを実際に使用する際は、使用者の責任において使用してください。 |
IntegerQ INDEX
h.ezura / afx / ezqnet