COOK BOOK

Collapse

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

今回は、Fractured Object Dynamicsを使用した例です。

Voronoi Fractureはもうおなじみの手法ですね。
Houdiniは、Voronoi Fractureにおいて2種類の分割手段を持っていています。
事前に分割しておくもの、シミュレーション時に分割するものです。

今回は、事前に分割する方法をチョイスしました。

が、

最近よく目にするシミュレーションのテスト映像で、
一気にVoronoiがバラバラと砕けるものがあります。

なんか、とても殺風景で、面白みがなく感じていました。

もちろん、本気映像ではなくて、テストなんだと思うんですが。。。

なので、今回は、徐々に崩れていく仕組みを考えて、
シミュレーションに色を付けていきたいと思いました。

ちょっとしたスパイスで、ガラリと変わるから面白いですね。

アプローチとしては、

Voronoiで分割したピースのセンターに、ポイントを配置します。

ポイントをパーティクルに変換して、コリジョンを適応します。

コリジョンがぶつかった場所から崩れていくようにするために、
"hittime"のアトリビュートを用意します。

"hittime"をシミュレーションをアクティブにするためのアトリビュートとして変換します。

この手順を踏むことで、シミュレーションに時間差を付けることが出来ます。
あくまでも擬似的ですが、とてもスマートにアプローチすることが出来ますね。

シミュレーション時にVoronoiを適応する手法を使うと、
崩れた時間をアトリビュートで持てますが、逆に、破片をコントロール出来ません。

事前に割っておく方法は、破片のコントロールをする事がしやすいと言う利点があります。
ただ、"hittime"を持たすには、一旦パーティクルで、前準備を必要が出てきます。
しかし、パーティクルにすることで、Lifeのアトリビュートを持てるので、
さらに味付け要素が増えることになります。

今回は、"hittime"と"life"を利用して、"hot"というアトリビュートをつくっています。
これは、シミュレーションが始まったらLifeが自動的に始まり、
寿命と共に0になるアトリビュートです。

これを使って、割れた断面が、熱く熱せられた状態のシェーダーを組んでいます。

また、Fractured Object Dynamicsをする際に、Pyroを使ったFluidも同時に計算しています。

これによって、断面から煙を出すことが出来る上、
そのFieldに、火花などを出すことが出来ています。

よりシミュレーションの空気感が出せているかと思います。

今回のモチーフに特に意味は無いのですが、
なんとなく、太古の封印が解かれた様な感じが出せていればと。。。

古から新への崩壊ってところでしょうか。

中身は色々迷ったんですが、金に、模様をつけるだけにしました。

今回一番大変だったのは、球体の模様をZBrushで描いている時かもしれませんｗ
はじめは楽しくて描いていたんですが、あまりの面積に、
普通のプロジェクションにすればよかったと後悔しました。。。

それで考えついたのがリングの方の模様です。
その時点で、手書きの心が折れていて、単純なテクスチャで行きたかったので、
般若心経をそれっぽく張るだけにしました。

思わぬいい味が出たのと、シェーダーがいい具合にハマって、
エナジーを感じる画になったかと思います。

CG WORLD (シージーワールド) 2011年 11月号 [雑誌]
クチコミを見る

Cartoon Effects

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

今回は、相棒の森江氏とのコラボレーション企画となります。
森江氏は、Animation Styleという連載をしていて、非常に優れたアニメーターです。
ちなみにBlogはこちら。0130.blg

以前から企画はしていたのですが、なかなかタイミングが合わず出来ませんでした。

この度ようやく、いい具合にコラボレーション出来たかと思います。

今回は、Mayaでアニメーションした物に対して、
カートゥーン調のエフェクトを付けていくと言う物です。

変わっているのは、3Dモーションブラーを作ると言ったところで、
単なるブラーではなくて、しかるべきところに、ゴーストブラーの様な、
漫画的なモーションブラーを作るアプローチです。

なかなかプロシージャルに出来たかと思います。

簡単な流れとしては、

FBXでインポートしたジオメトリに対して、モーションにリサンプルをかけて、
動きに応じた場所をチョイスして、パーティクルを発生させます。

パーティクルをつなぎ、それに対してメッシュを張ると言う物です。

単純なようですが、スマートにこなそうと思うと、なかなか難しいところが有ります。

実際、現状でも、改良すべき部分はたくさんあるので、
徐々にオプティマイズしていきたいですね。

この当時、MayaにはAlembicが付いていなくて、FBXを使いましたが、
記事を書いている現時点では、対応しています。

今後は、Houdini Maya間は、Alembicが一番早いかもしれませんね。

詳しくは、いずれ機会があれば話してみたいと思います。
文章で説明するのにも限界があるので…

CG WORLD (シージーワールド) 2011年 10月号 [雑誌]
クチコミを見る

Organism

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

この作品は、ある意味区切りです。
丁度連載12回目で、1年の節目ですね。

なので、色々復習も兼ねた作品になっています。

一つ目は、Houdiniのアセット管理の使いやすさを示し、
大規模なシーンを、以下に安価に制作するかと言う事に有ります。

これは、連載の記事自体では語ってはいませんが、非常に重要な事です。

Digital Assetを作って、作業の効率を上げています。
こうすることで、煩わしい設定項目を、大幅に削減できます。

二つ目は、Fluid,Particleの架け橋の話です。
Houdiniの特徴として、それぞれのネットワークに垣根がほとんど無いことがあげられます。

モデリングとパーティクルが、垣根なく繋げられると言う事は、
非常に大きな事で、それによって、オリジナリティのあるエフェクトを作る事が出来ます。

大きくは以上です。

この作品は、Organismと言った、非常に有機的な名前にも関わらず、
機械がモチーフで、なんとも整合性の無いものに仕上がっています。

はじめはそんな予定もなかったのですが、モデリングをしていくうちに、
機械化されていきました。

でも、機械で、有機体を表現できたら面白いかと思って、
チャレンジしてみる事にしました。

4つの点から、オーガニックさを出すことを試みています。

ひとつめは、球体のカバーに対して、SSSを入れている事です。
フェイクSSSですが、これを入れることで、工業製品っぽさが少し緩和される気がします。
（余談ですが、これはSTAR WARS EP2のグリーヴァス将軍の顔もSSSが入っているそうです。）

ふたつめは、球体の動きです。
カチッとした動きをさせたくなくて、先読み出来ないような動きを出すために、
パーティクルを1つだけ飛ばして、それに追従するようにしています。
この様にする事で、手付けでは付けにくい、ノイジーな動きを出しています。

みっつめは、Pyroで作ったシミュレーションに対して、
Particle Advection by Volumeを利用した動きをパーティクルに流し込んで作る、
ボリューム感のあるエフェクトです。
これにより、空間が表現でき、さらに重厚かつ、存在感のある物体へアクセントが付けられます。

最後に、空間に、ダストを舞わす事です。
シチュエーションが何処であると言う断定をしたく無いので、
水中とも、空気中とも取れるようなエフェクトを加えています。

これらを踏まえて、無機でありつつ、有機を取り入れた、掴みどころの無い画にしています。

あまり、技術よりになっても仕方ないので、たまには画に対するアプローチを書いてみました。

無から何かを作る事は、非常に重労働で、心身ともに厳しい時もありますが、
出来上がったときはまた一入ですね。

CG WORLD (シージーワールド) 2011年 09月号 [雑誌]
クチコミを見る

VEX Wave

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

VEX（VOP）を使用して、波のシェーダー、及びデフォーマーを作りました。

これは、画があまり自分で評価出来ないので、
少しブラッシュアップしてから掲載したいと思います。

内容自体は、非常に有意義な物なので、きちんと画を作ってから更新します。

申し訳ないです。

CG WORLD (シージーワールド) 2011年 08月号 [雑誌]
クチコミを見る

CGW155 Cover Art

CGWorld vol.155の表紙を作成しました。

大分遅い更新で、もう忘れ去られているかと思いますが、
一応順番で更新しないといけないかと思いまして。。。

これは、R.G.B.tokyoと言うチームと、弊社Transistor Studioで作成しました。
アートディレクターのデザインを元に、
モデリング、レイアウト、レンダリング、コンポジットで仕上げています。

CG WORLD (シージーワールド) 2011年 07月号 [雑誌]
クチコミを見る

RBD Chain

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

題材は、RBDを用いたチェーンのシミュレーションです。

チェーンなど、複雑に絡み合うものをシミュレーションする場合、
その多くは、Wire Solverなどでシミュレーションした、カーブなどに対して、
SOPを使った、ポスト処理で、チェーン化する工程などがあります。

しかし今回は、正直にRBDで処理してみました。

問題点として、初期設定のシミュレーションを処理しても、いい結果が出ないことにあります。
というのも、HoudiniのRBD Solverは、初期設定では、軽くするために、Substepをフレームごと、
つまり、1フレームにつき、一回の演算処理としています。

ところが、それだと、リング同士の干渉がうまく再現出来ません。
要は、1フレーム内で予測できない動きをしてしまった場合、
リングが外れてしまう現象が起きてきます。

これは、剛体シミュレーションにはあってはいけない事で、絶対的に避ける必要があります。
その場合、Substepを増やし、演算の精度を上げていく方法と、Collisionの精度を上げる方法、
この2つを取る必要があります。

Solverのパラメータには、演算の精度にまつわるものが羅列されています。

的確な数値を入れるには、実験的に色々試していくしかないでしょう。

実際、自分も、把握していないことだらけです。

今後、何らかの形で、検証していきたいと思っています。
アイディアがあれば教えてください。

また、これは脇役になってしまいますが、チェーンの両端を止めておく必要があったので、
それには、RBD Pin Constraintを使用しています。

Houdiniのダイナミクスには、様々なConstraintがあって、
これもまた色々と試せそうなものばかりです。

いずれガッツリとやってみたいですね。

CG WORLD (シージーワールド) 2011年 07月号 [雑誌]
クチコミを見る

Liquid Ball

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

SPHを用いたフルイドシミュレーションの例です。

このプロジェクトは、困難を極めるものでした。

自分自身が、あまりSPH Fluidを用いたことが無いのと、

基本的なアプローチで、ミスを連発したりと、なかなか画に出来ずにいました。

なので、更新が大幅に遅れてしまいました。

（実際、ちょっと萎えていた部分も有りますが…）

鉄はアツイうちに打つべきですね。

今回は、SPHを用いたわけですが、

Flip Solverを使わなかった理由は、

Flip Solverの性質上、質量を保ちにくいという事にあります。

今回のシチュエーションでは、ボールの中に、

一定量の液体が保たれなくてはいけないので、

結果、Flip Solverを使用できないのです。

反面、SPHは、Substepなどの兼ね合いで、暴発しやすくもあります。

ただ、それに関しては、時間をかければ解決することなので、

アプローチの仕方には関係の無いことですね。

Flip Solverは、非常に軽いです。

ただ、シチュエーションとしては、もっと広範囲なものや、

範囲に縛られないものに向いていると言えます。

反面、SPHは重く、レスポンスは悪いですが、

非常にリアリスティックにシミュレーション出来ます。

続いて起きた問題は、

SPHのパーティクルにメッシュを張る際に起こる、

コリジョンとの整合性の問題です。

ある程度、高密度なシミュレーションをしても、

メッシュを張った際に出来てしまう隙間の問題です。

特に今回は、コリジョンとなる球体がガラスですので、

その隙間は如実に出てきてしまいます。

そこで、無理やり、ガラス付近に接しているメッシュを、

Ray SOPでぴったりとくっつけてあげます。

実際にはこれでも隙間はあるのですが、幾らかはましになります。

最後の問題は、モーションブラーです。

今回は、Velocity Blurを使っているのですが、それがそもそもの間違いで、

本当は、mantraのGeo Time Samplesを上げて、Deform Blurを有効にするべきでした。

ちなみに、以前はDeformとTransformのMotion Blurが分かれていたのですが、

バージョンを重ねるごとに仕様が変わってしまいました。

恥ずかしながら、Geo Time Samplesをついこの間まで知らず、

Velocity Blurばかりを使って、なんでいちいちVelocity付けなくちゃいけねぇんだよと、

Houdini様のせいにしていました。

無知とは罪です。

そのため、Velocityを利用していたのですが、そうすることで、

球体が静止状態の時に、中の液体が激しく動けば、

ガラス球から液体だけのブラーが飛び出すという、

なんとも間抜けなエラーを重ね、さらには、

球体付近の液体のVelocityを球体自体のVelocityを使ってねじ曲げるといった、

なんともお粗末なアプローチをとってしまっています。

そのせいで、表面に、変なモヤモヤが出てしまっています。

教訓もかねて、あえて恥を晒そうと思います。

非常に反省点の多い作品になってしまいました。

次回に活かしていきたいですね。

CG WORLD (シージーワールド) 2011年 06月号 [雑誌]
クチコミを見る

Strawberry Crash

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

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

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

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

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

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

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

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

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

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

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

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

Wire to Plasma

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Procedural Jellyfish

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

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

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

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

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

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

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

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

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

が、、、

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

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

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

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

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

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