The Sands of Dune (Dune の砂)

フランク・ハーバートの名作 SF 小説「DUNE/デューン 砂の惑星」が、ドゥニ・ヴィルヌーヴ監督によって映画化されました。舞台となる惑星アラキスでは、派閥が対立し、砂漠の世界の希少資源であるスパイスの支配を巡って争います。

広大なスケールで繰り広げられる「DUNE/デューン 砂の惑星」で、DNEG の FX 部門はいくつもの大きい課題に直面します。作業は 3 チームに分けられ、SideFX Houdini がメインのツールとして使われました。バンクーバーでは、Gero Grimm 氏と Chris Phillips 氏が FX リード、Lisa Nolan 氏と Albert Szostkiewicz 氏が FX スーパーバイザーを務め、砂のシミュレーションと街の破壊の作業を担当しました。また、モントリオールのリードたちが、惑星カラダンの海のシミュレーションをはじめとするタスクを担当しました。

Grimm 氏が率いるチームの最大の課題は、砂漠を突き進む巨大なサンドワームが登場するショットでした。Grimm 氏は言います。「最も大切なのは、スケールを示すことです。砂は単純なようで、極めて複雑です」

サンドワームショットの大半でエフェクトチームの出発点になったのは、背景チームから提供された砂漠の風景です。「背景チームは、砂漠を Houdini だけで作成していました」と Grimm 氏。

シミュレーションは、サンドワームのブロッキングアニメーションでトリガーされます。サンドワームのモーションが、砂丘の Height Field の崩壊を駆動します。Height Field の浸食、変形、シミュレーションには、Houdini のツールや、FX TD の Ivan Larinin 氏が開発したカスタムの「dune ソルバ」を使いました。Larinin 氏は言います。「dune ソルバのおかげで、大規模なシミュレーションを行わずに、素早く砂丘の形状を生成できました。VEX や C++ でツールを実装しようと試みましたが、この映画に必要とされる膨大な砂漠を生成するには、スピードが不十分でした。OpenCL を使って作成した結果、10 倍以上のスピードで生成できました」

アーティストは次に、Vellum を使用して、砂丘の全体的な動きをシミュレートしました。シミュレーションを重ねて、ディテールを追加しています。Grimm 氏が説明します。「サンドワームの速度を Height Field に転送しました。それを使用して、Vellum シミュレーションと砂丘の崩壊を駆動およびトリガーしました。その後、それに対してセカンダリパーティクルシミュレーションを実行し、Vellum シミュレーションで砂の塊を時間軸で放出してから、モーションをより詳細かつ複雑にするためにパーティクルを追加しました。また、埃のシミュレーションも加えています」

大いに参考になったのは、砂漠用バギーやトラクターのビデオリファレンスです。チームはまた、砂丘固有の物理的性質を詳説した科学論文も探し出しました。たとえば、乾いた砂の「安息角」は約 32 度で、砂丘の側面がこの角度に達すると平衡状態となります。しかし、その構造はもろくもあります。「砂丘では、砂は転がって移動するため、どの砂粒も完全な球体です。そのせいで、非常に不安定です。底の方の砂をひとつかみ取るだけで、全体が崩れていきます」と Grimm 氏。

砂の爆発に関する研究では、爆発では塊になることが明らかになりました。ただし、空気抵抗によって、塊の外側表面は内側よりも速く崩壊します。DNEG チームは、これをシミュレートする Houdini スクリプトを作成しました。Grimm 氏は言います。「フレーム単位で砂の密度を計算しました。砂の密度が低い場所では、抵抗を高くしました。つまり、大きい塊は通常の重力にしたがって落下しますが、密度が低い場所の砂は、流れ落ちて消散します」より大きいスケールでは、内側の砂の崩壊はそう重要ではありません。波動、崩壊、渦巻く旋風という形で表れる乱気流のエフェクトの方が重要です。「通常のパーティクルシミュレーションで、このような乱気流すべてに対応できるわけではありません。そこでソルバを自作しました。パーティクル DOP シミュレーションと、VDB Project Non-Divergent といったツールを組み合わせて計算を実行し、個々の独立したパーティクルではなく、ボリュームのように動作させました。非常に良いディテールが得られ、ただ真っすぐ地上に落ちるだけの砂ではなくなりました。さらに、周りに舞う埃のシミュレーションも行って、全体を包み込むソフトなレイヤーを作成しました」

早期の砂のシミュレーションテストで分かったのは、ボリュームレンダリングとジオメトリレンダリングでは対処できず、ポイントベースの手法が唯一の選択肢であるということでした。Grimm 氏は言います。「大量のポイントを使わないと、見栄えが良くなりませんでした」エフェクトチームにとって、これは難問です。「砂丘には何千億ものポイントがありますが、すべてをレンダリングするのは不可能です」

鍵は、最適化でした。Grimm 氏は、ジオメトリの背後 (たとえばサンドワームやスパイス採掘者) や、前景のポイントの背後に隠れているポイントを特定する Houdini ツールを作成しました。「このスクリプトは、サンドワームやパーティクルの最初のレイヤーを識別し、その背後にあるすべてを削除します。レイトレーサーの仕組みに似ていますが、SOP による組み込みです。レンダーのプライマリのレイが認識しないものは、すべて削除したわけです。大量のポイントをカリングできました」と Grimm 氏。

このアプローチによって、エフェクトアーティストは Mantra ですべてレンダリングし、ビジュアルエフェクトスパーバイザから承認を得てから、比較的軽量な VDB ポイントクラウドをエクスポートできました。DNEG の R&D 部門は、VEX 構文を使用してポイント複製ツールを開発し、ショット固有の Houdini 設定を後工程に転送できるようにしました。Isotropix Clarisse でのライティングやレンダリングも可能で、移動しても情報が失われません。最終レンダリング時には、ポイント数は最大 100 倍まで増加しました。一番大きいサンドワームのショットでは、この数は 5 億ポイントに迫りました。

こういった効率化にも関わらず、シミュレーションオプションのイテレーションは時間のかかるプロセスです。Grimm 氏も同じ考えでした。「デイリー (レビュー) は行えませんでした。3、4 日ごと、ときには 1 週間空いたこともありました。データが膨大だったからです」これを迅速化するため、チームは大規模なシミュレーションをより小さいクラスタに分割しました。「うまくやれば、クラスタが相互に作用していないことは分かりません。実際には小規模な 20 のシミュレーションだとしても、1 つの大規模なシミュレーションのように見えます。全体のシミュレーションに 30 時間かけるかわりに、各シミュレーションを 30 分ほどで済ませられます」

FX リードである Grimm 氏は、個々のアーティストが障害を切り抜けられるよう頻繁にサポートしました。「アーティストも行き詰まることがあります。あちこちいじって適切な設定を探そうとしても、シミュレーションは思うように進みません」そんなときには、Grimm 氏は重要な要素 1 つに集中するようにとアーティストにアドバイスします。「サンドワームが砂の中を動くシーンで、本当に重要な部位はおそらく口先です。それならば、口だけをシミュレートし、うまくいくまですべてのフォースを調整した後で、変更を全体に適用します。私はこれを「頭のもつれをほどく」と呼んでいます！」

Gero Grimm 氏はプロジェクトを振り返ります。DNEG のエフェクトチームが「DUNE/デューン 砂の惑星」の驚異的な砂を作るために必要なツールは、Houdini が大半を与えてくれました。「ポイント複製ツールは R&D 部門が担当しましたが、それは DNEG が自社開発した OpenVDB データシステムを使用していたからです。それ以外は、ほとんど Houdini だけで作業しました。どのアーティストも、担当のショットを作業するために Houdini で自前のツールキットを開発しました。それをアーティストたちが共有したのです。素晴らしいコラボレーションでした」