COOK BOOK

CGWorld vol.153に掲載された記事です。


Strawberry Crush。
イチゴがクラッシュです。


今回のモチーフはイチゴですが、イチゴをレンダリングしてみたかったのでそうしました。
もちろん、単純にそれだけの理由では無いのですが。 

いざレンダリングしてみると、いちごのシズル感を出すのは難儀で、なかなかうまくいきませんでした。
限られた時間の中で、納得の行く結果まで辿りつくのは難しく、多少の妥協はありましたけど、最終的には目を背けたくなるような結果にならずにほっとしましたｗ

本来なら素材を分けてコンポジットで調整したいところですが、コストを考えるとそうもいかず、調整中にシェーダー側でプリコンポジットする形でレンダリングしています。

HoudiniのVOPはレンダリング結果を、レンダリングをする前に簡単なコンポジットをするかのように扱うことが出来ます。
そうすることで、のちのコンポジットの負担を減らすばかりか、一回のレンダリングでコンポジットまでの結果を反映出来るので、コストを抑えることが出来ます。

もちろん、本格的なコンポジットには叶うわけも無いので、必要に応じて、素材を分ける必要があります。
そんな場合でも、シェーダー側から、レンダラーへ、素材をエクスポートすることが出来ます。

この一連によって、ワークフローが単純化され、最終ルック調整を非常に簡単にすることが可能になります。


また、今回のメインディッシュは、Particle Advectionです。

これまでは、シミュレーションの際に、VelocityのFieldをVectorデータに変換し、それをAttribute Transferで流しこむ方法をとってきました。
今回は、SmokeFieldを利用したAdvectionを紹介しています。

これにより、Advectionが単純化されて、より簡単にパーティクルをモディファイすることが出来るようになります。

詳しくはCGWorld本誌や、CGWorld.jpでご確認ください。


 

CGWorld vol.152に掲載されたものです。

Wire to Plasma。
そのままの意味で、ワイヤーをプラズマに変換するというものです。

HoudiniのMantraは、線ポリゴンや点をレンダリングする事が出来ます。それを利用してプラズマ状の放電をつくることにチャレンジします。

他のレンダラだと、線ポリゴンをレンダリングする事はたやすくないかもしれません。

ましてや、線ポリゴン、所謂カーブなどを扱ってアニメーションさせることも難しいかもしれないです。

Houdiniは線ポリゴンだろうと点だろうと、サーフェイスだろうと、単純にポイントやバーテックスのポジションの羅列に過ぎず、それをどのようにでも扱えます。

Houdiniの強みはそこにあります。

ジオメトリを扱うというよりは、ジオメトリが持つべき基本的なアトリビュートを扱うと言ったイメージです。

考え方がそもそも違うと言ってしまえばそれまでですが、少し語弊があるので補足すると、他のソフトウェアが親切に裏側でやってくれていることを、Houdiniは表立ってやっています。
むしろそうあるべきだと言わんばかりに、面倒なことを要求してきます。
しかし、そうすることで、単純なバーテックスのトランスフォームも、単なる移動にとどまらず、バーテックスがもつポジションのアトリビュートに対する加算になってくることを分からせてくれます。

それを理解することで、複雑だと思われることが、いとも簡単に出来るようになってきます。

Houdiniにはそういった力もあって、CGのベーシックな部分を勉強するにはもってこいのソフトウェアです。


今回のプラズマは、単純な点のアニメーションを利用して、それを線にして分割し、ノイズを与えています。それの世代を増やして放電のように見せています。

仕組みは単純ですが、単純故、ベーシックな部分を押さえてなければ出来ません。Houdiniの基本機能で出来ることですが、応用していけばそれは無限大です。

また、影のアトリビュートとして用意されているのが、"width"です。これは、線ポリゴンに対して太さを持たせるアトリビュートです。同じことが"pscale"でも出来ます。
これらは、Mantraが、この線はこの太さと認識するために必要なアトリビュートです。

単純な線ポリゴンが放電として生まれ変わるためには、小さなスパイスの配合が欠かせないのです。


 

CGWorld vol.151に掲載されたProcedural Jellyfishです。

この回は、クラゲを自動制御で作りましょうというのがテーマですが、裏テーマには、プロージャルなアプローチと手付けのアニメーションや力技との共存があります。

Houdiniを扱っていると、いつしか全自動というワードが頭にこびりついてきます。それもこれも、Houdiniの素晴らしいシステムのせいです。自動制御がとても楽しくなってきます。
ところが、それは画に直接結びつかない場合が多いです。

私自身、画に対する追求はあまり深くなくて、プロセスこそすべての人間です。しかし、それは時に非常にジレンマで、完成図に対する逃げや言い訳でしかない場合が大いにあります。
ここで言うこと自体もそれのひとつなのかも・・・

今回のテーマは自分自身への課題でもあったりして、画に対する追求を、プロセスを問わず行えるのか、ソフトウェアを単純にツールと認識出来るのか、そういった部分が大きく含まれています。

Houdiniを触っている方ならわかるかと思いますが、Houdiniを単なるツールとして扱うことが難しくなってくる瞬間を感じる事があります。
例えば、難易度の高いアプローチをいかにスマートにこなすか。
そんな事をクリアしたときに感じるプロセスへの達成感。

それ自体、画に反映はされなくとも、自身とソフトウェアを賛えてしまいます。

画の完成度を高めるためには手段を選ばないという気持ちを揺るがしかねない、危険な思想です。
少し大げさに書きましたが、これは私がHoudiniを使用する上でいつも悩まされる事です。 

そんなジレンマと戦いつつ、手動と自動をうまく共存させ最終のルックを詰めることを目標に掲げてこの映像を作ることにしました。


が、、、

やってみると、これがまた非常に難儀なものでした。

クラゲというモチーフは、なんとも全自動で作りたくなるやつでした。悔しくも、最初の目標は、大幅に崩され、自動化する部分にどんどん蝕まれていきました。長年染み付いたHoudini魂が、マニュアルな部分を嫌うのです。
さんざん偉そうな事を書きましたが、完成された共存環境を作るのはまだまだ先の事になりそうです。


大きく反省すべき点は、 2箇所あって、ひとつは、クラゲの全体の動きをMotion EffectsでCHOP制御しているのですが、その関数の計算ミスで後半にズレが生じていることです。所見で気付く人もいると思いますが、自分は気づけませんでした。醜態を晒しました。
ふたつめは、中央の触手のヒダですが、法線の制御がうまく行ってないくて、パキパキしてしまっているという点です。

これはどのやり方で制御すればうまくいくかまだ試していませんが、かなり難しいんではないかと予想しています。作り方を改めた方が無難かもしれません。

こう言った部分が、あって、やはり手付には叶わないと思ってしまいました。
もちろん、大量生産ならまた話は違ってきますが。

目論見は大きくハズレてしまいました。
反省すべき点です。