Making of 花火。 c05。 Comp。

しばらく間が空いてしまった。






### コンポジット編






例によってインチキブレイクダウン風行きましょう。

720p で再生すれば、それなりに鮮明に見えます。たぶん。


まあアレですね、すいません、何がどうというほどのことはやってませんね。　参ったな、ほんとに書くことが無い。









一応、AE 作業画面。

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



うーむ、ナニがどうでもないなあ。




カイワレ大根だかモヤシだか知りませんがこの変なヒョロヒョロ花火を、５つの Pass に分けて XSI からレンダしてますね。　単なる別レンダです。　１つずつ色を変えるからです。

で、Starglow で１レイヤずつ色を変えていますね。

でもなんだか、色んな色が混じって綺麗なんだか汚いんだかわからん。　たぶん汚い orz







あとは、デプス Pass を出していますね。　なぜかデプス１と２に分けているようです。なんでそうしたのかは、今となっては不明です。　たぶん意味無いです。




デプス Pass は、Lenscare の Depth of Field に使われていますね。　レンズボケ。


でも、俺の経験では、こんなツブツブっぽい、ごちゃごちゃとしたデプス Pass 素材でレンズボケやっても、綺麗にボケてくれないことの方が多いと感じています。



もっとこう、面積が広いものなら、綺麗に行くことの方が多いと思うんですがねえ。　こういうごちゃごちゃしたやつだと、なんだかエッジが汚い感じになることが多いと感じています。


そしてその辺の探求は、いまだサボってやってません orz



なんか、このカットは、ボケなんかやらない方が良かったかもなあ。もっと引いて、要素がごちゃごちゃに重ならないようにした方が良かったような気もするし。

まあ、花火大会応募締め切りの１日だか２日だか３日だか前くらいにやっていた作業なので、良いも悪いもクソもなく、とにかく終わらせることだけを考えて、ひたすら前に進んだのでしょうね。　そんな作り方してんだから、気に入らなくても仕方ないですね。






ってことで、あまり工夫もしていなく、ゆえに特筆するべきことがなく、自分でも気に入ってないこのカット、お願いですから全力でスルーして下さい。






一応解説をコンプリートしようとして書いているだけで、内容的にはすげえ薄くなってますねえ。まあ仕方ない。ほんとに薄いんだから。







.

Tori と踊る男。

いや、あのですね、ほんとは RSMB の実験だったんですよ。

ReelSmartMotionBlur ね。RE:Vision の、スヴァらしい２Ｄモーションブラー生成プラグインですね。　AE とかで後付けモーションブラーをやる、アレですね。




RSMB に食わせるためのモーションベクタ素材を出すワークフローについて、実に久しぶりだったので忘れていて、手順の確認のために何か素材が必要だったのです。　なので、なんでもいいのでテストモーションを作ろうとしたのでした。　

普通ならキューブとかトーラスとかがくるくる回っているとかで十分なんでしょうけど、まあそれと同じレベルで、XSI 男がＴポーズのままでくるくる回っている画像を用意しようと思ったんですよ。　キューブもトーラスも XSI 男も、ただのプリミティブですからね。




しかしここで運命の分かれ道。





↓ こうすれば良かったものを、





↓ 思わず、こうしちゃったんですね。




前者は、ただのＴポーズなプリミティブですわね。　はい、くるくる rot Y でもさせれば、RSMB の実験には十分でしょう。


後者は、全身どころかフェイシャルまでリグが入った、Ready To Animate なキャラクタなわけですよ。






ここで男が、ニヤリと笑いました。



こうなるともはや男の思う壺です。

しかたなく、キーを打ち始めました。深夜に。









で、まあ、結局、こうなりました。　720p 再生でどうぞ。




RSMB なんてどこにも出てきません。
どうでも良くなりました。



１秒ループなダンス。

ＢＧＭは例の、パーティキュラー花火大会の時に作った曲です。
Garage Band でその時のデータ開いて、テンポ変えて、パーカッションのトラックを追加した程度。　先に１秒ループでダンスの動きを作っちゃっていたから、テンポはもう、120 bpm とかにすれば自動で合っちゃう。　さすが絵も音もその発生から１００％デジタル同士ですからね、無調整でパーフェクトに合いました。楽ちんです。

いや、まあ、アレですよ、モーション作業自体はほんの２０分か３０分か。　ただの１秒ループですからね。　そこまでは良かったのですが。




ふと思いついて、トーラスを降らそうと思っちゃってからが大変で。




まず、ジオメトリをインスタンスするとけっこう重いんですよね。このシミュレーションだけで、計算始めると１５分か２０分はかかっていると思います。　まあ世の中のプロフェッショナルなリジッドボディのシミュレーションと比べれば別に重くもなんともないのでしょうが、こんなどうでもいい動画のためにシミュレーションだけに２０分とかかかるのは、重いです。


トーラスごときで重いのはもちろんそれ自体腹が立つわけですが、もっと腹が立ったのは、昔から思っていたことではありますが、なんで ICE パーティクルのビルトインShape の中には cube や sphere や cone があるくせにトーラスがねえんだよ(ﾟДﾟ)ｺﾞﾙｧ!!  ということです。　これだけしょっちゅう使うんだからねえ、毎回 Instance Shape ノードとか出すのも面倒だし、そもそもビルトインの方が軽いでしょう。　　時期メジャーバージョンアップの時は、Shape に必ずトーラスを追加して下さい。わかりましたか嘔吐デスク様。


で、そんなことをしているうちにコリジョンオブジェクトが上手く機能しなくなったり。　ある程度シーン作成が進んでから、整理をしようとして名前とかちゃんと付け始めるのですが、コリジョンオブジェクトを入れた Group の名前を変えたり、他の Model の下にぶら下げたりなどしているうちに、なぜだか ICE ツリーから認識されない状態になってしまったというか、コリジョンが突き抜けてしまうようになってしまったというか。　まったくもう。


しかたなくコリジョンオブジェクトをゼロから作り直す所から始めてなんとか設定できても、リジッドボディは再生するたびに微妙に結果が変わるものだから、気に入った状態が出てきても、キャッシュを取っていないとその結果は永遠に再現できないんですよね、たぶん。　なので、良い状態を失うまいとして常にキャッシュを取るようになりさらに作業効率が落ちる。　まったくもう。



とかなんとか、トーラスを出して以来すごく大変になっちまったんです。　やっと終わったよ。　馬鹿か俺は。




もうモーションブラーもクソもないですね。ブラーやってねえし。

もうヤケクソですよ。ICE わかんねえんだもん。

XSI 男忘年会では、この動画のように、皆さん、踊り明かしましょうよ。　踊ればきっといいことありますよ。　だってほら、すごく楽しそうじゃないですかこの男。






そうそう。　大発見がありました。

Torus の複数形って、なんだかわかります？

Toruses とかじゃないんですよ。

Tori って言うんですって！


鳥じゃないですよ。　トリだかトゥリみたいに発音するのかな。　ともかく、Tori はトーラスの複数形なんです。　たまにありますよね、複数形にすると変な風に変わる英単語って　。トーラスもそういうコトバなんですね。






ほんとですってば。  調べたんだから。








.

Making of 花火。 c05。 ICE / RenderTree。

c05 です。

OGLビューポートキャプチャ動画。

あれ？　なんかアスペクト比間違えてる？　まあいいや。




・・・・しかしなんというか、なんでこうなっちゃったんでしょうねえ・・・。

このカイワレ大根みたいな花火、別に美しいとは思えんわ俺は orz
花火というより、なんかの胞子を出す植物みたいですよね。 汚れているのは水なんです、みたいな。

いや、こうしたかったわけではないんですよ、最初は。　
おそらく、よくある、こういうやつ、



この画像の下の方にあるやつ、こんなのが頭にあったと思うんですよね。




でも、実在の花火に見えるもの、つまり一定以上のリアリティがあるやつってのは、それなりに時間がかかるものです。　このショットを作り始めた時点で締め切りまでおそらくあと２日か３日という状況だし、これまでのショットでもリアルさを完全に捨ててＣＧ臭いというかエフェクト臭い感じに走ってきたこともあるので、むしろ意図的にリアルから遠ざけようとする言い訳がましくみっともない意思が働いて、だんだんパラメータをヘンな方向にいじり、カイワレになって行ったような気がします。

タービュランスとか強めに入れると、いかにもＣＧ臭い、あり得ない挙動になって行きますよね。なので、「 現実にはあり得ない、ＣＧならではの、ちょっと面白い花火でしょ 」　などという言い訳がしやすい絵になって行きますよね。　目の利く人が見れば、必ずしも狙ってそうしたわけではなく、単に能力不足でリアルを作れないだけだとか、手抜きしてるだけだとか、一発でバレますけどね orz

まあともかくも XSI の作業画面です。


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

エミッタはポリゴングリッドです。　１発ごとにエミッタも PointCloud も分けています。　全部別レンダしてますね。　後で色を１発ごとに転がそうとか思っていたんだと思います。　床にもポリゴングリッドがあって、こいつにヒットしたパーティクルは死ぬようにしてますね。　余計なパーティクルは殺して軽くするため＆要らん挙動のパーティクルがカメラに入ってくるのを未然に防ぐためですかね。　カメラは固定ですね。　背景は、グリッドをラティスで変形させて、好みの状態になるようにいじったようです。

### ICE編

これが ICETree 全体図です。


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




花火１発につき、これです。　全員がこのツリーを持っていて、多少パラメータを変えているだけのはずです。

Ａ付近が、エミッションや、床に当たったら死ぬ処理です。

Ｂが、先頭弾ですね。

Ｃが、Ｂが出すトレイルです。

まずＡから見て行きましょう。

うん、見事に特筆すべきことがない orz


エミッションスピードをランダマイズしてるのと、発射方向をランダマイズしてます。発射方向は、今回は全方位の球状ではなく、コーン状に発射させてますね。 Randomize Direction の中の数値は今見たら -45 ～ 45 でした。

後は、Test Collision With Surface で、床に当たったら即死するようにしているだけですね。　俺、同じ目的で Delete Particles by Volume もよく使います。

次、Ｂです。　先頭弾です。

うーぬ、これも特段の工夫をしたようには見えないなあ。　まあそんなもんです。


発射後の挙動は、フォースまかせですね。 Gravity と Drag のいつものパターンに、タービュランスを加えるという、これまた更にいつものパターンです。


タービュランスのツリーですが、Turbulize とか Randomize を by Range でやりたい場合、かつ 0 を中心にプラスマイナスを同じ幅でやりたい場合に、俺はこういうツリーを組むことが多いです。　なんのことはない、Min Value と Max Value にプラマイ違いの同じ数値を２回打つのがめんどくさいというだけです。　パーティクルの挙動に関わる話ではなく、２回の数値入力を１回で済ませたいという、ほんとそれだけです。


なのであまり調整の必要がない場合はこのツリーも組みません。　っていうか、最初はこのツリーを組まないまま調整を始めて、Min Value と Max Value を数回打ち直すハメになった時点で超めんどくさがりの俺はキレ始めて、このツリーを組んでしまいます。 そして組んだ後に最初に入力した数値がいい具合だったのでそれで確定してしまい、何度も数値を打ち直すのを便利にするためにわざわざ組んだこのツリーが、たった１回の入力でその役目終了という結果になることが多いです orz



ちなみにプラマイの中心がゼロではなく、例えば 3 にしたいなら、このツリーの結果に Add ノードで 3 を足してやればいいだけですね。　ゼロを中心とした -1.25 ～ 1.25 に 3 がプラスされるので、結果的に 2.75 ～ 3.25 の値が出てくることになります。

あとは、パーティクルのサイズをランダマイズしてチカチカ感を出すというのもワンパターンですいません。　ただし今回は、前回までのように前のフレームのサイズをベースにしてランダマイズするのではなく、毎フレ脈略のないランダム値が入るようにしてますね。こっちの方が良かったです。前のやり方だと敏感すぎて、ランダム値の出方によってはあっという間に超巨大パーティクルが生まれたりしてましたから。



あとは色のランダマイズか。ありものの Randomize Color コンパウンドを使って、Lightness に多少バラつきをもたせているだけです。　ほんの少し明るい黄色、暗い黄色があるのがわかると思います。　以上。



Spawn Trails でトレイルを発射し続けます。　

あっ　Spawn で少し工夫しているのを忘れていた。　ええと、何やったんだっけ。　これ書きながら今あわてて調べ始めた。



・・・わかった。トレイルのパーティクルが発射される空間範囲にバラつきを持たせる、つまり空間の中の１点から生まれるのではなく、その１点からプラスマイナス XX の範囲の空間から生まれて下さい、ということをやったんだった。　それが、上の画像の Spawn Trails の一番下にある FuckinEmissionSpaceRange ですね。


これ、Spawn Trails コンパウンドの中身を開いて、ちっとだけ改造したんですよ。　これがその中身です。

もともとは、Ａのアウトプットは、Ｂに入っていました。　Ａ以下のツリーが何をしているのかと言うと、どうやらパーティクルが発射される空間をジッタリングしているようですね。グループコメントに Softimage の人が書いた説明がありますが、動きの速いパーティクルから生まれるトレイルは空間上で飛び飛びの位置に現れてしまうから、それを避けるために、元のパーティクルの位置からちょっとずらした場所に発生させることによって、飛び飛びの空間の隙間を埋めるということをやっているようです。


これにヒントを得て、細いトレイルを太くしたというのが、俺がやった改造ですね。　パーティクルが発生する座標にバラつきを持たせるツリーがもう出来上がっているなら、そこに更に任意の数値をプラスマイナスしてやれば、このツリーで決定された発射位置よりさらに広い範囲で発射されることになる ＝ トレイルが太くなる　 と考えたのです。　太くしたかったんですよ。なんとなく。


ってことで、Ｃの Add ノードを足しました。そしてＤ以下を足しました。Ｄ以下は、まさにたったさっき出てきた「ゼロを中心にプラマイ同じ数値でランダム」のツリーになってますね。

つまり、ゼロ中心にプラマイ XX の値を発生させ、それをＣで Add しているので、結果は、Ａまでの結果として出た数値にプラマイ XX していることになります。　Ａまでの結果は、もともとこのコンパウンドで出した値ですから、もともとの数値にプラマイ XX した数値が最終結果になります。 バラつき幅は、Ｅの部分でエキスポーズして Spawn Trails の PPG からいじれるようにしました。



わかりにくいので、単体でやってみました。

何もしないままの Spawn Trails が残すトレイルは細い。左側です。　それに対し、プラマイ 0.1 の範囲で出現位置をバラけさせたのが右側です。 太くなった。これがやりたかったんです。



ああ良かった。。。大したアレではないかもしれないけど、ひと工夫入ってた。。。。

次Ｃ。トレイルです。

ううむ、今度こそ工夫無しか。

同じくタービュランスで乱していますが、プラマイ入力なツリーがまた登場。　今回はパーティクルの寿命を掛け合わせて後半ほど強く効くようにしてはありますが、これも前回まで出てきたネタで、新しくはありませんね。

後は色を寿命に合わせて変化させてるだけですね。

### RenderTree編

すすすすすいません、こちらも特に工夫無し。。。。

Color Pass の RenderTree。

先頭弾もトレイルも一緒くたですね。StateID ごとにツリーを分岐させたりはしていません。　元になる色は Color_Attribute で ICETree から拾ってきているので、先頭弾とトレイルで色は差がありますが、、ADD で Mix して明るくしたり Incidence でエッジ部分を透明にしたりする処理は一緒です。

次、Depth Pass の RendrTree。

これも前回まで出てきたのと同じ。Ray Length を使って、カメラから出たレイとパーティクルのサーフェスの交差した座標におけるカメラからの距離をゲットし、デプスの範囲を Change Range で決めて 0 ～ 1 の範囲にリマッピングし、それを色に変換するから白黒のグラデになる。というものです。


しかも、こともあろうに透明度を考慮していない。 パーティクルのエッジが透明であるにも関わらず、おかまいなしに Ray Length を使っている。 Ray Length はプライマリレイの長さですからね。 つまり透けたサーフェスを通過した時点でそこから先はセカンダリレイになるわけで、返してくる値はカメラのポジションからの距離ではなく、おそらくプライマリレイがヒットした座標（つまり透けたサーフェスの表面）から次のサーフェスの交点までの距離を返してくるはずだと思います。


結果、カメラからの距離ではなく、レイが最後に透明なサーフェスを通過した地点からの距離でレンダされるという不正確な Depth Pass 画像が出来上がり、最終的に AE で Lenscare に食わせた時におかしな Bokeh になります。　Ｙ崎さんはこういうのを許せないそうで、どんなチートを使ってでもおかしな Bokeh を排除して美しくしようとするのですが、俺などは「おかしな Bokeh で何が悪い」と開き直り、文句を言わせなくしてしまうという方向のチートをします。　Bokeh が壊れるとわかっていながら敢えて「まあいいだろ」と楽な出し方の Depth Passを選んでいるんですからタチが悪いです。　まあ、世の中色んなチートの方法があり、良くないものを良いと言い張るのも立派なチートの方法だよという話です。　ただし彼のようなチートのやり方だとＣＧ専門誌で連載を持つくらい賞賛され、俺のようなチートのやり方だといい歳こいていつまで経っても業界の片隅で小さく生存しているだけになり、Vimeoでガイジンにディスられ、下品なブログを書くことにひたすら精神力を費やすという、社会のゴミのような人間になりますのでご注意下さい。ええ、とってもご注意くださいね。

あれっ。　ここで唐突に思い出す。　昔からある、BA Shader Collection の BA Ray Length に、Total Ray Length というモードがあったよな？　　今、マニュアルを調べてみると、
http://www.binaryalchemy.de/develop/shd_ess/description.htm


　　total ray length from the camera to the surface, including reflections and refractions.

って書いてありますね。つまり、透けたサーフェスを通っても、プライマリレイの長さにどんどん加算していくということですよね？　ってことは透けたサーフェス越しでも正しくデプスの距離が取れるということじゃないですかね？

あー　前からこの Total Ray Length って何に使うのかなと思っていたんですよ。こういうことに使うものなのかな。　んー　これは実験が必要だ。　宿題増やすなよもう。

コンポジット編へ続く。

と思う。

あ。 この記事は、2011年11月11日午後11時11分に公開されるようにセットしますた。

isobeさん、超おめでとう。　心からお祝いするっス o(ﾟ∀ﾟo)




ふう～　画像間に合った！　６分前だｗ

さて、お祝いの酒は何がいいかね。

花火高画質バージョン。

先日から書いている、パーティキュラー花火大会に出品した映像の完成版を、Youtube にアップロードし直しました。　高画質で再生できるようになったみたいです。

720p とかで HD再生することができます。　明らかに画質というか、高精細感が上がった。

中身は変わらないので、高画質になって嬉しいのは作った本人である俺だけだということはよくわかってますが、まあいいじゃないですか。　階調とか色深度とか割と気にして作ったのに、ヴォロヴォロになってましたからね。残念だったのです。

マスターのムービーは、800 x 600 で、QuickTime アニメーション圧縮の品質 100% です。つまりロスレスです。　ファイルサイズは 2GB 強あるムービーです。　

これを 10Mbps 程度の H.264 にしてアップロードしたのが前回バージョンです。　H.264 ムービーになっても、そんなに劇的に画質は落ちてないんですが、Youtube にアップロードするともう１回なんらかのエンコードをかけるようなので、ここで劇的に画質が落ちますね。

で、ちょっと調べたら、そもそも 1280 x 720 以上のレゾにしないと Youtube 上で HD な再生モードが選べないのでダメよ、というのがわかってきて。　

しかし今回の花火大会は、規定のレゾが 800 x 600 だったのです。　作り始めたのが締め切り１週間前とかなのでレンダ時間も惜しいし、そのまんま 800 x 600 で作ってしまいました。　なのでマスターのレゾが 1280 x 720 相当に達していません。

しかたないので、AE で 1280 x 720 のコンポに完成済み 800 x 600 をブチ込んで、上下左右に余白がある状態にし、今度は 20Mbps 程度の H.264 でレンダし、 それを Youtube にアップロードしてみたら、明らかに高精細な再生になりました。 圧縮の品質の話ではなく、高解像度再生ができるようになったことによる恩恵が大きいように見えるのですが、どうなんでしょうかね。

ちなみに、同じく余白付き 1280 x 720 ではあるんですが H.264 エンコードなどはやらずアニメーション圧縮 100% のままというムービーも作ってみたのですが、これはファイルサイズがでかすぎるのか（元が 2GB強で、1280バージョンはそのプラスアルファくらい）、何度アップロードしても失敗でした。　アップロードは一旦成功し、「現在エンコード中」ですという旨の表示が出るのですが、数時間経つと「アップロードが中止されました」とかに変わってやがりましてね。中止してねえよ。　これを数回繰り返して、あきらめました。

そこで H.264 にしてみたら、一発でちゃんとアップできました。 ファイルサイズは 150MB弱ですね。　H.264 エンコードにしたことがポイントなのか、ファイルサイズが小さくなったことがポイントなのか。　よくわかりません。

それにしても、今どき、何でも 1280 x 720 以上にはしておいた方が良さそうですね。この花火も 960 x 720 でレンダしときゃよかったなあ。

でも嫌な時代ですね。フルＨＤとか平気でやってるし、しかもステレオ３Ｄとか。　4K TV とかマジでやめてください。　あなた、ほんとにそこまでして高精細で見たいですか。

4K が普通になったら、制作サイドにはどんだけでかいモニタが要るんだろう。やっぱ 1:1 の大きさで見れる環境無しには作れないじゃないですか。　机もでかいのが必要になり、オフィススペースは圧迫され、広いビルへの引越しを余儀なくされ、引越し貧乏で倒産していくＣＧプロダクション。ああ恐ろしい。

とか言って、現在既に 1:1 でちゃんと全域は見れない環境で作っちゃってますね。1920 x 1600 のモニタ１枚で、1280 x 720 の映像作ろうとすると、AE の画面はかなりキツい。どうしても縮小表示になってしまう。 あるいは 100% 表示で一部ウインドウに隠れているとか。　実はけっこうストレスです。　

今回の花火大会で 800 x 600 と聞いたとき、すげえ安心しましたもん。　ああ嬉しいな懐かしの SD だな。　AE 上でもほとんどの場合見切れずに 100% 表示でコンポできるな。嬉しいな。



この辺で高解像度化の流れは止めなければいけませんよ。　せめて 1280 x 720 までにしませんか。ねえ。　レンダ負荷もそうだけど、上記のように作り手側の表示環境の問題もあるし、ペンタブレットもでかいのが必要になり、ストレージは圧迫され、テクスチャ解像度だってそれに合わせて上がり、モデル解像度も当然上がり、納品データはネット越しに送れなくなり、パシリ君が 2TB の HDD を抱えて編集所に走るみたいな、まるで俺が駆け出しの頃にやっていたことがそのまんま繰り返される。　退行ですよこれは。


あと、関係ないけど「ハイビジョン」という言い方もいい加減やめませんか。それ日本以外で通用しないでしょう？　たぶん。　　　まったく、日本放送協会様の野郎、ふざけた名前を普及させようとしやがって。MUSEを押したかっただけだろう？　たぶん。　　　　「ＣＧデザイナー」みたいなもんですよ。やめましょうよ。

そういやメイキング記事まだ終わってませんね。
まあ、ネタとしてはもう切れかかっている気がします。
なら、全ショットやらなくてもいいわな。
どうしようかな。
ものすんごいエネルギー要るんだよな。
楽しいんですけどね。





.

Making of 花火。 c04。 Comp。

c04 の続きです。

###　コンポジット編

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

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

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

AE の作業画面。

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

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

・花火

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

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

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

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

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

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

・水面

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

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

それに Starglow をかますと、

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

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

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

こいつに Starglow しました。

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

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

このようになりました。　

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

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

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

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

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

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

たぶん続く。

.

Making of 花火。 c04。 ICE / RenderTree。

c04 です。

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

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

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




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

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


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

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

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


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



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


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

### ICE 編




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

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


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


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

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

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


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

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

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






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

ICETree はこれです。

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




・Surface から発射

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

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

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

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


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

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

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

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

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

・色

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


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


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

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

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

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

・Rate にアニメーション

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

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


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


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

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

●花火パーティクル（ State 1 ）

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

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


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

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

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

●トレイル（ State 2 ）

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

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




・マテリアル分岐用IsThisFuckinTrail

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

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





・トレイルの色変化

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



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

そして 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 情報に変換され、Ｂ１の Set Particle Color でセットし直されます。

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

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


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


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

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


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

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

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

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


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


これがその結果です。

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


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


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






●水面 ICE

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



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

その ICETree。

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



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


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


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


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

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

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


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

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

ICE は以上。たぶん。

### RenderTree編



●花火の RenderTree


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

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


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



・IsThisFuckinTrail で分岐


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

Boolean_Attribute を使ってまず IsThisFukinTrail の値をゲットし、Boolean_Logic の Input1 にぶち込みます。　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 を使って、中心部分は光の芯があるかのごとく明るく、周辺部分は比較的暗い上に透明度が高くて奥が透けて見えているというシェーディングです。


こんな感じ。



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





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

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

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

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

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

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

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

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





●水面の RenderTree


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

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

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


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

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


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







●水面デプス Pass


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

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


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


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

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

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






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


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








●リフレクションのみ Pass


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

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


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


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



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

●カメラ


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

わははー　カメラとインタレストの posY が動いているだけだー　しかもなんの工夫もないイーズインイーズアウトだー　（ ＾∀＾）ｹﾞﾗｹﾞﾗ


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









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


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




.

Making of 花火。 c03。 Comp。

c03 の続きです。

### コンポジット編

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

AE の作業画面

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

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

・グラデーション乗せ

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



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



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

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



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

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


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


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

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

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


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

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









・ケラレ

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



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





・Vector Blur

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

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


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


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


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


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

・ボケグロウ

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



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


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

・その他

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


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

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

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

.

Making of 花火。 c03。 ICE。

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

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

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

XSI の作業画面。

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


これまた超シンプル。

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

### ICETree 編

ICETree はこれです。

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

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

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

●エミッション

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

●メイン光球 State ( State 0 )

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

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

・重力ランダマイズ

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

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

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

・ちかちか

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

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

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

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

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

●ラストの花 State ( State 1 )


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

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

・Ｆカーブ

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

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

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

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

・結果をブースト

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

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

・色とか

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

●トレイル State ( State 2 )

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

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

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

ってことでこのコンパウンドの中身を見てみると、

なんのことはない、Turbulize Around Value を使っているだけではありませんか。


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

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

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

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

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

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





あ、あと、今回は State Machine ノードを使いませんでした。

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


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。

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






### コンポジット編


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

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

AfterEffectsCS5.5 でやってます。その作業画面。

クリックででかい画像が出ます。

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

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

・Starglow

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

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

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

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

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

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

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

・frischluft Lenscare

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

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

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

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

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

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

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

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

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

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

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

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

ともかく、透けて向こうに見えているパーティクルのデプス情報も取れているはずなので、そのせいか、

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



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

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

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

・色深度

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

ただですね、AE のモードを 32bit にしてみたら、すんげえ鮮やかな色になったんですよ。

これ、同じコンポジションを、単に色深度だけ 8, 16, 32 と変えてスクリーンショット撮ったものです。 8 と 16 では差が無いように見えるのに、32 だけはガツンと彩度が上がったように見えます。

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

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

・カメラ

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

・その他

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

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

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

Making of 花火。 c02。 ICE / RenderTree。

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

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

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

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

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

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

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

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


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

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

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

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




### ICE編


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

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

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

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

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

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

ではひとつずつ。

●エミッション部分

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


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

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

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

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


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

・発射頻度／数

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

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



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




・形

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

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



・State

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



・方向

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

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

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

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

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

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

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

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

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

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

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


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

・その他

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

●光球State

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

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

Ａの 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 にキーを打つなどパーティクル全体にグローバルな影響を与える荒業を使うことなく、パーティクル個々の寿命を基準にプロシージャルに作れないだろうか、という実験みたいなものです。　もっと研究が必要ですかね。 結果的には、いわゆるツメの動きにはなっていません。　調整していくうちにこれで落ち着いちゃったという。　まあいいや。

・重力の影響にバラつき

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

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

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

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

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

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



・色は３種類

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

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

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

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




・トレイル発射

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

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


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

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


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

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




・ちかちか

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

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

●トレイル State

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

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

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

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

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

てことで、Ｂを見てみると 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 というタービュランスの値に近いもしくは同一の結果になります。

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

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

・色

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

### RenderTree編


・Color Pass

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

色は 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。


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

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

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

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

たぶん続く。



.