« Making of 花火。 c02。 Comp。 | トップページ | Making of 花火。 c03。 Comp。 »

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 と同じでした。 よって新たに語るべきことはありません。 すいませんすいません。





きっと続く。

|

« Making of 花火。 c02。 Comp。 | トップページ | Making of 花火。 c03。 Comp。 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: Making of 花火。 c03。 ICE。:

« Making of 花火。 c02。 Comp。 | トップページ | Making of 花火。 c03。 Comp。 »