9月にDirectX11.1の情報がやっと開示されましたが、これに先行してOpenGL4.2がSIGGRAPH会期中に発表されています。
SIGGRAPHレポートではこのOpenGL4.2の機能について紹介しています。
機能の詳細については、記事の方を参照して欲しいのですが、1つだけ面白い機能をピックアップするとすれば、「Transform Feedback Instanced Example」でしょうか。
DirectX11(OpenGL 4.x)世代のGPUには、「Tessellation Stage」(テッセレーションステージ)が用意されていますが、1つ大きな問題点が指摘されるようになってきました。
[SIGGRAPH]ついにDirectX 11を凌駕した!? Khronosに聞く「OpenGL 4.2」の正体
http://www.4gamer.net/games/107/G010729/20110821001/
それは「ゲームのランタイムでテッセレーションを活用するのは結構重い」という問題です。ウルトラハイエンドGPUになれば別ですが、現実的なミドルレンジでは負荷が高すぎて現実的な活用が難しいと言うのです。これに関してはCRYTEKがCRYSIS2のDirectX11対応化パッチをリリースした際にも同様のことを述べていたので、開発現場からの生の意見として捉えていいでしょう。
重くなる原因は「ほとんど視点位置が変わらない場合でも、無意味に何度もテッセレーションが行われてしまう」と言ったことに起因します。
たとえば毎秒60コマのゲームで、視点から10m離れたところに100ポリゴンの低ポリゴンモデルを配置したとします。
これをテッセレーションステージを活用して10倍の1000ポリゴンモデルとして描画するとしますと、次のフレームを1/60秒後に描画することになりますが、この間のプレイヤーキャラクターの移動距離なんてものは微々たるものです(飛行機や車を題材にしたゲームの場合は別ですが)。
仮に30cm進んだとすると、次のフレームでは9.7m先に再び100ポリゴンの低ポリゴンモデルを配置することになります。
この場合、テッセレーションステージが再度ポリゴンモデルを1000ポリゴンに分割するのですが、分割結果は、前フレームのものと完全同一ではないものの、ほとんど違わないものとなるはずです。
つまり、この2フレームの間で(ほぼ)同じ結果にしかならないポリゴン分割を2回繰り返したことになるわけです。
この無駄を解消すべく、OpenGL4.2では、テッセレーションステージによって分割・変形された3Dモデルを、そのままキャプチャして再利用できる仕組みが実装されました。
これによってテッセレーションステージの起動頻度を下げることに繋がり、テッセレーションステージの無意味な負荷を下げることができます。
ただ、こういう制御はインテリジェントにGPU側がオートマチックにやってくれるといいんですけどねぇ。
「LODの面倒をGPU側で自動的に見てもらえる」というのがテッセレーションステージのウリの機能の1つだったはずですから。これでは結局LODをゲームエンジン側で面倒を見ないといけなくなってしまいます。
なお、この記事では、この他、ついに現実味を帯びてきたOpenCLのWeb版である「WebCL」の話題なども取り扱っています。
Comments
を渡して、そのデータを元に加工する必要があり、サーフェースのメモリ分、加工に掛る負荷等から、これまで
通りのLODで良いんじゃないの?ってことになりそうですね。
結局、折角デザイナがモデリングしたデータを、テッセレーターで加工して近似値的なモデルを作るのでは
リソースの面でもデザイン的にもあんまり良くないような気がしますね。
テッセレーターの活用はやっぱりプロシージャ的なアプローチがメインになるんでしょうか。