【倉地紀子のデジタル映像最前線レポート】映画『2012』 CG シミュレーションの新境地　11月２１日(土)、丸の内ルーブル他全国ロードショー　配給：ソニー・ピクチャーズ　エンタテインメント（3)

＜＜プロジェクト最大規模のR&D　剛体シミュレーション＞＞

　（（２）より続く）『2012』のプロジェクトで最大規模のR&Dが必要とされたのが、新たな剛体シミュレーション・システムの開発だった。５人の開発スタッフが４ヶ月以上をかけて取り組んだという。

　剛体シミュレーションに関していえば、もっとも手っ取り早いのはHoudiniの剛体シミュレーション機能を使うことだが、その方法論には今回の目的においては致命的な問題点があった。

　まず、第一の問題点は速度だった。

　前述したように、今回は広大なシーンに散在するありとあらゆる物体の破壊を、同時進行で進めてゆく必要があった。当然のことながら一度のシミュレーションで満足のゆくアニメーションが完成することは滅多になく、何度もシミュレーションを繰り返すことが必須となる。
　そのようなフィードバックという要素も含めて考えると、既存のツールとは比較にならないほど高速な計算機能が求められたのだった。

　そして速度と同様に既存のツールの致命的な問題点と判断されたのが、操作性だった。


＜＜ハリウッドで重宝されるHoudiniの特徴はポイント・ベースのコントロール＞＞

　そもそもハリウッドでHoudiniのシミュレーション機能が重宝がられるところには、このツールの特徴となっているポイント・ベースのコントロールが映画制作に非常に向いているからだった。

　このコントロールのフィロソフィーは、シミュレーション全体のコントロールをグローバルな設定によってではなく、点の集合を用いたローカルな設定によって巧みにコントロールできるということだという。

　たとえば、ビルに飛行機が衝突して引き起された破壊が次第に周りに広がってゆくというシミュレーションを設定する場合を考えてみてほしい。
　アーティストにとって直感的にわかりやすい手段で、飛行機の衝突した周辺部分を設定するだけで、最終的にビル全体の破壊というグローバルなエフェクトまでも、予測したとおりに生成できる。これは、映画制作における理想的なシミュレーションの形態といえる。

　Houdiniのポイント・ベースのコントロールはまさにそういった理想形に近いフィロソフィーをもっているのだが、残念ながら剛体シミュレーション機能に関しては、そのフィロソフィーが存分に反映されていないのだという。

　それゆえに今回、デジタル・ドメイン社では、速度と操作性の大幅な向上を目指して、新たな剛体シミュレーション・システムが開発されることになった。


＜＜オープン・ソースから新たなシミュレーション方程式を探索＞＞

　速度に関していえば、剛体シミュレーションの計算速度の根源を担っているのは、剛体の運動方程式を解く工程だ。

　R&Dはまず、この方程式を高速に解くソルバーをオープン・ソースから探す作業から始めた。
　最初に候補に挙がったのは、ゲーム・エンジンとしても活用されているODEというオープン・ソースだったという。しかし、ODEの場合には知名度が高まってきているだけに、その性能もすでに知り尽くされている。限界が見えているといってもよい。
　どうせなら未知の可能性を秘めたより将来性あるものをということで、目がつけられたのがBulletというオープン・ソースだった。

　こちらも一部のゲームでは、すでにコア・エンジンに取り込まれた経緯をもっている。しかし、まだまだ図り知れない潜在能力を秘めている。
　加えて、偶然にもこのオープン・ソースの作者の友人がデジタル・ドメイン社のR&D部門に所属していた。
　やはりソースの原点をつくりだした人物と共に開発を進められることの強みは大きい。

　そして、実際にテスト開始してみると、このオープン・ソースの性能はおもいのほか高く、速度的にも今回のプロジェクトでの使用に耐えられると確信できるものだった。そこで、Bullet をコア・エンジンとしたHoudiniのプラグインとして新たな剛体シミュレーション・システムを開発するという方向性がとられることになった。

　これがDropと名づけられた剛体シミュレーション・システムだ。


＜＜新たな剛体シミュレーション・システム「Drop」の誕生＞＞

　速度の問題はBulletの導入によってほぼ解決したともいえ、Dropの開発ではもう一つの大きな課題である操作性に重点が絞られた。
　
　様々な嗜好錯誤のすえにたどり着いたのは、たとえていえば、ちょうどサブサーフェース・スキャンタリングのような複雑で物理的に正確な特徴をもったシェーディング機能をテクスチャでコントロールしようという方法論によく似ている。

　ただし、シェーディングの場合には最終的に算出するのが物体表面の見え方であるため、物体表面に2Dテクスチャをあてがってコントロールとおこなっていたが、破壊の場合には物体の内部がどのように変化してゆくかを計算するためのボリュームメトリックなコントロールが必要される。

　したがって、剛体シミュレーションの操作性のイメージとしては「3Dテクスチャを用いたコントロールに相当する方法」が適用されたという。

　たとえば、ビルに飛行機が衝突してビルが破壊するというケースを例にとって、その破壊の進行をグレースケールの3Dテクスチャでコントロールすることを考えてみる。

　飛行機が衝突した部分に隣接したボリュームは真っ先に吹き飛ぶことになるので、この部分のボリュームには黒をあてがう。

　隣接部分の少し上と下にある部位はすぐには吹き飛ばずに、少しの間は形状をそのままにもちこたえたのちに崩壊して吹き飛ぶことになるので、この部分のボリュームには濃いグレーをあてがう。

　さらに上の部分はもう少し長くもちこたえたのちに崩壊するため、この部分のボリュームにはいくぶん明るめのグレーをあてがう。

　一方、濃いグレーをあてがった部分の下側は、最後までもちこたえる土台の部分に相当することから、この部分のボリュームには白に近いグレーをあてがうことになる。

　実際には上記のような単純なコントロールですむケースはほとんどない。


＜＜3Dテクスチャ設定にもさまざまな工夫と多様性＞＞

　さらに、アーティストにわかりやすい形で複雑なコントロールができるようにするために、3Dテクスチャ設定にもさまざまな工夫が凝らされた。

　だが、いずれしてもこのような直感的なコントロールをむつびつけることが、監督から舞い込む数々の要請に対して、非常に快適に対応することのできるシミュレーション環境を整備することにつながったことは確かだといえよう。


　しかし、実際にアーティストがシーンを作成する上で、真に快適なシミュレーション環境を整備するためには、上記のようなシステムの構築だけでは、まだまだ不十分だった。

　今回の破壊シーンで必要とされるシミュレーションは実に多様性に富んでおり、なおかつ膨大なものだった。

　たとえば、同じ飛行機が衝突した場合でも、それがビルではなく、家屋であったり、岩山であったり、森であったりした場合には、その破壊の様子はビルの場合とは違ってくる。

　同じく、たとえば「ばらばらに砕ける」という表現があったとしても、それがガラスの窓である場合と、岩石である場合と、紙でできた物体である場合とでは大きく変わってくる。

　こうしたパターンは、丹念な設定を繰り返すことによってつくりだすことはできるが、それではあまりにもアーティストの作業負荷が重くなる。したがって、つくりだしうる表現の世界を、いくつかのカテゴリーに分割し、それぞれの表現カテゴリーごとに“雛形”に相当するものを準備することが考えられた。

　たとえば、「ガラスが割れる」「岩石が砕ける」「コンクリートの塊が崩壊する」「紙がちぎれて飛び散る」などという表現は、それぞれの別のカテゴリーに属した雛形として準備された。

　また、これらの雛形には、あらかじめシミュレーションによって算出しておいた結果を再利用するという考え方も生かされていた。

　アーティストはこれらの雛形の中から適切なものを選択し、それに対してアーティスティックな側面から設定を加えて、表現すべき破壊シーンを完成させる。

　これによって、シーンに登場する個々の破壊表現に対して、システムにゼロから設定をあたえてシミュレーションを繰り返すよりもはるかに効率よくなおかつアーティストがアーティスティックな側面の作業に集中できるようなパイプラインが完成したのだった。

【写真解説】
（剛体シミュレーション・システム「Drop」を使用したシーン）
　Dropの最大の特徴は、アーティストにとってちょうど絵筆で絵をかくような、
直感的にわかりやすいシミュレーションのコントロールを可能にしたことだった。
様々なコントロール手段が提供されていたようだが、基本的にはテクスチャをベース
にしたコントロールが主軸となった。
　破壊シミュレーションでは、塊を割って塊を生成してゆく。シミュレーションが扱う対象がボリューメトリックであるゆえに、コントロールに用いられるテクスチャも2Dテクスチャではなく3Dテクスチャとなっていた。

　ここでは、そのコンセプトを最も単純な例を用いて説明する。たとえば、ビルに飛行機が衝突してビルが破壊するというシーケンスがあった場合に、その破壊の進行をグレースケールの3Dテクスチャでコントロールすることを考える。

　そして、色が濃いほど破壊のおこるタイミングや進行速度が速いと想定する。常識的に考えると破壊が進行してゆく順序は、
　①飛行機が衝突した部分　
　②　①に隣接した上下の部分　
　③　②に隣接した上側の部分　
　④　②に隣接した下側の部分
　　となる。
　したがって、テクスチャを用いたコントロールでは、3Dテクスチャのグレースケールを、この順序で黒から白へと次第に薄くしてゆくというのが、基本的な考え方となる。

（PolyBuster + Dropの見せ所：写真上から２ー５番目）
　地震によって山や地面が割れて、その壁面がむき出しになったシーンの表現は、PolyBuster + Dropのまさに腕の見せ所だったといえる。延々と何マイルも続く割れ目のいたるところで、割れ目はさらに分岐して広がり、それまでにはなかった岩肌が姿を現す。このような表現をアーティストが手作業でつくりだすことは到底不可能で、実質的にはモデリングからアニメーションに至るまでのすべてがPolyBuster + Dropによって自動生成された。

step1
　大雑把なシーンの設定と手作業でモデルやアニメーションを作成したオブジェクト。

step2
　岩肌から崩れ落ちる岩石などは、そのモデルからアニメーションに至るまでがすべてPolyBuster + Dropによって自動生成された。

step3
　建物などに関しても、もとになるモデルは手作業で作成されたが、いったん破壊がはじまったのちのアニメーションはすべてPolyBuster + Dropによって自動生成された。ただし、同じ「崩れ落ちる」アニメーションでも、岩肌の岩石が崩れ落ちる場合と、建物のコンクリートの破片が崩れ落ちる場合とでは、その動きは明らかに違ってくる。破壊シミュレーションのパイプラインでは、それぞれのケースをあらかじめ雛形として準備し、アーティストがゼロから破壊シミュレーション・システムに設定をおこなわずともその違いを的確に簡便に表現できるように工夫されていた。

　step4
　テクスチャリングやライティングによってさらにリアリズムを高めたものが最終映像となる。