アンドロメダ人気

最近、1980年頃のヤマトのプラモデルが再販されて、買ってもしょうがないな〜とか思いつつも、買ってしまいました。100円で売っていたシリーズで、今は210円で売ってます。子供の頃の記憶が疼くのでしょうか。

今、「さらばヤマト」を見返すと、中々にパンチが効いてて、見てて「ん〜?!」となる事も度々です。また、記憶ではインパクトの強い印象だった宇宙戦艦群も、実際の登場カット数はそれほどでもなく、子供心に随分「増強・補完」して見てたんだなぁ‥‥と思います。ビデオなんて無かった時代なので、映画館で1度きり見て、ずっと忘れないように反復しているうちに、どんどん「出来上がっていった」のでしょうネ。

作画・撮影なんかも、スケジュールが無かったのでしょうか、随分アラが目立ちますが、反面、今では3Dにしちゃうような大変な作画をこなしており、撮影でも奇麗なシーンがいくつもあります。テレサの洞窟のシーンは、透過光が画面作りの根本を成しており、白・黄色・グリーンの奇麗なグラデーションと軟調フィルタが、まさに神秘的な女性像を体現しています。同シーンの古代くんや真田さん(地上の人物)の色は、透過光のフレアが乗る事で微妙な色調を醸し出しております。「こういうシチュエーションのシーン、いつかやってみたいな」と感じましたネ。

子供時代、アンドロメダ(地球側の旗艦)は異様な人気を誇っており、みなでアンドロメダを描いたものです。あの複雑なディテールゆえ、上手く描けた子は一躍人気者になったほどです。

で、現代。いまでもアンドロメダは人気があるようで、ちまたにはプラモデルの作例がいっぱいあります。大型のアンドロメダも再販されておりますし、メカコレクションの小さいアンドロメダも再販されています。

大型のアンドロメダのほうは、ちょっとムックリした造形で、スマートな印象が消えているのが、ちょっと残念。発売当時、小学生だった私が、「こんなズングリしたのだったら、いいや」と、買えない事の理由付けにしていたのを、ふと思い出しました。

アンドロメダのデザインは、カラー的には、当時のアメリカ海軍のガルグレー&レドーム色と同じ、明るい配色です。また、2連の角張った波動砲のデザインは、どこか当時の最新鋭機F-14,F-15の二次元型エアインテークを想起させ、先進の「強いアメリカ」的な雰囲気を感じます。

ヤマトがそれこそ大和・武蔵だとしたら、アンドロメダはどこかアイオワ級的な直線ばったデザインで、「敗戦国色の濃厚な」旧ヤマトの作中にあって、暗黙のうちに強く語るものがあります。「戦勝国に吸収された敗戦国」の心情というか。‥‥デスラーと心情的に近しくなる表現が出てくるのも、「敗戦国同士」ゆえかも知れませんネ。

この頃までのアニメは、「敗戦のルサンチマン」が作品のルートになっている設定・ストーリーがよくあります。80年代に入って「うる星やつら」あたりでその影はほぼ消えたと思いますが、70年代(〜80年代初期)までの作品は、「父はまだ生きている」「母に会いたい」〜戦争孤児的な感情の流れを汲むものや、「国は負けたが、俺たちは負けてない」的な心情を根底に感じさせるものが、数多くありました。

もしかしたら、アンドロメダ人気は、作品の根底の感情からすれば、原作者としては苦みを感じるものかも知れませんネ。劇中では、最大の威容を誇って先陣をきるアンドロメダが、哀れにも全く無力で、ゴミ屑のように踏みつぶされる‥‥という描写で、「意図通り」の展開でしたが、子供たちの間ではデザインのかっこよさが優先され、アンドロメダの負けは「無かった事に」なっているという‥‥。

ヤマトシリーズのプラモを眺めて、単に「懐かしいプラモ」というよりは、デザインやカラーリングに色々な事を考えさせられる、オジサンになった私‥‥でした。

VMware Fusion 5

Windows環境が必要な時、近年はVMware Fusionという仮想マシン環境を使っています。私はリアルタイムレンダリングのゲームとか処理能力の必要なソフトウェアは使わないので、Fusionで充分事足りてしまいます。

このVMware Fusionは、アクトツーのWebでダウンロード版を買うよりも、アマゾンでパッケージ版を買った方が、まず15%くらい安いですし、USBメモリとディスクの両メディアが同梱されているのでお得です。

別途、OSのライセンスが必要ですが、Windowsに限らず、Ubuntuとか昔のMacOSXとかも動くようです。ちょっとだけRossetaが必要だけど、メインは10.8が良い‥‥なんて人は、10.5をFusionで実行する‥‥なんていうのもありですネ。

シームレスにWindowsが使えるのは、何だかんだいって、やっぱり楽です。別マシンを起動せずに済むので、電気代もかからないし。Fusionのバージョン5は、より一層、OSXのデスクトップとの統合が図られているので、WinodwsのソフトウェアをOSXのソフトウェアのように気軽に使えます。

仮想マシン‥‥と言えば、OS9の実行環境として、Sheep Shaverというのがあるのですが、いつか試してみようかと思っています。まあ、ノスタルジー以外のなにものでもないので、優先順位は低いですが‥‥。



コマ感覚

私は、長年アニメ業界に在籍して、いわゆる「コマ感覚」〜タイミングの感覚が24fpsで体の中に定着しています。

しかし、48,60,120などのハイフレームレートの場合、24コマ視点だと色々と扱いづらい面が出てきます。ゆえに、最近は1秒は1‥‥というような、ある種の浮遊小数点的な感覚でタイミングを捉えるように変えてきています。まあ、24コマの感覚は根強いので、どうしてもクセは出てしまいますが‥‥。

After Effectsのプロジェクト設定は、私は昔からタイムコード表記にしてあります。フレーム数表記は、使いません。シートを照合する際は、テキストレイヤーでシート枚数とコマ数を表示するガイドを作って合わせています。

フレーム数表記は、例えば、シート風に1スタートなら、6秒は1-144になります。私はこの「秒の間隔を直感的に感じない表記」がイヤなのです。「馴れればいいじゃん」とか言う人もいるかとは思いますが、フレームレートが変わる毎に「馴れ直す」んでしょうかネ?  30,60,120fpsの世界では、6秒は144コマじゃないですからネ。

アニメ制作ではなく、映像全般の制作における表現者たるには、フレームよりも秒感覚で体内ストップウォッチを持っていた方がツブしが効くと思うのです。もちろん、音楽の「拍」と同じく、24で秒をグリッドしても良いかとは思いますが、かたくなに24コマだけの世界に閉じこもるのは、少なくとも私は不安を感じます。‥‥というか、私は30fpsも普通に作業でこなさなければならないので、24の感覚のままではいられなかった‥‥のですけどネ。

これは大雑把に時間を捉える‥‥という事ではなくて、むしろ逆です。例えば24fpsの1コマという把握の仕方ではなく、0.04秒と実感する‥‥という事です。24コマに馴れきった体には、結構シンドいかも知れませんが、24コマだって仕事で馴れたんですから、出来ない事は無いです。思うに、0.02秒くらいの分解能は、持てるんじゃないですかネ。ごく普通に16分音符のハイハットが聴き分けられるんですから。

ちなみに、現在私が使っている時間情報テキストレイヤーの一例は、以下の通りです。
もっと高機能な切り貼りシート対応型のもありますし、もっと動作の軽いシンプルなものもありますが、スタンダードなものをご紹介しておきます。


var tsFrameCount=144;//6秒シートの場合

var fps=1/thisComp.frameDuration;
var fr=timeToFrames(time,fps,true);
var value1=getTsTime(fr,fps)["tsFrame"]+" : "+getTsTime(fr,fps)["tsTime"];
var value2=getTsTime(fr%tsFrameCount,fps)["tsFrame"]+" : "+getTsTime(fr%tsFrameCount,fps)["tsTime"];
var tsCount=String(Math.floor(fr/tsFrameCount)+1);

time.toFixed(2) + " / 秒¥r- - - - - - - - - - - - - -¥r" + value1 + " / 全体表記¥r- - - - - - - - - - - - - -¥r" + value2 + " / シート" + tsCount + "枚目";

function getTsTime(framecount,fps){
    return {tsTime:String(Math.floor(framecount/fps) + 100).slice(1) + "+" + String(Math.round(framecount%fps) + 101).slice(1), tsFrame:String(framecount + 10001).slice(1)};
}


timeToFrames()の困惑


After Effectsの尺など、時間やフレームをテキストレイヤーで表記する事はよくありますが、使い方によっては、意図しない結果になる事があります。

使う人はよく使う「timeToFrames()」は結構なくせ者で、ちゃんと3つの引数全てを入力しないと、何かのきっかけによって、返値が1、ズレる事があります。

例えば、12+12を表示しようとして、12+13になる事があります。これは、引数isDurationをtrueにすれば防げる事ですが、After Effects上での挙動が曖昧なので、「この引数は特に指定しなくても大丈夫だ」と処理しがちです。

同じスクリプト文でも、隣の人の環境ではちゃんと意図通りの結果、自分の環境だと1ズレる。じゃあ、自分の環境が何か違うのかと思っていると、隣の人の環境でも、やがて1ズレる。‥‥実は昨日体験した事例なのですが、挙動が曖昧で「再現性をつかめていない」ので根本の解決には至っておりません。対処法はありますが。

以下の例文。

timeToFrames(8/24,24,false)+" : "+timeToFrames(8/24,24,true);

人によっては「8 : 8」、違う人では「9 : 8」と表示されます。厄介なのは、「8 : 8」と表示されていた人の環境でも、何かのきっかけで「9 : 8」になる事です。なぜ最初から「9 : 8」と表示されないのでしょうネ?

要は「0,1,2,3,4」か「1,2,3,4」かの事だとは思うのですが、引数「isDuration」の挙動がおかしいんだよなあ‥‥。

作業用のテンプレートとして配布されるAfter Effectsプロジェクトで、上記のような障害が発生し、ボールドの尺表記が1フレーム分ズレる事があります。テンプレートを作った本人はその障害に気付いてないですし、受け取った人によっても挙動が違うので、「結果オーライ」とそうでない場合がマチマチなのです。

エラーの再現性を確立できなくても、対処法は簡単です。isDurationをtrueにして扱えば良いのです。isDurationをfalseにするのは、返値が曖昧なので、NGですかネ。‥‥まあ、ネジが外れた部分にガムテープで処置するような対処法ですが。

サンプルの尺表示のエクスプレッションです。

var offset=8;
var fps=1/thisComp.frameDuration;
var dur=timeToFrames(thisComp.duration,fps,true)-offset;
"("+String(Math.floor(dur/fps)) + "+" + String(100+Math.round(dur%fps)).slice(1)+")";

昨日はレンダリングしたQTをチェックしてビックリ。ボールド表記に、12+01とか、20+13とか、妙なコマ数が表記されてて、実際に尺をミスったかと思いました。困ったのは、環境によって障害が出ない事も多かった事です。草木も眠る深夜にAfter Effectsの珍妙な挙動に悩まされるとは‥‥。一律で全部1コマ多かったら、明快なんですけどネ。

尺、桁揃え

After Effectsで尺〜デュレーションを自動表記する際、私が昔から好んで使うのは、以下のようなエクスプレッションです。

var offset=8;
//ボールドなどの尺を引く場合は、適宜
var t=thisComp.duration-framesToTime(offset);
String(100+Math.floor(t)).slice(1)+ "+" + String(100+Math.round(t%1/thisComp.frameDuration)).slice(1);
//2桁で表記を統一する場合です


*ブログのデザイン上、改行されている箇所がありますが、行末はあくまで「 ; 」です。

私は、昔からの習慣で、小数点の端数で痛い目にあっているので、thisComp.durationをframeDurationで割る‥‥というような事はせずに、1秒で割った余りだけをframeDurationで割るようにしています。誤差を極力出さないルーチンにしておけば、どんな環境でも表記上の誤差は発生しない‥‥という事です。
*誤差の累積を、故意に発生させる場合は別ですヨ。

また、floorとroundは上手く使いわけてこそ‥‥です。floorばかり使っていると、思わぬ結果が出る事がありますネ。


また、数字の表記を2桁で揃えたい、4桁で揃えたい‥‥という時には、

var ketaNumber=Math.pow(10,桁数);

で、必要な桁数の位が繰り上がった数を用意しておき、

String(ketaNumber+任意の数).slice(1));

‥‥にすれば簡単にゼロで埋めた文字列を生成できます。つまり、0025が欲しい場合は、

String(10000+25).slice(1);

‥‥で済みます。わざわざIF文を使わずとも、1行でおさまります。

if num<10 {"0"+num} みたいなのは、2桁だとさほど苦ではないですが、例えば4桁の場合は、IF分岐がめんどくさい事になりますネ。for構文でゼロを追加するのも、なんだか大袈裟過ぎます。

私は今まで散々、桁数を揃えた番号と付き合ってきたのですが、何だかんだ言って、上記のプリミティブなやり方(10のべき算を一時的に足す)が一番シンプルで使い易く感じています。項目の数に応じて、動的に桁数を変える事だって、簡単にできますしネ。


*「var」も「;」も、エクスプレッションでは無くても見逃してくれるんですが、何かね、不安で。 ‥‥妙な省略癖がつくのもイヤだし。

スクリプト、凡ミスです

前に書いたスクリプトの例文で、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月あたりで何とか書き直そうかと思っています。あまり、奇麗にしようと欲張らずに。

目下の標準仕様

色々と映像技法を試すにつれ、2013年現在のコンシューマ向け機材で、作業運用上の限界かなと思うのは、大体4K/60fpsくらいかな‥‥と実感できるようになりました。これは2Dアニメーション作品の場合、ですが。

2Dアニメーション作品とは、現在業界標準のレタス仕上げ素材を撮影する方法とは全く異質なもので、アニメーターやコンポジット作業者が、あらゆるツールを駆使して絵を動かして映像を作るスタイルの作品です。‥‥ゆえに、現在のコンピュータ処理能力だと、4k/60fpsくらいが打ち止めでしょうか。レタス仕上げ方式のアニメ作品とは、段違いに処理能力が要求されます。

解る人には解る感じ‥‥で例えると、今のMac ProやCore i7 Macが、PowerMac8600かG3/233MHzくらいに感じる速度‥‥ですかネ。

しかし、4K/60fpsとなると、国立の技術研究所とか家電メーカーの開発部とかと連携しないと、足場がおぼつかないでしょうネ。テレビは存在しても、再生機器やメディアの問題とか、色々ありますし。

ただまあ、私としては、目下の標準仕様は、4K/60fpsとターゲットを定めて研究しています。これは最近出た4Kテレビ(2160P)に呼応しているのではなくて、単に次のステップへの中間地点です。次のステップ、これはすなわち、8K/120fpsなんですが、それはいくらなんでも、運用が追いつきません。

なぜ、4K/60fpsを目下の標準とするか‥‥ですが、「絵が動いて映像作品となる」というアニメーションの本質を再定義するには、このくらいのスペックが必要だと考えるからです。みんな、アニメとは、「塗りやすい略画が、1秒間8枚、もしくは1秒間12枚で動くもの」と思っているでしょうが、どうやら、その「概念」とは全く違うタイプのモノが作れる事が解ってきました。

願わくば、早々に、家電の映像再生機器関連が、もう1世代先へ技術更新されれば‥‥と思います。作っても、見せる場所がないのは悲しいですからネ。

ないものねだり

日々、黒鉛と紙と付き合ってて、ステッドラーペンテルの筆記具を愛用しているのですが、全ての用途に対して満足しているわけではありません。

特に、均一な線を描く場面などは、もっと良いものはないかと、考えてしまいます。

ペンのようなトレスブラックを軽い筆圧で描けて、細い線(0.1mmくらい)が筆圧で調整できて、芯は折れにくい‥‥という感じの筆記具。ないものねだりなのは、解ってはいます。今のところ、ステッドラーの0.3mmに2Bの芯というのが、一番ニーズに近いのですが、ちょっと気を緩めるとスキャン後の処理で悪影響の出る線になってしまうので、都合、筆圧が高くなりがちで、正直疲れます。そして、2Bは基本的に折れやすいのが泣き所です。

黒鉛特有の書き味が必要な場合は、全然気にならないのですが、黒白のハッキリした線が必要な場合は、悲観的になるくらい、鉛筆・シャーペンって「適してない」のかも知れない‥‥と考える事があります。

前々から、白黒クッキリ線の場合は、全面的にCOPICのマルチライナーに切り替えても良いかと考えてはいるのですが、無論、消しゴムは使えないですから、厳密な用途の場合(版権イラストなど)は下書き段階でほぼ完璧に仕上げておく必要があります。以前からマルチライナーは使っていますが、鉛筆画をマルチライナーに切り替えるとなると、「運用レベル」での変更が必要となります。

デジタルデータ視点ならば、ソフトウェアのシェイプ(ベクターとかパスとか呼び方は色々)で全部描いてしまうか。やっぱり、ステッドラーの0.3mmを基軸として、シャーペンの芯を総ざらいでテストしてみるか。

悩みどころです。

鉛筆に馴れ親しんで生きてきた慣習が、躊躇を誘います。

ちなみに、用紙も重要な要素です。どんなに黒鉛が真っ黒く紙に定着しても、紙の白色度が低いと、スキャン時にコントラストが稼げません。黄ばんだ紙はNGです。また、パルプの目が粗いと、線がブチブチになるので、平滑度も重要です。私は、坪量の低くて白色度の高い、薄いケント紙を常用しています。

紙のほうは、大体「これが落としどころかな」と思える紙は見つかっています。紙についてはまたいずれ‥‥。


一生のうちに完成できる絵を、できるだけ多くしたい‥‥という欲望ゆえに、どうしても効率的なツールを追い求めてしまいます。線で語る‥‥のは、鉛筆やシャーペンで充分に達成できます。しかし、「クッキリトレス線のデータ入力」というニーズでは、逆に黒鉛の表情が裏目にでます。

ドンシャリカーブのカーボン筆記具がほちい。


calendar

S M T W T F S
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>

selected entries

categories

archives

links

profile

search this site.

others

mobile

qrcode

powered

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