IntegerQ GeoLog

2008/8/26 (火)

改修型。

改修型の語句で思い出すのは、M4とM51です。M51は型番こそ違えど、ベースは豆っぽいデザインのM4です。

M4

何も頓挫している写真を選ばなくても‥‥と思いますが、M4には何か似合っているんだよなァ‥‥。


M50/M51




また、メーカー自らが改設計をおこなっているうちに「別物になっちゃったよ」と言うのもありますね。F-86とF-100なんかは有名です。






改修‥‥か。

xtoolsも進行中‥‥

xtoolsのバージョン２もポツポツと作り進めていますが、現在のバージョン１の改修作業も欠かせません。xtoolsは「みつばち」を遥かに上回る大規模なスクリプトなので、簡単にメジャーバージョンアップなど出来ないので、現用はまだバージョン１のままなのです。そう簡単には「疾風」や「パンター」にはリプレースできないのだ‥‥。

最近、連番のBG素材（最近は美術さんが3Dソフトウェアを駆使して「動く美術」を作ることもあります）に対応する為に「CBX」（xtoolsファミリーの１つ）と言うコンポジション自動構築スクリプトのコードを見直したのですが、改めて見返すと、‥‥コードが悪い‥‥！　明らかにAppleScriptチックな「お気楽」コードで、変数の取り扱いからNGな部分が多いのです。さらに「After Effects 6.5」時代のバグを回避するまどろっこしいコードがそこかしこに書かれていて、書いた本人でも「？？」となるようなコードが頻発します。

‥‥そうなのでした。「コードを書き直したい」意味でもバージョン２の開発を進めていたのを、今更ながらに思い起こしました。

とは言うものの、現在の主力スクリプトはあくまでもバージョン１。設計が多少古かろうが、「改修に次ぐ改修」で現状に適応させなければなりません。まるで「四号戦車」みたいですネ。

＊初期の四号戦車


＊最終期の四号戦車


xtoolsバージョン１は「シャーシにガタがきている」と常々感じているので、早い事、バージョン２にアップしたいのですが、使い方（言わば戦術上の運用法）そのものも試験を繰り返す必要があり、まだまだ実戦配備には至りません。

xtoolsバージョン２（‥‥話の流れで言うと「パンター」か？）がサクサクと動く日はもう少し先になりそうです。

みつばちES

‥‥と言う「伝票作成スクリプト」の作成もほぼ中盤に達し、そろそろ使える状態になりそうな感じです。

伝票作成‥‥と言っても、単に伝票作成の為だけにファイルにアクセスするのも勿体ないので、あれやこれやと機能を追加したら、まあ、何とも成り行き通りにスクリプトが肥大化して、手軽に完成させるつもりが随分と時間をかけてしまいました。

時間がかかってしまったのは、特に以下の部分です。

・映像制作汎用コードのESTK化
・書式のプラグイン化
・Premiereとの連携の検証

映像制作汎用コード‥‥とは、ぶっちゃけた話が「timeを0+0表記に変える」だとか「timeをタイムコード表記に変える」だとか「fpsの相互変換」とか「ファイル名を分析する」とかの、地味なコード（プログラム文）です。ここらへんの基礎的な部品〜日曜大工で例えるとネジとかビスとか〜を用意しておかないと、ムービークリップの内容を書き表す伝票を作成するスクリプトなど作れないのれす。どんな高価な削り出しパーツがあっても、パーツを繋ぐボルトやワッシャーがないとネ。

その昔にAppleScript用に作ったルーチンの数々を、ESTK用に書き換えるだけでなく、今日のニーズなどに合わせて性能アップしたので、結構面倒な作業でした。黒コマの「間の子フレーム」の切り捨てをON/OFFできるフレーム数の相互変換ルーチンなどは、何度やっても頭が混乱してきますネ‥‥。

書式のプラグイン化は、色々な伝票書式に適合できるよう、設計当初から「書式をプログラム本体に組み込まず、プラグインで供給する」システムとしました。‥‥まあ、単に正規表現でひな形HTMLの語句を置換するだけの機能なんですが、「置換の規約」に少々時間をかけてしまいました。

Premiereとの連携は、伝票作成時にAfter Effectsに配置したムービークリップを、そのままPremiereにコピペして、サックリとテープ落としする為の機能です。この「After Effects to Premiere のコピペ機能」、使われているのをあまり聞いた事がないですが、After Effectsのシーケンスレイヤーは、コピペにてPremiereのタイムラインにペーストできるのです。ビデオボードに対応したムービーコーデックならば、レイヤーをペーストしてタイムコードをちょちょっと設定するだけで、Premiere上のレンダリング無しにHDCAMへのテープ落しが可能となります。‥‥できれば、Premiere自体がスクリプト対応だと、Premiere上で伝票作成までやっちゃうところなんですけどネ‥‥。

今後は劇場作品でもHDCAM等の使用頻度が増える事が予想されるので、「みつばち」も環境の変化に順応して行く必要があるのです。それにしても、意外にしぶとい「みつばち」ではあります。

2008/8/21 (木)

ふと２週間ぶりの‥‥

‥‥blog書き込みでございます。盆休みと本業、etc...が重なり、更新が途絶えておりました。

今年は結構、絵を描く機会が増えてきております。なんだかんだ言っても、アニメは「絵を描く行為」が基本‥‥というか、成立の出発点となりますので、その辺をおろそかにして「後処理」（＝After Effects‥‥？）だけに終始すると、「ネタいじり」の範疇から脱せなくなってしまうように思います。少なくとも、私は日頃After Effectsばかりイジっているので、そうなりやすいのです。自覚のないまま、いつしか、「絵を造る」と言う感覚からどんどん遠ざかってしまうのかも知れません。

現在の役職柄、HDマスターのプレビューにも立ち会う事がありますが、HDの高画質を目の当たりにするにつけ、今後の映像制作のアイデアがどんどん浮かんできます。‥‥と同時に、このHDの潜在能力を引き出せない現在のアニメ制作システムの限界をしみじみと実感しますが、‥‥まあ、何十年も続いたシステムはそう容易く転換できるシロモノではないのでしょう。

加えて、Retas互換の作業様式も、「可能性の伸び悩み」を助長している‥‥とも思います。Retasは言わば「セル・フィルム時代のアニメ制作をどのようにコンピュータベースへと転換するか」を目指したソリューションですから、発想の出発点が、セル絵具・フィルム撮影台の影響を受けるのは、当然の成り行き‥‥なのでしょう。

その昔、テレビアニメは16mmフィルムで作られていた事が多かった訳ですが、その頃の基準・技術・作法が今でも脈々と受け継がれています。いわゆる「デジタル」にどっぷりの私とて、16mmフィルムで撮影されテレビ放映されていたアニメを見て育った「子供たち」のひとりです。

これから先、先人の作り上げたスタイルに乗ったまま、どれだけやっていけるんだろうか‥‥と、よく考えます。先人のスタイル・システムを踏襲すると言う事は、同時に制約を受け続ける事にも繋がります。‥‥その先人のシステムはまぎれもなく、フィルムカメラ時代の産物ですから、「その時代の因習」を色濃く反映している訳です。フィルムカメラもセル絵の具も無い、この現在においてもなお‥‥です。

「テレビアニメの子供たち」たる私が、新しいアニメーションを作るには、「kill my father」くらいの決心が必要なのかも知れませんネ。

2008/8/2 (土)

RAネタ、その８b「コンポジションの尺を変更」

ちょっと間があきましたが、RAネタその8のb‥‥です。

前回の「コンポジションの尺を変更する」スクリプトは、尺を伸ばした分だけ空白になってしまう事が問題でした。



そこで、スクリプト内に以下の処理命令を追加・組み込みます。

//変数itmには当該コンポジションが代入されています
for(var l=1;l<=itm.numLayers;l++){
itm.layer(l).outPoint=itm.duration;
}

すると、ちゃんと全てのレイヤーがちゃんとコンポジションの最後まで延長されるようになります。



これで、めでたし、めでたし‥‥と言いたいところですが、実はこの処理はとんでもなく大きな「穴」があります。

例えば、以下のようなコンポジションがあったとします。



作業慣れしている人なら、すぐに「このコンポジションにおいては、一定区間ごとにレイヤーを分割してオペレーションしている」と読み取る訳ですが、コンピュータはそうはいきません。命令に書いていない事‥‥つまり、「作業経験から憶測する」事など、ゼロからは実行できません。単純に、先ほどのスクリプトを実行すると、以下の様にとんでもない「余計なお世話」を実行してくれちゃいます。



レイヤーを分割したのが、まるで台無し。薬よりも毒のほうが多いスクリプトになってしまいました。こんなスクリプトを実行してしまったら、全てのコンポジションを泣く泣く手作業で修復するハメになります。

ここで一考。作業者は「何を見て」レイヤーを伸ばすべきか否かを判断しているのでしょう。まさかインスピレーションではあるまい。

ずばり、作業者は「レイヤーのアウト点が、コンポジションのエンド点と同一もしくは以上か」を判断基準として、レイヤーを伸ばすか伸ばさないか決断しています。つまり、レイヤーの長さ（時間長）がコンポジションの終わりまで続いている場合は、そのレイヤーの絵が最後のコマ（フレーム）まで必要だ‥‥と言う事なので、都合、「レイヤーを伸ばす必要が生じる」‥‥と判断している訳です。もちろん、全ての事例においてその判断基準でオペレーションしている訳ではありませんが、少なくともコンポジションのタイムラインウィンドウの状態をパッと見て判断する場合は、「レイヤーの尻の状態」を見て判断します。

スクリプトで処理する場合、こうした「人間の判断基準」を処理内容に組み込まない限り、スクリプトの命令通り律儀に動作するコンピュータはいつまでも「おバカさん」のままです。

ではとりあえず、その問題点を克服するスクリプトを書いてみましょう。「レイヤーのアウト点が、コンポジションのエンド点と同一もしくは以上か？」でIF分岐を作ってみます。

for(var l=1;l<=itm.numLayers;l++){
if(itm.layer(l).outPoint>=itm.duration){
itm.layer(l).outPoint=itm.duration;
}
}


うまくいった‥‥ように見えますが、実際に動かすと、レイヤーのアウト点はうんともすんとも反応しません。何故でしょうか？


＊上図のコンポジションにスクリプトを実行しても、何も変化がおこらない‥‥

答えは簡単。「コンポジションの尺を伸ばした後では、レイヤーのアウト点とコンポジションのエンド点の関係は変わっている」からです。コンポジションの尺を伸ばす前、つまり「オリジナルの状態」の時点でレイヤーのアウト点を調べなければイケないのです。コンポジションの尺を伸ばした後では、「コンポジションのエンド点と同一もしくは以上か？」なんて判断できない状況に陥っているのです。

では、その不具合を克服するスクリプトに書き換えてみましょう。

//各変数については、前回のスクリプトを参照
for(var l=1;l<=itm.numLayers;l++){
if(itm.layer(l).outPoint>=itm.duration){
itm.layer(l).outPoint=modDur;
}
}
itm.duration=modDur;//ここで初めてコンポの尺を変更

結果は以下の通り。



うまくいった‥‥様に見えます。しかし、これでもやっぱりポッカリと「大きな穴」が残されています。その大きな穴を修復するには、現状の「コンポジションの尺を変更する」程度の意識ではなく、発想の転換が必要となってきます。‥‥そこらへんのちょっとややこしい話は、次の「その８c」にて。

2008/8/1 (金)

iTunes7.7の不具合

‥‥にここ数日で出くわしました。実は7.7のアップデータ配布直後から、色々な方々が「うひー」と混乱していたようですが、私はここ２〜３日でようやく気付きました。

その不具合とは「文字化け」です。詳しい内容はネット上を「iTunes 7.7 文字　化け」で検索するといっぱい出てくるので、そちらを参照するよろし。

iTunesの「文字化け障害」はこれが最初ではなく、以前のバージョンにも同じ様な障害が発生した事がありました。‥‥なので、今回（7.7）は冷静に対処できました。加えて、障害の発見が早期だったので、5〜6曲の文字化け修正で済みました。（1万曲以上のタグを2.4にアップするのは、少々時間がかかりましたが‥‥）

iTunes7.7にしろ、MobileMeにしろ、その不具合の発端はやはり新しいiPhone絡み‥‥か？

まあ、端からちょっと見ただけでも、明らかに（Appleは）オーバーフローしているように見えます。オーバーフローなどしていない‥‥と言うのならば、iTunes7.7のリリース前に文字化けくらい検証できてるだろうし、年額9,800円を支払っている沢山のユーザの事を考えれば、MobileMeの運用テストだって周到におこなっているはず。‥‥でも、そうでは無かった訳です。使ってすぐ不具合が露見する様な状態で正式リリースするあたりで、Appleの混乱ぶりが伺えます。

ただし、、、私とて、Appleは‥‥とか、Adobeは‥‥などと、他人ごとのように言ってられる身分ではありません。「明日は我が身」あるいは「過去の我が身」でもあります。

どんなに注意を払って、幾重もの防御線を敷いたところで、漏れ・綻びは必ず生ずるものです。まして、あからさまに未完状態で戦線に突入‥‥となれば‥‥。

未完成な状態で勝負に出る事の恐ろしさを、垣間みる想いです。