« 2011年9月 | トップページ | 2011年11月 »

2011年10月

2011年10月31日 (月)

不条理ノーマル。

よくわかりません。
勢いで。




あれえ。前にもこんなスクリプトを書いたような、書かなかったような。




オブジェクトの、ポイント、エッジ、ポリゴン、つまりコンポーネントですが、そのコンポーネントの法線方向を向いたヌルが降臨するスクリプト。





//    クラスタ作る
var oCls = CreateCluster( Selection(0) );


//    テンポラリのヌル
var oNull = ActiveSceneRoot.AddNull( "tmpNull" );


//    コンストして向き合わせ
var oCns = oNull.Kinematics.AddConstraint( "ObjectToCluster", oCls );
oCns.tangent.value = true;
oCns.upvct_active.value = true;


//    コンスト削除したりクラスタ削除するとなぜかヌルの向き変わっちゃうので、
//    新たなヌルを出し、さっきのヌルに Global SRT 合わせ

var oNullNull = ActiveSceneRoot.AddNull( "FuckinNull" );
oNullNull.Kinematics.Global.Transform = oNull.Kinematics.Global.Transform;


//    テンポラリヌル抹殺

DeleteObj( oNull );


// クラスタ刺殺 (追記)
DeleteObj( oCls );


//    最終ヌル選択

ActivateObjectSelTool(null);
SelectObj( oNullNull );






コンポーネントを選択して実行。

エラーチェックも何もしてません。変な物選んでいたら動きませんよ。






酔った勢いだけで書いています。

法線方向取得とかわかんねえし。
っていうか前に fmt さんに教えてもらったのに忘れてるし。

だからクラスタ作って、コンストするという、自暴自棄。
法線方向の取得はわかんねえが、
こういうオペレーションをやると法線方向を向くヌルが来るってことは知ってる。
じゃあその手順だけスクリプトで書くか。
という発想です。
退廃的。


最後に不要なものを消そうと思ったら、消した瞬間にヌルの向きも戻りやがって。
なのでもう1発余計にヌルをかましたり。
刹那的。



スクリプティングの参考にはしないで下さい。
っていうかツールデザインの参考にしてはいけません。



まあ、酔っていても、自暴自棄でも、退廃的でも、刹那的でも、悪い例みたいなスクリプトでも、無いよりはずっと仕事がはかどる場合もあるぜ、という例にはなるでしょう。 っていうかそれだけでやってきましたよ俺は。ええそうですとも。








さあもう1本吞むかな。
麦とホップ美味いよ。
第3とは思えない。
1本100円くらいで買える。
俺の身分に相応な酒です (゚∀゚)



.

| | コメント (0) | トラックバック (0)

2011年10月30日 (日)

不条理RefPlane。

唐突にスクリプトが振ってくる日曜日の夜、皆様いかがお過ごしでしょうか。





リファレンスプレーンと SRT が一致したヌルが降臨するスクリプト。
JScript です。



var oRefPlanes = Dictionary.GetObject( "RefPlanes" );
var oFuckinNull = ActiveSceneRoot.AddNull( "FuckinPlaneNull" );

oFuckinNull.posx.value = oRefPlanes.NestedObjects( "Transform" ).posx.value;
oFuckinNull.posy.value = oRefPlanes.NestedObjects( "Transform" ).posy.value;
oFuckinNull.posz.value = oRefPlanes.NestedObjects( "Transform" ).posz.value;
oFuckinNull.rotx.value = oRefPlanes.NestedObjects( "Transform" ).rotx.value;
oFuckinNull.roty.value = oRefPlanes.NestedObjects( "Transform" ).roty.value;
oFuckinNull.rotz.value = oRefPlanes.NestedObjects( "Transform" ).rotz.value;
oFuckinNull.sclx.value = oRefPlanes.NestedObjects( "Transform" ).sclx.value;
oFuckinNull.scly.value = oRefPlanes.NestedObjects( "Transform" ).scly.value;
oFuckinNull.sclz.value = oRefPlanes.NestedObjects( "Transform" ).sclz.value;




<過程>

RefPlane オブジェクト
というものが存在するであろうことは、オブジェクトをピックして RefPlane を作った時にログされるコマンドを最初の手がかりに SDK ガイドを引けば、なんとなくわかって来ます。とっかかりはある。ここまで2分くらい。


RefPlane オブジェクトがシーンの中のどこにネストされているかは、カンでしかないんですがね、でもだいたいこういうのは、Explorer を Application モードにすりゃ出てくるんです。


シーンに依存せず、どんなシーンでもシステムの一部として必ず存在するオブジェクト、たとえば PlayControl オブジェクトとか ViewportCapture オブジェクトなんかもそうだけど、こういうのは Explorer の Application モードの下のどっかにありますね。 ってことで、こいつがシーングラフのどこに存在するかを確認するまでに、更に1分くらい。



そして、いきなりその名前で Dictionary.GetObject で取得できちまう。 RefPlane とか PlayControl とかって、唯一無二の存在であり、かつどんなシーンにも必ず存在するオブジェクトですから。 キムさんって言ったらフルネームで所属から言わないと見つからないけど、同じキムさんでも将軍様って言ったら所属も階級も言わずただ将軍様と言うだけで判別が付くのと同じです。

このオブジェクトはシーンごとによって変化したりせず、普遍の存在だぜということ自体は XSI をある程度以上使っている人ならすぐわかりますよね。 そしてそういうものは Dictionary.GetObject でいきなり名前言うだけでエラー出ずに安全に取得できるということは、スクリプトをある程度書いている人であればわかります。 

ってことで、Dictionary.GetObject で RefPlane オブジェクトを取得し、Logmessage などで表示してみてちゃんと取得できていることを確認するまで更に1分。



oRefPlane の下に Transform プロパティというものがあり、その中に Reference Plane の SRT が格納されているということは、Explorer からクリックしてみて PPG を見ればわかります。 30秒。







・・・・・こっからが問題で。

Logmessage( oRefPlane.Transform.posx.value ) ;


などと書いてもダメなのです。エラー出ちゃうんです。 oRefPlane まで取得できてるから、あとは芋づる方式で取得できるはずなのに、ダメ。 Transform オブジェクトが取得できてないんですね。 このパターン、XSI のスクリプト書いてるとよく出くわします。理由はわかりません。 XSI 様の思し召しです。


Logmessage( oRefPlanes.Properties( "Transform" ).Parameters( "posx" ).value ) ;


でもダメでした。なんでやねん。Transform プロパティそこにあるやないの。アイコンはグラデだから Property のはずで、Properties ( [prpperty name] ) で取得できるはずなのに、できんのか。なんでやねん。




ここで5分くらい使います。




苦し紛れに、NestedObjects を試します。


Logmessage( oRefPlanes.NestedObjects( "Transform" ).posx.value ) ;


あっさり通りました。

Properties が通らなくて NestedObjects が通る理由が、俺にはわかりません。
ともかく、NestedObjects を使えば Transform オブジェクトを取得できて、かつその先の posx などのパラメータにまで届くことがわかりました。


なので書き直したのが、冒頭のスクリプトです。1分とか。



合計9分半だか10分くらいで書いたことになります。
NestedObjects みたいなファックな問題がなければもっと早い。







そしてここまで書いてから、


 「 RefPlane.Transform までを最初からゲットできないの???」


という疑問が浮かびます。

ってことで、


var oTransform = Dictionary.GetObject( "RefPlanes.Transform" );
Logmessage( oTransform.posx.value );



こんな風に書いてみたら、通る!  なんだよそりゃ。 Dictionary.GetObject の呪文を唱えるとき、 RefPlane でやめずに Transform まで含めれば良かったようです。


ってことで、


var oTransform = Dictionary.GetObject( "RefPlanes.Transform" );
var oFuckinNull = ActiveSceneRoot.AddNull( "FuckinPlaneNull" );

oFuckinNull.posx.value = oTransform.posx.value;
oFuckinNull.posy.value = oTransform.posy.value;
oFuckinNull.posz.value = oTransform.posz.value;
oFuckinNull.rotx.value = oTransform.rotx.value;
oFuckinNull.roty.value = oTransform.roty.value;
oFuckinNull.rotz.value = oTransform.rotz.value;
oFuckinNull.sclx.value = oTransform.sclx.value;
oFuckinNull.scly.value = oTransform.scly.value;
oFuckinNull.sclz.value = oTransform.sclz.value;



このように書き直しました。これで NestedObjects とかいうファッキンなことを書かなくても済みます。



でもこの挙動、納得行きません。
RefPlane まで取得できなたら、それ以下は芋づるで取得できるのが普通なのに、できません。 Transform プロパティをゲットしようとしているのに、その親オブジェクトから Properties を使ってもゲットできないのも、おかしいです。 NestedObjects でだけゲットできるって、おかしいです。 どうにかしなさい嘔吐デスクさん。




こういう不条理と戦うのが、XSI スクリプティングです。

全ては太陽のせいだそうです。




このブログ記事を書くのに20分だか30分。
これから3日くらいかけて、このスクリプトの名前を考えます。





.

| | コメント (2) | トラックバック (0)

2011年10月29日 (土)

Making of 花火。 c04。 Comp。

c04 の続きです。








### コンポジット編


ブレイクダウン風ビデオはこちら。

・・・やっと高画質でアップロードできた。パーティキュラー花火大会のフォーマットは 800 x 600 だったんですが、1280 x 720 の中にブチ込んでアップロードしたら、高画質再生ができるようになったように見えます。 これまでのメイキング記事のムービーも、アップロードし直そうかな。




で、実はこのショットもコンプ的な特筆すべきことはほとんどありませんでした。
でもまあ、書きたいので書きます。


AE の作業画面。

A0_screen
クリックするとでかい画像。


普通にレイヤを重ね、それぞれに光ものエフェクトを足してったというだけっぽい。






・花火

Mental Ray でレンダした花火素材は例によって Starglow します。

A1_hanabisg

上がレンダしたまんまの状態、下が Starglow 済みです。



問題はですね、この素材は花火ひとつひとつがレイヤに分かれてないということです。 ってことは、Starglow はまるごとかけるしかないということです。花火の色に合わせて Starglow の色も調整するとか、できないってことです。

これだけの数の花火をレイヤ分けするのはすんげえ大変です。 しかしそれよりも、ICETree を根本から組み直す必要がありますね。 レイヤ分けが大変なので1素材にしたと言うよりも、花火を1輪ごとに分けた ICETree を組むのが大変なので1素材になってしまったというのが正直なところです。 前回の ICE編のところを見れば、花火を1輪ごとに分けることなどさらさら考えていない ICETree を組んでいるのがわかると思います。

ってことで、赤系の光芒になるような Starglow を丸ごとかましました。 暖色系の花火はまあいいのですが、青とか寒色系の花火にも赤い Starglow がかかってしまうため、若干ミスマッチというか、紫ががってしまってあまり綺麗じゃありません。 でもまあ、寒色系の Starglow を暖色系の花火にかますよりもマシに見えたので、こうしました。


思うに、Starglow の色のオプションで、「元素材の色を使う」というモードがあればいいんですよね。 明示的に1色にしてしまうのではなく、素材から色を拾ってそれを生成する光芒の色に反映させるということができて欲しいです。拾った部分の色が赤っぽかったら赤い光芒、青っぽかったら青い光芒、あるいは閾値を付けて任意の色にリマッピングとか。  Trapcode 様よろしくお願いします。







・水面

Mental Ray でレンダしたまんまの水面素材はこれです。

B1

前回書いたように、花火の映り込みも一緒にレンダされていますが、映り込みが本来より強調されたものになっています。 花火以外で映り込んでいるものは、指定の背景画だけです。



それに Starglow をかますと、

B2

こうです。青系 Starglow ですね。 そうそう、こんな感じにしたかったんです。 映り込んだ花火だけじゃなくて、水面のエッジというか、カメラから見て水平に近い部分がよく Starglow に反応してくれています。 前回書いた Incidence を使ったエッジの強調は、これを狙ったものです。





一方、これが花火の映り込みオンリーの素材です。

B3

詳しくは前回書きました。空もなく、水面自体の陰影もなく、純粋にリフレクションによる花火のみが見えている素材です。


こいつに Starglow しました。

B4

赤系にしたんですねえ。なんか、いじくってるうちにこうなっちゃったんです。



そして、さっきの Starglow 済み水面素材に、この赤 Starglow を加算して、

B5

このようになりました。 

さらに、手でマスクを切ってカメラに近い部分だけ若干のレンズボケを入れました。 カメラはティルトアップするアニメーションがあるので、ボケ部分もなんとなく手動でアニメーションして追いかけました。




後半になると、カメラが水平に近くなって来ます。つまり Incidence で取り出すエッジが見えやすくなるわけで、かつ画面上で密集してくるわけで、水面がいっそう Starglow でキラキラし始めます。

C1

なんかちと下品かもしれませんが、これ見よがしに水面のキラキラ感を強調したかったんですよね。



今思ったんですが、完全無風でベタ凪ぎの水面に映る花火、ってのも美しいかもしれませんね。まあ、要するに鏡写し状態ということですけど。水面がほとんど動かない状態で映り込んだ、上下にシンメトリな状態。





背景と全然馴染んでねえのは、まあいいや。
水に映った花火が見れればそれで良かったんです俺は。





ええと、あと何カットあるんだっけ。
まだ終わらないの。
ううむ。


たぶん続く。




.

| | コメント (8) | トラックバック (0)

2011年10月28日 (金)

Making of 花火。 c04。 ICE / RenderTree。

c04 です。





水面に映り込む花火、というイメージは初期からありましたね。 そういう絵は美しいであろうと思えたし、しかも現実の花火大会は河川敷など水際で行われることも多いので、花火+水というのは俺にとってはごく自然な組み合わせでした。


問題は、水面を出してしまうとパーティキュラー花火大会のレギュレーションに違反しないかどうか、ということですね。やはり意識はしました。背景は指定の画像以外使ってはいけないという規則があったので。



しかし俺の場合は、背景というよりは前景として使いたいこと、水面自体に独自の質感を持たせずに素直に指定の背景を100%映り込ませるつもりであること、レギュレーションには指定の背景と花火以外のものを出してはいけないとは書いてないこと、そんなに厳密なルールのつもりで書いているわけじゃなく同じ世界観の中での花火という方向で統一したいだけなのであろうと想像したこと、などを理由に、結局使うことにしました。




いやね、ほら、俺がこのコンテスト用に何か作るなら、当然 XSI を使った 3DCG になるわけですよ。3DCG でやるからには、3D らしいカメラをやりたくなるじゃないですか。 奥行きが欲しかったり、アオったりフカンにしたり、Z を感じる絵にしたくなるわけですよ。 しかしそうなると、地面を入れられないのが非常に苦しくなるんですよね。 指定の背景画は空だけで、地面が描かれてなかったのです。

だとすると基本はアオリ傾向のカメラアングルしかできないということになります。それはあまりにもキツい。地面が欲しい。でもルール上背景に描き足すわけにもいかない。 この辺の事情が、水面を後押ししました。 まあ、これを理由に失格になってもいいやと思えたので、気にしないことにしましたよ。 当初は ICE の研究をするという目的があったし、誰に頼まれたわけでもなく勝手にやり始めたのに、作りたいものを作れないんじゃ楽しくないな、と思ったのでね。もし受理してもらえなくても、ひとり裏花火大会として Youtube かどっかにアップできるだろうしね。


大会当日のUST中継を録画したものを後から見たら、やはり水面について疑問は出されていましたね。 でも結局受け入れてもらえたようで、ありがたかったです。 っていうか、背景に月を足した作品とかありましたよね? あれについては何も言ってなかったなあ。 背景の一部を切り取ってそこから実写の人間がのぞいているなんて作品もありました。 それについても特に何も指摘はなく、むしろ賞賛されていたように見えます。  まあ、もともとバーチャルな花火大会なんだから、自由な発想で色んな花火が出てくるのが楽しいはずですから、スタッフの皆さんもあまり厳格になるつもりはなかったんだろうなあと思います。


あれれれ。前置きが長くなっちまった。
すんません。



XSI 上での作業画面はこれです。

00_xsiscreen
クリックするとでかい画像。



例によってシンプルですね。 カメラ、空背景用のグリッド、エミッタ、PointCloud、水面グリッド、水面グリッド変形用 Lattice、ライトです。 パーティクル自体は相変わらずライティングに影響されないマテリアルを持たせてあるけれど、今回は水面があり、こちらはライトに影響されるシェーディングが必要なので、ライト1灯だけ焚きました。


水面グリッドは、やけにメッシュの解像度が高い。 これは水面の波デフォーメーションを、ディスプレイスメントマップなどではなく、ICE デフォーメーションでやろうとしたからです。 ま、カメラから遠い部分はここまで細かい必要はなかったかもしれません。逆にカメラに近い部分はもっと細かくても良かったかも。





### ICE 編




このヘンな台形みたいなのがエミッタオブジェクトなんですがね。

03_emitter

カメラの視野よりも外に花火を上げてもしようがないので、見えるところだけに発生するよう、カメラの FOV に合わせて末広がりな形のエミッタにしています。無駄に重くしたくないですからね。これは花火だけじゃなく例えばモブやる時なんかも常套手段ですよね。


ただし視野ギリギリいっぱいまでのエミッタだと不十分で、少しは余分に広くしておかないとダメですね。 画面の上下左右など端っこ部分の情報量って実はすごく大事で、ここがどう見えるかによって、画面外にまだまだその要素が続いているのか、それとも画面内にしか無いのか、印象が決まってしまいます。 言い換えれば、シーン全体のスケール感や量感を担っているのは、画面の端っこだと言っても過言ではない。 黒澤明が言ったんだっけ、「1000人のモブシーンを作りたいなら1000人のエキストラを呼んでもダメだ。10000人呼んで来い」みたいな意味の格言をどこかで読んだことがありますが、名言だと思います。 だから俺も、いつも画面の端っこを気にするようにしています。


このカットの場合はまあ、そんな大げさなもんじゃないんですけどね。おそらくは無駄な重さを避けようとしただけで、シーン全体の量感とかそこまでは気にしてなかったと思います。 悪い癖ですね、そんな大したことやってないくせに大したことのようにエラソーに語り出すのは。すいませんすいません。


ICETree 全体はこんな感じです。

04_icetree_all
クリックするとでかい画像。


一番上の部分が、最初のエミッションと、そのエミッションによって発射される State 0 のパーティクルです。 こいつは花火そのものを発射するのではなく、花火を起爆するトリガとしてしか使っていません。 花火そのものは次の State1 です。State0 はレンダされることは無く、State1 を発射させるためだけに使われています。

State1 は花火本体で、State2 は花火が空間に残していく軌跡=トレイルです。


ではひとつずつ見て行きます。






●エミッションと、すぐ死ぬトリガパーティクル( State 0 )

ICETree はこれです。

10_icetree_state0
クリックするとでかい画像。




・Surface から発射

Emit From Geometry コンパウンド使ってますね。エミッタは上記の台形みたいなやつ。 で、その PPG を見てみると、

03_emissionppg

Emission TypeSurface になっています。Volume ではない。 俺、Volume があまり好きでなくて、というか、いつもいい感じの分布にさせられなくて、結局 Surface にしてしまうことが多いですね。 今回の場合も、花火1個の直径がエミッタの高さと同じくらいなので、そしてアオって見ているので、Surface で発生させるくらいが画面上ちょうど良い分布位置になったんでしょうね。↓

03_distibution



・一瞬で死に、次の State に託す

このエミッションで発射されるパーティクルは、ただのトリガです。0.01秒で死ぬようにしてあります。その死亡をトリガにして、次の State のパーティクル=実際の花火を発射させています。


なぜこうしたかと言いますとですね、Emit From Geometry で普通に Surface から発射させると、エミッタオブジェクトのポリゴン表面のどこかある1点から、1個ずつのパーティクルが発射されますよね。 でも丸い放射状の花火を発生させたいので、ある1点から1個パーティクルが出たんじゃダメなわけですよ。 ある1点の場所はエミッタ表面ならどこでもいいんだけど、その1点から発射されると決まったら、同地点から球状全方位にたくさんのパーティクルが発射されなければ、花火にならないわけです。

この 「エミッタ表面に存在する、ランダムで決まる様々なパーティクル発射地点において、それぞれの発射地点から複数のパーティクルを発射させる」 というやり方がわからなかったんですよ。 誰か教えて下さい。 たぶん、自分でエミッションシステムを作るなり、エミッションコンパウンドに潜って行ってどこか書き換えるなりしないとダメですよね?

なので今回は安直に、ダミーのパーティクルとでも言うか、トリガのためだけに存在する State を作って、そいつはすぐ死ぬことにし、死んだらその地点からたくさんのパーティクルを発射させることにしたのです。 この方式なら、Spawn on Trigger で簡単にできますからね。

ということで、上の ICETree 画像の左側にあるように、Test Particle Reached Age Limit を使ってパーティクルが死んだかどうか判断し(寿命は 0.01なのですぐ死ぬ)、Spawn on Trigger でその死亡地点から 500個のパーティクルを 180度の広がり(=球状全方位)で発射しているわけです。この500個のパーティクルが State 1 であり、次に説明する、実際の花火の本体です。


このトリガパーティクルがエミッタ表面上のどこにどのタイミングで現れるかは、ICEまかせです。タイミングの方は、後に説明する Rate のアニメーションで若干の制御はできているものの、基本的には ICE まかせになっています。 なので、本当は音楽に合わせるなど気持ちのいいタイミングで花火が出てきて欲しいし、レイアウト的にも気持ちのいい場所にだけ出てきて欲しいのですが、今回はそこまで制御することはあきらめています。 エミッタオブジェクトが1つのままこれをやろうとすると、やはり独自のエミッションシステムを構築しないとダメだと思います。


・色

花火の色は、ここで決まります。 Randomize Color by Gradient です。 0.01秒で死ぬパーティクルなのでこの State0 の色はどうでもいいのですが、次の State1 のためにここで色を決めてしまっています。 どういうことかと言いますと・・・・。


普通にパーティクルの色をランダマイズなどしてしまうと、ツブ1つ1つの色が変わってしまうので、この花火にはふさわしくありません。 1輪ごとに1色であって欲しいわけです。 なので、最初のトリガパーティクルの時点で色を決めるのです。トリガパーティクルは1粒なので、上記の Randomize Color by Gradient でその1粒の色が決まり、そしてそのパーティクルが 0.01秒後には死んで500個の State1 パーティクルが発射されるわけですが、この State1 では色を何もいじっていません。そのため、死んだ1粒の色が500個のパーティクルに引き継がれ、結果、1輪につき1色になります。


本当はこの1輪=500個で1色ではなく、500個1つ1つ色を変えたりとかやってみたかったんですが、パパっとは上手く行かずに断念してしまいました。 この1色を基準にしてあるランダム範囲で色相をずらすとかは可能なんだけど、これだとランダム範囲の中で採り得る値がグラデーション過ぎて、ガツンと全く違う色を唐突に発生させるとかが上手く出来なかったんですよね。 出てくる値を round するとかして、中間の値が出ないようにすればいいのかなあ・・・?

あと、今回はシンプルに全球状に広がる花火ですが、1回の Spawn on Trigger で複雑な花火(例えばよくある朝顔の形をした花火のような、中心部分と周辺部分で全く挙動が異なるもの)を出現させる方法も、研究せねばなりませんなあ。



Randomize Color by Gradientでは、グラデーションの中間マーカは隣り合う色のどっちかにグイっと寄せて、半端な色は発生しないようなグラデーションになっています。上の ICETree 画像を見ると、6色発生させているようですね。 

このグラデーションのインターフェースを使って、スカラ値を発生させられるかしら? 可能なら、上で書いた、中間の値が出てこない、ステップ飛び飛びのランダム値ができそうですよね。





・Rate にアニメーション

エミッションの PPG を見ると Rate にアニメーションが入っていますが、こんなFカーブが入ってました。↓

03_emissionfcurve

ランダムな上下をしつつ、後半に行くほど Rate が上がっていってますね。 おそらくは、最初に noise のエクスプレッションを設定して、それを Plot し、Plot後にFカーブエディタの HLE で全体が右肩上がりになるよう調整したのだと思います。 そしてFカーブはゼロ以下にもなっているので、その時はパーティクルが発射されません。 


つまりこのFカーブは、「ずっと発射しっぱなしだと数が多過ぎてよろしくないが、だからと言って単に Rate を低くするだけだと少ない発射がダラダラ続いてしまいこれもよろしくない。なので多く出る時と全く出ない時のメリハリをつけよう。そのために、エミッションがゼロ以下になる時間も作ろう」 という意図でやっていることになります。 


また、このカットはサビの前なので、次に来るサビの盛り上がりを自然に導くためには、このカットの後半で花火が盛り下がってはいけません。なので HLE で右肩上がりにして、後半に行くほど Rate が上がる(=花火の数が多くなる)ことにしています。まあ、ただの気分です。

1フレごとにキーがあるFカーブに Plot してさらに HLE でいじるなんて、なんだか ICE の良い部分を全く使ってないような気がしませんか。こうやって決め打ちFカーブを焼き付けてしまうより、ICE ノードの組み合わせでプロシージャルにやるアプローチを探りたいものです。 でも、往々にして、手でFカーブ描いちまった方が早かったりするんですよねー orz





●花火パーティクル( State 1 )

11_icetree_state1
クリックするとでかい画像。

花火本体です。あまり特筆すべきことはありませんね。


花火の寿命は、Randomize の結果と Turbulize の結果を Add してますね。俺、なにをやりたかったのでしょう? さっぱりわかりません。

Spawn Trails でトレイルを生み出し続けています。毎フレ50個のパーティクルを、0.02という遅い速度で、20度という比較的狭い範囲の角度に射出しています。 つまり「空間に置いていってる」感じが強いわけで、まさに軌跡=トレイルですね。

後は、毎度のようにサイズが1フレごとにちかちか変わるようにしています。






●トレイル( State 2 )

12_icetree_state2
クリックするとでかい画像。

上記の花火パーティクル( State 1 )から毎フレ Spawn されたトレイルです。




・マテリアル分岐用IsThisFuckinTrail

Aの部分ですが、Get Particle State ID でパーティクル1粒1粒の State ID を取得し、それが 2 とイコールだったら IsThisFuckinTrail という独自アトリビュートに true をセットしています。

これは後ほど説明しますが、RenderTree 上で、メインの花火の光球(つまり先頭弾=上記の State 1 のパーティクル)とトレイルで違う質感を持たせたかったからこうしています。 先頭弾なのかトレイルなのかは、State ID を取得すればわかるじゃないですか。 このトレイルの State ID は2なんだから、2とイコールならそのパーティクルはトレイルであると判断できます。 そしてその結果を元に、RenderTree 上で分岐させています。





・トレイルの色変化

B1でトレイルのパーティクルに新たな色を設定していますね。 その上流にあるB2から流れを見ると、何をしているのかわかります。



B2は Get Particle Color なので、まずそのフレームにおけるパーティクルの色をゲットしてますね。 先述のように、もともと State 0 のトリガパーティクルに与えられた6色のうちのどれかが引き継がれていて、ここで取得されます。

そして Color to HSVA で分解されます。 Saturation と Alpha はそのままいじらずにスルーさせてますが、Hue と Value はランダムな値を加算しています。

Hue を見ると、-0.005 から 0.005 までの範囲のランダム値を、元の Hue の値に加算していますね。つまり、元の Hue プラスマイナス 0.005 という値になります。 多少色相を回している=違う色にしているということです。

Value を見ると、-0.065 から -0.015 の値を加算してますね。最小も最大もマイナスの値です。つまり、元の Value の値にマイナスの値を足してやることによって、より小さい数値にするということです。マイナスを加算しているわけだから、減算(引き算)をしているのと同じことですね。 結果、Value(明度) の値が小さくなるということは、色が暗くなるということです。



こうして元のパーティクルの色から、色相を少し変え、明度を少し下げた色が、再度 HSVAtoColor で Color 情報に変換され、B1の Set Particle Color でセットし直されます。

その接続先が大事なわけですが、Execute ノードのポートに入り、最終的には State2 の Execute Every Frame ポートに入っていってますね。つまり、上記の一連の色操作は、毎フレーム行われるということです。

次のフレームでは、また B2 の Get Particle Color から始まるわけですが、そこで取得される色は、前のフレームで一度この処理を通った色なわけです。 なので、生まれた最初の色から計算をし直すのではなく、色相をちょっとずらして明度をちょっと下げた結果の色が再び同じ処理にかかるわけなので、そしてランダムの範囲が狭いため、前のフレームからある程度連続性のある色になります。 前のフレームと比べて急にとんでもなく違う色になったり、急にズドンと暗くなったりはしないということです。


色相の場合はプラマイ幅が均等なので、どっちに転んでいくかはわかりません。ランダムです。 一方明度の方は、ランダム幅があるとは言え必ず値はマイナス方向へ向かうので、1フレ進むごとにどんどん暗くなります。


ということで、その結果がこんな感じです。

13_hanabicolor1

中心部分が暗いですよね。 中心部分のパーティクルは、より早く生まれたトレイルパーティクルですので、先頭弾付近よりも長いフレームを経過しています。上記のように1フレ進むごとに明度が落ちるようにしてあるので、画像のように中心部分が暗い状態の見栄えになります。 色相の方は、ちょっとしか回してないので、そんなに違いはわからないですかね。 まあ気分でやっただけです。


このように、トレイルの色を経過時間で変えていくという方法の実験のつもりでやってみました。 素直に Age とか Age% を取得してそれを元に色を変える方式の方が楽かもしれません。 今回の方式の場合は、1フレ進むごとにどれだけ色相や明度が変わるのかという 「ステップ値」 を決めているということになりますね。1フレごとのステップ値を毎フレ重ねたらこれくらい色が変化しましたよ、というイメージです。 これに対し、Age や Age% などで変える方法は、全体のカーブを決めるというイメージになるかと思います。1フレごとのステップ値は知らないけど、全体ではこれくらい色が変わってくださいよ、と指定しているとでも言うか。




ちなみにですね、このツリーの接続先を変えると結果が全然違うというのを、例示しておきます。

14_icetree_state2once
クリックするとでかい画像。

B1の Set Particle Color を、Execute Once on Enter State ポートに繋ぎ直しました。もともとは Execute Every Frame に入っていたので、毎フレ計算されていたわけですが、Execute Once on Enter State ポートにつなぐということは、この State に突入した瞬間に1回だけ計算されて、以降は値が変わらないということになります。


あと、結果が分かりやすく出るように Value のランダムに Multiply by Scalar を挟んで、ランダムの振れ幅を3倍だか4倍に拡大しています。 これは視覚的に分かりやすくしたというだけで、今説明しようとしている「接続先で結果が違う」という話とは本質的に関係はありません。


これがその結果です。

15_hanabicolor2

トレイルの色の変化に連続性が無いのがわかると思います。 先ほどのやつは先頭弾から花火の中心に向かってだんだん暗くなっていったのに対し、今回は脈略無く明るい色と黒い色が混じっています。


これは色の決定が1回しか計算されないからです。 トレイルは State 2 なわけですが、State2 のパーティクルが生成される瞬間にこの色のランダム化(色相を回し、明度を下げる)が1回だけ行われ、その時点でパーティクルの色は固定されます。以降のフレームでは再計算されないので、このような結果になります。 これは今回の花火で望んだ結果ではありません。 だんだん暗くなっていって欲しいですからね。


ということで、毎フレ計算されるのか、1回だけなのか、いつもそこらへんを気にして接続先を選ぶという話でした。






●水面 ICE

水面オブジェクトはただのポリゴングリッドですね。 エミッタと同様、カメラに入らない部分はメッシュ分割の重さが惜しいので、末広がりな形にしています。 さらにカメラに近い部分のみ分割数が多くしてありますね。 この記事の最初の画像参照。



水面のうねうねは、ICE デフォーメーションでやっています。

その ICETree。

20_waterturb

おおう、スヴァらしくシンプル(゚∀゚)



Turbulize Mesh なんてコンパウンド、いつからあったんでしょうかね? 俺は今回初めて知りました。 中身を見てみると、PointPosition を Turbulize しているだけなので、まあ、今まで手で組んできたツリーをちょっと簡単に構築できるコンパウンドって感じですかね。


2種類の大きさの違うタービュランスを重ねています。常套手段ですね。 あとは、Animated チェックボックスをオンにすることによってタービュランスが発生させるパターンもアニメーションさせていますが、Turbulence Center にもキーを打って手動アニメーションを入れています。


Turbulence Centerを動かすと、タービュランスのパターンが変化するのではなく、現在のパターンのまま XYZ にシフトするという効果があり、結果的に「全体の流れ」を作ることができます。 タービュランスのパターンがその場でうねうねしていてもあんまり水面っぽくないんですよね。やはり、ちょっとでも 「方向性のある流れ」 を感じないと、水面っぽくならないと俺は感じていますが、どうですか。


タービュランスの大きさによって微妙に流れる方向やスピードを変えてやって、良さそうなところを探ります。かなり微妙な調整であり、しかもレンダしないと具合がよくわからなかったりするので、このモーション調整は意外と手間のかかる作業になりますね。


それともう一つ、いつも水面で思うのが、フラクタル(タービュランス)のパターンが XYZ で均一だと水面っぽくないということです。 例えば Photoshop の雲模様フィルタを使ってフラクタル模様を出し、その画像を Bump や Displacement で使って水面をレンダにしても、あまり水面っぽく見えません。 これを、マッピングしたグリッドをヨコに数倍引き延ばすだとか、もしくはテクスチャ画像の方をヨコに引き延ばしてからマッピングするだとかすると、意外と水面っぽくなることが多いと感じています。

21_frac

これはやはり、水面というものは流れがあることが多く、タテヨコ比率1:1の起伏パターンが現れることが少ないからなのではないかという気がするのですが、どうですか。デタラメ言ってたらすいません。


ということで、テクスチャでやる場合は上記のようにあらかじめ引き延ばしたテクスチャを作成するか、マッピング後にオブジェクトをスケールで引き延ばすか、あるいは UV をいじって引き延ばしてしまうのですが、今回の場合はマッピングではないし、末広がりの形を先に決めてしまっていたのでオブジェクトにスケールをかけるやり方も避けたいところです。 なので、グリッドのタテヨコの分割数を変えることによって結果的に同じ効果を狙いました。

上の ICETree画像を見るとわかるように、Turbulize Mesh で発生させたタービュランスパターンは Y のみに適用されています。つまり PointPositon の Y 方向だけの変異量として使っています。 その上で、 X と Z でメッシュの分割数が違えば、この Y の変異量への敏感さというか、メッシュ解像度による追随性に差を付けられるので、結果的に上記の「引き延ばした」ような効果になります。


ICE は以上。たぶん。





### RenderTree編



●花火の RenderTree


花火の PointCloud の RenderTree はこれです。

30_rt_p
クリックするとでかい画像。


花火のみをレンダする Pass で使っています。



・IsThisFuckinTrail で分岐



Aの Color_Switch ですが、上記 ICETree のところで説明した 「そのパーティクルはメインの光球なのか、それともトレイルなのかを判断して RenderTree を分岐する」 という部分です。 

Boolean_Attribute を使ってまず IsThisFukinTrail の値をゲットし、Boolean_LogicInput1 にぶち込みます。 Boolean_Passthrough では 1 (つまり True)を設定しておき、先ほどの Boolean_Logic の Input2 にぶち込みます。 これがイコールかどうか、つまり現在評価しているパーティクルの IsThisFuckinTrail が True かどうかの結果を、A の Color_Switch にブチ込みます。

True だった場合(そのパーティクルがトレイルだった場合)、そのパーティクルは Color_Switch の input2 の方でシェーディングされます。 input2 には B1 の Color_Atta_ICETreeが突っ込まれてますね。これはただの Color_Attribute ノードです。つまり、トレイルは、ICETreeで決定された色を単色で塗りつぶすだけのシェーディングになります。陰影がないのだからシェーディングとすら言わないかも知れないな。

False だった場合(そのパーティクルがトレイルじゃなかった場合=メインの光球だった場合)は、input1 の方でシェーディングされます。 input1 の先には B2 以下のツリーがありますね。ここが使われます。 中身はどうというほどのことでもないです。Incidence を使って、中心部分は光の芯があるかのごとく明るく、周辺部分は比較的暗い上に透明度が高くて奥が透けて見えているというシェーディングです。


こんな感じ。

31_cam_p

先頭弾はB2以下のマテリアル(光の芯があり、ボケ足もある)が適用され、トレイルはB1のマテリアル(単色)が適用されているのがわかります。





ICETree では、Get Particle State ID を使って State を取得し、2だったらそれはトレイルだから IsThisFuckinTrail を true にする、なんていうめんどくさいことをやっていますが、RenderTree から直接 Particle State ID を取得することもできるので、そのやり方にすれば IsThisFuckinTrail なんていう下品なカスタムアトリビュートは不要になり、ICETree はよりシンプルになり得ます。

しかし RenderTree には if ノードなどの直感的に扱える便利な条件分岐のノードがないため、今回の場合は 0, 1, 2 の3種類の値をとり得る State ID を RenderTree 上で取得しても、その後の分岐を作るのがめんどくさいです。っていうかわかりにくいです。 

なので StateID を取得してトレイルかどうかを判断するのは if だとかが使える ICETree の時点で終わらせておいて、RenderTree の段階では 「こいつトレイルなの? 違うの?」 という質問への答えだけを渡すというしくみにしたつもりです。 こっちの方が俺にはわかりやすいです。



・直接カメラから見える場合と反射で見える場合

最後にマテリアルノードに入る前に、Ray_Type_Switch に入ってますね。 これは、パーティクルが直接カメラから見えている場合と、水面の反射で見えている場合とで、見え方を変えたかったからです。

A以下のツリーは eyerefraction に入っているので、直接カメラから見たり、何かの透明部分越しに見えた場合はこのA以下のツリーが適用されます。

しかし、RenderTreeの右上部分=Group Comment で囲った部分は reflection ポートに刺さっていますね。つまり反射して見えている場合は、この質感を使えということです。B2の結果を Add したりして明るくしています。つまり、水面に映る花火は、直接カメラから見る花火よりも明るくなるというインチキなことをやっています。水面に映り込む花火を強調したくて、このようにしています。

実際のレンダの時は花火と水面を別レンダリングするつもりなので、水面 Pass では花火のマテリアルを Partitionマテリアルで変えちまえば良く、このように Ray_Type_Switch を使う意味はそんなにありません。にもかかわらず使ったのは、久しぶりに手順を確認しておきたかったというだけです。 もし花火と水面を一緒にレンダする必要があって、かつカメラから見た場合と反射越しに見た場合で質感を変えたい時などは、この Ray_Type_Switch が活躍するわけです。





●水面の RenderTree


水面の RenderTree はこれです。別Passでレンダしてます。

32_rt_oceansurface
クリックするとでかい画像。

Architectural を使っていますね。フレネル効果のあるリフレクションを簡単にやりたかったのだと思います。カメラから見て水平に近い部分ほど、背景や花火をよく映し込みます。


Incidence を使って、カメラから見て水平に近い部分だけを取り出し、それをブレンドマスクにして何度か Add してますね。水平線の近くがより明るい色になっているのがそれです。

33_cam_oceansurface
そして、花火は別レンダするので、この Pass では Primary Ray をオフにしています。カメラからは見えないのに、水面に映り込んだ花火は見えているという状態です。空をマッピングしたグリッドも同様に Primary Ray オフです。


そして水面に映り込んだ花火は、先ほどの花火 Pass でカメラから直接見えている花火よりも明るいものです。上記、Ray_Type_Switch でそうしているからです。







●水面デプス Pass



水面のみ、Depth Pass を用意しており、こんなマテリアルになっています。

34_rt_oceandepth
Scalar_StateRay Length を拾っています。Ray Length = レイの長さってのはつまり、カメラからの距離です。 正確に言えば、カメラから発射された Primary Ray がジオメトリと交差した地点( Intersection Point )における、そのレイの長さということになると思います。 ともかく、この方法でカメラからの距離が、オブジェクト単位ではなく、ピクセル単位でゲットできます。Primary Ray 専用ということになるので透明のブツを透過した距離には使えませんが。


こうして得られた距離を Scalar Change Rance にブチ込んでいますね。そして Old Range Start100Old Range End0 になっていますから、Ray Length の結果を、100 から 0 のレンジだと見なしていることになります。 そしてそのレンジを New RangeStartEnd0 から 1 にリマッピングしたスカラ値を吐き出しています。 結果、オブジェクト表面の、カメラから距離が 100 の部分は 0 で、距離が 0 の部分は 1 になります。


この 0 から 1 のスカラ値を Scalar to Color でそのままカラーに変換してやれば、0 = 黒、1 = 白というグラデーションができあがり、普通にリニアなデプス画像になります。 が、今回の場合は、Gradient Mixer のインプットにブチ込んで、グラデーションを調節していますね。黒のレンジを圧倒的に大きくしています。 

レンダするとこうなってます。

35_cam_depth

今回は水面の奥行きがかなり広く、リニアなデプスにするとカメラから見えている範囲にグラデーションが発生しなかったのでしょう。水平線間際でしかグラデーションが無かったのでしょう。 なので、見える部分で奥行きのグラデーションになるように、Gradient Mixer を使って調整したということだと思います。






・・・・と、水面のデプスマテリアルの作り方を全力解説したのはいいのですが、今、AfterEffects のコンポジションを見てみたら、この水面デプス素材、使ってませんでした orz


たぶん使うだろうなーと思ってレンダしておいたはいいが、実際のコンポ時に出番がなかったのか、デプスな処理を入れるのを忘れていたか、時間がなかったのか。 いずれにせよ無駄な Pass になりました。本当にありがとうございました。








●リフレクションのみ Pass


水面のシェーディングは除去し、水面に映る花火しか見えていないという Pass もレンダリングしてました。

36_ref

水面の Pass の Arc Mat を複製してリフレクションなどの値はそのままに、色を真っ黒にして、ライトもこの Pass ではオフにし、結果、水面に映り込んでいる花火以外は見えないという Pass になっています。


コンポ時に花火 Pass の方は Starglow で光芒を入れるのですが、ここが2D処理の弱点で、水面と花火が一緒にレンダされているだけだと、水面に映り込む花火の方には Starglow が入れられなくなっちゃうじゃないですか。 空にはキラキラ光芒付きの花火が上がっているのに、水面に映っている方はキラキラ光芒無しという、インチキ状態になってしまいます。


まあ、どのみちインチキなことしかやるつもりないし、現象として正しい状態にしようなんてつもりはサラサラ無いのですが、調整に便利だろうと思ってこの素材を用意したわけです。実際にコンポで使ってますね。水面に映る花火により強く Starglow をかけて、これ見よがしにキラキラ感を強調しているようです。助平なコンポです。



ちなみに黒い部分はヌケているわけではない(アルファチャネルは白)なので、Add するか UmMult して抜くことが前提の素材になりますね。




●カメラ


テキトーに、気分でティルトアップなアニメーションをしているだけです。

40_camanim

わははー カメラとインタレストの posY が動いているだけだー しかもなんの工夫もないイーズインイーズアウトだー ( ^∀^)ゲラゲラ


まあ、そのイーズっぷりは調整してますがね。こういうゆっくりなカメラアニメーションは特に、そのフェアリング加減で簡単に気持ち悪くなっちゃいますからね。









XSI 上での解説はこれくらいかしら。
ううむ。しんどい。


たぶんコンポ編に続く。たぶん。




.

| | コメント (0) | トラックバック (0)

2011年10月25日 (火)

Making of 花火。 c03。 Comp。

c03 の続きです。






### コンポジット編


また例によってブレイクダウンビデオ風。







AE の作業画面
01_aescreen
クリックするとでかい画像。


c02 とほぼ同じですねえ。Starglow と Lenscare あたりを中心に、グラデーションをかぶせたりとかしているだけです。




・グラデーション乗せ

手前と奥の2つの花火で、なんとなく奥行き感というか、前後感というか、平板な印象を薄めるために何かやりたくなったのだと思います。 なので、AE のカラーカーブを使って暗いグラデーションを発生させ、背景+ Starglow 済み花火素材の上にまるごと乗算しています。 

02_colorcurve

手前の花火よりは下のレイヤなので、ここで前後の差を出そうとしているのですね。



ただし光が弱まってしまうので、Starglow なレイヤを複製+加算して、あらかじめ過剰に光らせておいた状態が上の画像の赤線より右側ですね。 そしてカラーカーブをまるごと上から乗算でかぶせたのが左側です。


ただし、背景がずいぶん暗くなってしまいました。地平線間際だけ明るくしたくなったので、今度は明るいカラーカーブを発生させて、加算しています。

03_colorcurve2

これは手前の花火も含んだ一番上から、まるごと乗せていますね。 赤線より右が使用前、左が使用後です。



・・・いやあ、それにしても、上に書いたような暗くしてから明るくしてとか、コンポジットの大御所からいかにも怒られそうな、強引で刹那的で、階調をゴリゴリと失って絵が劣化しそうなことしてますねぇ俺。すいません。 先日 CGWorld クリエイティブカンファレンスというセミナーに参加してきたのですが、どうやらコンポジットの神様らしいお方のセッションに参加したら、すんげえ怒られちゃったんですよ。


   「 君たち日本のコンポジタはわかっちょらん。 
    見た目の雰囲気だけでコンポジットしてるでしょ。
    まずはちゃんとピクセルの値を数値で見なさい。 
    そしてソフトウェアまかせにせず、
    合成する際のピクセル同士の計算式を理解して、
    破綻した値になるピクセルが出てこないコンポをやりなさい 」 


という意味のお叱りを受けました。俺の理解では、こういうお叱りだったと思います。 アドバイスなどという生ぬるいものではありません。お叱りだと受け止めました。 医者にコレステロールの高さを指摘され食い物の制限を命じられた時のような気分です。 これは生半可な知識ではなくちゃんと深いレベルで理解している人しか言えない苦言だぜオーラが、講師様の背中から 32bit float の階調で出まくっていましたよ。神々しかった。

合成のなんたるかについて、自分が全然わかってないということはわかっていたつもりですが、ここまで明快に怒られるとそれがますます明確に意識され、実に清々しく、実にためになりました。 猪木にビンタ張ってもらったような感じですかね。いやあ、強烈ビンタでした。ためになりました。 ある程度以上でかいプロジェクトじゃない限り、俺ごときはコンポジットも自分でやらねばならないことが多いので、このままではいけません。これまでの不勉強を恥じてこれから勉強します。 セミナーの内容は、技術的な意味で俺にとっては少し難しい話だったので綺麗に理解はしてないのですが、心構えとして本当に勉強になりました。この日で一番良かったセッションでした。いやマジで。全然嫌味ではなく。



ということで、このブログに書いているコンポジットは、決して真似しないで下さい。 ゴーセイのゴの字もわかっちょらんアスホール野郎が、見た目の雰囲気とその場のノリと締め切りへの恐怖だけを拠り所にして強引かつ厚顔無恥に突っ走った結果の刹那的盲目的ファッキンコンポジットです。御注意下さい。いやマジで。


俺は恥を晒しますよ。こんなファッキンコンポでもメイキングとか言いながら書いちゃいますからね。恥を晒さないと、依頼側からこいつは分かってるやつだと思われて本番の仕事の時に困ることになり得るし、また、恥を晒しておけば誰か親切なお方が哀れに思ってご丁寧に御教示してくれる可能性だってあるわけですよ。 変なプライドなのか虚栄心なのか、わかってないくせにわかったフリをしてしまうことも結構多いという実にイタい俺ですが、そんな見栄を張って得をしたためしなんて本当は一度だって無いんですよね。いつも後で損するし、その晩は忸怩たる思いに苛まれて布団の中でわぁっとか叫んだりするんです。それに比べれば、この程度の恥晒しなんて屁でもないはずです。わからんことをわからんと言って教えを乞う、できないことをできないと言って助けを乞う、ヘタクソあるいは不勉強ゆえのデタラメなものでも人前に晒して批判を浴びる。そんなん、屁でも無いと思うように心がけたいです。 また、自分のブログであるのをいいことにコンポジットをちゃんと理解してないアスホール野郎がコンポジットについて好き放題書くこのイタさを、こんな独白によって紛らわせたり許してもらおうとしたりしているこの態度こそ恥なわけですが、それも含めた恥晒しをしておくんですよ俺は。 ま、ほんとはもっと上手に恥を晒したいんですけどね。。。 俺の中で納得の行く恥の晒し具合が、全然まだ見つかっていない。 今日も布団の中で叫ばねばならないなあ。


おっと大幅に話が逸れて行ったのはいつものことで、未供養のCG浮遊霊が俺に憑依しているのです。自動書記というやつです。









・ケラレ

さて話を戻すと、次はケラレ。
カメラ/写真用語のケラレとは違うとは思うんですがケラレと呼んでしまっています。

04_kerare

こんなのを上から乗算しています。 一番上からです。 こういうのがなんとなく好きなんだからしようがない。





・Vector Blur

出ました。また馬鹿のひとつ覚えの CC Vector Blur です。

05_vectorblur

AE に標準で付いてきますよね。CC って何? どっかのプラグインメーカがアドビに買収されてバンドルされるようになったとか?


まあともかく、割とよく使うエフェクトです。 ツブツブのような絵を、なんとなく繋がったかのような、少しフルイド感があるような、リキッド臭い感じのような、なんとも形容しがたい怪しい状態にしてくれます。画像の右側が元の素材、左側がそれに Vector Blur をかけたものです。 元素材は別にツブツブじゃなくともいいのですが、俺はそういう使い方をすることが多い気がします。


笑えるくらい元の素材からかけ離れた雰囲気になることが多いエフェクトなので、いじくる価値はあると俺は思いますよ。すんげえ目の荒い、まるで70年代後期のゲームのようなでかいドットだけで構成された、ボコボコでガチガチなパーティクルとかにこのエフェクトをかけると面白い。なんとなく繋がって、線になり、しかも真面目に狙って作ろうと思うとなかなか難しいアミアミ感にしてくれたり。 え? あのショボい素材が、なんか少し高級に見えない? (゚∀゚;) みたいな。 ああ、コトバじゃわけわからんですね。 ともかく俺はよく使うのです。


でもこのカットでは、この Vector Blur のレイヤはそんなに主張してませんね。なくてもいいくらいでした。 c01 ではこのエフェクトにヘビーに頼っているんですけど、まあその話はまた後日。


Vector Blur は純粋に2Dエフェクトのはずなので(たぶん)、元素材のピクセルがスクリーン座標上でどう配置されているかだけが計算の元になっているのだと思うんですが、これが3D的に値を見てくれるエフェクトならいいのになあといつも思います。Z深度の情報を与えてあげて、Zでベクターブラーするとでも言うか。 デプスPassを食わせると手前と奥のピクセルで繋がってくれるとか。  あと、16/32bit 対応になると何かいいことあるのかしら。現状、8bit しか対応してないように見えます。




・ボケグロウ

手前の花火に発光感というか、もやーんとした発光フレア感が欲しかったので、Starglow済みの花火 Color Pass 素材を安直にボカして、加算で重ねています。

06_glowblured

これも安易にやってますよ。ピクセルの値など見ていません。階調がブッ飛んだりしやすい行為ですよね。慎重にやるべき行為だとは思うんですが、ついつい安易にやっています。


元素材に、もやや~んとしたグロウをまとわせる良い方法、ありますかね? いいフィルタとかあれば教えて下さい。 AE 標準の Glow はどうも苦手です。思った感じにパラメータを追い込めず、いつも発光感が足りないというか、マットっぽくなってしまうあるいは平板になってしまうとでもいうか。




・その他

BGは3D上で板にマッピングし、3Dカメラで移動のアニメーションをさせています。なのでBGは2Dでは動かしたりしておらず、スタンダードフレームと言うか100フレームというか、最終解像度ぴったりのサイズでレンダされています。


ピン送りらしきことをまたやっていますが、これも気分でやっただけです。 仮に花火がリアルスケールだとすると、この距離からこのレンズで撮った場合に、こんなボケにはなり得ない気がしますがどうですか。なんかミニチュアくさく見えますよね。 でも今回は、むしろそうしたかったのです。リアルなことなんてやっている時間ないから、そのウソ臭さの方で引っ張る方が正解だという気がしていました。 まあ、全カットで一貫してないところがイタいんですが・・・ orz






こんなところでしょうかね?

ううむ、なかなか書くの大変だけど、ここで止めるのは半端感があり過ぎるので、たぶん続けます。たぶん。



.

| | コメント (0) | トラックバック (0)

2011年10月24日 (月)

Making of 花火。 c03。 ICE。

花火メイキングの続きです。



c03 です。
ビューポートキャプチャはこれです。


もはや花火としてのリアリティなどカケラも目指していないことがよくわかります。 散った後の花火がこんなにタービュランスな動きしねえっつうの。 いいんです。 このあたりから、ちょっと怪しい、あり得ない、CGならではの変な花火にしようかな、などと思い始めていたんだと思います。 っていうかリアル狙ってもこの短期間じゃ俺には無理だし。




XSI の作業画面。
1_xsiscreen
クリックするとでかい画像。


これまた超シンプル。

エミッタになるヌルが2つ、PointCloud が2つ。 あとはアニメーションしているカメラ。背景画をマッピングしたグリッド。 以上。




### ICETree 編

ICETree はこれです。
2_icetree_all
クリックするとでかい画像。

一番上が最初のエミッション部分、State0 はそのエミッションで発射されるメインの光球、State1 はメインの光球が空間に残していく軌跡=トレイル、 State2 はメインの光球が死ぬときにパッと出てくるラストの花です。

このICETree はこのカット内の1個目の花火のものですが、2個目の花火もほぼ同じ構造でした。 違うのは、タービュランスなどのフォースの強さや、ラストの花が開くまでにかかる時間(つまりメイン球の寿命)、色、ランダムシード、くらいですかね。



●エミッション

3_emit

このエミッションでメインの光球が発射されます。
・・・・が、特段なんら工夫もしてなくて語るべきことがない orz
サイズ、スピード、寿命をランダマイズしているだけです。




●メイン光球 State ( State 0 )

4_state0
クリックするとでかい画像。

これも前回 c02 の時に書いたこと以上のことは何もやってないですね。工夫なくてすいません。 一応以下に書きますけどね。


・重力ランダマイズ

エミッションで発射スピードにもばらつきを与えていますが、さらに軌跡にバリエーション感が欲しくて重力の強さもランダマイズしています。


・レンダ時の透明度で使う独自アトリビュート

RenderTree で透明度として使うために、前と同じ、独自の TranspFucker アトリビュートを与えています。


・ちかちか

サイズを常に変化させてちかちかした感じに見せようという試みも、前のカットと同じ。


・トレイル発射と特定トリガで発射

メインの光球トレイルは、そのメイン球が死ぬまで毎フレーム出し続けたいので、Execute Every FrameSpawn Trails をブッ込んでいます。

一方、メイン球の寿命が尽きた瞬間に1回だけ新たなパーティクルを発射させているのが、Spawn on Trigger ですね。 

トリガは何でもいいのでしょうが今回は寿命が尽きたことをトリガにします。 なので Test Particle Reached Age Limit をトリガのポートにブッ込んでいます。こいつが true になったとき(寿命が尽きたとき)、Execute on Trigger ポートにブチ込まれた Spawn on Trigger が起動されます。 こうして発射されるのが State1 = 最後に咲く花です。





●ラストの花 State ( State 1 )


5_state1
クリックするとでかい画像。

ここでもやっていることは、前回の c02 と同じっぽいですね。


・Fカーブ

Get Particle Age% を2つに分岐させて、違う Fcurve に食わせ、それぞれ重力とタービュランスに使っていますね。

重力の方は、0,0 から始まって 1, -5 で終わっています。寿命ゼロ%(=ヨコ軸 0 つまり生まれてすぐ)の時に重力(タテの値)はゼロであり、寿命100%(=ヨコ軸 1 つまり死ぬとき)に重力が -5 働く、ということです。

タービュランスの方は、既に Turbulize Around Value で決定済みのタービュランスの強さに対して、Multiply By Scalar を使って何倍にするかを決める Factor につながっています。なので、生まれてすぐは 0 を掛け算するからタービュランスの力はゼロ、死ぬときは 1 を掛け算するからタービュランスの力は Turbulize Around Value で決定済みの強さとイコールになります。

今考えてみれば、重力の方もタービュランスと同じしくみにすれば良かったですね。つまり、最大重力パワーである -5 を先に決めておいて、それにFカーブの値を Multiply する形にすれば、重力の方もタービュランスと同じく 0,0 から始まり 1,1 で終わるFカーブにできるわけなので、もしカーブっぷり(カーブの形)が同じで良かった場合はFカーブノードを共有できたはずで、ノードの数を減らすことにより軽くなったり、わかりやすくなったりしたかもしれません。



・結果をブースト

「ちょいブースト」となっているのは、Multiply By Scalar で重力の強さを 1.25倍大きくしているのですね。 Multiply By Scalar を挟むのは、常套手段とでも言うか、今さら言うまでもないお約束パターンかも知れません。

ランダム系を使っている場合は特にそうですが、値のレンジをまるごと大きくしたり小さくしたりするのに、いちいち Randomize の最大/最小値とかを変更するのめんどくさいじゃないですか。 あるいは、今回の場合はランダムではなく寿命の値をFカーブで操作した結果なわけですが、ちょっとレンジを変えたいだけなのにFカーブいじるのも嫌ですよね。なんてものぐさなんでしょう。 なのでランダムやFカーブの結果を後からまるごとでかくしたり小さくしたりするために、Multiply By Scalar を使うわけですね。 ランダムしつつ、調整のため何度もいじることが予想されるパラメータ、たとえばエミッションの Speed なんかは、最初から Multiply By Scalar を付けておくことも多いですね。必要なければデフォルトの 1 のまま放置しておけば x 1 だから値は変わらないし、でかくしたいと思ったら 1.5 とか入れればそのまんま 1.5倍されるわけで、楽ですよね。


・色とか

色にバリエーション持たせるためにサイコロ振っているのも前回と同じ。
そしてまたもや TranspFucker を設定していますね。





●トレイル State ( State 2 )

6_state2
クリックするとでかい画像。

すいません、これも同じですねえ。 生まれてすぐはタービュランスの影響をあまり受けず、寿命の後半でどんどんかき乱されていくようにしています。同じです。

ただし、今回はフォースとしてタービュライズしているのではなく、Turbulize Particle Velocity コンパウンドを使って乱していますね。 特に理由はなく、色々やってみたいだとか、気分で使っているだけですけどね。ベロシティ、つまり方向と速度を持った概念だと思いますが、これを毎フレーム評価し直してるんだと思います。 こんなコンパウンド、前からあったっけ?

ってことでこのコンパウンドの中身を見てみると、
6_turbulize
なんのことはない、Turbulize Around Value を使っているだけではありませんか。


Base Value Get Particle Velocity から得られたベクタがブチ込まれていますね。つまり、前のフレームでパーティクルが飛んでいた方向を新たなタービュランスの基準点にしているということですね。こうしないと連続性のない、1フレごとに位置が不規則に変わったりする、デタラメなランダムになりますもんね。

で、Variance つまりプラスマイナスの振れ幅を、XYZ 同一の値でブチ込んでいる。つまり Turbulize Particle Velocity コンパウンドでユーザが Strength に入力した値は、そのまま XYZ に共通な振れ幅として使われるということですね。

そして結果的に得られたベクタを、新たに Velocity としてセットし直して終わり。 Speed はいじくってないから、このコンパウンドでは方向のみを扱い、速度はいじれないということになるんでしょうかね。 すいません、俺もその辺よくわかってなかったり。

まあともかく、フォースとして Turbulize Around Value を与え、Variance に XYZ を同一の値で与えた時と同じ挙動になるんではないかと思います。誰か実験して教えて下さい。 同じなのであれば、フォースの方でやるよりこっちが楽なような気もするし、そうでもない気もするし、どうでしょう。 まあどっちでもいいけど。











こんなところでしょうかね。

前回の c02 に無かった要素としては、メインの光球の寿命が尽きるときにもう1回小さい花が咲くというものですが、Spawn on Trigger 使ってるだけだし、全球状に広がってその後落ちていくだけだし、さほど工夫した感じがありません。 この花にもトレイルを付けたり、この花を構成する玉の寿命が尽きるときにもまた新しい花を咲かせたりなどと、永久ループな花火にするのも手かもしれません。フラクタル相似的花火。いつかやってみよう。





あ、あと、今回は State Machine ノードを使いませんでした。
7_states
クリックするとでかい画像。


Simulation Root ノードってのは、たしか 2011 SAP から付いたんだっけ。 この Simulation Root ノードに、State Machine の機能があるんですよね。 チェックボックスをオンにすると、Simulation Root 内のポートが State Machine の働きをするようです。 

でもなんだかわかりにくいというか、State Machine を State のルートにして、そこから枝分かれさせた方が好きです。 今回は、このつなぎ方でもいいのかどうか試してみただけという。

ただですね、ひとつわからないことがあります。 上記で出てきた State0 の画像にある、Simulation Root の Forces ポートや Execute1 ポートに刺さっているツリーは、State0 に効くものだと思っていました。 であれば、State0 ノードにある Execute Every Frame ポートにつないでも同じだろうと思うのですが、そうつなぐと違う挙動になるんですよ。 ここがいまひとつわかっていません。 研究が必要です。

まあ、State が複数ある場合は今後なるべくState Machine を使って、各 State にローカルに効くフォースその他は Simulation Root にはつながず各 State ノード以下だけにつなぐ、と決めてしまってからパラメータを調整するようにするとは思います。 そっちの方が俺にはわかりやすい。






### RenderTree 編

すいません、RenderTree見たら前回の c02 と同じでした。 よって新たに語るべきことはありません。 すいませんすいません。





きっと続く。

| | コメント (0) | トラックバック (0)

2011年10月21日 (金)

Making of 花火。 c02。 Comp。

c02 の技術解説の続きです。






### コンポジット編



まずはこのビデオを見ると、基本的に何をやっているのかわかると思います。

とか偉そうなこと言っておいて、別にどってことないですね。Starglow とか Lenscare とか使っているというだけです。こんなブレイクダウン風なビデオを作るのも恥ずかしいくらいだけど、まあ、やってみたかっただけですよ。中身はともかく外見だけはマトモな VFX のメイキング映像っぽい、みたいな。ええ、やってみたかっただけですとも。



AfterEffectsCS5.5 でやってます。その作業画面。
Aescreen1
クリックででかい画像が出ます。

ビデオの中の Fire 素材が、前の記事で書いた Color Pass のレンダ結果ですね。Mental Ray で、16bit の tiff でレンダしています。

Depth 素材も、前の記事で書きました。同じく Mental Ray で、16bit の tiff でレンダしています。 レンズボケの素材になります。



・Starglow

Color Pass に対しては Trapcode Starglow を使ってます。 昔から、光モノを作る時には欠かせないプラグインですね。 元素材の輝度などを参照して、クロスフィルタ的な光芒を生成してくれます。 ブツのカドにカッコよく光芒が出たりするので、好きなのです。 Trapcode Shine と共に、無くてはならないプラグインです。 Shine は今回の花火では使っていませんが。

設定は、安易に Warm Star プリセットを使っていますね。 おそらく、ThresholdStreak LengthBoost Light くらいしかいじってない気がします。もうちょっとパラメータがいじりやすいと細かく調整する気になるんですけどねえ。まあこれは AE のフィルタの UI 上の制限が大きいですかね。 俺はいつも細かい調整をせず、安易かつ下品に使ってしまっている気がします。

Threshold は、元素材への敏感度ですかね。数値が小さいほど敏感になります。つまり、大した輝度じゃなくともビカビカと光ります。元素材の様子が大きく変化する場合は、この数値にキーを打ってアニメーションさせることも多いです俺は。

Streak Length は光芒の長さですね。 光芒を長くすると光が弱くなって見える傾向があると思うんですが、どうですかね?  おそらく、光芒を長くしても光の総量は変わらないので、同じ明るさが長い距離に分散されて発光感が弱まる、という感じなのではないかと思っています。

Boost Light は中心部分の発光感をブーストさせる感じですか。 Streak Length を長くして光が弱くなったと感じたらここの数値を上げます。っていうか Streak Length に必ずしも関係なく、もっとガツンと光が欲しいという時に、とばばばっと上げてやります。


他にもいじるべき箇所がいっぱいあるのでしょうが、あまりいじってません。安易ですいません。 っていうかマニュアル読んだことねえや俺。 ダメぽですね orz


質問ですが、こういうクロスフィルタ系というか、キラキラした光芒、星を散りばめたような光を大量に生成してくれる AEプラグインって、他に何がありますかね? 俺が知っているのだと、Knoll Light Factory の Spectacular だっけ、あれを使うと素材のアルファチャネルの輝度だか面積だかに反応して、キラキラレンズフレアを生成してくれますよね。 でも、すげえ重いんだよなアレは。 しかも、インプットになる素材をいい感じに作るのがちとめんどくさく感じてしまう。 他にこれ系のプラグインでおすすめのもの、ありますか? 教えて下さいませ。




・frischluft Lenscare

レンズボケは Lenscare を使っています。

Lenscare

右が元素材に Starglow だけかけたもの、左は更に Lenscare をかけたものです。

このカットの場合、Lenscare に含まれている Depth of Field エフェクトを使ってますね。デプス素材を指定し、ピントを合わせたい部分をピックすると、ピック部分の輝度を合焦点の距離にしたボケを生成してくれます。 

奥行きに関係なくレイヤ全体をレンズボケにしたい場合は、Depth of Field ではなく Out of Focus エフェクトを使います。デプスの計算をしない分、たぶんこっちの方が速い。他のカットでたぶん使ったと思う。 パラメータは、デプス関係が無いだけで、ほぼ Depth of Field と同じ。


ボケの強さ、形(絞りの羽根の枚数)などはいじりますが、いつもそれ以外はあまりいじってないし、これまたマニュアルも読んでいなく、全然使いこなせていませんね。う。ヤヴァい。ちゃんと語れるほど使い込んでいないのにメイキング記事とか書くイタさに苛まれ始めてしまったではないか。まあいいや。すいません。

これは好みですが、俺はシャープなエッジのボケが見たいことが多いので、Iris > rounded facetsゼロにして絞り羽根の形が丸まっていない状態にすることがほとんどですね。
Roundedfacets  Rounded

デフォルトだとこの数値が1=丸いんですよ。 エフェクトのデフォルト値って、独自に設定できないんですかね? 毎回いじるの面倒なので、好みのデフォルト値に変えてしまいたいです。


前の記事でも書きましたが、最初は光球の半透明なエッジを考慮しないデプス素材でやっていたんですよ。
Depthlayer

↑この画像の左のような感じね。

でもこの素材を使ってレンズボケさせたら、↓エッジが汚くなっちゃったんです。

Badedge

上の Youtube ビデオでも、エッジが汚い旧バージョンが見れます。

なので、さっきのデプス素材画像の右側のように、半透明エッジを考慮に入れたデプス素材にしたら、汚いエッジは無くなりました。いや、もしかしたら目立たなくなっているだけかも知れません。 

ともかく、透けて向こうに見えているパーティクルのデプス情報も取れているはずなので、そのせいか、
Bokeh
このような 「カメラから見て、手前のパーティクルと重なっているけど、手前はボケたために、手前側は絞りの形にボケて、奥は元の丸い形のまま、透けて見えている」 状態が出やすくなった気がしているんですが、どうでしょうかね。 この状態、綺麗ですよね。



ピン送りは、まあ、適当です。やってみたかただけ。



Lenscare 以外のレンズボケプラグインは Final Focus を使ったことがあったけど、重かった&使いにくかった印象があるな。でも昔のことなので詳しくは忘れてしまいました。なので Lenscare が他のレンズボケプラグインと比べて良いのか悪いのか、あまりわかりません。オススメがあれば教えて下さい。


今考えてみると、Starglow 済みのものに対して、Starglow など全く考慮していないデプス素材を使って Lenscare しているわけで、かなりデタラメなことをやっている気がしてきました。 逆の順、つまりボケ済みのものに Starglow した方が良いような気がしないでもありません。 でも今さら気にしません。 MBA もらえたんだから。





・色深度

今回、大抵の素材は 16bit tiff でレンダしています。階調が豊かな方が後でいじるのに圧倒的に有利ですし、今回は光モノなので特にそうです。

ただですね、AE のモードを 32bit にしてみたら、すんげえ鮮やかな色になったんですよ。
Bitdepth
これ、同じコンポジションを、単に色深度だけ 8, 16, 32 と変えてスクリーンショット撮ったものです。 8 と 16 では差が無いように見えるのに、32 だけはガツンと彩度が上がったように見えます。

Starglow や Lenscare は 32bit に対応しているので、生成する色に差が出るのかもしれませんね。特にこういうグラデというかボケ足が多い素材を使っていると、その差が顕著に出やすいのかも知れません。素材を 16bit でレンダしているので、そもそも 32 で合成する理由は無いと思い込んでいたのですが、そうでもないらしい。 デタラメかもしれません。 

ともかく、いい感じの色に見えたので、全カットで基本は 32bit モードで合成しました。最終レンダは QuickTime のアニメーション圧縮100%ですので、 8bpc に落としていることになると思うんですが、合成の途中過程で階調を失ってない(飛んだりつぶれたりバンディングしたりしてない)からこそ、最終的な 8bpc の絵にも影響が大きく出るんだと思います。たぶん。 今度からこういうのやる時は、素材の色深度に関係なく、試しに 32bpc モードでも見てみることにしましょう。



・カメラ

3Dでカメラは動かしていません。っていうか、もともとカメラを動かすつもりはなかったカットだった気がします。 合成の段階で、ふと思いついてBGだけにスケールアニメーションを入れてみたら、カメラが動いているように見えるような見えないような微妙な感じになり、それがけっこう気に入ったのでそのまんま使いました。 よって、花火素材は固定カメラで撮り、BGだけカメラが寄って行ってるかのような動きを付け、それを平気な顔して合成しているという、実にデタラメなことになっているカットです。



・その他

あとは、カットによってBGの色をちとカーブで調整したり、花火ごとカーブで調整したり、ケラレ風な暗部を足してみたりしている程度です。 

馬鹿のひとつ覚えのようですいませんが、ケラレが好きです。 実際の写真を撮るときでも、ケラれた写真が撮れるとなんか嬉しいくらい。いかにも サーキュラーPL を使ったような青の彩度が高い空や海の写真が好きですが、そういう写真によくケラレがあるという記憶が、そうさせているのかもしれません。 ま、俺の場合は光学的な事象など全く無視してなんでもかんでもケラレを入れるという下品な使い方しか出来ないんですけどね。 画面が平板でどこか絵的に物足りない時なんかに、深く考えずに安易に足します。パラも好きですね。あと、意味不明の画面外光源によるフレア入射光とかも。 こういう、画面全体に一番上から強制的にかぶせるグラデーション系な処理とでも言うべき処理は、割と画面を豊かにしてくれると思っているんですけどね。 演出意図によっては、目線の誘導にもなるので便利です。出崎風パラとか。






コンポジットの話は以上かなあ。
たぶん他のカットの話へ続く。

| | コメント (2) | トラックバック (0)

2011年10月20日 (木)

Making of 花火。 c02。 ICE / RenderTree。

先日のパーティキュラー花火大会へ出した作品の、技術解説を書きたいと思ったんですよ。

いや、別に誰かにリクエストされたわけでもなんでもないんですけどね。
俺が勝手にやりたいだけ。



でも書き出してみたら、なんだかすんげえ大変で。
どこまで続くかわかんないけど、ひとまず気分で、書けた部分から出して行きましょう。



あ、言っておきますが、すごく高等なことをやっているわけでも、画期的なことをやっているわけでもないですよ。なんせ ICE の練習くらいのつもりで始めましたから。 しかも最後には練習という意図もどこへやら、もはやただ完成させることしか考えていませんでした。 誰にも頼まれていないのに、勝手に自分でやると決めて作り始めたんだから、完成してコンテストに出さなきゃもったいねえ! って、ほんと、最後はそれだけを考えてました。 

マトモにやったら間に合わなくなることがわかったので、完成させるためならということで、ICE の練習や研究になっていようがいまいが、ともかく誤魔化してデッチ上げるという感じになってしまったので、以下の技術解説も 「結果的に俺はこんなことをしていたようです」 という色が強いものになっているかもしれません。

まあいいや。 ともかく今回の花火作品の、ICE 関連や AE 関連について、書けるだけ書いてみます。










まずは、カット2の話を。これが一番最初に作ったカットでした。 
あ。そういう言い方は微妙だな。

「一番最初に作った素材が、結果的に c02 になりました」という方が正確です。 


このカットのビューポートキャプチャはこれです。


そしてこのシーンはこんなにシンプルです。
Xsiscreen

クリックで、でかい画像が別ウインドウに出ます。

エミッタになるヌルがひとつ、Point Cloud がひとつ、あとはカメラだけ。 ほんと、それだけのシーンです。ライトすらない。




### ICE編



ICEツリーはこのようになっています。
Ice_all

クリックで、でかい画像が別ウインドウに出ます。



上のICEツリー画像で、1の部分がエミッション関係ですね。

2が最初に発射されるパーティクルです。つまり、放射状に広がっているメインの玉です。このメインの玉が、Spawn Trails でトレイルになる小さい玉を産み続けます。

3が、そのトレイルですね。

1のエミッションによって2のメイン玉が発射され、そして2のメイン玉は寿命が尽きるまで3のトレイルを発射し続けているという構造になっています。 まあ、普通の構造だと思います。たぶん。




ではひとつずつ。

●エミッション部分

なんてことはない、ヌルをエミッタにした、普通のセットアップだと思います。Emit From Null コンパウンドを利用しています。
Ice1

エミッションシステム、つまりパーティクルの誕生ルールのシステムを、ゼロから自作するのはまだ俺にはできません。でもきっと、いずれやらねばなりません。標準のエミッション系コンパウンドに縛られていると未来はない、と感じています。 発生の場所、タイミング、その他、このコンパウンドに各種コンパウンドを突っ込んだだけだと、100%思い通りにはなりません。

例えば、どの位置で、何フレーム目に、いくつパーティクルが発生して欲しいか、あなた100%正確にコントロールできますか? このグリッドの表面において、、ぴったり1ユニットずつ間隔をあけた位置で、12フレ目に、それぞれの位置から1個だけパーティクルを発生させる、とか、できますか? 少なくとも標準コンパウンドじゃできない気がするのですが、どうでしょうかね? だから自作するしかないのかなと思っているのですが、エキスパートの方、どうでしょうかね?


まあともかく、順に見て行きましょう。 あ、大したことやってないので期待しないで下さいほんとに。 大したことを見たい方は、恋タローじゃない鯉タローじゃない、ええと、リタローさんのところへ行って下さい。

まずは Emit From Null コンパウンドの PPG を見てみます。
Ice1_em

ここが全ての始まりですね。


・発射頻度/数

Aは、Total Nuumber of Particles というモードになっています。いっぺんにこの数のパーティクルを出せというモードですね。 なので、Bで Rate を 3500 と指定しているので、シミュレーションの頭で 3500 のパーティクルを1回発射しておしまいです。

ここでいきなり質問ですが、このモードで、複数回発射することはできるのでしょうかね?  ぴったり1秒おきに、正確に100個ずつ発射、とかそういう風にコントロールしたいんですよね。でもこの Total Nuumber of Particles って、1回しか発射できませんよね? このコンパウンドの一番上、Enable のオンオフをアニメーションすることはできますが、オフにしておいてオンにすると、そのタイミングで1回、Rate で指定した数のパーティクルが発射されます。 その後オフにして、またオンにするキーを打っても、もうパーティクルは発射されません。 これ、2回目以降を発射させる方法を知っているお方がいたら、どうか教えて下さい。 まさにこういう制御のために、エミッションシステムを自作しないとダメかなあと思っているのです。



Mass はどっかで影響しているかもしれないけど、よくわからんのでデフォルトの 0.1 のまま放置しています。色も後でいじるのでここは放置でいい。




・形

次、Shape は Sphere にしています。これは後で書きますが、最終的にはボリュームシェーダではなく、普通のサーフェスシェーダを使ったマテリアルをくれてやります。Phong とかそういうやつのことです。なので Sphere にしました。

ちなみにまた質問ですが、 Point のままレンダリングってちゃんとできるんでしょうか? ここがわかっとらんのです俺。 ほんとは Point = つまりただの「点」あるいは「光点」としてレンダしたかったりするんですけどね。 しかし Shape が Point の状態で、パーティクルサイズを少しでかくしてレンダしてみると、下半分の半円みたいな形でレンダされますよね・・・・?  ここら辺研究せねば・・・レガシーパーティクルはこの辺楽だったなあ。 っていうか、最も基礎的な研究を怠ったまま花火などを作ろうとしている己の傲慢さに腹が立ちますええ立ちますとも。



・State

Dは State ですね。このエミッションで生まれるパーティクルの State ID は 0 ですと言っているだけです。が、この後 Spawn Trails とかやるので、今自分がいじくっているパーティクルの State ID はいくつだ、と意識しておかないわけにはいきません。っていうか今回の花火プロジェクトは、1つの State だけで作れる花火は少ないので、常にそれを意識しながらやっていました。



・方向

Eは発射方向ですか。 0 ~ 180 だから半球状に発射されるのかと思いきや、全球状に発射されます。 すいません、この辺の意味が実はよくわかってません。しくみが分からなくてもいじくってみて思った通りになればいいやということでスルーしてますが、こういう態度が ICE の理解を遅らせていることは言うまでもありません。 しくみというか、理屈を知っている方、どうか教えて下さい。



Emit From Null コンパウンドは以上。
次に、先ほどのエミッション関係全体のツリーをもう1回。

Ice1


・FCurve を使って異端児をちょっとだけ混ぜる

Size や Speed をランダマイズしてますが、画像のA、Bのように Fcurve ノードをかまして、数値に偏りを持たせています。 ランダマイズするときに、「平均的な値から極端に外れた "異端児" を、ちょっとだけ出したい。ちょっとだけでいい。ちょっとじゃないと異端児にならない」 とかいう時によく使ってます。 速度の分布はだいたいこれくらいだけど、ごくたまにすんげえ速いやつがいて欲しい、とかそういう時です。ごくたまに、という所が重要です。 画像のように、途中でポキっと折れ曲がったリニアなFカーブにすることが多いのですが、これについてはまた別の機会に書きます。



・サイコロ振ってトレイル出すやつかどうか決める

Cの部分はですね、後に出てくるトレイルのための「サイコロ」みたいなつもりでやってみました。

Dで self.SpawnFlag という値をセットしていますね。これは勝手に作ったカスタムアトリビュートです。値の種類はブーリアン=つまり true/false です。 Cでサイコロを振って、ある値が出たときだけ、この SpawnFlag を true にする、というつもりでこうしています。

動画を見てもらうとわかりますが、全ての光球がトレイルを引いているわけではないですよね。全員にトレイルを引かせたら、もう画面がごちゃごちゃになってしまったわけです。美しくなかったわけですよ。 なのでトレイルを引かない光球も作りたかったというだけです。光球ごとにフラグをセットして、フラグが立っているの光球のみトレイルを発射させる、というしくみにしたかったのです。 

そしてこのサイコロ部分は Execute on Emit に刺しているので、光球が生まれた瞬間に1回だけサイコロが振られるはずです。 つまり、生まれた瞬間に1回振られたサイコロによってその光球はトレイル有りなのか無しなのかを運命付けられ、一度決まったらもう永遠に変わらないというしくみです。

サイコロはCです。1~20の乱数を発生させます。この時点ではスカラ値ですので Round を入れて整数にしてあげます。 そしてその値が 1 とイコールだった場合は、SpawnFlag に true をセットしています。それ以外の値だった場合は、false をセットしています。

つまり、1から20まで出る可能性があるサイコロを振って、1という数字が出たときのみ true にしているので、確立は20分の1ということになります。 結果、光球20個に1個の割合でトレイルを引くことになります。 あとで、実際にトレイルを発生させる仕込みをした後で、このサイコロがちゃんと機能しているか検証します。


ちなみに、こんなめんどくさいことするくらいならCloud を別にするというのが、正しいかも知れません。 トレイルを引くパーティクルを持つ Cloud と、トレイルを引かないパーティクルを持つ Cloud が別であってはいけない理由は、そんなにないのではないか。 レンダ時に何か問題あるかな。 まあ、少なくとも、このカットに限っては、1つの Cloud にこだわる意味はあまりありません。 にもかかわらずこうしているのは、やってみたかったというだけです。


・その他

あとは、Simulation Root にお約束の Simulate Particle が刺さっているのと、寿命が来たら死ぬように Delete Particle at Age Limit が刺さっているのと、State Machine が Execute に刺さっているだけですね。 State はメインの光球とトレイルの2種類あるので、この先の State Machine から2つに枝分かれします。




●光球State

次にメインの光球の挙動の制御部分です。
Ice2

・発射時からのツメっぽい動き

Aの FCurveノードとその前にある Get Particle Age Parcentage で、Drag の強さを調整していますね。 

これはどういうことかというと、Drag つまり減速というか、動きにブレーキをかけるフォースなわけですが、パーティクルが生まれてすぐ Drag の影響を受けるのではなく、生まれて少しの間は Drag の影響が少なく、しばらく経つと Drag の影響を大きく受ける、という感じにしたかったんです。 動きのスローダウンを、いわゆるツメの感じにしようとあがいた結果です。上手く行っているかどうかは微妙ですが・・・・。

仕組みを説明すると、まず、Get Particle Age Parcentage の挙動を理解せねばなりませんが、こいつはパーティクルの寿命に従って 0 から 1 の値を返します。つまり生まれたばかりのパーティクルは 0 で、死ぬときに 1 になります。 %なのに最大は 100 ではなく 1.0 なんですが、まあこれはこういうもんだと覚えると良いでしょう。この方が後で掛け算とかする場合に楽ですし。

それを Fcurve ノードに突っ込んで 0,0 から 1.0, 0.6 にマッピングしてますね。 ヨコが元のレンジ、タテが新しいレンジだと思えばいいと思います。 0, 0 で始まっているので Age% が 0 の時は結果の値も同じく 0 で、 1.0, 0.6 で終わっているから Age% が 1.0 になった時(つまり寿命を迎えた時)の結果の値は 0.6 になるようにリマップというかリスケールというか Change Range というか、しているわけです。

その値を、Drag の Strength(強さ)に突っ込んでいる。 つまり、誕生した時点では Drag の影響はゼロで、寿命が進むにつれ Drag の影響が大きくなって行き(つまり減速して行き)、最後には 0.6 という強さで Drag の影響を受けている状態で死ぬことになります。 ただし、FCurve の形を見ると最初の方でグイっと上がっていますので、Drag の影響をあまり受けないのは誕生後ほんのわずかな時間でしかなく、すぐに大きく(最大値である 0.6 に近い値の)Drag の影響を受け始めることになります。

こうして、誕生時だけクイックですぐにスローダウンするという、いわゆるツメっぽい挙動を、Drag の Strength にキーを打つなどパーティクル全体にグローバルな影響を与える荒業を使うことなく、パーティクル個々の寿命を基準にプロシージャルに作れないだろうか、という実験みたいなものです。 もっと研究が必要ですかね。 結果的には、いわゆるツメの動きにはなっていません。 調整していくうちにこれで落ち着いちゃったという。 まあいいや。


・重力の影響にバラつき

Bで -0.5 から -1 までの乱数を発生させ、それを Gravity の Y にぶち込んでますね。 光球が重力によって落ちていくその重力の強さにバラつきが欲しかったんだと思います。たぶん、トレイルの美しさのためだったのだと思います。

今見てみると、Min と Max が逆じゃねえか? -0.5 より -1 の方が小さいのに、なんで -1 の方が Max になってんだ? と思うんだがまあいいや。


・レンダのために独自透明度アトリビュート設定

Cの部分ですが、self.TranspFucker という独自アトリビュート(スカラ)をセットしています。 まず Age% を取得し、その値を FCurve でいじった結果が TranspFucker になってます。これは、後に RenderTree で取得して、Transparency つまり透明度にするためにやっています。

FCurve は 0, 0 から 1.0, 1.0 までになってますね。 Age% の値は 0~1.0 で、Transparency も 0~1.0 だから、レンジは変えてないことになります。 つまり、生まれたてのパーティクルは 0 という値が返るので、Transparency がゼロになり、つまり透明度ゼロ、イコール不透明度100というやつで、要は何も透けてない全部見えるパーティクルだということです。 寿命が尽きるときには 1.0 になるので、全透明になる=見えなくなるということです。 この辺の処理は RenderTree で値をどう扱うかの話なので、後でシェーダの話をする時にまた出します。 

で、FCurve を画像のような形にすることによって、生まれてしばらくは透明度があまり上がらない、寿命が尽きる直前になると急に透明度が上がる、という状態にしています。 リニアにしてしまうと生まれてすぐに半透明になってしまうのが嫌で、死ぬ直前までよく見えている、死ぬ直前から消え始める、という風にしたかったのです。



・色は3種類

Dでまたサイコロ振ってますね。 でもさっきは Round 使ってたのに、今度は最初から整数が出るサイコロになってるな。 Select Case につないだから整数型に変わったのかな。よくわからん。

まあいいや、進めましょう。 PPG を見るとわかるように、このサイコロは 0 から 2 の値を出します。 0, 1, 2 の3種類の値を採り得ると言うことです。そして Select CaseCondition に結果をぶち込んでいます。 Select Case は、Condition の値が 0 ならこれしろ、1 ならこれしろ、という条件分岐のノードですね。 JSctipt で言う switch みたいな。

で、サイコロの結果によって、3種類の Modify Particle Color を突っ込んでいます。PPG は表示していませんが、この3つの Modify Particle Color は、いずれも寿命に応じてパーティクルの色がグラデーションで変化するようにしてあります。そのグラデの色を3つで微妙に変えてあります。

つまり、サイコロ振って、0 だったらこの寿命に従ってこのグラデで色変われ、1 だったら同じく寿命に従って、でもこっちのグラデで色変われ、と指令していることになります。 色に少しバリエーションがあった方が良かろうと思っただけです。




・トレイル発射


次にEですが、さっきサイコロ振ってセットした SpawnFlag をまずはゲットしています。そして if ノードを使って、SpawnFlag が true だった場合のみ、Spawn Trails コンパウンドが実行されるようにしています。 独自に作ったアトリビュートである SpawnFlag をいよいよ使うときが来たということですね。

光球1個生まれるごとにサイコロを振って、その結果でトレイルの有無を決めるというこのシステム、ちゃんと正しく動いているかどうか一応確認してみました。サイコロが出した値を round した後の整数と、結果である true/false を Show Value で表示させ、見やすくするためにエミッションの数を減らしました。
Saikoroshowvalue1

緑がサイコロが出した値、ピンクが結果である true/false です。 これを見ると、サイコロの値=緑が 11 とか 13 とか 18 とかの場合、結果=ピンクは 0 になってますよね。そしてトレイルを引いていません。

トレイルになっている部分の先端にズームしてみると、
Saikoroshowvalue2

ど頭のパーティクル、つまり最初のエミッションで生まれたメインの光球は緑もピンクも1です。つまり、サイコロ(緑)で1が出たので、結果は true になり(= true は数字で言うと1)、そして結果が true だからトレイルを引いているという状態ですね。 なんか上手く機能しているように見えます。

ちなみにこの画像を見ると、どうやら、メイン光玉だけではなくトレイルの方のパーティクルに対してもこの SpawnFlag の評価がされているように見えますね。0,0 と表示されているから。 たぶん無駄だと思います。メインの光玉に対してトレイルを持たせるかどうかのフラグなんだから、結果として出てきたトレイルのパーティクルがこのフラグを持つ意味はありません。この計算をさせなくすることができればシミュレーションが速くなる気がするのですが、どうでしょう。あるいは Show Value のために出てきただけであって、実際は計算されてないなんてことはあり得るかしら。




・ちかちか

花火っぽさの重要な要素として、玉の「チカチカ感」って言うんですか、明滅というか、そういうものがあると思うんですが、それをやろうとしたのがFですね。メイン光球のサイズをチカチカと大きくしたり小さくしたりすることで、そんな感じにしようとしています。

やっていることは、現在のパーティクルサイズをゲットして、そこにランダム値を掛けて、セットし直してますが、正直これ、失敗でした。どんどんでかくなって収拾が付かなくなるやつとかが出てきたので。 なので現在のパーティクルサイズなどゲットせずに、普通にレンジを決めてランダムしてやる方が良い気がしています。他のカットではそんな風にしていたかも知れません。




●トレイル State

次に、さっきのメイン光球から発射されたトレイルの挙動です。
Ice3

・寿命の進行に合わせてタービュランス

Aの部分なんですが、さっき出てきた寿命が進むに連れて Drag の影響を強く受けるというしくみと同じようなものですね。 今回の場合は、Turbulize ですが。

画像のように、Turbulize Aroud Value を使っていて、Base Value は 0, 0, 0 です。Variance にAからのツリーをつないでいます。 またもや Age% ですね。 つまり、基本的にトレイルのパーティクルはタービュランスの影響を与えたい。基点はゼロで、タービュランスのプラスマイナスの差を1つの固定値ではなく寿命が影響したものにしたい。 ということです。

具体的には、生まれてすぐはタービュランスの影響をあまり受けたくない、寿命が進むにつれてタービュランスの影響を強く受けるようにしたい、ということです。 なぜかと言うと、トレイルがすぐにタービュランスでかき乱されてしまったのでは、やはり画面がゴチャゴチャになって美しくなかったからです。 生まれてしばらくの間はメインの光球の軌跡に見えるようにその場にとどまり、だんだんと気流に乱されて崩れていくという風にしたかったわけですよ。

てことで、Bを見てみると 0.1 です。 基本的に、タービュランスは 0, 0, 0 に対してプラスマイナス 0.1 にしたい(プラマイ0.1が最大値)という意味です。ただし、上に書いたようにいきなり最大値になるのではなく、寿命が尽きたときに最大値になっていて欲しいわけであり、生まれてからしばらくの間は弱い方が良い。

Get Perticle Age% は上で書いたように 0 から 1.0 の値を返しますから、それを最大値である 0.1 に掛け算するのが最も手っ取り早いですね。 生まれてすぐの頃は 0.1 x 0 や 0.1 x 0.02 などという計算になるので、結果は 0 や 0.002 ということになり、タービュランスの影響は皆無もしくはほとんど受けていないということになります。

寿命が尽きる頃には Get Perticle Age% の値は 0.9 や 1.0 を返すわけなので、0.1 x 0.9 = 0.09 や 0.1 x 1.0 = 0.1 という計算になり、自分で最大値と決めた 0.1 というタービュランスの値に近いもしくは同一の結果になります。

Fカーブはその中間をコントロールしているわけですが、見てみるとほとんどリニアと変わらない形になってますね。 今回の場合はたまたま、調整していたらリニアに近いくらいがちょうど良かったんでしょうね。

ってことで、動画を見てもらうとわかりますが、メインの光球が空間に残していったトレイルは、しばらくの間はあまり動かず、結果「軌跡」のように見えて、でも時間が経つにつれ段々とタービュランスで乱されていっているのがわかると思います。


・色

特筆すべきこともないですね。ご覧のように Modify Particle Color コンパウンドを Age% モードで使っているというだけです。 トレイルパーティクルの個々の寿命に応じて、このグラデで色が変化しますというだけです。





### RenderTree編


・Color Pass

上記のような Point Cloud に対して組んだ RenderTree はこれです。
Rendertree1

色は Color Attribute で取って来ているので、ICETree で決めた色が反映されています。

Mix2colors で同じ色を加算で混ぜてますね。Incidence を使って、中心部分に光の「芯」ができるようにしたのだと思います。

エッジはボケていたいので、やはり Incidence を使い、Transparency に突っ込んで半透明にしていますね。 で、寿命に従いだんだん透明になって行くために、上記の TranspFukcer をここでゲットして、Incidence の値に加算しています。TranspFukcer は上で書いた通り、FCurve でいじっていはいるものの、基本的には生まれてすぐは 0、死ぬときに 1.0 になる値です。つまり、最初は Incidence の値に 0 が加算されるので Incidence の値そのまんまが Transparency に入っていきます。 だんだん加算される数値が増え、最後には 1.0 が加算されるので、たとえ Incidence で 0 だった部分でさえも 1 になり、結果 Transparency = 1 つまり全透明、つまり見えない、つまり消えた、ということになっているはずです。

Particle Age% を Attribute の Scalar でゲットするのが最も素直かとは思いますが、これだと生まれた直後からもう透明に向かって消え始めてしまうわけで、それは嫌なので(しばらくは全く消えずにいたいので)、FCurve を挟んで TranspFucker というカスタムアトリビュートにし、そちらを参照してレンダ時の Transparency を決定しているということになります。


Constant シェーダ使ってますし、ライティングは関係ないツリーですね。なのでシーンにはライトが存在すらしていません。



・Depath Pass

上の RenderTree はメインの Pass( Color Pass )のマテリアルですが、もうひとつ、ポスト処理でのレンズボケ用に Depth Pass を用意しています。

その RenderTree。
Rendertree_depth_2

俺は大抵の場合、デプスは Scalar State の RayLength を白黒に変換してやっているのですが、このやり方だと Primary Ray の長さしか考慮されないわけで、今回のように Transparency を使っているとよろしくありません。 本当は透けて向こうが見えているのに、透けてないデプスの絵ができてしまうということです。おそらくはこれが原因で、ポスト処理でレンズボケをかました時に汚いエッジが出ました。これはまた別の記事で書きます。 他のショットではぶっちゃけ、汚いエッジのままでもバレなかったので放置していたりもするんですが、このショットだけはバレバレだったので、Transparency も考慮に入れたデプス素材を作らざるを得ませんでした。

ということで Depth Pass では、表面色を ICETree から取って来るのではなく白単色にして、 Transparency は Color Pass と同じ設定の Incidence を使い、Pass に Volume Fog を設定して黒を指定し、白いパーティクルがカメラから遠くに行くほど黒になるという状態にしています。



以上、Color Pass と Depth Pass をレンダし、AE で合成しました。背景は2Dの静止画を AE上で合成したようです。 コンポジットはまた別記事で書きます。たぶん。

他のショットもまあ、似たような構造、というかほとんど同じ構造で成り立っています。あまり手広く実験できませんでしたね。


たぶん続く。



.

| | コメント (5) | トラックバック (0)

2011年10月15日 (土)

起動画面。

某所で話をしていたので、一応アップしておきます。
XSI の起動画面を変える方法。


嘔吐デスク様のこのページに書いてあります。
http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=13834108&linkID=12544120



ほぼそのまんま引用しますが、
2つ方法があって、

  1.指定の場所に指定の名前の画像を置いておく
  2.setenv.bat で、任意の場所にある任意の名前の画像を指定する

のどちらかでやることになりますね。






1の場合、

%SI_HOME% フォルダに、splash.bmp という名前で bmp フォーマットの画像を置けば良いことになります。
 
%SI_HOME%ってのは、例えば C:\Program Files\Autodesk\Softimage 2011 Subscription Advantage Pack SP1 フォルダですね。 つまりそのバージョンの XSI がインストールされている最もルートのフォルダです。

ファイル名は splash.bmp じゃないと認識されません。
画像のフォーマットは bmp でなければいけません。



・・・・・XSI のこの bmp の制限、いい加減どうにかならんかね。昔からこうだよな。ボタンの画像も bmp じゃないといけないんだよな。普通に jpeg とか PNG とか使わせろやドルァ







2の場合、


setenv.bat の中に1行、自分で書き足すことになります。

例えば、

  set XSI_SPLASH=C:\MyFuckingFolder\MyFuckingXSIStartupScreen.bmp

などと書き足します。 setenv.bat の中のどの行でもいいのですが、自分でいじった箇所を分かりやすくする為に、俺は一番最後に書き足しています。


こちらのやり方でやった場合は、画像を置いておくフォルダも任意ですし、ファイル名も任意です。 ただし画像フォーマットは、やはり bmp でなければいけません。





ちなみに setenv.bat は、XSI を起動するときに最初に実行されなければいけない Windows の bat ファイルですね。 ここに書かれているもろもろの環境設定を済ませないと XSI は正しく動きません。 XSI に付属のコマンドプロンプトからではなく、Windows標準のコマンドプロンプトから xsi コマンドで起動しようとしてもダメなのは、これが理由です。 これを知らなかった頃はコマンドラインのレンダを起動できなくて困りましたよ。 一方 XSI 付属のコマンドプロンプトは、先にこの setenv.bat を経由してからプロンプトを立ち上げる方式になっているので、そのプロンプトからは正しく XSI が起動できるわけですね。



で、setenv.bat の在り処ですが、例えば

  C:\Program Files\Autodesk\Softimage 2012\Application\bin

など、アプリケーションそのもののインストールフォルダ(実行形式のファイルを収めた bin フォルダ) にあります。  

俺はいつもこのフォルダに潜って行って setenv.bat をメモ帳などでいじってしまいますが、UserTools を起動していじることもできますね。

Usertools

でも別に便利でもなんでもないので、まあ、俺は手で潜っていきます。










ちゅうことで、俺はいくつかのバージョンで起動画面を変えています。

Splash

別にただの気分ですがね。
XSI 4 や 5 の起動画面が好きですね。
7 も。

歴代の起動画面の画像は、ここら辺でゲットします。
http://xsisupport.wordpress.com/2011/03/18/friday-flashback-10/


眠気覚ましのためにフード野郎の起動画面をあえて設定しようと思うこともあるのですが、嫌悪感が先立っていまだ実行できていません。 Mr. Hoodie って書いてますね。フードさん、ってところですか。 けっ。 フード野郎で十分です。


あ、SI|3D の起動画像が欲しいなあ。 4.0 のは上のサイトにありますが、俺は 3.8 止まりで XSI に行ったので、その画像は知りません。 3.8くらいまでのあの起動画像が欲しい。



そういえば、なんか最近、起動画面が見えている時間が短くなったと思いませんか? アプリケーションはまだ起動し切ってないのに、起動画面は割と早めに消えてしまって、グレーっぽい画面が長く続く感じです。これじゃ意味ねえんだけどなあ。 64bit になったりマシンが速くなったりして、起動時間が短縮されたからなのかなあ。





2010以降の起動画面は、もう、死刑ですね。

嘔吐デスク帝國に侵略されてしまったのだから、仕方のないことですけどね。

まあどうでもいい。

ちゃんと落ちずに動いてくれれば起動画面なんてどうでもいい。

ちゃんと落ちずに動いてくれれば。




.

| | コメント (4) | トラックバック (0)

2011年10月13日 (木)

やっと第2次の会計報告。 そして3次。

すすすすすすいません! 
大変なことを忘れていました。



XSI男花火云々などと書いていて思い出しました。

以前行った、福島復興支援XSI男Tシャツ次募集の寄付を、実行していませんでした。

すんげえ時間が経っているのに、
大変申し訳ないです!!!

orz 
orz  orz 




花火なんて作っている場合じゃなかった。 最も大事なことを忘れていました。 ちょうどその時期から仕事が忙しくなったりと、もろもろ忙殺されていたのですが、そんなことは何の言い訳にもなりません。 寄付に行かなくては行かなくてはと思いながらも、だらしなく順延しているうちに忘れていた、というのが真実であります。 ほんと、だらしない人間ですいません orz




ということで、今日、寄付を実行して来ました。
会計報告をします。


第2次募集では、自分の分も含め、合計24枚の発注を承りました。
1枚 3,500円での販売ですので、 3,500 x 24 = 84,000円の売り上げになりました。



Tシャツ製作のアートスペースさんに支払った金額は、24,690円です。

その内訳は、


  Tシャツ代(ユナイテッドアスレ5.6oz  640円×24枚=15,360円
  プリント代(胸1色)320円×24枚=7,680円
  袋詰め 25円×24枚=600円
  送料 1,050円
  ---------------------------------------------------
  合計 24,690円



↓アートスペースさんからの領収書がこれです。
Img_0036

Tシャツの枚数が57枚となっていますがこれは24枚の間違いです。 第1回の枚数が57枚だったので、アートスペースさんが前回分と混同して間違えて記入しちゃっただけだと思います。金額の 24,690円は合っていますので問題ないです。アートスペースさんには実際この金額しか払ってませんし。

ということで、総売り上げからTシャツ作製のコストを差し引いて、

  84,000 - 24,690 = 59,310円

が、今回の寄付額になります。 イエイ。



これを、本日2011年10月13日、郵便局にて、福島県災害対策本部に寄付して来ました。

↓その受領証です。
Img_0035



前回、第1次の時の寄付額は、142,915円でした。

今回の 59,310円をプラスして、合計 202,225円を、福島県に寄付できたことになります。 

皆様のおかげです (゚∀゚)

本当にありがとうございました (゚∀゚)

全力で感謝いたします (゚∀゚)







ちなみに今回の1枚あたりの作製コストは、 24,690 ÷ 24 = 約1029円 ということになり、前回の 992円 よりは少し高く付きました。でも思ったほどではなかったですね。

ただし、今回の第2次発注は、第1次の時から3ヶ月以内の発注だったため版が残っており、製版代 5,000円が全くかからなかったというのが大きいと思います。 もし次をやるとなると、すでに最初の製版から3ヶ月以上経過しているため版は破棄されているはずで、たとえ同じ図柄でも新たに製版代が 5,000円かかるはずだと思います。




では第3回目をやるのかというと、やりたい。
というのは、第2次の募集が終わった後、この夏以降の呑み会などで、このTシャツが欲しいと言ってくれる人がまたチラホラ出てきたからです。

10枚以上集まるならやるべきだと思っています。 たしか10枚以下だとかなり割高になってしまうので、3,500円の販売価格を維持しようとすると、たぶん寄付額が極端に少なくなってしまうんですよね。 なので10枚の注文を目安に、やろうかと思います。



一部の人には8月とか9月に第3回をやりたいとか言ってあったのに、お待たせしてすいません。 っていうかもう待ってないですか。 時間が経っちゃって、もうどうでもよくなっちゃいましたか。 

そんなこと言わないで下さいよ (TдT)

震災はまだ終わってねえんスよ (ノД`)



もともとこの XSI男Tシャツプロジェクトをやろうと思うに至ったきっかけである、浪江に住んでいた俺の友人夫婦は、どうやら2回目の一時立ち入りが政府から許可されたようで、今月末、避難先の愛知から故郷の浪江の家に戻って、荷物などを運び出すそうです。もちろん防護服に身を固めて。

第1回目の立ち入りの時は、家は倒壊してないけど屋根が傷みまくっていて、雨漏りがひどくて家全体の損傷が進んでいたという話を、携帯メールで本人から聞きました。 ちなみにこの家は原発からだいたい 15~16km の地点ですね。 しかも北西なので、放射線量が一番高かった方向だと思います。 海からは離れているので津波は大丈夫でした。
 
しかしこの彼の同級生の男が、同じく浪江町内で、江戸時代から代々続く酒蔵を継いで杜氏をやっていたんですが、蔵が海の目の前にあったために、津波に全部持っていかれてしまいました。原発からは真北に 6km の地点です。 俺もこの蔵に過去2回訪れて彼と話をしましたが、クソが付くくらい真面目な酒造り職人でしたよ。 蔵を見学させてもらい、色んな話を聞いて、わあ、これぞ職人気質だなあ、俺より若いのにすごいなあ、俺はここまで真面目にCG作ってねえなあ、などと思いました。 

幸い一家全員津波から逃げたので命は助かって、今では同じく福島県内有数の酒処である会津で蔵を借りて、もう今酒造年度の酒を作っています。一部は既に出荷したはずだと思う。そしてちょうど今頃から新米による本格的な酒造シーズンなので、これから忙しくなることでしょう。まだ簡単に買えないと思うんだけど、数がある程度出回るようになってきたら、もちろん俺も買いますよ彼の酒を。 美味いのは知ってるし。

実は2本、ストックしてあります。震災後、しばらくは、あるいは永遠に彼の酒が吞めなくなるかもしれないと思ったので、2本だけストックしてあるのです。 彼の作った新しい酒が普通に買えるようになるまでは、この2本の酒は開けません。





この浪江の2家族が、俺個人にとっては最も身近な被災者なのかな。



それ以外では、大学の先輩一家が宮城県の気仙沼で被災しました。

↓これ、その先輩の家です。 ケータイメールに添付されて来た写真です。
Dvc00100

いやあ・・・・もう・・・・・、家そのものが流されずに良かったねえ、っていうか一家全員、命が流されなくて良かったねえ、と思いますよほんと。ひでえ惨状です。 この家屋はどうなったんだろう。その後住めているのかな。電話して聞いてみようかな。

この先輩には、俺の同級生が音頭を取って義捐金集めをやってくれたので、俺もそれに乗ってわずかではありますが現金を送りました。 ほんとは We pray for Miyagi もやらねばならんのですが、なかなかね。

この先輩の職場は水産加工会社なのですが、津波で流されました。倒産したかどうかは知らないけど、先輩は解雇されたそうです。そりゃ止むを得んですわな。 新しい職を見つけられたのかどうかは、まだ知りません。




あとは、旅先で知り合った友達が岩手の人間で、震災後しばらく連絡が取れずに心配しました。メールとかはもちろん、Google Person Finder も使ってずっと探していたんですが、ええといつだっけ、たぶん地震当日から2週間だか3週間後だかに俺のケータイに電話をくれましてね。 「生ぎてるよ!  職場と愛車が津波に流されだけど、命は助かったがら!」 と言ってましたね。 彼女は今も元気に仕事してるんだろうか。また電話してみないとな。 We pray for Iwate も必要になってしまうな・・・・ ううむ・・・・・。




とまあ、俺の周りの被災者の話ばかりしてしまいましたが、ともかくですね、連中は今も被災を続けているわけでしてね、まだまだ全然終わらないわけですよ。 俺なんか、直接的な支援としては金を出すくらいしかできなくて、でも金持ちじゃないのでドカンとまとまった金額を寄付するのは難しく、やはりこうして皆さんに協力を呼びかけるしかないわけです。 金が全てではないけれど、連中に金が必要なことは事実ですしね。 宮城も岩手も茨城も千葉も、と手を広げる力は俺にはありませんが、まずはできることからということで、細々と福島を支援したいっス。


まあ、あの、あんまりカッコつけたことを言うような真似はしたくないし全然本意ではないので、この辺でやめておきますが、まあ、協力してくれる人とか、協力なんてどうでもいいけど XSI男Tシャツを着てみたい人とかいましたら、どうかいつでも連絡を下さい。






ということで、ローリングスタート的に、ダラダラと募集を開始します。
今、第3次募集スタートしました。


いずれ期限を決めますが、今すぐは決めませんので、福島復興支援XSI男Tシャツを 3,500円で買ってくれるというお方は、まずは連絡を下さいませ。 集まり方を見て、締め切りなどを決めようと思います。

このブログにコメントして頂くか、
junkithejunkie あっとぉ gmail どっとぉ 混む
まで連絡を下さい。
もちろんそれ以外の連絡手段でもかまいません。


Tシャツの仕様は変えないつもりですし、募集要項も特に変えるつもりはありません。 なので、この2次募集の時の記事を読んでもらえれば、だいたいわかると思います。

質問があればどうか遠慮なくお願いします。個別にメールで質問でもかまいません。


ちなみに災害対策本部に寄付されたお金の用途は、被災者への分配です。インフラの再建などに使われることはなく、被災者への直接の分配金になるはずです。






XSI の代理店様、次のキャンペーンでこのTシャツを XSI にバンドルするなんていかがですかね? きっと売り上げが上がりますよ! 1本の売り上げにつき 3,500円を俺に預けてくれれば、Tシャツと引き換えに、俺が責任持って福島に届けますよ!

震災で家屋やオフィスがかなりやられたから、空調設備なんかの需要も高まるよなあ。福島へTシャツで支援をする空調屋。 いい宣伝の機会かもなあ。



あちらの某社様が10枚くらい買ってくれて、例の専門雑誌の読者プレゼントにするなんてのはどうかなあ。 それを読んで感動した福島の少年が、俺もCG屋になる! とか言ってこの業界に入ってきてくれるなら、俺は必死で止め歓迎します。



うむ、なら、いっそのこと嘔吐デスク様が。





いやいやいやいや、こんな風に大手を巻き込もうとしてもダメですねそうですね。
草の根活動ですからね。
まあどうでもいいや。
お金さえ寄付できれば。

ともかくよろしくお願い致します(゚∀゚)








そういえば、このTシャツを社員の制服にしてしまったあの会社は、どうなったかなあ・・・。 会社宛に送ったんだが、皆さんに無事行き渡ったかなあ・・・・・ ボソッ




.

| | コメント (0) | トラックバック (0)

2011年10月11日 (火)

夜空に散るXSI男。

「パーティキュラー花火大会」というCGコンテストのようなイベントがありましてね。

ちょっとやってみたくなって、応募したんですよ。

そしたら、1等賞もらっちゃいました (゚∀゚;)





パーティキュラー花火大会2011 応募作品 : We pray for Fukushima






ううむ、Youtube も Vimeo も画質は変わらないくらい悪いな。 両方とも全く同じ動画です。

今回の場合は絵の性質上、階調とか大事なので、できれば高画質で見てもらいたいと思うんですが、まあそんなこと思っているのは作った本人だけで、見る側はどーでもいいですよねえ。 ええ、わかってますよ。

Vimeo の方は動画の右下あたりに Download this video というリンクがあり、たぶん1週間くらいはオリジナルの QuickTime ムービーがダウンロードできます。もしかしたら Vimeo の会員登録が必要かも知れません。 そのムービーすら mp4 ですので圧縮による画質劣化はあるのですが、ストリーミングされる動画より断然画質が良いので、興味のあるお方はそちらをダウンロードしてお手持ちの QuickTimeプレーヤなどで見て頂けると嬉しいです。 XSI男が夜空に散ります。パァっ、と。







このコンテストは、もともとは AfterEffects のプラグインである Trapcode Particular を使ったバーチャル花火映像のコンテストという趣旨だったように見えますが、作品の募集要綱を読むとパーティキュラーを使わなくとも良い、使用ソフトウェアは何でも良い、という意味のことが書かれていたんですね。 じゃあ、XSI で作ってもいいってことでしょ。 花火映像なら、ICE の勉強にちょうど良さそうじゃないか。 って思いますよね。普通。



折りしも進行中のプロジェクトが終わりに近づいていた時期だったので、数日後からは本腰入れて作れるなと思い、急遽実験を始めました。 いや、実験とも言えないくらいの、ひとりブレストとでも言うか、アイデア出しとでもいうか。

で、その勢いのまま、完成まで、びっくりするくらいただの思いつきと言うか、完全に行き当たりばったりで作り進めましてね。 脚本無し。 コンテ無し。 構想無し。 あるのは時間と妄想だけでした。

でもその妄想ですら、行き当たりばったりで頭に浮かぶものに従ったというだけです。その場その場で無作為に頭に浮かぶ妄想のカケラを、自力で ICE に落とし込める程度まで劣化させて、なんとなく動いているベアな素材を2つか3つくらい作り、ショットの順番も何も決まらないまま AfterEffects のタイムラインにぶち込みます。

それをなんとなく RAM プレビューで眺めているうちに、「ああ、なんか音楽があるといいんじゃねえの」 とか、「変にウケを狙うより綺麗系で行く方がこの短い時間でまとまりそうだぞ」 とか、「ボケだよなやっぱり。暗い背景に光球だから、Bokeh だけで引っ張れる気がする」とか、頭の中に囁きが聞こえてくるので、素直にそれに従います。 でも尺もカット割りも何も決めません。そもそもどういう花火が出てくるかとか、どんな順番でどう見せるとか、なんにも決めません。これらが最終的に決まったのは、最後の2日間くらいだったでしょうかね。 白状しますが、主役のように見える XSI男花火ですら、出そうと決めたのはたぶん締め切りの2日前くらいです。 しかも数時間のテストで上手く行かなかったら、綺麗さっぱり忘れて、もっと別の、作りやすい花火にしていたことでしょう。



こんな感じで実にいい加減に作業を進め、プロダクション期間としては1週間弱で作りました。最後の2日間くらいは徹夜に近い状態になりましたが。

プリプロと言えないくらいの上記の実験は、ファイルのタイムスタンプを見ると9月22日とかになってますね。締め切りの11日前くらいか。 で、カットらしきものを作り始めたのが9月27日のようです。締め切りの6日前。その時やっていたプロジェクトを納品した直後です。プリプロはほんのちょっとだけなので、実質はこの6日間だか7日間だかで詰め込んでやってますね。それくらい無計画だったということです。






音楽は Apple の Garage Band を使って自作しました。このソフトウェア、すごいですよねえ。 前にも1回使ったことがあって、やはり急ぎで音楽が必要だったんですが、初めて使うというのに5時間だか6時間だかでなんとなく音楽が出来てしまうんですね。

しかもやってることはドラッグ&ドロップだけですよ。既存の音楽フレーズのパーツを並べるだけ。しかも楽器やムードを検索ワードのように入れるとそれっぽいプリセットが出てくるので、素直にそれに従って選ぶだけです。「ピアノ」 「しっとり」 とか。

こうして約30分で音楽ができました。30分ですよ。ほんとですってば。 まあ、DTM に凝っている人とかプロの人が聴いたら音楽とも言えないくらいのちゃんちゃらおかしいモノでしょうが、俺には十分です。 たった30分で出来る、という言い方もできるけど、正直に言えば、時間をかける気がしないので30分でやめたけど十分満足した、という感じでしょうかね。 ピアノ2トラック、パーカッション1トラック。 十分です。

Garage Band から書き出した音楽ファイルのスタンプを見ると、9月27日の 21:45 になっています。締め切りまで5日とちょっとです。 でも音楽さえできてしまえば大丈夫! 俺にとってはこのBGMがコンテのようでもあり、タイムシートのようでもあります。 もともと花火らしき要素を次々に脈略無く出して行くくらいしかやるつもりがなかったので、骨子になる音楽が出来ちまえばあとは音に合わせてそれらしくデッチ上げるのみです。 小節の切れ目がショットの切れ目になり、拍のタイミングがエミッションタイミングになり、音楽の尺が作品の尺になります。もともと大会規定で10秒から1分前後くらいの尺にせよとあるので、そしてスローテンポな曲にしているので、そんなに多くの音楽パーツは必要ありません。 こうしてデッチ上げた曲が、本当に作品の背骨になりました。 これ以降は曲に素直に従うだけなので、あまり迷わない。楽ちんです。




残り3日を切ったくらいから、やべえ、これは本格的に間に合わねえぞ、と思い始めて、すごくドキドキしましたね。 レンダ時間と自分の体力も考慮に入れねばなりません。なんせマシンは1台しか持っていません。作業マシンがイコールレンダリングマシンです。そのためメシを食う、寝るなどのタイミングに正確にレンダをぶつける必要がありました。また、体力を計算して、今寝ないで夜まで作業するのは絶対無理だから、ならあと30分だけ頑張ってあのショットのレンダを仕込んでから寝よう。2時間半寝れば復活するはずだ。たとえレンダの方が早く終わることが予想されても、無理して早く起きようとはしない。それをやると最後の12時間を走れなくなる。落ち着け。大丈夫だ。 とかなんとか。

最後2日間はこんな状況ですから、妄想はどんどん劣化させましたよ。 ほんとはこんな感じの絵が頭に浮かんだけど、マトモに作っていると間に合わないからこの要素だけ拾ってしまえ~、レンダも分けなくていいぜ~、ほんとは AE で StarGlow かます時に元の色ごとに別レイヤになってた方がいじりやすいけど気にしないぜ~、AE上でどんどんキーフレーム打ってショット内でもその時その時に都合のいい状態を作り出すぜ~、後戻りしねえぜ~ とか。ものすごい勢いで妥協します。

半分以上のショットはテイク1だと思います。 つまり一度も修正を入れていない。 最初にレンダした素材のままゴリ押しです。 アンチエイリアスがどうしたとか、ボケのデプス素材で Transparency を考慮に入れてないから汚いエッジになったとか、そういう技術的なチョンボも鬼のようにしてますよ。でも気にしない。 AE のエフェクトでごまかしたり、目線がなるべく画面の中心部分以外に行かないように仕向けたり。 ごまかしてすらいない場所もいっぱいあります。つまり問題が露呈しているのにそのまま放置。 いいんです。 そんなの、俺以外の人は気にしないんだから。


こうして妥協しまくって作りましたが、俺は大丈夫です。 世の中には妥協=死という人もいるそうですが、俺は幸い、映像に妥協するくらいで死ぬこともなければ、妥協したことを死ぬまで後悔し続けることもない程度には強い精神を持っています。 実は妥協したとか、ほんとは直すべきだと自分でわかっていながら直さなかった仕事なんて、正直に言いますが俺はそんなんばっかりですよ。金もらってやっている仕事すら、妥協のオンパレードです。 っていうか金もらっている仕事の方が妥協が多いかもしれませんね。 開き直ってすいません。 でもこれは俺にとっては揺るぎない真実、ごまかしようのない事実なので、こんな風に広言するような話ではないしそれどころか妥協を一切しないことを広言する人よりよっぽどイタい野郎に見えるかもしれませんが、今回たまたま1位を頂いた行きがかり上、事実は事実のまま白状しておくしかないという心境なんですよね、今は。 すいません、どうでもいいか。





こうしてなんとかデッチ上げ、締め切りである10月3日の朝8時くらいに提出しました。 3日の23時59分が締め切りだったので、あと16時間くらいあったのですが、そこでやめてしまうあたりが俺らしいですね。 提出の手間を差し引いても、12~13時間はあったはずです。そんだけ時間があれば2~3ショットをレンダリングし直したり、なんなら妥協して作成を中止したショットを復活させることもできたと思うんですが、ここ2日くらいはあんまり寝てないし、当初思っていたよりはゴージャスな感じになったのでまあいいや~ 寝よう~ ということにしたのです。 朝の8時から吞むビールは美味かった。


ちなみに花火パーティクルの動きは ICE で作っていますが、あと色の変化や大きさの変化なども ICE によるものですが、色や質感は AE 上でヘビーにいじっています。っていうかそれ前提。 XSI から美しい光モノをまんまレンダできるとは思えない。 Trapcode StarGlow 様と、frischluft Lenscare 様のお力を大いに借りています。







大会当日は長野県の山の中の屋外で星を見ながら酒を呑んでいたので、花火大会の Ustream中継は見れませんでした。 でも携帯の電波が届いたので、スマホではない普通の携帯でツイッターを見てみたのですが、やっぱ携帯で途切れ途切れに見ているだけでは状況がよくわからず。 しかし近しい人が俺に「優勝おめでとう」とか言ってくるのを断続的に見てアセりました。その後、少しまとめて情報を見て、1等賞を頂いたということを理解しました。2日後に帰宅してみると、主催者の方からその旨メールが来ていたので、真実だと確認しました。




1位の賞品は、
Mac Book Air の 11インチだそうで
(゚∀゚;)
すげえ (゚∀゚;)
超ありがとうございます (゚∀゚;)
そんないいものをもらえる賞をもらえたのが光栄です (゚∀゚;)






しかしですね。。。。。





俺、9月初旬に、Mac Book Air の 13インチを買ったばかりなのですよ。
しかもメモリはフル搭載の 4GB。
SSD もフル搭載の 256GB。
CPU もフルスペックな i7

キーボードは自分の好みで US。


というわけで、すでに最大スペック状態の MBA を持っているのですよ。。。 今回頂けることになった MBA の方が勝っている点は唯一、小さい/軽いことだけか。

むむむ。2台持っていても使い分けしようがなさそうだしなあ。

ぶっちゃけ、Form とか Optical Flares が欲しかったなあ (・∀・)







さて、あとは技術的な話を書くかどうか。
せっかく賞もらったし、書きたいんだよな。
賞もらったから書くモチベーションが続くとでも言うか。


そういえば長らく賞とか、そういうものに縁が無かったなあ。
昔から俺、仕事でも趣味でもスポーツでも、栄冠に輝くことはほとんど無かったんですよね。栄冠とか栄誉とか、憧れはあるんですが、実力云々もそうだけど俺の場合生き方が下手糞で、自らの身をそういうものから遠ざけてしまう嫌いがあると思っています。だから今回は素直に嬉しいですよ。わーー賞とか、久しぶりにもらっちまったなあ! という感じ。  知り合いのCG屋の中にはもっと大きな(世間の認知度が大きいという意味)栄冠を手にしている人がいっぱいいるんですが、うらやましいねたましいといつも思っています。 でも今回だけは俺も、それに比べれば非常に小さい栄冠かも知れませんけどね、こういう栄誉を賜ることができて幸せですよ。上で書いたように超行き当たりばったりで作ったのが申し訳ない気がするくらいです。



投票してくれた方々、超ありがとうございました。 スタッフの方々も、大変な運営だったでしょうに、超お疲れ様でした。 ありがとうございました (゚∀゚)







.

| | コメント (10) | トラックバック (0)

« 2011年9月 | トップページ | 2011年11月 »