[Paper] Ptex: Per-Face Texture Mapping for Production Rendering

http://www.disneyanimation.com/library/ptex/ 遅ればせながら、Ptex を読んでみました. SDS(サブディビジョンサーフェス)のフェースごとにテクスチャ座標をパラメータ座標で割り当て([faceid, u, v] で識別する)ることで、 UV 割り当ての必要が無くなり、また隣接するフェースの情報も保持することでフェース間でシームのない高品質なテクスチャマッピングを実現する手法です. 利点 – セットアップフリー(UV 割り当ての必要がない) – フェースごとにテクスチャの解像度を操作できる. – シームレス(正確にシームレスではなく、シームレスに近い状態にまでできる) 欠点 – モデラ側で Ptex をサポートする必要がある. – パイプラインが変わる(disney ではうまくいった… なんて言っていますが、他のスタジオでも同様になるか不明?) – SDS にしかつかえない. 個人的な感想としては、(もしやるなら) Ptex はレンダラ側でサポートするのはそれほど大変ではないけど(さほど複雑な処理をしているわけでないので)、 やはりモデラ側で Ptex の対応をどうするかが大きな問題になるかなぁ、というところです. (現在某モデリングソフトに Ptex 対応をお願いしているらしいですが) あとは、フェースごとにテクスチャを割り当てることで、テクスチャファイルの最適化ができるのはよいですね. 普通のポリゴンモデル + テクスチャマップというケースでも、単に UV 全体で mipmap を作るのではなく、 特定の UV 領域で miplevel の調整とかできるようなテクスチャフォーマットを考案するのもいいかもしれないと思いました. (これはこれで、ペイントソフト側の対応が必要になりますが)

Approximating Dynamic Global Illumination in Image Space

(image from “Approximating Dynamic Global Illumination in Image Space”) Approximating Dynamic Global Illumination in Image Space Tobias Ritschel, Thorsten Grosch, Hans-Peter Seidel Proceedings ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games (I3D) 2009 http://www.uni-koblenz.de/~ritschel/ うぉっ! これはすげー! – スクリーンスペースなのでジオメトリの複雑さと無縁 – 動的ジオメトリ可 – 前計算なし – GPU に容易に実装可能 で近似的に GI (1 回の indirect diffuse) をリアルタイムでやってしまっています. 手法としては、基本的には既存研究である SSAO(Screen SpaceContinue reading “Approximating Dynamic Global Illumination in Image Space”

Out-of-core Data Management for Path Tracing on Hybrid Resources

(from Out-of-core Data Management for Path Tracing on Hybrid Resources) Out-of-core Data Management for Path Tracing on Hybrid Resources Brian C. Budge, Tony Bernardin, Shubhabrata Sengupta, Kenneth I. Joy, John D. Owens Eurographics 2009 http://graphics.idav.ucdavis.edu/publications/print_pub?pub_id=957 [Ja] 大規模シーン向けのスケーラブルなパストレアーキティクチャの提案. Out-of-core と呼ばれる、必要なときだけメモリにデータをロードして有限なメモリ量でも効率良く大規模なデータを処理する手法をパストレにも応用して、スケーラブルなパストレにしてみました, という感じ. また、GPU も使わなければもったいない(スケーラブルでない!)ということで、 GPU でもレイトレカーネルを CUDA で実装してより異種混合プロセッサの構成でもスケールするようにしています. GPU でのレイトレですが、レイトレコアは CPU の 6-12 倍とありますが、 システム全体でみるとレンダリング時間は CPU とContinue reading “Out-of-core Data Management for Path Tracing on Hybrid Resources”

Course notes on Beyond Programmable Shading

(via ompf.org) SIGGRAPH 2008: Beyond Programmable Shading http://s08.idav.ucdavis.edu/ Extra infos on Larrabee, and next-gen graphics techs(parallel computing framework, raycasting, etc) Here’s my impression on these slides. Interactive Cinematic Lighting It’s a just review of previous works. There’s no impressive things. I know existing research has a serious drawback(to be solved in the future work), butContinue reading “Course notes on Beyond Programmable Shading”

Larrabee paper review

http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf 読みました. 結論. 性能は微妙. レイトレアクセラレータロジックはなしのよう. 開発は楽なのが唯一の救いか. Larrabee 構成概要 なんとも普通. そりゃ CPU メニーコアなので普通になりますね. gather/scatter VPU のインストラクションは L1 のアドレスをソースオペランドに取ることができる. 非連続アドレスからのロード(gather)と非連続アドレスへのストア(scatter)をサポートしている。 ただしキャッシュの速度に制限されるので、たとえばすべての要素が異なる場所を示していれば(データが L1 にキャッシュされているとして)最悪 16 サイクルはかかることになる。 ただし実際はそれなりにコヒーレンスがあるのでそれより少なくなるとのこと. 大域アドレス(仮想アドレス)に対する gather/scatter はできそうな記述ですが、atomic 操作とか考えるととても複雑になって実装が難しい気がしていますがどうでしょうか. ベクトル演算命令は masked 実行あり。まあこれは普通ですね。ベクトルデータの load/store 命令でもベクトル要素ごとに mask をかけることができて, mask された要素はアップデートされないようにすることができるよう.こちらはたしかにあると便利. GFLOPS コア数は可変みたいだけど、たぶん製品として最初に出てくるのを考えると 16 コアの構成あたりが妥当そうでしょうか. 16 cores、1GHz, madd が 1cycle でできるとして、  16(cores) * 16(vector width) * 1(GHz) * 2(madd)Continue reading “Larrabee paper review”

EGSR 2008 papers

(via private communication) http://kesen.huang.googlepages.com/egsr2008Papers.htm There are interesting papers this year! Especially, Shallow Bounding Volume Hierarchies for Fast SIMD Ray Tracing of Incoherent Rays Holger Dammertz, Johannes Hanika, Alexander Keller http://www.uni-ulm.de/in/mi/mitarbeiter/holger-dammertz.html QBVH They makes QBVH, quad-tree BVH which is applicable for SIMD processing. In QBVH it tests 4 bounding box simultaneously by SIMD, while traversal isContinue reading “EGSR 2008 papers”

Real-Time KD-Tree Construction on Graphics Hardware

Real-Time KD-Tree Construction on Graphics Hardware Kun Zhou; Qiming Hou; Rui Wang; Baining Guo http://research.microsoft.com/research/pubs/view.aspx? 0rc=p&type=technical+report&id=1468 My impression: TOO BAD! The comparison against CPU is not fair. And much worser, when analyzing the result the GPU implementation is 4-5 times inefficient than CPU. これはひどい. – レイトレのトラバーサルパフォーマンス Core2 CPU 4 core にたいして GF8800 Ultra で、差が良くて GPUContinue reading “Real-Time KD-Tree Construction on Graphics Hardware”

Filter Importance Sampling

Filter Importance Sampling M. Ernst, M. Stamminger, G. Greiner, RT06 http://doi.ieeecomputersociety.org/10.1109/RT.2006.280223 簡単な要約 レイトレでのピクセルサンプリングでは、 サンプル点の分布はリコンストラクションフィルタ(Mitchell とかね)の重みを考慮していない. そこで本手法では、リコンストラクションフィルタの分布からサンプル点を インポータンスサンプルで生成する手法を提案し、MC ノイズが 50% ほど減ることを示しています. # リコンストラクションフィルタの関数に従ってサンプル点を分布させるのは、 # なんか前からあったような気もしないでもないですが. 問題定義 通常のレンダリングでは、レイトレなどでサンプリングをした後、 そのサンプル群からリコンストラクションフィルタで各サンプルを重み付けして最終的なピクセル色を求めます. このとき、サンプルの値が大きくても、それに対応するリコンストラクションフィルタの重みが小さくて、 最終的なピクセル色へのサンプルの寄与が小さくなることがあります. たとえば論文では、となりあうピクセルで、強いライティングからのサンプルが、 一方のピクセルではフィルタ重みが小さいので寄与が小さく、 他方のピクセルではフィルタ重みが大きいので寄与が大きくなり、 結果として分散が大きくなってノイズとなることを例として取り上げています. (とくに 1 pixel あたりのサンプル数が 64 などと少ないとき) 提案されている解決方法 問題は、リコンストラクションフィルタの分布が考慮されていないためです. そこで本論文では、リコンストラクションフィルタの分布にしたがって サンプル点をインポータンスサンプリングして生成し、 重みはすべて同じ(=box filtering)とすることで、 このような現象に対処して既存手法より 50% のノイズ減少が可能であることを提案しています. リコンストラクションフィルタにしたがってサンプル位置を生成するので、 たとえばフィルタ幅がピクセル幅を越えている場合は、 ピクセルをはみでるサンプルもでてくることに注意します. 私的考察 手法としてはリコンストラクションフィルタにしたがってサンプル位置を分布させるだけなので、 実装は容易なほうでしょう. しかし、問題は、これはリコンストラクションも込みの関数からのインポータンスサンプリングなので、Continue reading “Filter Importance Sampling”

Recent advances on motion blur rendering

Last week, I’ve talked/discussed a lot with renderists over the world about the offline renderer. After the discussion, I think we’ve confirmed that there is still a lot of things to do in (global illumination) rendering. One of it is fast & efficient computation of motion blur, this still has not been solved fully inContinue reading “Recent advances on motion blur rendering”

Hardware-Aware Analysis and Optimization of Stable Fluids

Hardware-Aware Analysis and Optimization of Stable Fluids Theodore Kim I3D 2008. http://www.cs.unc.edu/~kim/I3D08/ (image from Hardware-Aware Analysis and Optimization of Stable Fluids) I like what they are doing in this paper, i.e., first estimate theoretical performance of computation and bandwidth of the algorithm, compares measured performance and theoretical peak to find bottleneck, then derive new techniqueContinue reading “Hardware-Aware Analysis and Optimization of Stable Fluids”