Softwareが開発を担当したレーシングゲームである。2では,「4画面分割による4人同時プレイで3D立体視に対応させる」という命題に取り組んだため,視点ごとにレンダリングするという手法は,最初から選択肢になかったという。これは,2視点分(左右視点用レンダリング)×4人となると,1人のときに比べて8倍のジオメトリ負荷になるためだ。SIMD型RISCプロセッサ)を用いることにしたという。3が搭載しているCellプロセッサのSPUは,7基のうち1基がシステムで利用されており,6基が利用できる仕様である。この4基のSPUが利用される。2だが,GPUかCPUかという処理主体が異なるわけだ。Writes(拡散書き出し系)手法の概要さらに両者の違いは,処理系の仕組みにおいても見られる。深度値から左右の目の視点に合ったズレ量を求めるという点は両者ともに変わらないが,異なるのはどのフレームを基準としているかである。Reads」(収集読み出し系)手法が用いられている。Writes」(拡散書き出し系)手法が採用されている。2の場合も,視点をずらしたことによって新たに遮蔽が生じる可能性があるのだが,左右の目の視野,すなわち3D立体視表示用のフレームを基準としているため,遮蔽に対して特別な後処理が不要になる。左の写真が平面視表示用のフレームとなる。中央が左目用,右が右目用の3D立体視表示用フレームだこの変換処理は独立性のあるタスクとして処理が可能また,人間の目が左右に並んでいることから,この処理系は,縦方向には依存関係がないと想定できる。この画像処理系は1ライン単位区切って考えれば,完全に独立したタスクとして見なすことができる。並列に処理ができるわけで,SPUに任せるタスクとしてはおあつらえ向きなのだ。2では,ITEMバッファという,1ライン分の横解像度に相当する作業バッファが用意される。この作業バッファを用いて,“ネタ元”となる平面視表示用のフレームと,深度値から逆算したズレ幅で左右にズラしたフレームとの対応関係を書き込んでいき,最後に画素値を計算するという流れになるわけだ。2が用いている手法と同じく,「平面視表示時のフレームで遮蔽されている一方,3D立体視表示用に生成したフレームだと遮蔽されず,新たに見えることになる『未知の領域』は,何の画素値も与えられない『穴』になってしまう」という問題はある。2においては,奥側の背景を複製することでこの領域の穴埋めを行うとのことだった。新たに見えることになる領域に関しては,穴埋め処理が必要になるこのアーティファクトは,やはり丸みを帯びた3Dモデルの輪郭付近で起きやすい。2では,丸みを帯びた車が多く登場するため,画面全体の約5%がそうした領域になるそうだ。動きの速いゲームのため,見た目はそれほど破綻していないというのが制作側の感想である。2で用いられていた手法でもそうだったが,こうした平面視表示時のフレームから3D立体視表示用のフレームを合成する手法では,深度値を持たない半透明オブジェクトの扱いを無視しなければならないことになる。Softwareの見解だ平面視表示用のフレーム左目用として合成した3D立体視表示用のフレーム。緑でマークされている部分が新たに見えることになる領域だこの未知の領域を背景で埋めてごまかした左目用のフレーム。Softwareによれば,3D立体視表示に変換した場合のフレームレートは,平面視表示時と比べても低下がなかったとのこと。この点は,改めてSPUのパワフルさに驚かされた部分だ。CLでも実装できるはずなので,PCでも似たようなアプローチを実践してくるスタジオが登場してくる可能性がある。現在,ゲームを3D立体視で楽しむユーザーがまだ少ないので,本稿で紹介したような疑似手法に対するクレームのようなものをあまり聞かない。360などのコンシューマゲーム機では,こうした手法が今後主流になっていくのかもしれない。