Interactive Indirect Illumination Using Voxel Cone Tracingに関する考察

実は、この手法の大まかな部分は既に理解していたつもりだったのですが、あえて人に説明できるぐらい詳しく知っておこうと思い、3回のポストに分けてこのリアルタイムレンダリング手法を見てみました。論文内では、シェーディングの計算そのものよりも、sparse voxel octreeの構築と、fiteringを中心に解説してあったと思います。

posterを読んだ時点で生じた疑問点

posterを読んだ時点で疑問に思った、voxel内にNDF,BRDF,irradianceを格納する理由は論文からは読み取れませんでした。しかし、ジオメトリ情報の構築と直接光のinjectionは、別のパスで行われる様なので、それぞれを格納しておく必要があるのだと思われます。また、NDFとBRDFを掛け合わせずに保持することで、特に高LODのvoxelで、遮蔽情報(NDF)の劣化というか、意味消失を避ける狙いがあるのだと思います。NDF,BRDF,をGaussian lobeでconvolutionするあたりは、パシフィコ横浜で見た、All-frequency rendering of dynamic, spatially-varying reflectance[2009 SIGGRAPH Asia Wang et al.]を思い出しました。将来的にvoxelの粒度や保存できる容量に余裕が出てくれば、この手法はそのままに、レンダリングの大幅な高度化が望めると思います。

sparse voxel octree

sparse voxel octreeに関する解説は詳しく行われていたので、非常に助かります。 やはりこの構造を採用することで、メモリ効率を飛躍的に向上させることができるので、それによってvoxel内の情報の充実と、十分なvoxel粒度の確保ができたのだと思います。加えて、GPU処理で行う場合は、中間処理でuniformなvoxel gridを生成したくなりますが、それを避けて、あえて難しいと思われるoctreeの直接構築を行っているところは、この手法の中で注目に値すると思います。またGPU上でのvoxel構築というのは、大域照明だけでなく、いろいろな適用場所があると思われるので、この論文を、GPU上でのリアルタイムvoxel構築手法とだけ見た場合でも、十分に価値があるものだと思います。また、この手法は現在でも最適化の余地が残っているのではないかと思います。おそらくですがUnreal Engine 4での実装は、DX11上でこのoctreeの構築部分を、かなり追い込んでいるんじゃないかなと勘繰っています。また将来的な話ですが、GPU上でスレッドの起動が直接出来る様になれば、処理を容易に高速化できると思われます。

論文の第10項で示されている内容

静的なオブジェクトによるoctreeの構築には280msかかるそうです。つまり、毎フレームoctreeを再構築することは、現状ではリアルタイムレンダリングと呼べる時間では行うことが出来ないわけです。ゲームなどで実装する場合は、何らかの工夫が必要です。

specular cone tracingを行った場合のフレームレートは、行わなかった場合に比べると、だいぶ低下しています。つまり、選択度の高い、細長い形状のcone tracingによって、細かいレベルのvoxelを多数travaseした場合のコストは、おそらく非常に高いと思われます。単純にtravaseしなければならないconeの数が多いために起こっているのかも知れませんし、アクセスパターンの変化による問題かもしれません。cone tracingによってtravaseする際のvoxelは、たとえ隣接しているvoxelでも、テクスチャのアドレス的には、おそらく離れた位置になってしまうと思います。こうなると、テクスチャキャッシュのヒット率は期待できないでしょう。通常のレンダリングで行うテクスチャ読み出しに比べると、サンプリングにかかるコストは高いと思われます。また、このミスヒットによるレイテンシを隠蔽するためには、数多くのスレッドを起動するしかないのですが、呼び出されるスレッド全体が持っているアクセスパターンも、この場合ほぼランダムアクセスになると思うので、GPUのシステム全体のキャッシュに対しても、やはり厳しい処理になることが予想されます。
さらにこの部分に関して考察を深めると、cone tracingを行う際は、deferred renderingの結果を受けた、screen spaceのG-bufferを用います。ここで、単純にSSのブロック単位でcone tracingのスレッドを呼び出してしまうと、該当ブロックが深度方向で広範囲に分布していた場合、このスレッドブロックは広範囲のvoxelに対してアクセスを行うことになるはずです。ここでは、depthに対するグルーピングを先に行ってから、スレッドブロックを分けて呼び出すことで、テクスチャのキャッシュのヒット率を向上させることが可能だと思います。ピクセルシェーダーが使用できる状況なら、depth bounds test でスレッドの早期棄却を行うことも可能かもしれません。いずれにせよ、これは机上の空論で、自分で数字を取ってないので、なんともいえないですが。

light leakingに関して

私はLPVのレンダリング結果を見て、いつも思うのですが、ライトの当たっていない部分が明るくなる時に、これはlight leakingによるものなのか、それともLPVによる間接照明なのか、正直よく分からないと思うぐらい、light leakingが多いと感じていました。もちろんlight leakingに対する対策は、LPV手法の中でも用いられてきましたが、voxelの粒度による制限と、低次のSHによって、ジオメトリの遮蔽をうまく取り扱うのは難しかったと思います。
今回の手法では、NDFがGaussian lobeなので、voxel内のジオメトリ情報が1平面で構成される場合は、基本的に完璧な遮蔽を行うことが出来るはずです。加えて、高LODのvoxelで6方向からの情報を保持することで、かなりlight leakingを抑制できていると思います。ですから性能の制限でspecular cone tracingを行わないとしても、LPVに対するアドバンテージは、なお大きいと思います。

Ambient Occlusionの品質について

論文とposterに出てくるAOのスクリーンショットは、非常に高品質に見えます。やはりscreen spaceのものとは一線を画す、空間を感じさせるものになっていると思います。正直これだけでもvoxelを構築する価値があるのではないかと思ってしまいます。もし、AOのみの処理に注力した場合は、かなりのメモリ使用量、演算量の削減が見込めると思うので、voxelの粒度や適用空間の大きさも、さらに向上させることが出来るかもしれません。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中