After Effectsのゾンビ変数

ここのところ、作り続けていたグレーディングシステム用のパイプラインアプリですが、ほぼ完成し、あとはバグ潰しや機能改善をチクチクと地道に進めていくのみです。どんなに気を配ったつもりでも、実際に運用すれば、ポコポコと穴は出てくるものです。

After EffectsをAppleScriptで駆動する方法は、丁寧にAppleScriptとAfter Effects間でやり取りするのではなく、ESTKの命令文を作って丸投げする方法です。AppleScriptでPhotoshopを操作する際は、様々な返値を利用できるのですが、After Effectsの場合は貧相なexitCodeしか返ってきません。exitCodeは整数のみで、文字列などは扱えないので、スクリプトを実行した結果は実質受け取り不可能に等しいです。例えば、コンポジションのレイヤー名一覧を外部から取得する‥‥なんて事は通常の段取りではできないのです。

じゃあ、どうやってAfter Effectsをスクリプトで転がすかと言うと、ソケットや独自のクリップボードを使う‥‥などもありますが、環境の整備がそこそこ面倒なので、私は「変数を泳がす」方法で切り抜ける事が多いです。恐らく、一番安易で簡単です。

After Effectsの変数はゾンビのように、After Effectsが死ぬ(アプリ終了)まで生き続けるので、これを利用して、「ゾンビ変数に値を持たせたまま泳がせて」外部から上手く操作するわけです。

AppleScriptなど外部からは、変数・定数の中身ではなく、あくまで変数名だけで、転がしていきます。つまり‥‥
 
//Script 1
var _OUTPUT_COMP=app.projects.item(1);

‥‥として、変数に普通に代入しておけば、スクリプトを一旦終了しても、After Effectsが終了しないかぎりは、いきなり、
 
//Script 2
_OUTPUT_COMP.layer(1);

‥‥と書き始めても、undefinedになる事もなく、普通に取り扱い可能です。変数の中身は外界に取り出さずに、変数自体を外部からあっちゃこっちゃと転がして、上手くいった場合は0、そうでない場合は0以外をexitCodeに代入して、「result as integer = 0」でBooleanに変換し「結果報告だけを聞く」カタチにするのです。

いつまでも変数が死なないこの習性(?)を利用すれば、結構自由にAfter Effectsを「遠隔操作」で転がせるのですが、反面、変数が暴走(大袈裟ですけど)する危険性もあります。JavaScriptはDimとか宣言しなくても、おもむろに変数を使う事ができますが、ゆえに、既に前の前の前のスクリプトで使用済みの変数を、意識無しに使ってしまう可能性もあります。なので、ゾンビ変数を意識的に転がす際は、変数の名前のお約束を自分の中で定義してキッチリと運用する事が必須となります。


変数 i に10が代入されたところでスクリプト終了。


別のスクリプトで 変数 i をおもむろに使うと、既に10の値がセットされているので、結果は30。うひー。‥‥もちろん、変数 i の使用前歴がなければ「iは未定義」となってエラーです。スクリプト作成者の「管理能力」が問われる仕様ですネ。undefinedねらいの軽妙な文面でなく、しっかり変数の宣言と初期化をやっておかないと、後で弩壷にハマる仕様となっております。


‥‥ちなみに、エクスプレッションはそういう事(ソンビ)はないようで、1レイヤー1フレームごとに値はクリアされるみたいです。まあ、全てのエクスプレッション上の変数が生き残りまくってたら、わけがわかんなくなるでしょうからネ。

 

AppleScriptのcontinue

AppleScriptは、Macユーザかつスクリプトを常用している人間でないと使わないので、マイナーなアプリではありますが、その能力はあなどれません。私の自作ツールのほとんどはAppleScriptベースですが、業務の生産効率を左右するほどの影響力があります。

ただ、AppleScriptに何も不満がないわけではなく、こんなのがあるといいのにな‥‥と思う機能はそこそこあります。すごく基本的なところではループ文における「continue」です。

AppleScriptでも「continue」はあるのですが、「処理を続ける」という命令で、ループの処理を抜けて次回へスキップする内容ではありません。JavaScriptのcontinue相当はどうもAppleScriptには存在しないようです。breakはexitでイケるんですが。

要は、処理を抜ける構造が実現できれば良いので、以下のようにしてcontinueと同等の動作は実現できます。

set myList to {}
repeat with i in {1, 2, 0, 15, 2, 2.1, 2, 3}
    repeat 1 times--continue実現の為のrepeat
        set i to i as number
        if i = 2 then exit repeat
        set myList to myList & i
    end repeat
end repeat
return myList
--結果は{1, 0, 15, 2.1, 3} 
〜変数「i」が2の時はexit(break;)して、以降の処理はスキップします

入れ子のrepeat上でexitを使えば、exit以降の処理は実行されずにスキップされるので、continueと同じ働きをします。

しかしなんでしょ‥‥、行儀は悪いですよね。continue実現のために、repeatを本来とは違う目的で用いているのですから。

インクリメントとかは、単に「set i to i+1」とやればよいので、文字数の冗長さにガマンするだけで済むんですが、continue模倣の為だけにrepeatを使うのは、後になってコードを読み返した際に「何でここでrepeatを使ってるんだ?」と自分でも判らなくなりそうで、面倒でコワいです。

ちなみに‥‥。参考文中の「set i to i as number」を読んで、「なぜ、そんなクドいキャストを?」と思う人もおられるかもしれません。変数 i には当然Numberクラスが代入されていると思うわけですが、その変数 i を「is」「=」の比較演算子を用いて評価すると、実際はうまくいかないのです。AppleScriptにはありがちな動作ですネ。「item 2 of {1,2,3}(つまり2ですネ) 」は、2ではない‥‥という比較演算‥‥。でもまあ、もう16年もAppleScriptと付き合ってると、他の言語にはないクセもお馴染みなので、もはや混乱する事はあまりないです。AppleScriptが「何でヘソを曲げているのか」は大体察しがつきます。しかし、JavaScriptなどの他の言語に慣れた人がAppleScriptを使うと、「???」の連続かも知れませんネ(苦)。

Mac After Effetcs 12.1のマウスホイール

バグです。

After Effects 12.1のMac版にて、映像表示部の拡大縮小をマウスホイールで操作しようとすると、反応が鈍くてイラッときます。

この症状は米国のAdobeスタッフも認めるところで‥‥

We have verified this bug internally in After Effects 12.1 on Mac OS, with a variety of mouse hardware. The problem does not occur on Windows.

The issue is related to scrolling speed. If you scroll very slowly, the scroll action is not recognized. If you scroll at a faster speed, the scrolling action is recognized. This is true for scrolling in all panels, not just viewers; it's possible you only see it in viewers because your intent to zoom via scroll requires more precision.

Apologies for the bug. We are investigating the cause and a fix. In the meantime, my recommendation is that when you need to zoom in via small increments in a viewer, use the keyboard shortcuts, or switch briefly to the Zoom tool.


‥‥だそうな。フォーラムより抜粋。

要は、「After Effectsのマウスホイールの問題は当方でも認識しており、Mac版でのみ発生する。問題が解決するまで、ショートカットなど他の手段でよろしゅう。。。」という事です。

むきき。職場のは12.0だけど、自宅のは12.1にしちゃったんだよねェ。

ちなみに、ズームイン&アウトは、テンキーじゃないほうの「.」「,」です。半角英数字入力で。

あー、もっとはやくフィードバックしておけば良かった。。。まさかAE側の障害とは思わんかったです。

上方修正

グレーディング作業におけるパイプラインプログラムの導入効果は、予想以上に高く、当初3日分と見積もっていた作業量を1日でこなせる勢いです。同時に撮影業務も少々兼務していますが、そちらは相変わらずのペースで、様々な場面で効率を落とすトラップが仕掛けられています。撮影もStandardizationを実現できれば、効率化も夢ではないとは思いますが、現状では部署単独で改善に望む事は実質不可能とも思います。

でもそうやって、互いの部署同士が干渉を避けてきた結果が、今の状態と言えます。30年以上、基本的な制作システムが変わってこなかった‥‥つまりは、制作システムの技術革新をしないまま現在に至った状態です。それなのに、やる事をどんどん増やしているのだから、昔と同じ状態を保てるわけがない、歪みが出ないわけがない‥‥ですよネ。

やる事が増えたから金を増やしてくれ‥‥という考え方もあります。でも一方で、やる事が増えるのに伴って、生産システム内部での技術革新を模索していないのはどういう事か。言わば、自分の健康維持を、医者や医療制度のせいだけにして、自分の生活習慣は何も改善しない‥‥のでは、かなり説得力に欠けると思うのです。

何をするにも巨象のようなカロリー消費が必要な、今の業界制作システムでは、保守的な「成功例のある」作風に終止せざる得ないと感じています。

もし運用技術の革新を実現して、フットワークを軽くできたなら‥‥。それは、作品企画でも実制作でも雇用面でも、大きなシフトチェンジになるように思います。旧来からの状態を維持‥‥という考えを捨てられない限り、新しいフェイズへは進出できないのではないでしょうか。

ゆとり世代って、世間ではイジられる対象みたいになっていますが、私は結構、Unique(=独特)な面白い人材が多いと感じています。不思議ちゃんもいれば、才人・才女もいて、バラエティに富んでいるように見受けられます。‥‥私の周りがたまたま‥‥なのかな? 自己の感覚に準ずる一方で、思考を巡らす習慣を持つ‥‥というか。‥‥でもまあ、世の「ゆとり世代は」と嘆きたがるオジさんたちから見れば、行動パターン要素の「配列順」が気に入らないのかもしれませんけどネ。若い人間が現アニメ業界から学ぶべき「しきたり」は沢山ありますが、30年前の構造を絶対的だと信じ込む必要はないですし、「泳がされた世代」なのが反ってThink differentの可能性を秘めているようにも思うのですヨ。業界のシステムの非合理(昔は合理だったかも知れないけど)を純粋かつクールに観察できるのは、セル用紙やフィルムから遠い人間かも知れませんネ。

プログラムひと段落

After Effectsをグレーディングソフトウェアに仕立てるスクリプトプログラムがようやく実働状態となり、とりあえずはひと段落です。プログラムそのものは「パイプライン・ソフトウェア」とも呼べるもので、要はグレーディング作業の「段取り」を整えてくれる内容です。‥‥なので、凄く地道なプログラムです。

1,000行超えのスクリプトなので、もはや簡易なソフトウェア状態です。外部モジュールを多用しているので、ベタに内部処理に換算すると、2,000〜2,500行くらいには到達するやも知れません。規模が大きくなってくると、コードの管理が大変なので、使いやすいIDE(統合開発環境)が欲しくなってきますネ。昔使っていたREALbasicはモジュールやクラスをグラフィカルに示してくれるので、中規模クラスの開発には都合良かったのです。AppleScriptエディタやESTKエディタは、やっぱりテキストエディタ+アルファですもんネ。大量の文字をかき分け、プログラムを書き進めるのがツラい、、、。

今回のお題はグレーディング‥‥とは言っても、全部クリップが揃ってからおこなう行儀の良いものではなくて、バラで素材が入ってくる、管理の面倒なタイプの作業なので、それを人手で捌いていたらカロリーを大量消費してしまいます。その影響はモロに映像に出るので、どうしてもパイプラインの自動化は必須だったのです。

私の目指している作業スタイルは、少人数で高品質の映像を作る事です。そのためには、パイプラインのお世話のためにカロリーを消費している場合ではないのです。技量の高いスタッフを雑事で疲弊させる事無く、映像作りそのものに集中させる事ができれば、時間やお金の価値、ひいては人そのものの価値も変わってくるはずです。

「少数精鋭」なんて言う人は多いけど、人が少ないからインフラもおざなり‥‥なんて事も多いですネ。人が少なければ少ないほど、インフラには高度なものが求められると実感してます。人海でカバーする事ができないのですから。

実際に作り立てホヤホヤのプログラムを走らせてみましたが、‥‥やっぱりパイプラインの流通をコンピュータがケアしてくれるのは、超快適です。すぐに作業に入れて、作業中は映像だけに集中し、ノルマをこなしたら後腐れ無くサックリ帰宅できます。作業進捗情報は作業の節目にデータベースへ自動記録されるので、わざわざ日報などを書く必要もありませんし、集計表もすぐにデータベースから引き出せます。

でもまあ、考えてみれば、1,000行以上に及ぶプログラム同等の段取りを、以前は人が貴重な時間と体力を消費してこなしていたのですから、そりゃあ段取るだけで疲れるのも当然です。プログラムコードに書き起こしてみれば、人間がどれだけコンピュータでも代理可能な雑事に忙殺されているのかがグラフィカルに解りますヨ。‥‥少なくとも私は、その細々とした雑事を引き受ける自信は無いですし、凡ミスしてさらにややこしい事態になるような気がします。

人やお金の価値って、作業システムやインフラ次第で極めて大きく上下すると実感します。漠然とコンピュータを用意してネットワークでつなぐだけじゃ、かえって手間が増えるんじゃないのかな‥‥と思うのです。
 

立体参考資料

私は作品制作の参考資料として、プラモデルを活用します。マンガのコマや絵コンテを描く際に、設定だけチラリと見て描くより、プラモを手に取って描いたほうがアイデアが豊富に浮かびます。その機種ごとの「いい顔」「いいアングル」が目の前で即座に確認できますからネ。

プラモ制作も自分でやるのですが、物量をこなさないとダメなので、中々に大変です。休日の短時間しか制作に時間を割けないので、いかに短期で仕上げるかがミソとなります。

立体を把握するための資料なので、実機のようなリアル表現は不要です。立体把握の際に、実機塗装は邪魔になる事が多く、つや消しの単色で塗られているほうが都合が良いので、サーフェイサーと墨入れ、最後にトップコートだけで済ませます。

なので、戦車などの地上物、艦船などの海洋物は、窓ガラスさえなければとても楽です。しかし飛行機はキャノピーのマスキングに手がかかるので、どうしても停滞しがちです。以下のように‥‥。


*サーフェイサーはほどよい艶消しなので、ご覧の通りに、立体が把握しやすく、影付けの参考にもなります。3Dで作るという選択肢もあるでしょうが、何から何まで3Dで作るのは大変ですから、まずはプラモデルで実感を得るところから始めるのが良いと考えています。

この他、写真の倍の数のプラモが、キャノピー待ちで滞っています。ちなみに上のプラモは、タミヤの1/100シリーズで、1967年頃の金型で、私と同年齢の製品です。コックピットの表現は1/100かつ旧製品なのでビミョーですが、ロングで全体のフォルムを簡易確認するにはちょうど良い大きさです。

キャノピーのマスキングは、Adobe Illustratorで実寸のマスクを作成し、伸びる透明シートにプリントして作るのですが、中々全面が埋まらないので、どうしても「図版完成待ち>プリント待ち>キャノピー待ち」という悩ましい連鎖が発生します。資料用途なので、同じ機種のバリエーションを複数作る事が多く、毎回ワンオフでマスキングをしていられないのです。また、段差消しや継ぎ目消しもほどほどで終わらせ、資料として支障のない程度におさめます。趣味ではなく、業務用の作り方‥‥ですネ。

ただ、サーフェイサーばかり大量に吹くと、スプレーブースのフィルタがすぐに目詰まりします。クレオスのブースはこともあろうに「フィルタの交換は両面テープで貼り直して」という異様に面倒な仕様なので、真正直に付き合っていられません。なので、鉄のプレートをフィルタ取り付け部周辺に強力ボンドで取り付け、強力磁石でフィルタペーパーを固定して使用しています。改造しちゃえば、クレオスブースのフィルタ交換もグッと楽になります。固定する磁石は100円ショップのものだと磁力が弱くてNGなので、コクヨのネオマグバルク品を買うと良いです。ちなみにフィルタはデイツーの換気扇用フィルタを流用しており、正規品より格安です。


*どんなサイズのフィルタでも流用可能なように、ベタベタと金属プレートを貼りまくっています。金属プレートもフィルタもケイヨーD2で安く入手しました。隙間は吸入の風圧でフィルタが側面に密着するので、この程度の固定で充分機能します。

出来上がったモデルは飾るのではなく、収納箱に判別しやすく保管します。あくまで実用なので、飾る必要はないのです。

しかし、まだ未制作のプラモが山ほど。‥‥以下の写真の10倍はあるのです。。。ぐえ。



 

目指すならハイアマ

現在はプロ並みのハード&ソフトウェアを安価に購入できるようになったので、アニメーションを自主制作する人が増えているようです。さらにはYouTubeなどの全世界に向けた公開の場があるので、昔よりは自主アニメを制作するモチベーションは高くなっていると思われます。

私は「アマチュア」を「報酬契約がないがゆえに、自分の好きなものを作れる」存在だと考えています。決して、技量の上下ではない‥‥と。

実際、アニメではないですが、プラモデルの「超スゴい」アマチュア作品をいくつも見た事があります。プロは報酬相応のクリオリティが求められますが、逆に言えば、報酬以上のクオリティは作らないという事でもあります。アマチュアはそんな制限はOut Of 眼中、まさに「値段の付けられない」作品を、一般のサラリーマンの方が作ってしまうのです。私のアマチュアの印象は、そうした「ハイ・アマチュア」の姿です。

で、アニメ。アニメは映像制作の知識がまだ世間には広まっていない影響か、アマチュア作品では作品云々よりも技術的なトラブルが目につきます。その技術トラブルのせいで、完成度が最後にガクッとダウンしている作品が多いように感じます。トラブルとは、輪郭のちらつき、フリッカー、アップorダウンコンバートのミステイク、映像信号レベルに無頓着、トーンジャンプ‥‥などなど。

正直、もったいない。‥‥調理場では美味しく出来上がったものを、盛りつけで失敗し、さらにはテーブルに料理を運ぶ際にこぼしてしまい、最後の最後で料理が台無しになってしまう‥‥。

もし「アマチュアだから、そのへんは大目にみて」というのなら、周りもそういう程度にしか見ないでしょう。でも、そんなの悔しくありませんか。‥‥折角作るんだったら、技術トラブルに邪魔される事なく、作品ができるだけストレートに観客に伝わったほうが良いじゃないですか。

例えば‥‥。
 
輪郭のちらつき
>画面全体のフォーカスやニュアンスをミクロレベルで調整する意識を持っていますか?
 =セルの輪郭線がキツ過ぎるとチラツキの原因になりますので、適度にボカしましょう
 =素材を配置してエフェクトをかけるだけでなく、全体のニュアンスを細かく操作しましょう


フリッカー(画面の動きが目にひっかかる)
>カメラワークやセル(人物やメカなど)のモーションを吟味していますか?
 =カメラワークはシチュエーションによってフリッカーのように見える事がありますので、カメラワークの速度などを変更して吟味しましょう
 =キャラの動きとカメラワークの動きが噛み合ないとフリッカーが盛大に出ますので、コンポジットの方法を変えてみましょう


アップorダウンコンバートのミステイク
>最良のマスターを作る意識を持ち、かつ、公開テストを実施していますか?
 =プルダウンなどのフィールド合成は現在は不要ですので、24pや30pのフォーマットで制作しましょう
 =DVDやBDに焼く際にはディスク作成ソフトのマニュアルを熟読しましょう(DVDの24p対応は意外にもあまり知られていないようで、不要な2:3プルダウンをする人が今でも多いです)
 =YouTubeでアップロードし全世界公開する前に、非公開でアップロード&再生テストを入念におこない、問題があれば、公開は一旦取りやめて、コーデックの設定などを試行錯誤し、障害を取り除いてから公開しましょう


映像信号レベルに無頓着
>いくつもの異なる環境で映像を再生していますか?
 =1つのPC環境だけで作っていると、色が偏る事がありますので、DVDなどに作品を焼いて色々なテレビ(身内や知人宅の)で見て、まず自分の環境と自作映像の傾向を知っておきましょう
 =レベル補正のヒストグラムなどを全体&RGB別にみて、黒の締まり具合や白の抜け方が意図する状態になっているか、確認しましょう
 =できれば、編集後にAfter EffectsやFinal Cutなどでグレーディングをおこない、全体のカラールックの最終調整をしましょう


トーンジャンプ
>公開メディア用に映像をチューニングする意識を持っていますか?
 =10bit(422)や12bit(4444)ではセーフでもYouTubeやDVDではNGな事がありますので、After Effectsなどで8bitに減色した公開用原版をつくりましょう

 
自宅機材でも充分実践可能な内容を書き連ねてみました。高価な基準モニタや測定器がなくても、プロ品質に肉薄する映像は運用次第でアマチュアでも作れる状態にあります。要は「見る人々に、最良の状態で映像を届けよう」とする意識、マインドセットの問題です。

自分の好きな事だけしかやらず、他の事はめんどくさがって放置する‥‥という意識が、作品をどんどん蝕んでいる事に気付けるか否か?‥‥ですネ。

どんなに美味しい料理でも、髪の毛が入ってたり、ハエが浮いてたりしたら、喰いたくなくなりますよね。ゴキブリが混ざっていた時点でアウト!‥‥です。解決法は簡単です。髪の毛や虫が入らないように、心を配る事、です。

意識が甘めだと、「自分の好きな事だけをやろう」という状態が、そのまんま、作品に出てしまうのです。「面倒な細部まで手を抜かず、手塩にかけて完成させて、満を持して公開する」という意識、マインドセットを持てれば、作品を蝕んでいた障害要素は激減し、より高い完成度を持つ作品となるはずです。もしキャパオーバーならば、未完成で出すのではなく、内容を削る決断力も、意識として必要となります。

でも、新たなマインドセットを獲得するのって、自分ひとりじゃ中々難しいんですよネ。‥‥ですから、他人の出来の良い作品を見て、ショックを受けて、自分の価値観を徐々に高めていく必要があるのです。私も日本のアニメ業界だけだと、ともすれば井の中の蛙になりそうでしたが、実写や欧米の制作手法を見て、「全然甘い」と思うに至り、新たな格闘をしている日々です。米・某社のアニメ(3Dじゃない〜まだ非公開?)を見た時はかなりショックで、日本側の決定的な遅れを痛感し、「日本のアニメ業界というマインドセット」からスッパリ抜け出る覚悟ができました。そういう刺激がマインドセットの変化には必要なのです。

Adobe CCやCLIP STUDIOなどがリリースされた現在、機材的なハンデはもう薄皮1枚です。あとは、「執念」というマインドセットだけ‥‥です。

安くても良い品

ここ最近、After Effectsの自動制御を利用して、VFX&グレーディングのシステム作りを進めています。私は近い未来、作画にもAfter Effectsを使用したシステムを作ろうとしているので、今回はその前哨戦というわけです。

After Effectsの良い点は、まずは安価である点、次にマニュアル(細かい手仕込み)で色んな事が出来る点、最後にスクリプト制御にかなり対応している点でしょうか。あくまで、私の主観ですが。

他の競合製品とかを見てもあまりココロがトキメかないのは、数十万〜数百万だしても、さほど結果物のクオリティが変わらない事に因ります。After Effectsの基本的な設計は、1997年に私が本格的に使い出した頃と変わらず、その点をつつけば「古い」と言われそうですが、新しいソフトウェアを使っても結局はクリエータ次第で結果が決まるのですから、全然気にしておりません。逆に、高い機材を使ってショボいのを作るほうが、恥ずかしいかな‥‥と思います。

私は最近、CLIP STUDIO PAINT EXというソフトウェアを使い始めましたが、中々に気にいっており、新しいアニメーション作りに使えないか、模索しているところです。私は2000年初頭のRETASの印象から、開発元のセルシスの製品を避ける傾向にありましたが、今のセルシスは以前とは大きく変わっていて、業界向けソフトウェアの販売というよりは、日本のアニメ&コミックのクリエーションを盛り上げようとしている雰囲気を感じます。

CLIP STUDIO PAINT EXは、月額500円で使用が可能で、特質すべきはクレジットカードや銀行口座を所有していなくても、コンビニで決済が出来る事です。これは若年層には大きな利点です。クレジットカード決済オンリーにすれば手っ取り早いでしょうが、あえて10代の学生でも可能な決済を実現し、かつ月額が500円なのですから、その意図は言わずとも充分汲み取れます。

CLIP STUDIO PAINT EXは、MacとWinの両バージョンがリリースされており、Macで一番安価な私のMac mini(i7で16GBメモリ)でもストレスなく動いております。各種の描線制御機能など基礎技術の高さを感じるソフトウェアでもあり、使い方に慣れれば、Photoshopよりは格段にアニメーション制作に向いているかも知れません。Photoshopのショートカットを数多く踏襲しているので、転向組もあまり迷わず作業が進みます。

私は未来の維持費も含めてシステムだと考えているので、ソフトウェアを導入する際はバージョンアップなどの維持費をべらぼうに要求するソフトウェアは「危険」だと判断し、できるだけ敬遠するようにしています。でもまあそれにしても、CLIP STUDIO PAINT EXの500円は安さが極端ですけどネ。毎回5万も10万も要求するソフトウェアはやがてバージョンアップが滞り、システムの崩壊が始まりますから、6〜12年くらいのスパンで維持できるソフトウェアを選択すべきです。ソフトウェアの購入の際に「清水の舞台から飛び降りる」ようでは後が続きません。

使い方次第で、米国大手のスタジオに比肩しうる作品は作れると思います。国内で言えば、アマ・個人でもプロ同等かそれ以上のものを作れる可能性を持つと思います。「一定以上の機能を持つソフトウェア」を手にしたならば、最終的にはクリエータ個々の技能が雌雄を決します。

なので、「一定以上の機能を持つソフトウェア」を何とか手元に揃えたいところです。Adobe CCの学割がもっと安ければ(高校生だと月3,000円はキツいですし、バイトをやってたらソフトをイジる時間が減りますから、どうしても親御さんの大きな援助が必要になるでしょう)、10代からバリバリ作れるんですけどねえ‥‥。

プログラムぐるぐる

私は今、ファイナルビジュアルエフェクト・カラーグレーディングのシステムプログラム開発の佳境で、頭の中にプログラムコードやダイアグラムがぐるぐると動き回る日々が続いております。絵作りとプログラムは、根本的なものは実はとても似ているのですが、手段が大きく異なるので、1日の中で同時に進行させるのは正直ツラいものがあります。しかし、「両立させなければダメ」なのは、もう経験上、痛いほど解っています。

After EffectsやPhotoshopなどを作業者各々が操作するにしても、では全体としてどのように運用するのか?‥‥を、コンピュータネットワークを活用したシステムプログラムで具現化すべく苦闘しているのです。After Effectsが漠然とコンピュータにインストールしてあるだけじゃダメで、作業リソース(素材や結果物)や各種情報をいかにして有機的にバインドさせてシステムとして成立させるかが必要なのです。システム作りをしておかないと、アリ地獄のような苦悶の日々、討死覚悟・バンザイ突撃の作業が待っています。

映像制作にコンピュータを用いる意義は、単に画具の代用品としてPhotoshopやAfter Effectsを用いるだけに留まらず、制作全体に機能すべきものです。コンピュータの能力を制作運用の全体に浸透させれば、著しい高効率化を果たせるのは明白なのですが、深刻な1つの問題によって、状況は停滞したままです。

深刻な1つの問題‥‥とは、シンプルな事ですが「マインドセット」です。「意識」「思考」とでも言いましょうか。コンピュータが制作運用を飛躍的に向上させるという意識が根本的に無いがゆえに、PhotoshopやAfter Effects、エクセル、Webブラウザ、メールをスタンドアロンの単体ソフトとして使う事ばかりに終止しているのでしょう。どれもみな、画具やカメラ、帳簿、図書館や辞典、手紙や電話の「代用品」としての使われかたです。

代用品思考なので、基本的なスタンスは以前と何も変わりません。以前の道具が高機能化しただけの意識に留まります。ゆえに人の動き方も以前と同じ。人の扱い方も、足りなければ人を増やし、余れば減らす‥‥という具合です。

業界は苦しいというけれど、実は自分たちの思考にも重大かつ根本的な問題があるようにも思います。基盤となるシステムを一向に改善しないまま、人材を自動販売機の商品のように扱うままの意識では、苦しい状態から抜け出せるわけもない‥‥と思うのは考え過ぎでしょうか。

でもまあ、昭和の時代に確立した今の作り方は、昭和生まれの人々が墓穴へと道連れにする‥‥ので、ちょうど良いのかも知れないな‥‥と、最近は達観しております。

ただ、昭和生まれでもジタバタともがく私のような人間も業界内には潜在するでしょうし、平成生まれの若い人は「勝手に道連れにするな」とも思うでしょう。‥‥だったら、新しいシステムを作らんと。先人の開拓精神を継承しつつ、新しい土台を形成しないと。

コンピュータは人間を疎外するものだという考えは、著しく古いレッテルでの発想です。ある種、昭和的‥‥とでもいいましょうか。

前々から言い続けている事ですが、コンピュータプログラムの活用は、制作現場当事者たちの能力を「引き立たせる」ために使うのです。臆する事無くズバリと言えば、人間を尊重させるために、コンピュータを使うわけです。私の考えるシステムはコンピュータで出来る事はわざわざ人間がやらず、人間にしかできない事を人間がやるという人間性重視のものだと自負しています。

コンピュータ入門編として、コンピュータを代用品として使う方法はありでしょう。しかし、もうそろそろ、プログラムにも着手しないと状況は先に進まないと思います。現場意識の新旧は、「自分たちの現場を支えるトータルシステムを、自己開発できるか否か」で、明確に示されるでしょう。

自分たちで土台を作り直さない限り、今の状況からは絶対に抜け出せないと思います。コンピュータプログラムを遠巻きにしているようでは、スタートすらできません。多かれ少なかれ、プログラムの素養を持っていなければ、ディスカッションすらままならないでしょう。プログラム音痴の人間「だけ」が寄り集まって、新しいシステムの有意義なディスカッションなんて不可能です。アニメとコンピュータの両方の知識が、まず必要です。

サザエさんの「デジタル化」でもわかるように、もはやアニメはコンピュータなしでは作れません。なのに、今でも異質な門外漢として、コンピュータを扱っているフシがそこかしこにあります。「インターネットが嫌いです」とインターネットを使って発言しているようなものです。そろそろ、目的と手段の整合性を直視しても良いんじゃないですかネ。

不整合を内包して無駄を延々と発生し続けているのに、「大変」だなんて、ある種の自作自演です。アニメーション制作は、何をどうやったって、基本的にとても作業量が多くて大変なものです。なのに、段取りを多くしてさらなる大変なものへと作り上げちゃっているわけです。作業量が多くて大変ならば、なぜ無駄や大回りを回避して効率を上げる方法を模索しないのか、不思議でしょうがないのですが、「アニメの作り方はそういうもの」というマインドセットが強固なので、呪縛を解けないのです。仮に1セクションが新しい提案をしても、全体意識が提案を却下する事も多いです。

戦(いくさ)度胸は必要ですが、それがイコール、バンザイ突撃なのだとしたら、コンピュータを導入してもなお、アニメ業界の根っこは昔と何も変わっていない‥‥という事です。兵士の度胸頼みの白兵突撃を繰り返す、無策の戦術と戦略。零戦無敵の神話は、サッチウィーブの確立によって早々に失われていた事は、日本人の私には耳痛い事ですが、事実は事実です。日本人はもしかしたら、昔取った杵柄を大事にし過ぎるのかも知れません。

数々の名作を生み出してきた昭和のアニメ制作システム。コンピュータやインターネットなど現場にはなかった時代のシステムです。私はそのシステム上で動く人々にどこか、大戦末期の零戦の悲痛な姿がオーバーラップするのです。しかし、運命まで重ね合わせる必要はない‥‥とも思うのです。


翻訳中

まだ当分の間、AppleScriptにはお世話になる感じなので、現在JavaScriptの基本的なメソッドをAppleScriptに翻訳してライブラリ化しています。

AppleScriptは、「大文字を小文字に」とか「配列をスライスする」「文字列を置換する」などのよく使う操作を、一発で呼び出せません。プログラム文をガシガシ書きまくる際に、何かと面倒です。なので、.toLowerCaseや.slice、.replaceなどをサブルーチンとして作って、簡単に呼び出せる仕組みを実践中です。共通のコンポーネントとして1つのスクリプトファイル内に蓄積して、スクリプトを作る際に「load script」すれば管理も簡便です。

スクリプトのコンポーネントの扱いは、難しい事はありません。以下のようにとても簡単です。
 
file "MacHD:components:basic.scpt"〜スクリプトコンポーネントです
to myMethod_A (str)
return "こんにちは、" & str & "さん。"
end

file "MacHD:Documents:myScript.app"〜実際の自作アプリケーションです
set bsx to load script file "MacHD:components:basic.scpt"
display dialog bsx's myMethod_A ("太郎")
display dialog bsx's myMethod_A ("花子")
display dialog bsx's myMethod_A ("お集りのみな")

映像制作に使うJavaScriptのメソッドは、基本的なもので充分です。join、slice、replace、match、toUppserCaseやtoLowerCaseくらいでほとんどカバーできます。substringやsubstrなどは、sliceで代用可能でしょう。なので、AppleScriptに翻訳するメソッドもそれほど多くはならないと思います。‥‥ただ、RegExpの翻訳(というか、導入)はどうしようかな‥‥とは思っていますが。。。AppleScriptで正規表現が使えたら楽は楽‥‥ですけどネ。

メソッドは翻訳できるものの、文章表現そのものの特質までは操作できません。例えば、AppleScriptはundefinedやnullをfalseと同義に評価する機能はありませんから、制御構造はAppleScriptの流儀でおこなうほかありません。JavaScriptは未定義の変数やNaN、0なども「偽」として評価されるのが楽なんですけどね‥‥。
 
if value1 then set value2 to "OK"//AppleScriptはNG〜value1は定義していない変数なので

set value1 to 100
if value1 then set value2 to "OK"//AppleScriptはNG〜変数がbooleanではないので

set value1 to 100
set value1 to value1 is 100
if value1 then set value2 to "OK"//段取りが面倒ですが、これならOK〜誰でも読み解ける文体を重視してるんでしょうね


でもまあ、各言語の文章表現までは介入できなくても、メソッドを共通にするだけで、随分とスクリプト作成は楽になります。これもインフラの一環と言えますが、インフラを怠ると、後でとんでもない代償を払う事になりますから、根気よく地道に貯め込んでいく所存です。


calendar

S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728   
<< February 2018 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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