Go procedural | Houdini campaign

by syoyo

http://www.sidefx.com/index.php?option=com_content&task=view&id=1548&Itemid=66

go procedural と称して、houdini が半額キャンペーンやっています.
これを機会にちょっと Houdini 環境も整備しようかな.

go procedural プロモーションでは、なぜプロシージャルベースの手法が必要か、以下のように述べられています.

CG 業界は爆発的に成長していますが、スタジオは多量の高度にリアルな視覚効果のショットを、
少ないリソースでこなしていかなくてはならなくなってきています.
この爆発的増加を解決するために、多くのスタジオは Houdini を利用したプロシージャルな手法を選択しています.

これを読んで、こんなことを想像しました.

– ユーザの目は越えてきており、高品質で物量のある VFX を作らなくてはならなくなってきている.
-> 人手でそれを解決するには自ずと限界がある
-> よって、モデリングやアニメーションをプロシージャルでやることでその問題を解決しようというのが Houdini の go procedural なのだろう
-> ではそうなったとき、レンダリングはどうなるか?
-> プロシージャルで多量に複雑に生成されたジオメトリ、テクスチャをレンダリングするには高速、高品質なレンダラが必要だ

… というわけで、これからはレンダラも高速、高品質、プロシージャル対応なものが必要とされてくるに違いない!
まあ物量が増えて、求められるクオリティが上がってくるのは間違いないので、その点では go procedural は、
大規模でも高速にレンダリングするという lucille の方向性とマッチしています.

lucille をプロシージャルに強いレンダラにしてみましょうかね.
もちろん、プロシージャル対応はどのような形式になるにしろ、対応は必須となるでしょうが.
(たとえば RIB の Procedural, MentalRay で言う Geometry shader 機構のサポート).

プロシージャルに強い、というのは、プロシージャルのためのインターフェイスを用意するだけでなく、
レンダラ側で、プロシージャル専用言語を用意するとか、プロシージャルコードを Python で書けるとか、
マルチスレッドでもスケールアップしてプロシージャルのコードが動作するとか、
(MR の Geometry shader とかは、明示的にやらないとシングルスレッドコードとして実行されるんじゃないかな?)
Houdini の procedural コード(VEX?)と連携できるとか,
そんなあたりの、プロシージャルを書き、そして実行する部分を効率化することを強化するということになります.

Advertisements