|
3DゲームファンのためのPSPグラフィックス講座 |
講演を担当したSCEA Developer SupportのDavid Coombes氏(左)と、Peter Young氏(右) | 「PSPは全く新しいデジタルエンターテインメントのプラットフォームである」ことが今回も強調された |
こうしたインスタンス化によるメモリバンド節約は最近のPC向けGPUでも行なわれている |
3Dゲームソフトの実行中、CPUは描画命令をGPUに大量に発行する。GPUがどの程度描画命令を実行できたのかをCPUが監視しながらGPUを動かしていたのでは、CPUは物理演算やキャラクタ管理に手が回らなくなり、そのハードウェアのポテンシャルが活かしにくい。
そこで、この両者の間を取り持つ助っ人としてDMA(Direct Memory Acces)が設置されている。CPUは描画命令を発行し、GPUの動作状況を無視してメモリにストア。DMAはGPUの動作状況を見て自動的に描画命令をGPUに転送していく。
これでCPUとGPUは極力並列に動作できるようになり、実行効率が上がる。また、この仕組みのおかげで、バスの利用の集中と分散が起こりにくく平均的にバスが活用されるので、効率も最適化される。
DMAの動作は、DMAがバスを占有して全速でデータ転送を行なうバーストモードではなく、協調モードになるので、CPUの動作を阻害しない。このあたりの設計もPS2によく似ている。
また、描画リスト(グラフィックスを描くための手順のようなもの)のストリーム構造はインスタンス化されており、サブルーチンコールのように必要なデータを取ってきてから実行される処理系になる。簡単に言えば描画リストの圧縮の仕組みが採用されている……と考えればよい。
この仕組みではインスタンスの参照のオーバーヘッドが発生する弱点があるが、描画リストの作成にメモリコピーの頻発を避けることができるメリットがある。おそらく「こちらの仕組みを採用した方がパフォーマンスが上がりやすい」という裏付けの元に採用したのだろう。
そして、描画リストには初期カリングも適用される。初期カリングとは、その状況で確実に画面に現れないポリゴンのジオメトリ情報をカットしてしまう仕組みのことだ。画面外の建物はレンダリングされないので、こうした建物のジオメトリ情報を描画リストからカットしてしまおう……という手続きだ。
PSPのGPUにはユーザークリッププレーン機能が搭載される。
これは、3Dゲーム開発者がGPUの座標系のどこからどこまでを描画するかを指定できる仕組みだ。3Dゲームをプレイしていて、遠くの3Dオブジェクトが、ある距離を境に消えたり現れたりする見えない描画境界線のようなものを知覚したことがあるだろう。こうした描画境界のうち、遠いクリッププレーンを「Far Clip Plane」、視点側のクリッププレーンを「Near Clip Plane」という。
描画境界線は「Far」と「Near」の他、画角の描画境界線もある。3Dグラフィックスは視点に設置されたカメラから捉えた映像をモニタに表示しているわけだが、当然カメラに映っている(=画角)外は見えない。つまりこの画角の外にあるオブジェクトは描かなくても支障がない。これが画角のクリッププレーンだ。
3Dグラフィックスの世界における最適化の基本方針として、「見えない物は描かない」というものがある。そこで、クリッププレーンの外にあるものは描かないようにしよう……というアイディアが生まれる。
PSPのGPUでは、クリッププレーンの機能を有効/無効にできる。無効にすればクリッププレーン処理が省略されるのでその分軽くなるが、無駄に見えない物が描画される可能性がある。有効にすればクリッププレーン処理が行なわれるのでこれがオーバーヘッドになるが、その分、無駄な描画が減ってGPUに余裕が生まれる(かもしれない)。どちらを使うべきかはその3Dゲームの設計やシーンに依存する。
いわゆる3Dゲームであれば、普通は有効にしておけば問題はないわけだが、実はPSPのクリッププレーン機能には制限がある。
それは、座標系をはみ出すような大きな3Dオブジェクトはクリッププレーン機能の有効無効に関わらず、描画されない(カリングされてしまう)のである。本来見える可能性があるのに描画されない……というケースが出てくるのだ。
これについてSCEA(Sony Computer Entertainment America)は「問題ない」としている。なぜならば、PSPの座標系は画面解像度換算で4,096×4,096×4,096ドット相当、画面サイズの縦方向にして15倍、横方向は8倍以上もの広さがあり、そうした問題ケースはほとんど起こりえない、と踏んでいるからだ。
逆に問題が起こりそうなケースを考えてみると、遙か遠くに全長が画面2個分ほどある超巨大戦艦スプライトを登場させ、それを左右に移動させた場合、突如カリングされて目の前から姿を消すことがある……ということになる。
ただ、これについても「問題ない」とSCEAはいう。話は簡単で、どでかい超巨大戦艦を1ポリゴンのスプライトで定義せず、複数のポリゴンに分解して扱えばいいのだ。すると画面に見えないところにある超巨大戦艦の先端部や末端部がカリングされるだけで済むことになり、視覚的な破綻は全く起きない。
結論をまとめると、PSPではあまり極端にでかいモデルを1個で定義するな……ということになるだろうか。
PSPはPS2以上の表現力があるといっても、PS2のような据置型ゲーム機ではないので、メモリバス性能がずば抜けて良いわけではない。そんなわけで、PSPでは3Dゲームのパフォーマンスを稼ぐためには、結構、涙ぐましい努力をしなければならないようだ。SCEAが提唱するのは頂点とテクスチャの物理的な圧縮だ。
PSPのジオメトリ演算器は、頂点データとして「32bit浮動小数点実数(FP32)」、「16bit整数(INT16)」、「8bit整数(INT8)」の3タイプの表現形式での演算が可能だという。この中で最もメモリバス使用率が低いINT8を積極的に活用すれば、頂点データをFP32の1/4で表現できる。
ただしINT8だけでは精度的に苦しいので、複雑な動きをするオブジェクトにはFP32を使い、あまり動かない遠景のオブジェクトには8bit整数を使うようにするなどの使い分けを奨励するようだ。
テクスチャも同様で、PSPではRGBとA(αチャンネル)が全て8bitの32bit(R8G8B8A8)カラー、16bit(R5G6B5A0,R5G5B5A1,R4G4B4A4)カラーといったものが利用できるが、あらかじめ使う色を限定しておき、4bit/8bit/16bitなどのパレットベースのテクスチャを使えば色表現の滑らかさとメモリバス節約のトレードオフ的な両立が可能になる。もちろんデータ量も32bitカラーテクスチャと比べて小さくなるのでメモリの使用量節約にもなる。
パッチによる高次曲面は少ない情報量で丸みのあるキャラクタモデルを形成できる利点がある。また、視点からの距離に応じたポリゴン分割が行なわれることにより、動的なLODが実現される |
高次曲面機能を搭載した理由についてSCEAは3つの理由を挙げている。
1つは滑らかな曲面を膨大な頂点を用いず関数で表現できるため、描画リストのメモリバンド節約に繋がるという理由だ。
2つ目は、視点からの距離に依存しない、曲面表現が自動的に行なえるという理由だ。その関数パラメータだけで曲面表現が視点に近ければより滑らかに、遠ければよりおおざっぱに描かれることになり、いわゆる、自発的な「Level of Detail(LOD)」が実現されることになる(実際には視点からの距離に応じたポリゴン分割が自動で行なわれる形で実現される)。
3つめは関数パラメータを変更することで複雑な曲面アニメーションができるという理由。うねったり曲がったりふくらんだり……とった表現を関数のパラメータを変えるだけで行なえる。これが頂点ベースのモデルだと、これを構成している頂点の全てを変位させなければならない。
PSPが持っている高次曲面機能は2種類。「ベジェパッチ」と「Bスプラインパッチ」の2つだ。
「ベジェパッチ(Bezier Patch)」はベジェ曲線に従って曲面を表現するものだ。ちなみに「パッチ」とは「補う」という意味がある。仕組みとしては、ベジェ曲線のカーブに沿うように、元のポリゴンモデル構造に対し法線を補う形で(パッチして)ポリゴンを生成する(分割する)テクノロジーだ。
なお、ベジェパッチは制御方法が難しく、制限も多く、なかなか動くキャラクタモデルをこの手法で実現するのは難しい。たとえば制御点を1ついじっただけで全てのパッチが変化する。つまりは、細かいディテールを持ったキャラクタをベジェパッチで作り上げても、それを動かすことはかなり難しいということになる。よってSCEAでは、ベジェパッチは背景や地形表現などの大きい静的オブジェクトに用いることを奨励するようだ。
一方、「Bスプラインパッチ(B-spline Patch)」はベジェパッチよりも制御が簡単でディテールのモデリングも行ないやすい。ただし、演算量がベジェパッチよりも多い分GPUにかかる負荷は大きくなる。こちらの手法は逆に大きいオブジェクトには向かず、ゲームの主役を務めるような、動きとディテールが重要となる3Dキャラクタ表現に適しているようだ。
パッチによるポリゴン分割(Subdivision)は、高次曲面の実現様式の一つだが、弱点も指摘されている。たとえば、ドラスティックにポリゴン分割度が変わっている“分割境界線”ともいうべき地点付近は、視点が動いたりすると“ポリゴンの破れ”が発生する。ポリゴンとポリゴンのつなぎ目に隙間ができるのだ。たとえば手前から奥へと広がる地形のようなオブジェクトの分割でこれが現れやすい。
PSPではこの現象の回避方法として、あまりにも劇的にポリゴン分割数が変化するような分割を近接したポリゴン間で行なわない……という仕組みを取り入れているそうだ。
あるいは、岩肌系の岩質地形の表現であればあらかじめバックグラウンドを茶色に塗りつぶしておき、「ポリゴン破れが起きたときにその破れ目からこの茶色が見えるようにして隙間を目立たせない」という、プレイステーション時代にあったようなテクニックでこの欠点を回避(?)する方法も紹介した。
もっとも、奥行きの限られている3Dキャラクタや3Dオブジェクトではこうした「分割境界線」のようなものは現れにくいので、特性を理解して活用すれば「弱点」にはならない、とSCEAは説明する。
少ないジオメトリ情報量で、滑らかで表情豊かな表現ができる高次曲面パッチは、この図を見る限りではかなり魅力的なテクノロジに思える。これまで“嫌われ者”だったこの種のテクノロジが、果たしてPSPではどのような活用がなされるのか、興味深い。
頂点が共有されずに、T字状にポリゴン分割が行なわれるとポリゴンの切れ目が見えてしまうことがある。図でいうところの青紫部と緑部の境界がこの分割境界線 | 左がモデリング状のデータ。これを高次曲面パッチでPSPにて表示すれば右のように滑らかになる。この例で行けば、ヘルメット部が完全に丸くなり、手足の造形も丸みを帯びてかわいらしくなる。少ないデータ量で滑らかな曲面が得られるのが高次曲面パッチの利点だ |
動きによるインタラクティビティが重要となる3Dゲームのキャラクタ表現において、アニメーションという要素は非常に重要なものになる。
3Dキャラクタの動き/アニメーションとは現実問題として「頂点の変位」ということになる。肘を軸にして腕を曲げれば、肘側の頂点は伸び、肘の内側のV字に縮んで曲がる部分の頂点は密集する感じで集約する。自分で腕を曲げて皮膚の動きに注目してみるとイメージがつかめるだろう。
こうしたアニメーション時の頂点の変位は、「頂点プレンディング」と呼ばれる技術で処理されることが一般的だ。これは簡単に言うと複数の頂点情報をある演算処理に従って変位(移動させる)という処理系になる。
PSPのGPUがハードウェアサポートする頂点ブレンディングの仕組みは「モーフ・ブレンディング(Morph Blending)」と「頂点スキニング(Vertex Skinning/Weighted Vertices)」の2つだ。
● モーフ・ブレンディング~3Dキャラクタの変身アニメーションを8個までサポート
モーフィング機能はアイディア次第で面白い表現ができそうだ |
技術的には古典的なもので、変身前と変身後の両モデル間で「どの頂点がどの頂点に対応するか」を指定しておき、実際の変形の際にはその頂点の変位の様子を補間再現していく……といったものになる。
ただしSCEAによれば、このモーフィング機能はメモリの使用頻度が上がり、メモリバンドの圧迫が懸念されるため、その使用には注意が必要だという。また、モーフィング機能には得意な領域と不得意な領域があり、登場する全てのキャラクタの動きにこれを活用することは現実的ではないということだ。
例えば、モーフィング機能は同一モデルの形状変化にも応用でき、それこそ、手足の移動アニメーションの生成にもこの機能は活用できる。しかし、実際にこれをやると「手足が移動している」というよりも「変形している」ように見え、リアリティに欠ける。こういったアニメーションには後述のボーンを仕込んでの頂点スキニングを活用した方が自然に見えるのだ。
逆に、キャラクタの表情の変化表現(例:怒り顔から笑い顔へ)、いわゆる「表情アニメーション(Facial Animation)」にはモーフィング機能を使うと効果的だという。表皮の微妙な凹凸が変化するだけの表情アニメーションは、ポリゴン下にボーンを仕込んだスキニング処理系では、その実現が難しいためだ。
● 頂点スキニング~高次曲面にも対応したボーンスキニング処理
頂点スキニングの概念図。青い部分が骨(ボーン)で、白い部分が外皮ポリゴン(メッシュ)だ。手足の折り曲げなどはボーンの動きに外皮を追来させるようなイメージで変形して表現される |
3Dキャラクタを構成する外皮ポリゴンの頂点を、骨組み(ボーン)モデルの各骨や関節に割り当てていき、キャラクタのアクションの際のアニメーションはこの骨の移動を基軸に行なっていく。骨が曲がったら外皮ポリゴンも曲がる。まさに我々人間そのままの内骨格モデルを形成しているような感じだ。
この外皮と骨の割付を1対1で行なっていると、例えば膝の関節付近のところで膨ら脛(ふくらはぎ)や脛(すね)がめり込んだりする変な現象を引き起こす。PS世代のゲームなどではこうした現象が日常茶飯事で確認できたと思う。
こうした現象を回避するために、最近の3Dグラフィックス技術では外皮ポリゴンの頂点を複数の骨に重み付けをして割り当て、骨が曲がったり移動したりしたときの最終的なポリゴン位置(頂点)を、複数の骨の位置や他のポリゴンの位置(頂点)と平均化して算出して、なめらかな外皮の変位を実現するのが、「頂点スキニング(頂点ブレンディング、行列パレットスキニングなどといったりもする)」だ。
PSPのGPUはこの頂点スキニングの処理系に対応しており、1頂点あたり8本のボーンの状態情報を配慮した形で頂点ブレンディングが行なえる。もちろん、ブレンディングされて行なわれた外皮ポリゴンの法線ベクトルも同時に正しく修正されるので、ライティング(陰影処理)に異常が出る(明るくなるべきところが明るくないなど)こともない。
さらに、前述した高次曲面表現のうち「Bスプラインパッチ」との連動が考慮される点にも注目したい。
Bスプラインパッチを使って組み上げられた3Dキャラクタのボーンスキニングができるとなれば、丸みのある、表情豊かな3Dキャラクタのリアルなアニメーションが、かなりメモリを節約した上で実現可能になる。
最後に、3Dグラフィックスの最終的なクオリティを決定づけるピクセル・レンダリング・パイプラインの仕様についても見ていきたい。
結論から言うとPSPのGPUは、携帯ゲーム機としてはかなり贅沢なスペックのピクセルレンダリングパイプラインを内蔵している。機能的に見れば、PCでいうところのDirectX 7世代GPU相当のポテンシャルは備えているといっていい。
それでは各フィーチャーを順番に見ていくことにしよう。
● αブレンディング~現行OpenGLでサポートされるα演算をサポート
PSPエミュレータの映像より。図中の薄明るくなっている部分がα値を使ったライトマップ表現。相互反射までを配慮したような背景の淡いライティングの再現に活用されることが多い |
αブレンディングとは、簡単に言えばこのα値を元に、テクスチャやバッファ同士を合成する機能のことだ。
PSP GPUのピクセルパイプラインには現行PC用GPUと比較しても遜色ないほどのαブレンディング機能バリエーションを備えており、現行OpenGLでサポートされるα演算はほとんどサポートされているという。たとえば、基本的な半透明合成演算の他に、合成先の色情報を増減させるライトマップ演算なども行なえる。
SCEAは「α値にハイダイナミックレンジ(HDR)情報を格納してこれを処理することもできる」と説明しており、もしかするとα値に応じて合成後の色を意図的に白飛びさせたり……といった、疑似HDR表現を行なえるのかもしれない。
● ステンシルバッファ~ステンシルシャドウボリューム生成にも活用可能
この写真では少々見にくいのだが、足元に影が出ているのがわかるだろうか |
なお、ステンシルバッファの表現幅は8bitで、PC用GPUと同等だ。PC用GPUと同仕様だと想定すれば、ステンシルバッファはおそらくZバッファとペアで管理され、こちらは最大24bit幅なのではないだろうか。
● テクスチャリング~環境マッピングや投射テクスチャリングをサポート
各マテリアル表現の反射モデルとしては拡散反射、鏡面反射などが用意されるが、残念ながらプログラマブルピクセルシェーダー機能は持っていない |
テクスチャフィルタリングは、バイリニアとトライリニアの線形補間に対応。異方性(アニソトロピック)フィルタリングはサポートされないようだが、PSPの表示解像度を考えれば、理にかなった機能削減ではある。
遠景オブジェクトに貼り込むテクスチャとして高品位に縮小したテクスチャを生成するミップマップ機能も搭載。テクスチャリングの際には最適に縮小されたミップマップテクスチャからのテクセル読み出しが行なわれる。
テクスチャリングもただ、用意した画像をそのままポリゴンに貼り付けるだけでなく、プロジェクタで映像を投影したようなイメージでテクスチャリングを行なう「投射テクスチャリング」にも対応する。
この機能により、懐中電灯で照らした箇所が明るく照らされて見えるような、「動的ライトマップ」表現、あるいはセルフシャドウ表現こそ行なえないものの正確なキャラクタ形状の影を地面や壁に投射できる「投射影」表現が行なえる。
また、ユニークなのがその時点の頂点情報などからテクスチャ座標をリアルタイムに生成してテクスチャリングを行なう、「陰影マッピング(Shade Maping)」にも対応する。
例えば、その頂点(ピクセル)の法線ベクトルをもとにテクスチャ座標を生成してテクスチャリングすれば、周囲が映り込んだような表現、いわゆる「環境マップ」表現が可能になる。
あるいは、「そのポリゴンが光源方向に向いているか否か」だけでテクスチャ座標を生成して、暗いか明るいかだけを描いた2値テクスチャを用いてテクスチャリングを行なえば、アニメ調のセルシェーディング(トゥーンレンダリング)が行なえる。法線マップを使ったバンプマッピングが行なえるかどうかは不明。あるとすれば「陰影マッピング」機能の一環として提供されることだろう。
光源は環境光、平行光源、点光源、スポットライトが利用できる。光源処理(陰影演算)をピクセル単位に行なえるか、頂点単位どまりなのかは明らかにされなかったが、おそらくピクセル単位(パー・ピクセル)に対応しているものと思われる。
ユーザーが気になるのは、PSPでどういったゲームが出てくるかということになるわけだが、これは全く予想がつかない。なぜかというと、開発スタイルがこれまでの携帯ゲーム機とは異なってくる可能性が強いからだ。
SCEAも「これまでの携帯ゲーム機用ゲームの開発チームサイズでは難しいかもしれない。なぜならユーザーもPSPのゲームに対してはPS以上、PS2並のクオリティや内容を期待してくるからだ」と説明する。
PSPの3Dグラフィックス機能はPS2並かそれ以上、またサウンド機能もサラウンド表現に対応となれば、その開発には3Dアーティストやサウンドデザイナの起用が必要不可欠になる。開発チームの規模は当然大きくなる。ゲームソフトがUMDという1.8GBもの大容量メディアで供給されるためにコンテンツ密度への期待も大きくなる。するとストーリー性やゲーム内容についても、高度なものが求められてくることだろう。つまりPSP用ゲームタイトルの開発において期待に見合ったものを作るとなれば、据え置き型ゲーム機並の開発コストがかかってくるだろう……とSCEAは予測するのだ。
ただ、SCEAはこの点について、「PS2とPSPのハードウェア機能の格差があまりないために、開発プロジェクトの共有ができ、これで開発コストを幾分か抑えられるはず」とフォローする。
つまり、テクスチャやサウンド、AI、物理エンジンなどを、据え置き型ゲーム機(具体的にはPS2など)向けに開発したものを流用したりすれば、開発コストは抑えられるというわけだ。確かに、同一ゲームタイトルをPS2とPSP向けに開発する場合にはそうした目論みもアリだとは思う。
また、「開発コストを抑えつつ見栄えの良いゲームをPSPに提供する」ことだけにこだわるのであれば、画面比率の違いなどを無視して考えれば、「既存PS2タイトルをPSPに移植する」という方策で、タイトルを充実させる方策も考えられるだろう。ただ、それではPSPのプラットフォームの魅力が出にくそうだが、それでも意外に初期のPSPタイトルはこの傾向が強く出るかもしれない。
「ハイスペック3Dゲーム機」と「携帯ゲーム機」……それぞれのキーワード自体にいまや珍しさはないが、この2つが1つなったゲーム機は今までに存在しなかったためにPSPの未来像は非常にイメージしにくい。もしかすると各ゲームスタジオは、PSPのゲーム開発のためには、新たな開発パラダイムを導き出さなければならないかもしれない。
2004年4月初旬現在、PSPゲームの開発はPC上で動作するエミュレータ上で行なわれているが、4月下旬には試作実機がゲームスタジオに提供される見込みのようだ。E3では、この試作実機が一般公開されると見られている | 本体同時発売タイトルは「東京ゲームショー2004」にて公開される予定。製品の発売は日本国内では2004年末とアナウンスされている |
(2004年4月6日)
[Reported by トライゼット西川善司]
GAME Watchホームページ |
|