perspective.dll

２つ前のモーフィングで少しお話しをしましたが、そもそもperspective.dllの使い方がわからん！と知り合いに突っ込まれましたので、最低限の書式についてです。
ちなみにパースペクティブって何？って人はググって下さい。
ぶっちゃけこれ単体ではほとんど使い道ありません。むしろこう言う使い方ありそうって言うのがありましたらお教え下さい。試してみたいです。
何かと組み合わせて始めて劇的な効果を現すタイプのものなので、無くてもそんなに困る事は無いでしょう。

では準備です。

１．吉里吉里以外では”perspective.dll”が必要です。
　　吉里吉里関連サイトのどっかにあります。あまり不用意にURLを貼れませんので探してください。たぶんすぐ見つかります。

２．startup.tjsの上の方に　Plugins.link("perspective.dll");　と書く。
　　サブフォルダに置いた場合、プロジェクトフォルダの下からのパスを通す事。

これで準備完了です。

このdllがいったいどう言うdllかと言うと、特定のレイヤーの画像を特定のレイヤーにパースペクティブ”的”変形をさせて表示すると言う物です。
パースペクティブを日本語に訳すのはかなり意味合いにブレがあるので難しいのですがまぁそう言う事です。

でこのdllの使い方をいくつかの解説サイトで覗くと

@macro name=perspectivecopy
@eval exp="kag.getLayerFromElm(mp,'dest').perspectiveCopy(kag.getLayerFromElm(mp,'src'),+mp.left,+mp.top,+mp.width,+mp.height,+mp.x1,+mp.y1,+mp.x2,+mp.y2,+mp.x3,+mp.y3,+mp.x4,+mp.y4)"
@endmacro

……みたいに書かれてます。
今回の参照はOUTFOCUSさんのperspective.dllに関する記述からです。いつも大変お世話になっております。

これをTJSで使用するように解読すると……

kag.getLayerFromElm(%['layer'=>'layer_dest', 'page'=>'page_dest','prefix'=>'dest']).perspectiveCopy(kag.getLayerFromElm(%['layer'=>'layer_src', 'page'=>'page_src','prefix'=>'src']),left,top,width,height,x1,y1,x2,y2,x3,y3,x4,y4)

layer_dest = コピー先レイヤーno
page_dest = コピー先ページ　fore/back
layer_src = コピー元レイヤーno
page_src = コピー元ページ　fore/back
left = ソースの基点座標Ｘ(通常0）
top = ソースの基点座標Ｙ(通常0)
width = ソースの基点座標から数えた幅
height = ソースの基点座標から数えた高さ
x1 = コピー先の基点座標Ｘ
y1 = コピー先の基点座標Ｙ
x2 = コピー先の右上座標Ｘ
y2 = コピー先の右上座標Ｙ
x3 = コピー先の左下座標Ｘ
y3 = コピー先の左下座標Ｙ
x4 = コピー先の右下座標Ｘ
y4 = コピー先の右下座標Ｙ

こんな感じです。あとはそれぞれの数値を入れ込むと遠近法のように画像が変形します。

テレビの砂嵐動画

最初にお詫びです。　上のニコ動の動画はどうレートを下げてもビットレートオーバーになってしまいましたので、極端に画質を落としてようやくアップ成功したもので非常に見づらいです。
こう言う単純な不連続なノイズ画面が一番エンコに負担が掛かるのは理解してましたが、案の定でした。Orz

アナログＴＶの砂嵐です。
無いと微妙に困ったりするのでちょっと作ってみたのですが、よく考えると地デジになるとこれもなくなっちゃうのでしょうか。
子供の頃、この砂嵐から必死に宇宙人のメッセージを読み取ろうとしたのは、きっと私だけでは無いはず。
ちなみにこれはVHF域の砂嵐です。
個人的にはUHF域の砂嵐が品があるように思うのですが……物語は関東圏で進行する事が多いのでVHFじゃないとダメと言う理由からVHF域の砂嵐です。
VHF域は帯域が狭い上に、最近のテレビは高性能で、”意味のある波形に修正しようとする”機能があるのでこんな感じの黒っぽい何かの模様のような感じになってしまいます。
そのあたりの事は、昔ＮＨＫ教育で数学の秋山先生がその基礎理論をわかりやすく解説してくれてたのですが、ちょっと忘れてしまいました。

この砂嵐、ＡＥで作ったものです。
こう言うノイズや水の流れのようなカオス理論に基づいた連続体を嘘臭く無く作るのは、ＡＥに限らず非常に難しいですね。（テレビのノイズもある意味複雑な因子が色々絡み合ってると見なせます）
なのでそれっぽく作る一番良い方法は、ＰＣ（ソフト）に任せて出来るだけ人間は触らないと言う事が究極的な感じじゃないかと思います。

吉里吉里の動画用に最適化した物はコチラです。
10秒ループ素材ですが、画像それぞれには連続性が無いので適当にぶった切って短くして使われても特に問題無いと思います。
ほとんど需要無いと思いますが、良かったら使ってやってください。

モーフィング

某所で話題を振られましたので、お返事です。
モーフィングは実は以前に考えてかなりネットで調べたのですが、良くわかりませんでした。
実現したいとは考えてますが、具体的にはメッシュワープかペジェワープあたりのわかりやすい解説サイトでも見つけないと難しいかなと思ってます。
ご存じの方がいらっしゃいましたら、そのあたりの解説サイトをお教え下さい。　お願いします。
サイドインマクロに組み込むのであれば、単純にperspectivecopy.dllを組み込めば良いかと思ってはいるのですが静止画ならともかく動的な物には流石に重たいようです。　これに関しては具体的な検証が済んだらご報告します。
吉里吉里では無いのですが、パースペクティブを組み込んだフェードを取り入れてらっしゃる会社もあり、すごいなと眺めること頻り。　事実、見栄えが良いんですよね……
ほんのちょっとした部分なのですけど、そこを適当にこれで良しとするかある程度こだわるかの差がクオリティの差だよなぁっと最近つとに感じます。

一枚画へのモーフィングに関してはたぶんパーツをＡＥ出力のパラパラアニメで持って、それを総合的に管理するオブジェクトを組む方がうちのレベル的に現実的かなと考えてます。
Ｍ２さんのモーフィングはそれを演算で行ってらっしゃるようで高い技術力は流石と言うところですね。
ところで昔からあるツールですが、ynwさんのXX-CAKE!も上手く使えばかなり良い感じなので上手く使えないかと思案中です。
ぷるんぷるん動かす事に関しては、ＡＥで作るより使いやすくまた微調整が容易で非常に便利です。　使いどころが激しく限定されそうですが。

　　／⌒ヽ
　く/･〝　⌒ヽ
　 |　3　(∪￣]
　く､･〟 (∩￣]

ちょっとかわいいAAだったのでコピってみました。

動画による奥行きの表現

以前のエントリーでスクリプトによる擬似的な奥行きを持たせる動画をアップしましたので、今回はそれと対になる動画による奥行き表現のテストです。
ここまでいくと演出と言うよりは手品とか大道芸に近い物で、「そこまでこだわってアホちゃうか」と言われれば素直にアホですと答えますOrz

たぶん勘の良い方はすでにピンと来られてると思いますが、立ちキャラの前後を★のパーティクルの動画で挟んだだけです。
なので、吉里吉里と言うよりはAEの領分の作業が大部分を占めます。　と言うより、ハッキリ言ってしまえばparticularのみで作成してます。
★のパーティクルは本当はポリゴンにしたくて、過去に使っていたShadeと3ds maxの体験版をDLして使ってみたのですが……かんっぺきに忘却の彼方でしたOrz
近いうちにヒマを見て覚え直します。
ここでは公開してないのですが、前々から羽根が降ってくるループ素材とかせっせと作ってまして、それが落下時の質量的な部分や羽根自体の柔らかさとか今現在2Dからの表現に限界を感じてまして、やはりポリゴンで作るしか無いかと考えているところです。
まぁこんなアホな事に力を入れてるシナリオライターとか日本中探してもうちだけだと思いますので、ご覧頂けてる方は気長におつきあいください。

星空とりあえず完成

《星空０４》
とりあえずの完成形です。
一見バージョン０３と大して変わらないように見えますが、根本から全て新しく作り直しています。
星のレイヤーは７枚重ね、さらにそれをレイヤーモードを変えて二重に重ねています。（実際にはループ素材にするために１つの星レイヤーを３枚重ねしてますので星レイヤーだけで４２枚重なってます）
また大気の揺らぎを入れたり、チリの表現を入れたり、球面収差を強めに加えたりしてみました。
その上で、そのままだと見栄えが悪いので少しアニメ的な星の動きを入れてあります。
結果、バージョン０３同様フル動画になってしまいましたOrz
複雑にレイヤーモードを重ねてますので、星の部分と背景部分に分解して別々に再生するとこの動画とは違う印象の動画になってしまいます。

今回はAEの機能のみでの作成で、PS等の外部アプリは使用していません。
Particularも今回は使用していません。
理由はチリの表現のように明滅させるのは、明滅の為にキーを打つか動画としてパーティクルを設定するしか無いので面倒だったのと、高性能なだけにそれなりに重いプラグインなので大量に使うには向かないからです。
試してませんが、４２枚も重ねたらたぶんうちのマシンでもフリーズするかも知れません。それこそ専門でAEに特化したマシンじゃないときつい処理です。
AEは、昔ほどではありませんがちょっと重い処理や複雑な処理をすると今でも結構普通に落ちます。
そりゃもう、これオープンβじゃないよね？と言いたくなる程落ちます。
あまりにも落ちるので、不正落ちの直前にデータを「一度だけ保存するチャンス」を与えると言うトンデモ回避策が組み込まれた程です。
なので、出来るだけ軽く作る事も重要になってきます。
それでもおそらく一昔前なら、これはレンダに半日掛かる程重たい処理で、それをわずか数分で出来てしまうマシンの性能の向上には目を見張ります。

《追記　110508》
ちょっと言葉足らずと勘違いがあったので追記。
明滅のキーをOver Lifeに打つと、出力が最初の0フレーム1回限りのために同じレイヤー上での出力された粒子の明滅のパターンが一緒になってしまいます。
これを回避するためには、粒子の明滅を動画で持ち、Particle TypeをSpriteでやれば回避出来るのですが、粒子を動画で持つとかなり重くなります。　粒子の動画を作るのも面倒でした。

勘違いは、1つのフッテージに設定したエフェクトを複数のコンポで使っても、フッテージの出力は一度だけ行われそれを使い回すようです。
当然ですよね。一々呼ばれる度に演算してたら、マシンパワーいくらあっても足りないOrz