ぶっちゃけ、今のAE

After Effectsは、私の「第2の鉛筆」とも言えるソフトウェアで、あんまり悪くは書きたくないんですけど、実際に2017年春現在のAfter Effectsには使いにくさや障害が増えてきて、ぶっちゃけ「悪ければ、悪いとしか書きようがない」です。

 

イメージキャッシュが更新されずに「ゴースト」が居続ける

 

非リアルタイムで遅く再生するときに、わざわざ音声トラックを遅回しで音出しする必要‥‥ある?

 

プレビューのキャシュが虫食いの場合、スキップして繋げて再生する必要‥‥ある? 逆に混乱しない?

 

フル画面でプレビューすると再生の途中で突如暗転して真っ暗になって戻ってこなくなることが3回に1回くらいある

 

ここのところのAfter Effectsの数バージョンは、どちらかというと「改悪」のベクトルに向いているように思えます。いいなと思える部分もありますが、日頃使いの部分が使いにくくなっているので、印象として「改悪」に感じるのです。

 

日頃使いの部分が使いにくくなった‥‥というのは、今までの慣習から変わったからで、要は使う自分側の問題だ‥‥と思おうとしても、プレビューすると暗転して絵が全く出なくなったり、イメージキャッシュが「あるはずもない絵を表示し続けたり」みたいなバグにいくつも遭遇すると、さすがに暗い気持ちにもなってきます。

 

新しい機能を追加したり、仕様を小変更することで、今まで安定していた部分が大きく崩れてしまうのなら、「そんな新機能いらんわ」という感情になっても致し方なし。

 

 

また、サブスクリプションの使用料金形態も、「不出来を許容する方便」になってしまっているのだとしたら、ユーザにとってはとんだ貧乏くじです。

 

 

「いや、これはたまたま、ケアレスミスで」と開発側は言うのかも知れませんが、こうしたミスが頻発してたら、決して「ケアできないミス」ではなくて、「ケアしようとしないミス」でしょう。

 

使う側としては、「ケアに至らない内部的な事情」すら邪推したくなります。

 

 

Creative Cloudを「アドビ税」とか言う人もいますが、システム要件の変化に追随してソフトウェアが安定して使い続けられ、機能も時代に合わせて向上していくのなら、「税」は喜んで支払います。

 

しかし、「税制」が「税を受け取る側の手抜きに繋がる」のなら、絶望しかないです。‥‥ぶっちゃけな。

 

私は職場とは別に、自分の自己研究用に2ライセンス分、つまり年間12万円をCCに支払っていますが、さすがに、1ライセンス分は削ってしまおうと思い始めています。多少やりにくくなっても、しょうがないです。今のAfter Effectsを含むCCに価値を見いだせなくなっています。

 

After Effectsの開発側の内部で、どのような変化が起きているのか、アウトサイダーの私は伺い知る事はできませんが、確実にAfter Effectsは不安定な動作状態になっている「今ここにある危機」があります。

 

 

ソフトウェアに限らず、アニメでも同じことが言えますが、会社の方針が変われば作品の傾向は変わりますし、現場の人員編成が変われば作品の品質も変わります。会社のブランドというものは、玄関の表札のロゴが作り出しているものではなく、中の人々が作り出しているのです。

 

After Effectsの「中の人たち」は何を想っているのか。After Effectsの今の状態を「これで良い」と想って送り出しているのか。

 

 

会社やグループ、そして個人においても、「良い波」「悪い波」の時がありますから、短気にならずに、まったりと接していくべきとは思います。

 

After Effectsも「今は悪い波の時だ」と心得て、ユーザとして、大局を見据えていこうと思っています。

 

 

追記:

RAMプレビューについて、YouTubeで「新バージョンで良くなった」的な映像が公開されてます‥‥が、

 

 

あのねえ‥‥‥‥、レイヤーが3つしかないような状況って何よ? しかも、再生がいかにも軽そうなムービーファイルのレイヤーで。

 

「劇軽」のコンポジションでデモしてみせて、高速になっただの、使いやすくなっただのって‥‥、まさか開発内部でもこの程度のコンポジション内容で「よし!うまくできた!」なんて言ってるんじゃないだろうな‥‥。怖いわ。マジで。

 

10〜20年前の頃は、開発マネージャーの方が時には米国の開発スタッフをも引き連れて、現場をよくリサーチしに来てくれていたものですが、最近はまるで無いよね。

 

あ〜〜‥‥あれか。アニメ業界はCS6でストップしてるから、アニメ業界にはリサーチの必要なし‥‥ってことかな?

 

でも、そういう制作グループだけじゃないんですヨ。

 

4Kで、レイヤー数も極めて多く、手描きで動かす動画だけでなく、手描きの原画をAfter Effectsで動かすような、重いミッションをこなす2017年のAfter Effectsの使用状況も、是非リサーチをしにきてくださると、After Effectsの未来の展望の一助にはなるかと思います。

 

編集ソフトでできるようなことを、After Effectsで再現してみせても、意味ないじゃん。編集ソフトは膨大なクリップ数からまさに「本編を編んでいく」ソフト、After Effectsは1カット1カットを「丹念に仕上げていく」ソフト‥‥で、同じ映像処理ソフトウェアでも意図も目的も大きく異なるのですから。

 


AE

今から20年くらい前、After Effectsのバージョン3.1から使い始めて、4.0や5.0へ進んでいく中、「After Effectsって、未来はどこまでバージョンがいくんだろうねえ。もしかして、バージョン20!‥‥なんてあったりして。うけけ。」と雑談しておりましたが、今やAfter Effectsはバージョン14。20もそう遠くない感じがしてきました。

 

アニメ業界では今でもCS5.5や6を使う会社も存在し、そのあたりもアニメ業界の今後の問題を象徴しています。実写作品のスタッフの方々と雑談をしていると、化石のようなバージョンを使い続けているアニメ制作現場の状況は、中々に忸怩たる思いに駆られます。

注)CS6はバージョン的には11ですが、年代的にはかなり前のバージョンで、私は職場や自宅では既にアンインストールして久しく、バージョンの内容も忘れております。CS6よりも古いCS5.5までになると、もはや霞むくらいにはるか昔の気がしますが、今でも使っている作品がある‥‥とは耳にしたことがあります。あまりにも古い機材を使い続けていると、機材更新の時に相当な物理的ショック(金‥‥ね)を受けると思います。恐ろしや。

 

After Effects自体にも、未来に生き抜くための課題は結構山積みのような感じです。今後はGPUなどを様々な処理に積極的に活用できて、とにかく速度向上を目指さないと、4K時代にAfter Effectsそのものが化石と呼ばれる日が来るかも知れません。ビデオプレビューなどの漠然と旧態依然とした、After Effectsの手つかずの旧式部分を、どんどん現在のニーズに合わせていく必要がありましょう。

 

一方で、After Effectsのスクリプト制御機能は、どんなに時代が進んでも、心強い味方です。

 

今どきのソフトウェアが、「こんだけ機能がミラクルになって、もはや、スクリプト制御なんて必要ないでしょ。だから、実装しないよ」とばかりにスクリプト制御機能を切っていくことが多い中、いざという時にスクリプトが使えるのと使えないのでは、状況への対応力が格段に変わってきます。

 

機能が豊富で未来的であることと、自動制御能力は、別腹です。

 

どんなに未来の映像を指向してても、やっぱりマウスとキーボードだけの手作業オンリーの選択肢しかないのは、制作体制の根本からドクトリンが変わってきます。手作業オンリーだったら、現場の生産計画や技術を低く見積もらなければなりません。可能を不可能と判断する愚行すら起こり得ます。

 

 

とはいうものの、スクリプトはやはり敷居が高く感じますし、実際に言語ガイドは英文オンリーで迷うことも多いです。

 

私の実感からして、After Effectsのスクリプトは、3つのポイントを踏まえれば、初心者でもイケそうに思います。

 

  • オブジェクトの継承(インヘリタンス)に気を使う
  • オブジェクトの階層構造に気を配る
  • オブジェクトとコレクションの扱いを理解する

 

‥‥の3つくらいかな‥‥と思います。あとは、普通のJavaScriptが展開されるだけです。

 

After Effectsの場合、様々なオブジェクトを扱います。レイヤーアイテム、コンプアイテム、AVアイテム、レンダーキューアイテム、アウトプットモジュール、etc...。

 

これらのオブジェクトの性質がどのような特徴を持つのか、把握しなければ扱いようがありません。また、どういう階層に存在するのかを把握しなければ、参照して情報を得ることすらできません。

 

そして意外に躓きやすいのが、After Effects独自のオブジェクトの扱いです。納得できれば、取り扱いに手を焼くこともないですが、特に初心の頃ですと、配列(単純な配列(Array)、ハッシュ、ディクショナリなど)の扱いそのものに手を焼くので、「コレクション」などという配列めいたオブジェクトに混乱するのです。

 

コレクションオブジェクトを理解できていないと、結構、色んなことができないですもんネ。

 

例えば、プロジェクト内の1番目のアイテムの名前を得るには、

 

app.project.item(1).name;

 

‥‥か、

 

app.project.items[1].name;

 

‥‥です。

 

アイテムを直に参照する場合は、[ ] ではなく ( ) を使い、なおかつ、インデックス番号が0ではなく1から始まるのも特徴です。

 

もし、配列を使った場合、このようになります。

 

var myArray = [app.project.item(1)];
myArray[0].name;

 

自分で生成したArrayの場合は、当然のことながら、JavaScriptのArrayを使うので、インデックス番号は0からスタートします。

 

これねえ‥‥、初心の頃だと、混同するんだよね‥‥。

 

 

でも、逆に言えば、そのくらいですかね、最初に気をつけておくべきことといえば。

 

あとは、レイヤーとして実体はあるものの、アイテムとしては存在しないテキストレイヤーとか、After Effectsの内部事情をおいおい理解していけば良いくらい‥‥ですかね。

 

 

ちなみに、After Effects流儀のインデックス番号に合わせて、ケアレスミスを防ぐには、Arrayの先頭にnullでも入れとけば、番号を揃えられます。ノウハウとも言えないくらいシンプルな方法ですが。

 

var i=1;

var myArray = [null, app.project.item(i)];
myArray[i].name;

 

 

After Effectsならではの基本的なことを踏まえておけば、After Effectsのスクリプト作りは大して難しい事でもないのです。

 

基本的なところを踏まえずに、唐突に始めて、すぐに壁にぶち当たって‥‥みたいな、「独り相撲で難しく」しなければ、案外、After Effectsの自動制御は理屈で覚えられると思うんですよ。

 

でもまあ、その「基本の理屈」を教えられる人材に乏しいのも、アニメ業界の現場の行き詰まりではあるのですけどネ。構造を理解していない人が、短期で得たノウハウだけでプログラムを教えようとしても、学習する側の人間が余計混乱する事態を招きますしね。

 

 

After Effectsは設計こそ少々古さを感じる昨今ではありますが、名実ともに日本のアニメ業界を支えるソフトウェアです。日本のほとんど全てのアニメは、CoreRETASではなく、NUKEでもなく、After Effectsがコンポジットしているのですから。

 

After Effectsはエレガントではないかも知れませんが、「映像のクラフトマンシップ」に応える質実剛健なソフトウェアです。

 

After Effectsがもしバージョン20までいったら、ぜひ「Anniversary V.20」のイベントでも開けるといいですネ。


Math.sin()を手に馴染ませる

前回紹介したMath.sin()関数は、10数年前からAfter Effectsに実装されているものの、少なくとも私は、たまに使っては忘れ‥‥を繰り返し、すぐにsinとcosの関係性を忘れます。毎日のように使っていれば覚えたまま忘れないんでしょうけど、中々に出番の少ない関数なので、必要になるたびに記憶から掘り出す始末です。

ちょっと余談ですが、円運動というのは、真正面から見て等速に動いていても、横から見るといわゆる「両端詰め」の動きに見えます。アニメではよく両端詰めの動きが出てきますが、そうした多くの動きは関節(や接合部)を基点とした円運動の変形でもあります。もちろん、すべての動きがそうであるわけではないですが、例えば、力を抜いた腕がフラフラ動くのは、変形した円運動の典型と言えます。円が変形すれば楕円や8の字になり、そこにエネルギーの加速減速が加味されれば、いわゆるリアクションをたっぷり含んだキャラの動きが出来上がります。‥‥アニメーターの方なら、思い当たるのではないでしょうか。

After Effectsでは、そうした円運動をプログラム文で表現することができます。エクスプレッションという「プチ・プログラム」をレイヤーの位置や回転や不透明度に適用することで、規則的(不規則な動きも表現できますが、とりあえず)な動きをキーフレーム無しで表現することが可能です。

例えば、レイヤーの位置に、

value+[time*100,0];

‥‥と書き込めば、1秒あたり100ピクセル、右に向かってレイヤーが移動する動きを作れます。

この機能を利用して、Math.sin()、Math.cos()、そして円周率のMath.PIを用いれば、様々な円運動を作り出せます。以下は、基本的なバリエーションです。


*1080p60で再生すると、滑らかな2K60pの動きを見れます。
*半径を「486px」にしているのは、画面内に収まりつつ、54px(1080/2/10=54)間隔のグリッドに綺麗に接するためです。

X軸とY軸のそれぞれの動きが組み合わさると円の軌道へと変化する様子は、ビジュアルで見れば、なるほど‥‥と感覚的に納得できるのではないでしょうか。円運動なんて、映像制作に全く関係ない人でも、日常で見慣れているありふれた要素ですが、その成り立ちを明確に認識しているのは、まさにプロの映像制作者の特質と言えます。

上図のMath.sin(),cos()の使い方を覚えておけば、After Effectsにおいて規則的な円運動で困ることは無くなります。‥‥と、自分の忘備録代わりに書いておこう。

ちなみに、頭脳パズル的な考えで、8の字の動きもエクスプレッションで表現してみました。8の字を描くためには、どのような軌跡を辿れば良いのか、プログラム文でパズルを解いてみます。



簡単なのは、左側の上下に軌道が偏った8の字のタイプです。意外に難しかったのは、右側の正円2つを組み合わせたタイプで、上下の往復を表現するのに手間取りました。

こうした円運動の動きは、ランプの点滅などにも応用できますし、自分流のwiggle(揺れ)を作る元ネタにもできます。

素材待ちの暇つぶしに、どうぞ。

ちなみにMath.PI

ちなみに、前回のテスト映像で左右に往復する球の動きは、sin関数を使っております。sin()なんてほとんど使わないから、すぐ忘れるんですけど、アニメ的に言えば、要は円運動に活用する関数です。

ただ、そのままですとタイミングが扱いにくいので、時間に円周率「Math.PI」をかけてやって、1周期1秒へと標準化して使うのが良いです。

以下のようなプログラム文をエクスプレッションに適用するだけで、レイヤーを左右に往復させる動きを作れます。

val=Math.sin(time*Math.PI)*(thisComp.width/2);
value+[val,0];


もし、球を画面中央からスタートさせず、右端か左端からスタートさせたい場合は、timeに0.5をオフセットしてやるだけです。例えば、timeを(time+0.5)のように。‥‥またはsin(サイン)をcos(コサイン)に変えても同じ結果が得られます。

「thisComp.width/2」は、画面全体を往復するために、画面の横幅を取得して2で割っているのです。ここを自分の好きな数字に置き換えれば、そのように動きが変更されます。

理屈は簡単。でも、プログラム自体を避け続けていると、妙に難しく感じてしまうものです。

私は手ぶれや画面ブレなどの生っぽい動きにはエクスプレッションの関数(randomやwiggleなど)は使わず、自分の動きの感性を反映させるためにあえてキーフレームを手打ちして、尺が長い場合はloopOut()などで延長しますが、コンピュータの得意な機械的な動き=算術が活きる動きの場合は、sin()などのJavaScript Mathを用います。

使い勝手は人それぞれだとは思いますが、私の場合は、周期的な円運動や振り子の往復の場合は、エクスプレッションで対応することが多いです。

After Effectsのキャッシュ問題

After Effectsでメモリを大量に消費するコンポジションをレンダリングすると、キャッシュが混乱してイメージキャッシュの相違が発生することがあります。

「After Effectsで作画する」ような重い処理を、さらに積み重ねて極度に重くした際に、発生しやすくなります。

障害例は「エフェクト(プラグイン)が外れて見える」「存在しない絵が存在する」など、まさにキャッシュの混乱による症状です。

例えば、レイヤーを全て非表示にしても、絵が画面に残る‥‥などの奇怪な(理屈で説明できるから「怪」ではないんですが)現象が発生します。もちろん、シャイレイヤーが隠れていた‥‥なんてオチではないですヨ。

障害を除去するのは、「全てのキャッシュをクリアする」コマンドを実行すればOKです。200GBとかヤバい量のキャッシュを、After Effectsは平然と溜め込みますからね‥‥。

この障害が怖いのは、「いつからキャッシュのゴーストが悪さをしているのか」、作業をしている最中では気づきにくい点です。After Effectsの動作上の不具合ですが、まあ、いつ解消されるかもわからん障害ですから、今の所は、定期的にキャッシュをクリアして、混乱しているであろうバッファを手動でリフレッシュするのが簡単な対処法です。

4Kの「デジタルアニメーション」のような、今のマシンにとって負担の大きいレンダリングを実行する直前に、キャッシュをクリアしておくのが確実です。

ちなみに、After Effectsの隠し環境設定の「シークレット環境設定」を使えば、レイヤーキャッシュを無効にできるんですが、不具合が出るのは内容が重い時だけなので、一緒くたに無効にすることはないですから、特にONにはしておりません。

Expメモ:loopのきかないプロパティをvalueAtTime()で

アマチュア・学生向けの教材を作る最中、loop関数の適用できないプロパティをループしたい場合、どのようにすれば良いか、ふとマジメに考えてみました。エクスプレッションで効率化を図れると言いながら、トーンカーブやメッシュワープで簡単に頓挫するのもブザマなので‥‥。

loop関数に頼らなくとも、現在時間をリピート区間で「%(割り算の余り)」すれば簡単にできそうだ‥‥ということで作ってみました。まあ、古典的な方法スね。

valueAtTime(time%key(numKeys).time);

これならば、メッシュワープのディストーションメッシュにも適用できます。実際、これでとりあえず、うまくできました。

loopOut("cycle"); ‥‥とほぼ似た動作になりますが、1つだけ問題があります。

上記エクスプレッションだと、レイヤー開始時間のオフセットがきかない‥‥のです。

まあ、考えてみれば、timeを何の加工なしに使うやり方なんて、コンポジション先頭からループの開始時点が始まってなければ、簡単に破綻する書き方です。使い勝手がよくありません。

レイヤーのstartTimeを使って、レイヤーをタイムライン上で右左に位置をずらしても通用する書き方だと‥‥

valueAtTime((time-startTime)%(key(numKeys).time-key(1).time)+startTime);

‥‥となります。できれば「loopOut("cycle"); 」くらいに、暗記できる短い命令文にしたかったのですが、私の知恵では無理です。1行で収めるのがやっとです。

これですと、まさにloopOut("cycle")と同じ使い方が可能です。ただ、モーションブラーではtimeが先頭に戻る瞬間に変な絵が出ちゃうかも知れません。とりあえず、私の試した範囲では大丈夫でしたが‥‥。
*注)0,10,20,30,40,50→0‥‥みたいなサイクルですと、50から0に戻る際に、モーレツなモーションブラーがかかる場合があります。これはキーフレームのコピペでも同じことではありますが。

ちなみに、key(numKeys)、つまりラストのキーフレームの値は、開始点のキーフレームと同じ値でないと、うまくいきません‥‥のは、loopOut()も同じすネ。また、キーフレームの繰り返しを実現するエクスプレッションなので当然ではありますが、適用したいプロパティにキーフレームが最低2個以上存在しないとエラーになります。

そんなこんなで、CC2015のエクスプレッション言語メニューを久々に眺めて回りましたが、‥‥あれれ、昔より要素が増えて、使いやすくなってます‥‥かね? 単に昔の私が幼稚だっただけかな‥‥。まあ、プログラムって、構造を理解するまでは迷宮みたいなものですもんネ。

注記:漠然とkeyやstartTimeなどと書いた場合、暗黙のうちに「me」「this」が対象となります。thisLayer, thisCompなんて書かなくても良いわけです。使い回しが効いて、短い文のエクスプレッションを書くには、暗黙の対象をイメージするのが良いスね。

トーンカーブの中割り

After Effectsのトーンカーブでキーフレームを複数打って、キーフレーム間を中割りさせようとすると、期待通りの結果にならない事があります。つい最近、実写作品の締め切り当日に発見しました。

もの凄く微妙なトーンカーブ変化を、長い尺をかけて中割りさせると、トーンの段階変化がジャンプする事があります。

期待する結果としては、無段階に推移してほしいわけですが、実際の結果は、1秒に1回変化するような大雑把な段階変化となり、その大雑把さが目視できてしまいます。

完成後のムービーを確認した当初、ガス素材のレイヤーでも外れたか?‥‥と思ったのですが、色々と検査したところ、トーンカーブが犯人だった事がわかりました。

30〜40秒のカットをニジリ〜っとトーンを締めていく内容で、そのトーンの締めをトーンカーブのカーブ変化で操作していたのですが、それがNG。カーブ変化は微妙過ぎると、中割りが雑になるようです。

各色16bitの色深度において、そのような大雑把なトーン変化が起こるとは考えにくいので、方針を変えて「あらかじめトーンを絞った調整レイヤーの不透明度を操作する」方法に切り替えたら、期待通りの「滑らかなトーン変化」が得られました。

こういう障害事例って、締め切り間際に発覚しがちなのはナゼだろう。

だから、例えレンダリングが1時間で終わる見込みであっても、「あと1時間で終わります」なんて告知してはダメなんですよネ。そのレンダリングが成功する「完全な保証」は無いわけで、一方の受け取る側は「1時間後に必ず受け取れる」と期待するわけです。

私は今までの作業経験の中で何回か、「まさか、このタイミングでそのトラブル!?」という事を経験してきたので、今回の実写も2シーケンスを最短で2時間で出せる見込みではあったものの、一晩挟んで、翌朝の編集さん渡しにしてもらいました。‥‥で、幸い(?)にも、その読みが当たり、普段だったら目にしないような珍しいエラーに対処して、次の行程へと受け渡す事ができました。

危ない橋が待ち構えている時ほど(プロジェクト全体のバッファが少ないから危ない橋ができるわけですが)、せめて内部的なバッファを用意しておかないと‥‥ですネ。

Boldの自動尺表示の誤差

今日、電話で「実際の尺と、ボールド(スレート)の尺表示が1コマズレる」的な話を知人から尋ねられたのですが、「尺が6秒前後でも発生する」と聞いて、エクスプレッションのアレだな‥‥とピンときました。23.976のアレではなく。

エクスプレッションのtimeToFrames()だかの引数のうち、「duration=true」にしておかないと、尺が1コマ少なく表示される事があります。私も数年前、他社から渡されたひな形プロジェクトで同じトラブルに遭遇して、エクスプレッションのコードを書き換えた事があるので、覚えとるのです。

しかしなんだ。今でもそういうミスを含んだエクスプレッションが出回っとるのね。10年近く前から見ているような気もする。

尺を丸ごとtimeToFramesにブっこむのも楽なんですが、整数で割った余りを計算するやり方だったら、duration=falseでも1コマズレなかった記憶があるのです‥‥が、随分昔の話なので覚えていません。

* * *

timeToFrames()とは違う話題ですが、24fpsや30fpsって、迂闊に小数点で計算すると、0.333333333334とかの誤差で期待する結果にならない事があって、昔は外部のプログラムとAfter Effectsの「小数点のやりとり」で色々と工夫していました。今でもAfter Effectsの仕様が昔と同じならば‥‥ですが、After Effectsは基本「floor」、つまり0.00000001でも足りないと切り捨てる仕様のようです。11.9999999フレームは、11フレームになるので、12.00000001にしといた方がトラブルを回避できるんですよネ。

アニメのタイムシートに馴れちゃうと、コマで勘定する事が多くなりますが、After Effectsを使う時は頭の片隅に実数(real)の感覚を常駐させておいた方が良いです。24コマのタイムシートの1コマは、1秒を「1」とする空間の中では、どう扱われているのか‥‥という事スね。

クラシック3D

新しい作業環境や、After Effectsのバージョンアップで、ついつい見落としてしまうのが、「3Dレイヤーのレンダラー」の設定です。急いでいると特にネ。

After Effectsのコンポジション設定は、デフォルトで「レイトレース3D」になっていますが、環境やコンポジション内容によってはこの設定項目が重荷になって、べらぼうにレンダリング時間が長くなります。極端な例を言えば、1時間で済むレンダリングが、24時間とか。

レイトレース3Dの機能が不要の場合は、「クラシック3D」へとコンポジション設定を変更しておくのが、面倒無くて良いです。普通に2Dベースのアニメ制作をおこなう場合は、レイトレース3Dの出番はほぼありませんので、新しいマシンやバージョンアップしたAfter Effectsを初めて使う際には、忘れずに「クラシック3D」へ設定変更しておくと良いです。Adobeのデフォルトとは逆の状態、つまり、クラシック3Dをデフォルトにして、必要な時だけレイトレース3Dへと切り替えるほうが、少なくとも2Dのアニメーションには向いています。

‥‥と言ってる私が、よく設定変更を忘れるんですけどネ‥‥。

ありえないレンダリング予測時間がレンダーキューで表示されたら、一旦止めて、コンポジション設定の「高度>レンダラー」の設定を確認してみても良いかも‥‥です。

しかし何だ、重箱の隅突きですが、After Effects上の「クラシック3D」と「レイトレース 3D」という文字表示、なぜに「レイトレース 3D」のほうには「3D」の前に半角スペースが入ってるんだろう。

After Effectsに文字情報を埋め込む

‥‥というタイトルを見て、あまり深く考えずに「‥‥それって、テキストレイヤーの事でしょ」と言う人は、ご名答です。

After Effectsには、テキストレイヤーがあるので、文字情報ならいくらでも書き込めるのです。

現アニメ業界の制作技法に限らず、様々な「作業の取り決め」は大体が文字情報で表現できます。という事は、作業の取り決めを文字情報として策定すれば、After Effectsでも積極的な活用ができる‥‥というわけです。‥‥実はそれが、私が10年近く前から取り組んでいる「atDB」〜アニメーション技術情報データベース〜なんですけどネ。

事前の規約をしっかりフィックスしておき、After Effectsの「item」の番地を読み出すfunctionも併せて用意しておけば、情報に確実にアクセスできる仕組みがAfter Effectsのプロジェクト内部に構築できます。

itemの「parentFolder」をフォルダ階層の上方に向かって繰り返し文で読み出し、「root」に達したらストップするようなサブルーチン〜functionを作ります。さらにcompItem(コンポジション)かどうかもチェックします。そうすると、
 
/db/cutinfo@anime_01_001

‥‥のように、まるでフォルダの階層を指定するかのごとく、itemの特定が可能になります。さらに、そのitem〜コンポジション「cutinfo@anime_01_001」の中の特定のレイヤー「layer('transition_info')」のソーステキストを読み書きすれば、トランジションの情報をAfter Effectsに埋め込む事も可能となります。

もちろん、トランジション情報だけでなく、自分らのワークグループで埋め込みたい情報を「文字ベース」で規定すれば、いくらでも必要な情報をAfter Effectsのプロジェクトファイルごとに持たせる事が可能です。

After Effectsのプロジェクトファイルに必要な文字情報を埋め込んでしまえば、後はエクスプレッションで如何様にでも捌けます。
 
comp('cutinfo@anime_01_001').layer('transition_info').text.sourceText;

用語の正引き・逆引き辞書も、
 
OLi=カット頭OL
OLo=カット尻OL
FI=フェードイン
FO=フェードアウト

‥‥などの書式でやはりテキストレイヤーに書き込んでしまい、エクスプレッションで「連想配列」に変換、カット固有の情報と組み合わせて、
 
「カット頭OL(1+0)」

‥‥なんていう文字列をカットボールドに自動表記させる事も可能です。

普通のアニメ撮影の「スタンドアロン」状態のエクスプレッションでは、コンポジションのデュレーションを読み出して尺の自動表記は可能でも、カット毎に異なるトランジション情報は、テキスト手打ち込みで表記するしかありません。しかし、データベースから情報が供給されれば、様々な自動表記が可能になり、加えて、表記をミスる事も防げますし、事前に尺間違いに気づいて修正する事もできます。

「データベースサーバを使う」事を覚悟し、実際に運用すれば、After Effectsは別次元の「グループウェア」的な側面を見せ始めます。

データベースの運用になれて、使い方が洗練されはじめると、「そもそも、After Effectsに情報を書き込むんじゃなくて、サーバと随時アクセスすれば良いんじゃないか」という考えも浮かびます。しかし、私は未来の状況(全国各地に点在するスタッフとのやりとり)も考えて、「サーバへのアクセスが少なくても、情報を一回読み込めば、スタンドアロンで作業が進む」方法も残しておきたいと考えています。ゆえに、After Effectsに情報を書き込んでしまう方法も模索しています。

未来への課題は沢山あります。些末に見える、こうしたテキストレイヤーごときの運用術も、「ちりつも」で、やがて大きな成果へと結びついていくのです、


calendar

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM