« 整数乱数の激怒。 | トップページ | XSI男忘年会あり〼。 »

2011年11月11日 (金)

Making of 花火。 c05。 ICE / RenderTree。

c05 です。





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


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




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

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


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



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




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

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




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

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

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



### ICE編



これが ICETree 全体図です。

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




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

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

Bが、先頭弾ですね。

Cが、Bが出すトレイルです。




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

Icetree_a

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


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

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







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

Icetree_b

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


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


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


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



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





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



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



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

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



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


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

B_spawn

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


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


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

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



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

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



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







次C。トレイルです。

Icetree_c

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

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

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









### RenderTree編


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

Color Pass の RenderTree。

Rendertree1

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


次、Depth Pass の RendrTree。

Rendertree2

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


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


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



あれっ。 ここで唐突に思い出す。 昔からある、BA Shader CollectionBA 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)


Isobe_20111111

ふう~ 画像間に合った! 6分前だw

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

|

« 整数乱数の激怒。 | トップページ | XSI男忘年会あり〼。 »

コメント

コメントを書く



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




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/217974/53219048

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

« 整数乱数の激怒。 | トップページ | XSI男忘年会あり〼。 »