3の正式対応を謳い、そのビジネス展開のスピードが非常に素早かったこと、そして当時の日本の開発者にとっては難解に見えたプログラマブルシェーダーアーキテクチャのGPUをいとも簡単に使いこなした風情のテクノロジーデモを矢継ぎ早に公開していったことで、日本でも知名度の高いゲームエンジンとなった。「UE3」の開発マニュアルが完全な英語ベースであったこと、「UE3」日本語ローカライズチームが北米側に存在したために技術サポートのやりとりに時差問題がつきまとってしまったこと......などが足を引っ張り、欧米の開発スタジオと比べると、日本での採用率は当初彼らが予想していたよりは伸びなかった。Gamesでは、2009年後期より日本法人の設立に動き出す。2010年現在は、「エピック・ゲームズ・ジャパン合同会社」として南青山にオフィスを構え、日本およびアジアパシフィックエリアのゲーム業界に向けて「UE3」ビジネスの布教活動を本格始動させた。”的な2005年当時、日本のゲーム開発シーンは「UE3」ビッグバンで度肝を抜かれたものだが、あれから5年経った2010年の現在では、大手ゲーム開発スタジオは、すでに各社独自のゲームエンジン、あるいは開発フレームワークを完成させてしまっており、「UE3に対する視線」はあの頃とは明らかに違ってしまった。インディペンデント系開発スタジオにおいては、まだ、「UE3」を訴求していける余地はあると思うが、心配なのは「UE3」はライセンスフィーが高価だという点。予算を多く取れないそうした中小スタジオにとっては、その部分が障壁となるはず。「UE3」のようなユニバーサル型ゲーム開発フレームワークはゲームの開発を「早く」行なえるかもしれないが、「安く」は行なえないという“現実”が浮き彫りになりつつあり、この部分でどう折り合いを付けていけるかが、「UE3」が今後日本で成功を収めるためのキーポイントになりそうな気がする。エピック・ゲームズ・ジャパンの活動には、今後、注目していく必要があるだろう。【【プロモーションムービー】】UDKの優秀作品紹介ムービー。Gamesは、今年も、「UE3」を進化させた。「UE3」専用シェーダー・オーサリングツールともいえるマテリアルエディターが進化した。「UE3」マテリアルエディターはシェーダー基本要素を組み合わせてオリジナルの材質(マテリアル)表現が作成できる強力なツールだが、2010年版「UE3」(以下「UE3-2010」)では頂点変形の属性設定の要素が追加され、作成したマテリアルに対してゲームシーンの状況変化などと相互にインタラクトして自己変形することができるようになった。ゲームシーン側で制御される熱パラメータに応じて熔解する表現などがマテリアルエディターの設定で行なえるようになる。パーティクルエディタでは、作成したパーティクル・アニメーションに対してゲームシーン側からのライティングが適用できるライトボリューム表現の作成ができるようになった。「UE3」のグラフィックスエンジンの根幹部分については、影生成/ライティングシステムが進化させられたことも報告されている。これは、遠方の影生成に関しては静的なライトマップを適用するが、視点からの距離に近い領域に関しては、非常に高解像度な動的な影生成を行ない、これをシームレスに繋ぐというテクノロジーだ。Detail)実装ということができるかもしれない。Willard氏は語る。デプスシャドウ技法ベースの影生成を用いての複雑なジオメトリ構造シーンにおける影生成は、「均等な品質を維持する」意味において難しい。シャドウマップをカスケードさせて生成させることで、シャドウマップの使用効率を均一化させる工夫も考案されているが、ジャングルのようなシーンでは費用対効果においてあまり芳しくない。「究極の描画品質よりもパフォーマンスを重視する」という向きならば、たしかにこの「UE3」の実装は優れているかもしれない。ちなみに、このテクニックは「ソニック・ワールド・アドベンチャー」でも利用されているものであり、詳細については本連載の「ソニック・ワールド・アドベンチャー」編を参照してほしい。「UE3-2010」のデモとして製作されたジャングルシーン。ジャングルはCRYTEKが好んで用いてきたモチーフだが、今回あえてぶつけてきたのはライバル意識から?「UE3-2010」では、いくつかの新しいツールが提供される。1つ目は「メッシュ・ペインティングツール」だ。これは、そのシーンに適用するマテリアル種類として最大4つを選択し、これらを1つずつ頂点カラーのαRGBの4要素に割り付け、その割り当てたマテリアルを絵の具の“色”のようなイメージでマウスポインタで適当に選択して3Dモデルやシーンに塗っていくことで、境界レスなマテリアル分布をデザインできるツールだ。頂点カラーをマテリアルIDとして用いて、その分布を描いていく......というイメージだろうか。デモでは、頂点カラーの赤が苔、青が泥という割り当てで、シーンの頂点カラーの赤を塗った部分に苔が生え、青に塗った部分が泥となり、赤と青の両方が塗られた部分は泥と苔がミックスされる表現となっていた。頂点カラーは、通常は頂点単位のライティングを行なった際の色を格納しておく領域だが、「UE3」ではこれをマテリアル分布の焼き込み用途属性に使うことができるというわけだ。動的に更新も可能であるため、戦争ゲームでは、たとえば背景に飛び散った血糊を表現したり、銃弾が着弾した部分のダメージ表現などにも使えるはずだ。頂点カラーに静的な影などを焼き込むのはよく用いられれるが、マテリアル分布を頂点カラーに埋め込むというのは面白い。1つは「スプライン・デフォメーション・ツール」だ。これはある単一の3Dモデル部品を構成するポリゴン群をスプライン高次曲線に沿う形で自在に変形させられる機能だ。変形後は3Dシーンを構成する部品パーツとして利用できるが、3Dモデル情報は基本モデルの1つだけでよく、変形後の3Dモデル情報そのものはいらないというのがウリ。触手のパーツとなる棒状の短い円柱モデルを用意し、これを1つ1つくねくねと自在に曲げて繋いでいけば触手の表現ができる。一般的には、長い触手を構築すればするほどその触手を構成する部品モデルの情報がかさみ大きくなっていく。この「UE3」の手法を用いれば、どんなに長い触手をシーンに構築しても、GPU側が持っておかなければならない3Dモデルデータは基本の円柱1個だけでいい。GPU側の描画自体はインスタンシングを用いて行なわれるため、単一の3Dモデルを、複数回コピー&ペースト的に描画しているのと変わらない負荷となる。これまでは同じことをやろうとすると、触手を構築する部品3Dモデルのバリエーションをたくさん持たなければならなかったが、単一の3Dモデル部品をGPU側に転送後は、その3Dモデル部品の位置情報と変形情報だけで描画できてしまう。見方を変えると3Dシーンの高効率圧縮、あるいは描画コマンドオーバーヘッドの劇的な低減に結びつけられるテクニックと言うことができる。「触手だけでなく、ロープ、建物同士や電信柱を繋ぐケーブル、架橋上の道路やモノレール表現、応用すれば、なにかの溶解表現にも使えるだろう」(Willard氏)。Tool」(アンリアル・ファサード・ツール)だ。このツールは、屋外の街のシーンを作る際に威力を発揮するもので、少ない手間で説得力のある建物3Dモデルを生成し、シーンに配置することまでができるものになる。デザイナーがやるべくきことは、まず、建物を建てたいところに箱を置くことから始める。箱の大きさは建物の大きさや高さを表わし、箱を置く位置は建物を建てる位置に相当する。ひとたび箱を置いたら、窓の形、入り口の位置、入り口の大きさ、建物の各層の高さを設定すれば、その設定したとおりの建物がシーンに建つ。レベルデザインツールのような、もっといえば使用している雰囲気は「シムシティ」をプレイしているようにも見えて、楽しげであった。建った建物はそうした設定のテクスチャが適用されるのではなく、ちゃんと、各階には立体的な窓枠が付き、ベランダが付き、入り口には扉も付く。「まさにプロシージャル」といった風情だ。建物は必ずしも直方体である必要はなく、段差のある建物、円柱状の建物、複数の頂上階があるような複雑な形状の建物も生成できる。その場合、扉や窓、屋上の繋ぎ部分が不自然にならないような、実在の建物の設計にもあるような建築ルール補正が行なわれて生成されるという。各ビルの地上階に関しては、店舗階にすることもできる。様々な店舗とすることで、実際の街のように息づく街というか、生活感のある景観作りが行なえる。ENGINE的な機能はあるのか」と質問してみたところ「ない。Toolはあくまで建物を配置していくことを支援するツールでオートメーションツールではない」とのことだった。生成されて配置されたビルディングのレンダリングは、ちゃんとグラフィックスエンジン側のLODシステムに配慮された形で行なわれる。遠距離にある建物は、テクスチャを張りつけただけのシンプルな低ポリゴンモデルとなるため、描画境界を感じさせない、エピックスケールな都市景観をハイパフォーマンスに表現できるのだ。Softwareとのコラボレーションも発表している。Gamesが「UE3」のパブリッシング、メンテナンスにおいて利用するというもの。ライセンシーは以降、追加料金なしで、アップデート管理や開発メンバー間の情報共有、ライセンス管理などにおいてSteamworksに統合されるようになる。パートナーシップがらみとしてはもう1つ、Autodeskとの技術提携が今回発表されている。Max」、「Maya」といったDCCツールで製作した様々な3Dデータを、Autodeskが提唱するFBXデータ形式で相互にやりとりする仕組みが、「UE3」においても行なえるようになった。Autodeskのプロシージャル人体アニメーション・ミドルウェア「HumakIK4.5」が「UE3」に対応することも報告されている。「HumanIK」は「あらかじめ制作しておいた人体モーション」、「斜面、壁などのそのゲームシーンから受ける外的制約/障害」、「人体が持つ動き特性シミュレーション」の全てに配慮した挙動をプロシージャル生成する強力なミドルウェアだ。「HumanIK4.5」から、正式に「UE3」への対応が行なわれたことで、「UE3」上の人体キャラクターを、「HumanIK4.5」のアシストを加えて「UE3」のダイナミックシーンで動かせるようになる。「UE3-2010」は立体視に対応。NVIDIAブースでも「UE3-2010」の立体視デモが行なわれていたさらに、「UE3-2010」が、正式に立体視に対応することも発表された。360のコンソール機版の「UE3」においても立体視をサポートする。具体的には、2視点からの立体視用のレンダリングオプションを「UE3」側で正式にサポートしたというだけであり、ゲームプログラム側をほとんど触らずに、「UE3」ベースゲームの立体視対応が行なえる......としている。「UE3-2010」だけでなく、2009年末に公開された非商用/教育用の無料版「UE3」である「UDK」も立体視に対応するとのことだ。Defense」のプレイデモも行なわれた。Gamesも例に漏れず、この分野への進出を表明している。会期中、iPhone版の「UE3」が公開されたことは、大きなセンセーションを呼んだが、真相としては、「UE3がiPhoneに移植された」のではなく、「UE3のグラフィックスエンジンがOpenGL/ES2.0への対応を果たした」ということのようだ。Adams氏によれば、「開発は自分も含めてわずか2人で行なった。開発がスタートしたのは2009年10月から。『UE3』で開発したプロジェクトであれば、システムのメモリ容量が十分で、OpenGL/ES2.0ベースの携帯機器向けGPUが搭載されていれば、このモバイル版『UE3』上で動かすことができる」とのこと。今回のGDCでは、iPhone版「UE3」とは別にNVIDIAの組み込み向けGPUのTEGRA2版の「UE3」も同時に公開されたが、これは両者同じOpenGL/ES2.0ベースのGPUを搭載しており、根本的には同じモノだ。それぞれのGPUがサポートしているシェーダー機能の限界が異なるため、ターゲットGPUに合わせた最適化(というよりもスペックダウン?)を行なっている。iPhoneとTEGRA2でいえば、TEGRA2の方がGPU世代が新しいため、表現力はTEGRA2版の方が上になる。7版の「UE3」の登場もあり得るのだろうか。「『UE3』は美しい先進グラフィックスがウリであり、プログラマブルシェーダーが動かないプラットフォームへの移植は難しい。7で利用できるグラフィックスフィーチャーは非常に限定的であるため、『UE3』のプラットフォームとしては適さないと言わざるを得ない」(Adams氏)。7で提供されるグラフィックス機能はプログラマブルシェーダーは非サポートであり、ポリゴンに適用できるテクスチャも2枚までという大きな制約がある。iPhoneと比較するとGPU世代のギャップが大きく、「UE3」を動作させるのが無理というのもやむなしといったところか。「UE3」のセカンドチャンスは携帯版「UE3」にあり?OpenGL/ES2.0版の「UE3」は今後、注目すべき存在となるかもしれない。日本では携帯電話および携帯ゲーム機でのゲームプレイがメインストリーム化してきており、こちらの分野のゲーム開発に携わっているゲーム開発スタジオはまだプログラマブルシェーダーアーキテクチャのグラフィックスには慣れていない。ハードウェアは確実に進化していくため、“きわめて”近い将来、携帯電話および携帯ゲーム機のグラフィックスの主流がプログラマブルシェーダーアーキテクチャベースに移行することだろう。「UE3ビックバン」は、もしかすると今度は携帯プラットフォームで巻き起こるかも知れない。サポートは、このための布石なのか。