ゲーム
スマートフォン
タブレット
Android
OpenGL
移植

Havok Vision Engine* を Android* プラットフォームへ移行する

同カテゴリーの次の記事

インテルが提供するモバイル・アプリケーション開発向け HTML5 ツール

この記事は、インテル® デベロッパー・ゾーンに掲載されている「Porting the Havok Vision Engine to Android* Platforms」の日本語参考訳です。

モバイル・プラットフォーム革命

私が知る限り、3D エンジンを携帯電話へ移行しようとする最初の試みは 2000 年代初期に Superscape* 社により行われました。Superscape* の Swerve* エンジンを ARM7 で実行できるようにするため、Superscape* は OEM 数社と協力して取り組みました。当時の ARM7 ベースの携帯電話の CPU は約 40MHz で、キャッシュは搭載されていませんでした。実行可能なコンテンツは、テクスチャーや Z バッファーを使用しない最大 40 個のフラットシェードの多角形でした。これは、すべてのアーティストにとって挑戦と言えました。その後登場した、キャッシュを備えた 100 MHz で実行する ARM9 ベースの Nokia* 7650 のような初期のスマートフォンは、これと比べると非常に高速でした。しかし、これは 10 年以上も前のことです。

当時と比べるとモバイル・プラットフォームは大きく進化しました。携帯電話初の 3D ゲームと、現在 Android* デバイスで我々が目にするゲームとの共通点はほとんどないでしょう。このような大きな違いをもたらした要因の 1 つは、モバイル SoC (システムオンチップ) に専用グラフィックス・ハードウェアが統合されたことです。さらにその他の多数のアーキテクチャーの改良によって、三角形ポリゴンの処理能力が数百から数十万へ大幅に増強され、ピクセル数が 2 桁増えました。最近では、ゲーム機のようなゲームをモバイルデバイス向けに作成できるまでになりました。

しかし、ゲーム制作者はさらなるリソースを求め続け、テクノロジーを極限まで追求する悪い癖があります。つまり、現在我々が直面している課題の多くは、過去の課題にとてもよく似ています。多くの点で、モバイル・プラットフォームは現世代のゲーム機とほぼ同レベルですが、最近の PC ゲームにはまだ遅れをとっています。また、モバイルゲームには、開発を行う前に知っておくべき考慮事項があります。

電力効率は、現在、そして今後も、引き続きモバイルデバイスの処理能力全体を制限する大きな要因になるでしょう。メモリーはここ数年で大きな改善が見られたものの、まだ制限されており、バックグラウンドで実行中のほかのプロセスと共有されます。バンド幅は、言うまでもなく、統合アーキテクチャーにおいて貴重なリソースであり、効率良く使用する必要があります。そうでなければ、パフォーマンスが大幅に低下します。さらに、モバイル開発者は、多様なデバイス、処理能力、画面サイズ、入力方法、一般的な操作などを常に考慮しなければいけません。

Anarchy の登場

Havok* は Android* 開発者の負担を軽減するため、Project Anarchy* によりこれら多くの課題に対応しています。

最近リリースされた Project Anarchy* ツールセットは、Havok Vision Engine*、Havok Physics*、Havok AI*、Havok Animation Studio* で構成されています。これらのコンポーネントは、Modern Combat 4、Halo* 4、Skyrim*、Orcs Must Die、Guild Wars 2 など多数のゲームで採用されています。Project Anarchy* は、最近のプラットフォーム向けにこれらのテクノロジーを最適化し、Autodesk の 3ds Max* と Maya* 用のエクスポーター、WYSIWYG エディターをバンドルしており、iOS*、Android* (ARM および x86)、Tizen* 向けに開発を行うプログラマーに提供されています。


図 1. Project Anarchy* に含まれる RPG デモのスクリーンショット。
現在の Android* プラットフォームで実行可能なコンテンツの例。

Havok* Vision Engine* をモバイルへ移行する

Android* への移行で最も手間のかかったものは 3D ゲームエンジンです。Havok Vision Engine* は、スケーラブルで効率良いマルチプラットフォーム・ランタイム・テクノロジーで、あらゆる種類のゲームに適しており、PC やゲーム機で複雑なシーンを高フレームレートでスムーズにレンダリングします。モバイル・プラットフォームでは、同水準の動作に加えて、ほかのプラットフォームと同じツールセットを利用できるようにしつつ、モバイル・プラットフォーム開発に関連した課題への対応も求められました。

Havok はこれまで、Xbox 360*、PlayStation* 3、PlayStation* Vita などのゲーム機に取り組む機会があったため、メモリーが少ない環境にも慣れており、そのような制限された環境向けにエンジンとライブラリーを最適化済みでした。しかし、モバイルへの移行にはその他の最適化が必要であり、限られたリソースで上手く実行するために、モバイル・プラットフォームの特性を考慮して新しい手法を考えなければいけませんでした。描画呼び出し、バンド幅の使用量、シェーダーの複雑さを軽減するため、いくつかの最適化を行う必要がありました。

レンダリングのヒント

例えば、追加のレンダリング・パスや透過処理にはコストがかかります。そのため、ダイナミック・ライティング手法を簡素化する必要がありました。そこで、シーンへの影響が最も大きく、重ね描きが最も多い動的な光源を静的な光源にして 1パスにまとめる最適化を行いました。多くの場合、1 つのシーンには動的な主光源が 1 つあるため、この最適化により描画呼び出しとバンド幅が軽減され、パフォーマンスが大幅に向上しました。さらに、低コストの選択肢としてバーテックス・ライティングも提供していますが、通常のマップにはピクセルライトが必要です。

Havok Vision Engine* は、あらかじめ焼き付けられたローカルおよびグローバル・イルミネーション (スタティック・ジオメトリーのライトマップに格納されています)、そしてライトグリッド (あらかじめ計算されている照度をダイナミック・オブジェクトに適用します) をサポートしています。ライトグリッドでは、シーンに 3D グリッドが表示され、各セルに 6 方向からの入射光が格納されます。モバイルデバイスでは、パフォーマンスを向上するため、よりシンプルな表現を使用することもできます。その場合、1 つの主方向からの光と環境光値のみを格納します。ライティング効果は全く同じにはなりませんが、多くの場合、非常に高速で十分な効果が得られます。


図 2. 通常のライティングとシンプルなライティングの効果の違い

通常、モバイル GPU では複雑な算術演算を行うリソースが限られているため、フレームレートの観点から反射光の指数関数の評価が、深刻なボトルネックになる可能性があります。これを回避するため、周囲のすべての光源からの情報を集約して、シーンエディターでキューブマップがあらかじめ焼き付けられています。拡散反射は通常どおり計算されますが、反射光は生成されたキューブマップからサンプルを取得し、ローカル・オクルージョンを考慮して明度を調整して近似値を求めます。そうすることで、十分な効果を得つつ、1 回のテクスチャー・ルックアップで任意の数の反射光の近似値を求めることができます。

シャドウマッピングも微調整が必要でした。PC ゲームのように遅延シャドウマスクを使用する (全画面の後処理パスで深度を比較し、結果のテクスチャーを使ってダイナミック・ライティングの調整を行う) 代わりに、メモリーバンド幅の使用を軽減するため、ライティング・パスでシャドウマップを直接フェッチしています。さらに、モバイルデバイスではテクスチャー・サンプリングのコストが比較的高いため、シャドウマップで近傍比率の代わりにサンプルの比較を 1 回だけ行っています。その結果、シャドウはハードエッジになりますが、一般にこれは、シャドウ・キャスティングが小さな領域に限定されていれば問題ありません。現在、シャドウマップは指向性ライトとスポットライトでサポートされています。PC とゲーム機で使用している 4 面体のシャドウマップ手法はコストが高くなるため、モバイル・プラットフォームではポイントライトのシャドウマップはサポートしていません。モバイル・プラットフォームでも、シャドウマップは小さな領域でのみ使用し、プレーヤーや一部の敵など、いくつかのオブジェクトにのみシャドウ・キャスティングを適用することを推奨します。

モバイル上でスムーズに動作するように空間効果 (空間光、霧の量、太陽光線) の調整も行いました。通常、これらの手法では、透過パスを複数回レンダリングしたり、ピクセルごとに複数回のテクスチャー・サンプリングを実行したり、積分を計算する必要があり、モバイル上ではそれぞれの処理のコストが非常に高くなります。そのため、別のアプローチをとることにしました。モバイル・プラットフォームでは、空間が玉ねぎのようにいくつかのレイヤーから成る多角形メッシュによって構成されており、シェーダーはカメラが近づくに連れてフェードアウトします。ここでは、ジオメトリーが見えないほど透明性が低くなったら、ジオメトリーを線に変換しています。変換された三角形はラスタライズ処理されないため、ピクセル・フィルレートが大幅に向上し、ある程度のパフォーマンスが得られます。


図 3. Android* でのシャドウマップと空間効果の例

地形もモバイル向けにいくつかの変更が必要でした。PC やゲーム機では、急勾配でテクスチャーが伸びないように、動的にジオメトリーがミップマップされるハイトフィールドの地形と、ランタイム・テクスチャー・ブレンディングおよび 3 ウェイマッピングを併用しています。そのため、バーテックスの数が比較的多く、複数の詳細なテクスチャーが混在しているためバンド幅の使用量が非常に大きくなります。モバイル・プラットフォームでは、Havok Vision Engine* の地形処理が動作するように、ハイトマップから最適化された静的メッシュを生成し、テクスチャーを地形セクターごとに 1 つのマップに焼き付けられるようにしています。結果として、ランタイムに変更可能な地形など、大きな地形をレンダリングすることはできませんが、これはモバイルでは一般に許容されている範囲です。

Havok Vision Engine* に追加されたもう 1 つの便利な機能は、高解像度の画面でピクセルが多いシーンのパフォーマンスを向上する、アップスケーリング・オプションです。この機能は、シーンを低解像度のオフスクリーン・ターゲットにレンダリングし、別のステップでそれを画面解像度へアップスケーリングします。一方で、高画質を維持するため UI 要素とテキストはフル解像度でレンダリングされます。この機能は、画面解像度が 300 dpi 以上のデバイスに最適で、大幅なパフォーマンスの向上が得られます。

モバイル GPU の特性を考慮したシェーダーのオーサリング

Havok Vision Engine* の既存のシェーダーはすべて HLSL で記述されています。そのため、OpenGL* ES プラットフォームをターゲットにする場合、最初に問題となるのはシェーダーを GLSL で記述しなければならないことです。クロスプラットフォーム開発をできるだけ簡単にするため、Havok Vision Engine* ではシェーダーを HLSL/Cg で一度記述するだけで、コンパイル時に vForge シーンエディターにより GLSL へ自動変換されるようにしました。

モバイル向けにシェーダーを記述する際の 2 つ目の問題は、従来のプラットフォームと比べてハードウェア・アーキテクチャーが大きく異なることです。第一に、スペースと電力を抑えるため、すべてのモバイル SoC はユニファイド・メモリーを採用しています。システム RAM は通常遅く、CPU と GPU で共有されており、その使用は制限されています。そのため、できるだけ RAM を使わないようにしています。例えば、一般に、バーテックスのサイズとテクスチャー・フェッチの数は最小限に抑えたほうが良いでしょう。

もう 1 つの大きな違いは、インテル® Atom™ プロセッサーに内蔵されている PowerVR* GPU などのほとんどの GPU は、タイルベースの遅延レンダリングを使用しています。GPU がフレームバッファーをタイルに分割し (16×16、32×32)、最後までレンダリングを遅延して、最後に各タイルのすべての描画呼び出しを処理します (1 つのタイル全体が 1 つの GPU コアに収まります)。この手法は、オンチップメモリーを使ってピクセル値が計算されるため非常に効率良く、従来のレンダリング手法と比べてメモリーバンド幅と電力の消費を抑えられ、モバイルデバイスにとって理想的です。また、いくつかの GPU レジスターを使用するだけなので、深度とステンシルテストのコストを低く抑えられることも利点です。さらに、分割データのみ RAM へコピーされるため、アルファ・ブレンディングのためのバンド幅が不要となり、MSAA のコストとメモリー使用も抑えることができます。

タイルベースのアーキテクチャーでは、色/深度/ステンシルバッファーがシーンの最初に RAM からタイルメモリーへコピーされ (復元)、シーンの最後に RAM へコピーバックされます (分割)。これらのバッファーはメモリーに保持されるため、そのコンテンツを後で再利用できます。多くのアプリケーションでは、これらのバッファーはレンダリング・プロセスの開始時にクリアされます。その場合、バッファーへの読み込み/書き込みは無駄になります。そのため、Havok Vision Engine* では EXT_discard_framebuffers 拡張で、後続処理で使用されないバッファーコンテンツを破棄しています。同様の理由から、レンダリング・ターゲットの切り替えは最小限に抑えると良いでしょう。

また、ピクセルシェーダーで依存性のあるテクスチャー読み込みは、テクスチャー・プリフェッチを無駄にするため、避けることにしました。シェーダー実行ユニットで依存性のあるテクスチャー読み込みが実行されると、そのスレッドは休止状態になり、新しいテクスチャー・フェッチ・タスクが発行されます。これを回避するため、ピクセルシェーダーではテクスチャー座標に対する算術演算を行っていません。

また、動的分岐はパイプライン・フラッシュを引き起こしてパフォーマンスを低下させるため、これもシェーダーで行わないようにしました。Havok Vision Engine* では、シェーダー・プロバイダーでマテリアルのプロパティーに応じてそのマテリアル用の特定のシェーダー置換を選択しています。これらのシェーダーは、ランタイムのメモリー消費量を減らすため、圧縮形式で格納されており、実際に必要になったら展開されます。

シェーダーの算術演算の精度を考慮することも重要です。精度を下げることでパフォーマンスの大幅な向上が得られます。そのため、特定の効果が得られる許容範囲の最小精度を常に使用することを推奨します。


図 4. Havok Vision Engine* の軽量なモバイルシェーダーの使用例:
光を放つ放射状のテクスチャーと反射キューブマップにより岩に光沢を与えている。

ここでは一般的な最適化について触れました。これらは、すべての Android* プラットフォームに適用することができるでしょう。ただし、各デバイスと各 GPU にはそれぞれの特性があることに留意してください。特定のプラットフォーム向けの開発に着手する前に、ベンダー固有の開発ガイドラインに目を通すと良いでしょう。

継続的な悩みの種

電話やメールの着信に加え、数千ものイベントが最悪のタイミングで発生する可能性があるため、Android* デバイスではアプリケーション・ライフタイム管理は重要です。オペレーティング・システムは、アプリケーションにリソースの解放を求めることができます (例えばほかのアプリケーションが起動されてシステムリソースを必要とする場合など)。同様に、オペレーティング・システムは、いつでもアプリケーションに終了を命じることができます。

Havok Vision Engine* は、モバイル・アプリケーションがバックグラウンドに移行すると、グラフィックス・リソース (テクスチャー、GPU バッファー、シェーダー) のアンロードと復元を行います。Android* プラットフォームでは、アプリケーションがバックグラウンドに移行すると直ちにすべての OpenGL ES ハンドルが無効化されるため、これは必要な処理です。しかし、ほかのプラットフォームでも、一般に一部のメモリーを解放することで、利用可能なメモリーの低下が原因でオペレーティング・システムによってアプリケーションが終了させられるリスクを軽減することができます。

また、Android* プラットフォームでは、OS イベントの発生順序がデバイスやメーカーにより異なります。そのため、できるだけイベントの順序に依存しない、強固な内部状態ハンドラーを実装する必要があります。つまり、アプリケーションの動作状態を監視し、ウィンドウハンドルを保持しているかどうか、またフォーカスされているかどうかを確認する必要があります。


図 5. Android* デバイスにおけるアプリケーション・ライフタイム管理は重要

Havok Physics*、Havok AI*、Havok Animation Studio*

Project Anarchy* に含まれるその他の製品、Havok Physics*、Havok AI*、Havok Animation Studio* にはグラフィックスに関連する部分はありません。そのため、モバイルデバイスへの移行では CPU とメモリーの最適化を行っただけです。

これらの製品はすでに Linux* ベースのシステムをサポートしており、モバイル環境と Linux* 環境のコンパイラーおよびシステム API は類似しているため、モバイルへの移行に必要なコード変更は比較的簡単に行えました。主な作業は、コードを高速化することでした。インテルと協力して、インテル® ストリーミング SIMD 拡張命令 (インテル® SSE) 向けにコードを最適化しました。一部のコード領域ではコンパイラーにより大きな違いがもたらされ、プラットフォーム SDK が新しくなってコンパイラーのバージョンが上がるたびにパフォーマンスが向上しました。

次に、マルチスレッド化に取り組みました。ほとんどのモバイル CPU もマルチコアです。そのため、PC およびゲーム機でマルチスレッド向けにすでに最適化されているコードを、モバイル・プラットフォームでプロファイルして、ターゲットシステムで効率良くスレッド化されていることを確認しました。

最後に、メモリー速度が遅いモバイル・プラットフォーム上でもコードのキャッシュ効率が維持されることを確認しました。これはモバイル固有の問題ではないため、キャッシュミスを減らす既存の最適化を上手く適用することができました。

骨の折れるワークフローから手間のかからないワークフローへ

モバイル・プラットフォームの開発ワークフローは、複数のプラットフォーム向けに開発し、各デバイスの要件 (つまり、異なるテクスチャー・サイズ、ファイル形式、圧縮形式) に合わせて異なる形式で移行しなければならない場合、常に骨が折れるものとされてきました。また、多くの場合、アプリケーション・パッケージにファイルをバンドルしなければならず、アセット (テクスチャー、サウンド、モデル) を変更するたびに、パッケージをリビルドしデバイスへアップロードする必要があります。大規模なプロジェクトでは、パッケージのビルド、アップロード、インストールに多くの時間がかかり、各サイクルの時間が増えることで開発期間が非常に長くなることもあります。


図 6. vForge シーンエディターで開発中の RPG デモコンテンツ

アセットの管理とプレビュー

このプロセスを素早く行えるように、いくつかのカスタムツールを実装することにしました。1 つ目はアセット管理システムで、簡単に使えるアセットブラウザーが vForge シーンエディターに統合されます。アセット管理システムは、テクスチャーをソース形式 (PNG、TGA) からプラットフォーム固有の形式 (DDS、PVR、ETC) へ変換することができる自動変換機能を提供しているため、どのテクスチャー形式がどのプラットフォームでサポートされているか、開発者が考える必要はありません。実際の変換は vForge により自動で行われますが、アセットごとに個別の設定が可能なので、必要に応じて微調整したり、外部ツールをフックして任意のアセットタイプのカスタム変換を行う (つまり、モデルのバーテックスの数を減らす) こともできます。

また、プラットフォームに応じてシェーダーの割り当てを指定できるマテリアル・テンプレート・エディターを vForge に追加しました。これにより、異なるプラットフォーム向けに最適化された異なるシェーダーを一度設定するだけで、同じ設定のすべてのマテリアルで利用できるようになります。

vForge では、ソースアセットではなく、デバイス固有のリソースとシェーダーを用いてすべてのシーンをプレビューすることができます。そのため、展開しなくても、ターゲットデバイスでシーンがどのように見えるかを素早く確認できます。


図 7. アセット管理システム: 自動アセット変換機能と
シーンエディターに統合され簡単に使えるアセットブラウザーを提供

魔法のようなアセットの変更

2 つ目のツールは、モバイルデバイスで実行中のアプリケーションがホスト PC からデータをストリーミングできるようにする、HTTP ベースのファイル・サーバー・システムです。これは開発サイクルにおいて非常に便利で、vForge プレビューとともに使用することで、アセットが変更されるたびにアプリケーションの再パッケージと再展開を行う必要がなくなります。

ファイルサーバーは、ダウンロードされたファイルをデバイス上のキャッシュに保存し、ホスト PC で変更があった場合のみファイルを再ダウンロードします。変更されたシーンやテクスチャーだけが転送されるため、開発時間を大幅に短縮できます。実行中のアプリケーション内部でほぼすべてのリソースタイプを動的にリロードできるので、ほとんどの場合リソースを更新するためにデバイスでアプリケーションを再起動する必要さえありません。

通常、このツールを使うと、パッケージにはコンパイル済みの実行形式コードだけが含まれ、スクリプトなどはファイルサーバーから転送されるため、アプリケーション・パッケージの作成と展開を高速に行えます。一般に、実行形式コードは関連するシーンデータよりもかなり小さいため、開発時間を大幅に短縮できます。

入力のリモート処理

3 つ目のツールは、”Remote Input (リモート入力)” です。HTML5 ベースの Web アプリケーションで、モバイルデバイスから PC 上で実行中のゲームに入力を転送します。タッチ入力イベントやデバイスの加速度と向きのデータを、モバイル上の Web ブラウザーからアプリケーションの PC バージョンや vForge 内で実行中のシーンに転送できるため、モバイルデバイスに展開しなくても、ゲームでマルチタッチ入力のプロトタイプを迅速に作成しテストすることができます。

OpenGL* ES 3.0 と将来の展望

この記事で触れた OpenGL* の制限は、近い将来なくなるかもしれません。スマートフォンとタブレットがさらに強力になれば、いくつかの制限は緩和されるでしょう。ただし、ゲーム機能は進化し、過去 15 年間と同様にモバイル・ハードウェアの限界に挑み続けるでしょう。

新しいデバイスはより多くの CPU および GPU コアを搭載しているため、マルチスレッド・コンピューティングを利用する必要性はさらに高まります。長期的には、現在の PC のパフォーマンスと機能に近くなることが予測されますが、メモリーバンド幅の制限など、モバイルで気を付けなければいけないことはまだあるでしょう。

最新の API も魅力的で、挑戦的な幅広い可能性があります。すでにいくつかのデバイスが、OpenGL* ES 3.0 (Android* 4.3 Jelly Bean* 以降でサポート) に完全準拠したコアやドライバーを採用しています。新機能には、オクルージョン・クエリー (PC とゲーム機ではすでに採用されています)、変換フィードバック (多くの骨数を使用する GPU スキニングなどの機能を有効にします)、インスタンシング (描画呼び出し数と CPU 負荷を減らすのに有効です)、マルチ・レンダー・ターゲット (遅延レンダリングと後処理効果を補助します)、各種テクスチャー形式、その他の魅力的な多くの機能が含まれています。また、モバイル分野でも利用され始めている OpenCL* により、一部の計算を GPU で行えるようになるでしょう。PlayStation 4 では全処理を GPU で行う物理シミュレーションがすでにありますが、モバイルではこれはまだ広く研究開発が進められている興味深い分野と言えます。

著者紹介

Carla Brossa
Havok* 社のデベロッパー・リレーション・エンジニア。Havok Vision Engine* を使ってより優れたゲームを制作できるように開発者を支援しています。2004 年からモバイル 3D グラフィックス分野で働いています。バルセロナにある RTZ という小さな会社で Java* および Brew* 携帯電話向け 3D ゲームの開発からスタートし、数年後、iPhone* 向けのゲーム開発に移り、Havok* に入る前は、ARM* で Mali-T600 シリーズ GPU 向けの OpenGL* ES ドライバー・プロジェクトに数年間従事していました。

 

Intel、インテル、Intel ロゴ、Intel Atom は、アメリカ合衆国およびその他の国における Intel Corporation の商標です。
© 2013 Intel Corporation. 無断での引用、転載を禁じます。
* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。
OpenCL および OpenCL ロゴは、Apple Inc. の商標であり、Khronos の使用許諾を受けて使用しています。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

関連記事