« 2010年4月 | トップページ | 2010年6月 »

2010年5月

2010年5月 6日 (木)

Dancing with Hot Sperms。

ちょっと前になりますが、いわゆるトレイルエフェクトって言うんですか、光の尻尾をすーーっと引いていくようなやつ。それをやる必要が出てきてごちゃごちゃいじってたんですがね。

ICE野郎 msk 様の助けを借りて、っていうかほとんどおんぶに抱っこで、なんとなくそれらしきものができました。


その成果で作った実験ムービー。

Dancing with Hot Sperms from junki the junkie on Vimeo.

圧縮によってひどい画質になっちまってます。ううむ、大したものではないけど、ここまで画質落ちるのは嫌ですねえ。もうちょっとキレイなんだけどな。。。。 どっかもうちっと高画質で動画を上げられるサイトないですかね?



スクリーンショット。
Dwhs_ss
恐ろしくシンプルなシーンです。 エミッタが1つ。 コリジョン用の箱が1つ。PointCloud が1つ。 あとはカメラ。 以上。


ICETree。
Dwhs_icetree
Create Strands で Strand を発生させているわけですが、その長さはパーティクルの Age によって制御されています。 Age つまり生まれてから経過した時間を、Rescale で望みの範囲に押し込めて、Create Strands の Strand Length にぶち込んでいます。

あとは Strand の Size をちょっと調整したり、Strand の向きをパーティクルの進行方向に合わせたりしているくらいか。

パーティクルの動き自体は Turbulize におまかせ。実にいい加減です。



RenderTree。
Dwhs_rendertree

Particle_Strand_Gradient をバラしたものを BA(Particle_Volume_Cloud) にぶち込んでいます。 Strand を含むパーティクルの密度を BA に食わせているだけ、ってことになりますかね。

色は Gradient ノードで決定。 オタマジャクシの頭部分と尻尾部分の太さを変えるために Scalar_Math_Curve で調整しています。
あとはポスト処理でごちゃごちゃいじってます。 Depth な Pass を使ったレンズボケとか、StarGlow とか。


とまあ、自分でもわかっているんだかどうだかアヤシイのですが、ひとまずこれでなんとかなりました。msk さん超ありがとう。マジであなたのおかげです。いつもお世話になります。




問題はレンダリングですね。1枚何分だっけ、けっこう重い。

それと、BA がメモリを食うみたいで、警告が出て画面じゅう真っ赤のレンダリングになっちゃう。警告を読むと、Lookup Table の Cell サイズがこのままだと、メモリをこんだけ食っちまうよ、これじゃメモリ足りなくて落ちちゃうから、計算やめちゃうよ。代わりに真っ赤なレンダリングにしといてあげるねゴルァ みたいなことを言っています(かなり恣意的な意訳)。

BA の中でCell サイズをある程度小さくしないと、ガタガタの絵になっちまうんですね。空間をボクセルに分割する?その細かさだと思うんですが、パーティクルが飛び交う領域があって、Cell サイズがでかいとその領域の分割数は少なく、その分 Volume の解像力が落ちるためガタガタの見た目になっちゃう。 Cell サイズを小さくすればより多く分割されるため解像力が上がり綺麗な見た目の Volume がレンダリングされるけど、分割数が多いためやたらメモリを食う。 フリーズするよりはマシだろうということで BA 様がご親切にも警告を出し、真っ赤っかの絵をレンダリングして下さる。 たぶんこういう仕組みなんだと思います。 間違っていたら指摘して下さい。

なので空間をあまり広く取れない気がするんですね。今回もこの問題でなかなかレンダリングできなかったので、コリジョンの箱を小さくしてオタマジャクシたちがすぐに跳ね返ってくるようにしました。 これならパーティクルが存在する空間が箱以上の大きさにならないから、死ぬほど Cell サイズを小さくする必要もなく、なんとかレンダリングできました。 でもやはりガタっている部分もあるのでもっと Cell サイズを小さくしたいところですが、メモリ不足でどうにもなりません。

これはもう、メモリを食わないアルゴリズムのヴォリュームシェーダを開発してもらうか、64bit マシンに 16GB くらいメモリ積んでゴリ押しでレンダリングするくらいしかないのでしょうかね。  俺、何か勘違いしているようでしたらどうか教えて下さい。ほんとこれ、なんとかしたいのです。


これは XSI じゃなくて Max の Fume の話ですが、要はこれのようなことができればいいのかなあ? などと思ってみたり。
http://sky-high-nest.sblo.jp/article/36708763.html
エフェクト番長、けゑ様のスヴァらしきブログ。 Fume や Fume を使いこなしている番長に憧れてしまいます。勃ちます。

でも領域を複数用意したら、やっぱりその分メモリを食ってしまうような気がするんですが、ううむ、よくわかりません。けゑ様の記事では、メモリ節約のために分割するという言い方では書いていないので、そういう観点からの記事ではないのかもしれません。



ICE 自体はスヴァらしいんですが、ICE パーティクルに関しては、そのレンダリング方法がいつもネックになっている気がします。どんなにスヴァらしい挙動を付けられても、それをちゃんとレンダリングできないんじゃ意味がない。
メモリ食わずに、速くて、ブツのスケールにあまり依存しなくて、設定がピーキーじゃなくて、表に出ているパラメータは少なく、いい感じのいい加減さがあり、どんな通常シェーダとも組み合わせ可能で、突っ込んでいじろうと思えばどこまででも深く手段が用意されている、そんなボリュームレンダリングソリューションを、誰か開発して下さい。買いますから。

ビューポート上の表示もダメダメですね ICE パーティクルは。全然ファイナル状態を想像できない。RenderTree に激しく頼るからなのか。 旧パーティクルはこの点ではなかなか良かったのになあ。。。。。





.

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

« 2010年4月 | トップページ | 2010年6月 »