スクリプト、凡ミスです

前に書いたスクリプトの例文で、8フレームのオフセットで、

thisComp.duration-8;

とか書いてましたけど、これじゃあ、8秒引いてしまいますがな。。。すみません。

正しくは、

thisComp.duration-(framesToTime(8));

ですネ。

仕事してたら、ふと気付きました。

当該の記事は訂正して、順番を上げときました。

オリジナルのFunction集

スクリプトやプログラムを覚えたての頃(1996年頃)は、漠然とコードを書いていたのですが、それではあまりにも効率が悪い事に気がつき、定型の処理をモジュール化して共用するようになりました。誰に教えられたのでもなく、自然と。

オブジェクト指向のプログラムを覚えたのは、自己流のモジュールを作り始めて、さらに効率的な方法を求めていた頃でした。2000年前後の頃に、REALbasicというのがMacソフトウェアで出て、それで自作のクラスの作り方・使い方やプロトタイプ的な考え方を習得しました。オブジェクト指向って、何たるかが理解できるまでは悶々としますが、理屈がふと解る境界があって、それを超えると、反ってエスカレートしてオブジェクト的な考えで指向するようになります。‥‥まあ、それは私の場合、ですが。

でも、オブジェクト指向を持ち出さなくても、効率的に自作ソフトは作れます。時と場所で使い分ければ良いんですネ。

効率的に作る方法は、何よりも「使い回しの効くFunction」を作る貯める事です。例えば、連番の番号抜けをチェックするルーチンを、その度に書いていたら、まず時間を浪費してしまいますし、改良を加えようとすると、複数の自作ソフトウェアに埋め込まれたそのルーチンを全部直して回るハメになります。

MacOSXの場合は「Application Support」と言う共有ライブラリを置いておく場所も用意されてますから、そこに自作のFunction集を置いて、ソフトウェア上ではそのFunctionを呼び出すようにします。もしFunctionに不具合があった場合は修正すれば、すべてのソフトウェアに反映されます。

まあ、スタンドアロンのソフトウェアを作りたいのなら別なのですが、アニメーション制作で用いる様々なツールで共有するFunctionライブラリは、作り貯めて、活用できるよう整備しておくと、開発の面でとても楽になります。

塵も積もれば‥‥でしょうが、結構な数のFunction、サブルーチンを書き貯めました。ファイル名を分析する、撮影種別を撮影用語に変換する、番号欠番をリストする、EDLをAfter Effectsのtimeに変換する、数列からタイムリマップキーを生成する、TGAの空セルを生成する、他社の命名規則へ変換するマクロ、虫食いのイメージシーケンスを虫食い連番から生成する‥‥などなど。

Function集が充実してくると、骨組みを作ってFunctionで肉付けするだけで、そこそこの処理ソフトが作れるようになります。その時に足りないものは、ここぞとばかりに書き足せば、Function集はどんどん強力に育ってきます。

やっぱり、コンピュータはプログラムを作れてナンボ、だと思います。うわべで快適を謳うソフトが増えても、底力としてプログラムの知識は「特にコンピュータで四六時中仕事をする人」は必須だと思います。今も昔も変わらずに。

思うに、近年のコンピュータって、使う人間と使われる人間の「貧富の差」がどんどん大きくなっているように思います。iOSなんぞに満足してたら、あかんのです。

コードを書き直し

プロジェクトとコンポジションを自動でビルドする「CBX」というオリジナルソフトウェアがあるのですが、作った当時、After Effectsのスクリプトを探りながら書いたので、今読むと「ありえない」ような書き方が頻発しております。覚えながら作る弊害みたいなもので。

そろそろ、その「CBX」も、書き正すところは正して、開発を一旦終了すべきかと考えております。大量に作画して大量にペイントして‥‥というスタイルのアニメの作り方が、もう私にとってはリアルでは無くなってきた事もあり、「CBX」を使う頻度はどんどん減少するでしょう。しかし、まだ従来撮影様式の要請があるのも事実なので、少ない頻度であっても「レタス素材のコンポジット」を効率良く作業するために、内容をかすかでも記憶している今のうちにコードを読みやすく、刷新しようかと考えています。

‥‥自分で書いたプログラムでも、時が経てばすっかり忘れるものなのです。というか、私の場合は、少なくとも。

「CBX」は通常のアニメ撮影内容〜セルと背景、全セル、BGオンリーなど、旧来からのアニメ撮影のスタンダードを網羅するため、非常に面倒で煩雑なルーチンが内蔵されております。さらに、必要に応じて「増築」したゆえに、ラビリンスと化しており、作った本人でも早々に迷子になります。困ったもんで。

もしこのまま放置すると、数年後には書いた本人ですら読解に時間のかかるシロモノになってしまいます。

あと、もうちょっとは活躍しそうなツールですし、近々に必要になるので、4月あたりで何とか書き直そうかと思っています。あまり、奇麗にしようと欲張らずに。

空セル

After Effectsでアニメ撮影‥‥で思い出しましたが、初心の頃、大体つまずくのが、「空セル」の処理です。

ちまたを眺めてみると、

  • ブラインドエフェクトなどのエフェクト処理
  • 透明度0%
  • 全部透明の画像を用意する

‥‥が多いようです。今でも、そうなんだろうか?

一番簡単で融通が利くのは、プリコン&空フレームでしょう。初心者はなぜ、これに気付かんのか、不思議です。私も以前はそうでしたから。

画像シーケンス(もしくはQTでも)を読みこんで、すぐに使うのではなく、一旦プリコンします。‥‥で、プリコンした先でコンポのデュレーションを1フレーム分延ばし、何も絵がない1フレームをコンポジション上で作ってやるわけです。すげー簡単な、空セル製造法。

仮に先頭1フレーム目を空にして、2フレーム以降からイメージシーケンスをレイヤー配置すると、「0:00:00:00」フレームが空セルになりますネ。ちまたのWebでは、「timeRemapの値の調整だけでは難しい」とありますが、プリコンして空フレームを用意するだけで、「timeRemapの値の調整だけ完了」します。透明度やブラインドを併用するよりも、シンプルかつエレガントです。メンテも楽です。

スムージングのフィルタはプリコン前でも後でも。‥‥ただし、プリコン後にスムージングをする際は、レイヤー配置の座標は「0.5」が発生しないようにルーチンを組みましょう。じゃないと、画像補間法が邪魔して、スムージングがうまく適用されません。

プロジェクトのオートビルドのサブルーチンに、イメージシーケンス検証ルーチンと、この空セル処置を含めたプリコンのルーチンを組み込んでおくと、困った動画番号(歯抜けの番号とか、追加動画のA101,102とか)にも対応できます。空セルを作るだけでなく、歯抜けのセルを空セルで補うわけですネ。

イメージシーケンスファイル名を総チェックし、番号が全部繋がっていれば動画フッテージ、そうでなければ、静止画フッテージとして読み込みます。もちろん、スクリプトで、ですよ。歯抜けだったり、番号が一部飛んでいる場合は、静止画フッテージで読み込んだ連番をシーケンスレイヤー的に配置します。これももちろん、スクリプトで、です。‥‥シーケンスレイヤーなんて、手作業でやると地獄ですが、コンピュータでスクリプト処理すると一瞬ですからネ。

でもまあ、実は私、こうした「シートをつけて動きを云々」するタイプのアニメーションから、結構ご無沙汰しています。私が規約しているタイムシート「らしき」ものは、まず横書きですし、ABCDEセルなんていう概念はありません。3Dのリギングやオブジェクトのバインドに近い考え方で、シートの主目的は、演技シーケンスを記述するためのものです。1秒間を把握しやすくするために、都合、秒間をセル(=表の)で分割していますが、24コマの縛りはありません。概念としてはステップレスなので、60fpsでも120fpsでも、その場に合わせていかようにでも。‥‥もちろん、紙ではなく、データです。コンフィグ関連をいちいち紙にしているとロスが半端ないですからネ。

PHPとかJavaScriptとか

PHPロゴ-GIF久々にPHPのコードを書いているのですが、すっかり忘れとります。困ったもので。

どう書けば、PHP足り得るんだっけか‥‥とか、そんなレベルで忘れてます。ぶっちゃけ、似たような色んな言語を扱ってると、混同するんです。

PHPは、

<?php

?>

ですね。

Webをやるなら、PHPとかJavaScriptを最低限でも活用すべきです。そこそこ本気でやるならば、です。

「高度な事ができる」とか、そんなんじゃありません。手間を減らせるのです。要はCSSと一緒ですネ。

「HTMLだけ書いた方が、一番手間が少ないじゃん?」とか思う人は、あまり量をこなしていないんだと思います。でも、量といっても、ページにして50〜100くらいのレベルであって、実際にその量をメンテすれば、「手間」について実感できるとは思うんですけどネ。

例えば、Webページに共通のパーツや、記述。必ず、ページ最下部に表記されるクレジット的な一文を、50ページくらい書いた後で、「変更したい」となったら、どうするんでしょう? 我慢して50ページを全部開いて、修正部分を書き直しますか?‥‥そういうのを人生の無駄使いと呼びます。

「ひな形ファイルを用意して、そこから各々ページを書き増やす」だけじゃダメなんです。もしそのひな形が間違ってたり、後々修正したいと思ったら、それまでに書き溜めたコンテンツは全部修正しなきゃならんじゃないですか。

もしPHPやJavaScriptがあれば、そうした「ページ共通の記述・パーツ」を1つのファイルだけで管理し、どんなに書き増やそうが、最小の手間で、いつでも変更を反映できるようになります。

一番手軽なJavaScriptですと、例えば「credit.js」などの適当な名前でファイルを作り、document write()でクレジット文を書いておき、何10ページに及ぶ各HTMLページはJavaScriptを実行するだけにしておきます。つまり、スクリプトを実行する事だけをHTML上で書いておいて、文面の中身は他のファイル「credit.js」に任すわけです。そうすれば、「credit.js」を書き換えるだけで、100ページだろうが、1000ページだろうが、変更内容が反映されます。

PHPの場合は、共通パーツを書き集めたファイルを用意しておき、include_once()でそのファイルを読みこんで、実際の本文内で活用します。いくつもの変数、ユーザ定義の関数を書いておけば、あらゆる場面で活用できます。

このような構造は、もちろん、コンポジットの作業現場でも利用可能です。私はもう10年以上前に、「同じ作品を皆で作業するのに、何で、めいめいがAfterEffectsの設定を自己的におこなってるんだ?」と非効率で危うい(=人によって設定が間違っているかもしれない)運用に疑問を感じていました。ゆえに、xtoolsとatDBを自己開発し、「基本設定や仕様は、サーバ(=一元管理)に任せる」運用を実践したのです。これによって、ケアレスミスが格段に減ったのは言うまでもありません。

メンテや環境整備の手間が減る。これはすなわち、「本当に作りたいものに時間を割り当てられる」という事です。コンピュータは「真正直に手作業で向き合っていたら、その人間の『生気』をどんどん吸い取っていく」性質が多分にあります。怖いヤツなのです。

で、PHPとJavaScript。

本来は様々な機能を持っているのですが、「手間を削減する、ちょっとした工夫」にも威力を発揮します。プロパティの集中管理だけでも、使う意義はありますし、それならば難易度は低いです。変数をまとめて記述し、Web本文中に「echo」するだけですからネ。



今どきのCSS

近年はCSSによるWebページのデザインがどんどんエスカレートしているのは、端から見てて知ってましたが、実際にページを作ってみると隔世の感をしみじみと実感します。ウィジウィグのHTMLエディタが下火になったのも頷けます。細かいところまで手を入れようとすると、どうしてもコードを直に書かないと難しいですもんネ。

テーブルやフレームでレイアウトしていた昔が懐かしい‥‥。自分でIDやクラスを宣言して、サブルーチンのように書く今のやりかたって、もうほとんどプログラムですよネ。なので、プログラムに拒否反応がある人は、中々手が出せない状況になっているのかも知れません。

私が気になるのは、CSSの「背景」です。昔はこんなに高機能ではなかったような‥‥と調べてみると、何やら、「拡張・修正の続いている CSS 仕様の全てを完全に実装しているユーザーエージェントは事実上皆無といってよく、実際シェアで多数を占めるユーザエージェントは部分対応にすぎない」とのWikipediaの記述が。。。昔見たCSSとは随分出来る事が増えていると思ったら、やっぱりそうだったのか。

まあ、書式を統一する目的で使うのが、無難と言うところでしょうか。用途は自分のWebだけだしネ。


calendar

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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